Check_MK
Checkmk ist eine in Python und C++ entwickelte Software für das Service-Monitoring von IT-Infrastruktur. Sie wird zur Überwachung von Server, Netzwerk, Applikationen, Public Clouds, Containern, Speicher, Datenbanken und Umweltsensoren genutzt.
- Check MK Editionen und Preise
- Installation
- Netzwerk Vorraussetzungen (Firewall)
- Installation auf Debian 11 Bullseye
- Installation auf Redhat / CentOS 8
- HTTPS aktivieren mit Selbsigniertem Zertifikat
- Einrichten Emailversand mit Postfix
- Einrichtung Email mit dem Nullmailer (Eine alternative zu Postfix)
- Einrichtung Email mit msmtp (nullmailer alternative auf CentOS)
- Einrichtung Email Adresse und Einrichtung Contact Group und testen der Notification
- Maximum Checkmk checkers anpassen
- API User Einrichten
- Check MK Plugins / Extensions - Exchange (mpk)
- Einrichtung der Infrastruktur
- Installation Agent für Betriebsysteme mit apt Packetmanager
- Installation Agent für Betriebsysteme mit rpm Packetmanager
- Installation Agent für andere Betriebsysteme ohne systemd / xinetd (Anbindung per ssh) tar.gz
- Installation Agent für Windows
- Anlegen von Hostgruppen und deren Verzeichnisse
- Anlegen von Hosts
- Agents am CheckMK Server registrieren
- Checks Schwellenwerte / Limits anpassen
- Benachrichtungen für bestimmte Checks deaktivieren
- Wartungszeiten - geplante Downtimes festlegen
- Discovery anpassen -> Netzwerkkarten ausschliessen
- Checks und wie Sie funktionieren
- Eigene Checks erstellen
- Eigene Check Bilbliothek
- Pushover - Notifications
- Plugins die explicit konfiguriert werden müssen
Check MK Editionen und Preise
Preise
Die Preise in einem Screenshot zusammengefast
Editionenvergleich
| Funktionen | Checkmk Raw | Checkmk Enterprise |
|---|---|---|
| Monitoring-Bereiche | ||
| 2.000+ qualitätsgesicherte Plugins | ||
| Agentenbasiertes Monitoring | ||
| Agentenloses Monitoring | ||
| Server-Monitoring | ||
| Netzwerk-Monitoring | ||
| Network Flow-Monitoring1 | ||
| Monitoring von Applikationen | ||
| Multi-Cloud-Monitoring | ||
| Container-Monitoring | ||
| Kubernetes-Monitoring | ||
| Datenbank-Monitoring | ||
| Storage-Monitoring | ||
| SNMP-Monitoring | ||
| Log- & Event-Monitoring | ||
| Hauptfunktionen | ||
| Intelligente und granulare Alarmierung | ||
| Monitoring von Geschäftsprozessen | ||
| Mächtige Suche und Filter | ||
| Tags & Labels | ||
| Hardware-/Software-Inventarisierung | ||
| Benutzerdefinierbare GUI | ||
| Granulares Benutzerrollen- und Berechtigungsmanagement. | ||
| Unbegrenzte Benutzerkonten | ||
| Verteiltes Monitoring | ||
| High Availability (HA)-Unterstützung2 | ||
| Virtuelle Appliance2 | ||
| Dashboards und Graphen | ||
| Anpassbare Echtzeit-Dashboards | ||
| Modernes Graphing | ||
| Effiziente Langzeit-Datenspeicherung | ||
| Anpassbare und kombinierbare Graphen | ||
| Übersichts-Dashboard | ||
| Host-Karten-Dashlet | ||
| Tacho-Dashlet | ||
| Einzelmetrik-Dashlet | ||
| Multimetrik-Dashlet | ||
| Balken-Dashlet | ||
| Serviceprobleme-Dashlet | ||
| Alarmstatistiken-Dashlet | ||
| Benachrichtigungszeitreihe | ||
| Fortgeschrittene Analytik | ||
| Prognosebasiertes Monitoring | ||
| Erweiterte Prognoseanalysen | ||
| Reporting | ||
| Verfügbarkeitsanalysen | ||
| PDF-Berichte | ||
| SLA-Monitoring | ||
| Automatisierung | ||
| Automatische Host-Erkennung | ||
| Automatische Service-Erkennung | ||
| REST API | ||
| Automatisiertes Monitoring von dynamischen, flüchtigen Infrastrukturen | ||
| Agentenmanagement und automatisierte Agenten-Updates | ||
| Automatisierter Alarm-Handler | ||
| Regelmäßige Wartungszeiten | ||
| Verwaltung von Erweiterungspaketen | ||
| Leistung | ||
| Monitoring-Kern | Nagios | Checkmk Microcore |
| Skalierbarkeit | 1,000+ hosts | 100,000+ hosts |
| CPU-Effizienz | mittel | sehr hoch |
| Kürzestes Monitoring-Intervall | 60s | 1s |
| Leistung des verteilten Monitorings | mittel | sehr hoch |
| Analyse der langfristigen Verfügbarkeit | langsam | sehr schnell |
| Integrationen | ||
| LDAP- und AD-Unterstützung | ||
| Slack und Mattermost | ||
| Opsgenie | ||
| VictorOps | ||
| PagerDuty | ||
| Cisco WebEx Teams | ||
| SIGNL4 Alerting | ||
| iLert | ||
| Prometheus | ||
| Prometheus für dynamische Infrastrukturen | ||
| Grafana | ||
| Jira | ||
| ServiceNow | ||
| ntop 1 (network flow monitoring) | ||
| i-doit3 | ||
| Security | ||
| Sichere Agenten by Design | ||
| Verschlüsselte Kommunikation | ||
| Passwort-Speicher | ||
| Managed-Services-Funktionalitäten | ||
| Verwaltung mehrerer Kunden5 | ||
| Kundenübergreifende Dashboards5 | ||
| Strikte Trennung von Kundendaten5 | ||
| Support | ||
| Support durch die Community | ||
| E-Mail-Support6 | ||
| Support-Portal6 | ||
| Verbindliche Reaktionszeit6 | ||
1) Erfordert das ntop Add-on
2) Erfordert ein Abonnement der virtuellen Appliance oder der physischen Checkmk-Appliance.
3) Erfordert das i-doit Add-on
4) Cloud- und Kubernetes-Monitoring sind auch in der Raw Edition mögloich, jedoch mit sehr viel mehr Aufwand als bei der Enterprise Edition, welche mittels der dynamischen Konfiguration Cloud- und Kubernetes-Objekte automatisch konfiguriert.
5) Erfordert die Managed Services Lizenz
6) Support-Pakete können zusätzlich zur Software-Subskription gekauft werden..
Installation
Netzwerk Vorraussetzungen (Firewall)
Beschreibung:
Der Server und die Agents kommunizieren über mehrere Ports. Diese müssen eingehend erreichbar sein
Firewall Ports
Überwachung von Hosts (Agent, SNMP)
Die folgenden Ports auf überwachten Hosts müssen vom Checkmk-Server aus erreichbar sein.
| Port | Protokoll | Bezeichnung | Ergänzende Informationen |
|---|---|---|---|
|
161 |
UDP |
Via SNMP überwachte Hosts erhalten über diesen Port die Anforderung |
|
|
6556 |
TCP |
Via Checkmk-Agent überwachte Hosts werden über diesen Port abgefragt. Die Kommunikation erfolgt TLS verschlüsselt oder im Klartext (wie beim Linux-Agenten im Legacy-Modus). |
|
|
— |
ICMP |
Ping |
Checkmk überwacht die Erreichbarkeit von Hosts per Ping. Ist dies nicht möglich, muss die Ermittlung des Host-Zustands mit der Regel Host Check Command festgelegt werden. |
Aktive Checks greifen direkt auf die Ports der überwachten Dienste zu, die daher auch vom Checkmk-Server aus erreichbar sein müssen. Die Überwachung mit Spezialagenten kann erfordern, andere/weitere Ports zu öffnen. So benötigt der Spezialagent für VMware ESXi (auch NetApp und viele weitere) die Öffnung des Ports 443 auf dem ESXi Server.
Checkmk-Server
Die folgenden Ports auf dem Checkmk-Server müssen für die Hosts im Monitoring erreichbar sein.
| Port | Protokoll | Bezeichnung | Ergänzende Informationen |
|---|---|---|---|
|
80 |
TCP |
Hypertext Transfer Protocol (HTTP) |
Agent Updater (Agentenbäckerei), Discovery des Agent Controller Ports |
|
162 |
UDP |
Simple Network Management Protocol Trap (SNMPTRAP) EC |
Empfang von SNMP-Traps über die Event Console (optional aktivierbar) |
|
443 |
TCP |
Hypertext Transfer Protocol over SSL/TLS (HTTPS) |
Agent Updater (Agentenbäckerei), Discovery des Agent Controller Ports, mit Transportverschlüsselung |
|
514 |
TCP und UDP |
Syslog (EC) |
Empfang von Syslog-Nachrichten über die Event Console (optional aktivierbar) |
|
6559 |
UDP |
Empfang von UDP-Paketen für die Echtzeitprüfungen einzelner Dienste (selten verwendet, optional aktivierbar) |
|
|
8000 |
TCP |
Agent Controller TLS-Registrierung |
Wenn mehrere Instanzen auf dem Checkmk-Server laufen, sind eventuell weitere Ports (8001, 8002…) nötig. |
Die TLS-Registrierung von Agenten nutzt die REST-API auf Port 80/443 zur Discovery des Ports zur Registrierung (meist 8000 TCP). Sind beide nicht erreichbar, kann der Port per Kommandozeilenoption angegeben werden. Falls Port 8000 nicht erreichbar ist, kann auf anderen Hosts im Monitoring eine Registrierung im Auftrag erfolgen.
Verteiltes Monitoring
Remoteinstanz
Die folgenden Ports auf Remote-Instanzen müssen vom als Zentralinstanz arbeitenden Checkmk-Server erreichbar sein.
| Port | Protokoll | Bezeichnung | Ergänzende Informationen |
|---|---|---|---|
|
80 |
TCP |
HTTPS (Hypertext Transfer Protocol) |
Synchronisierung im verteilten Monitoring |
|
443 |
TCP |
Hypertext Transfer Protocol over SSL/TLS (HTTPS) |
Synchronisierung im verteilten Monitoring, mit Transportverschlüsselung |
|
6555 |
TCP |
Benachrichtigungs-Spooler (notification spooler) |
Der Benachrichtigungs-Spooler dient dem zentralen Versand von Benachrichtigungen, hier beim Verbindungsaufbau durch die Zentralinstanz (optional aktivierbar) |
|
6557 |
TCP |
Wenn mehrere Instanzen auf dem Checkmk-Server laufen, sind eventuell weitere Ports nötig (optional aktivierbar) |
|
|
6558 |
TCP |
Statusanschluss der Event Console (optional aktivierbar) |
Zentralinstanz
Prinzipiell ist verteiltes Monitoring ohne weitere Hilfsmittel wie Tunneling bereits möglich, wenn die Zentralinstanz eine Verbindung zu den Remote-Instanzen herstellen kann. Die Erreichbarkeit der Zentralinstanz durch Remote-Instanzen ist nur für optionale Funktionalitäten (z.B. Agentenbäckerei) erforderlich.
Die folgenden Ports auf dem als Zentralinstanz arbeitenden Checkmk-Server müssen durch die zugeordneten Remote-Instanzen erreichbar sein, um die beschriebene Funktionalität bereitzustellen.
| Port | Protokoll | Bezeichnung | Ergänzende Informationen |
|---|---|---|---|
|
80 |
TCP |
Hypertext Transfer Protocol (HTTP) |
|
|
443 |
TCP |
Hypertext Transfer Protocol over SSL/TLS (HTTPS) |
Für Agentenbäckerei und dynamische Host-Konfiguration, mit Transportverschlüsselung |
|
6555 |
TCP |
Benachrichtigungs-Spooler (notification spooler) |
Der Benachrichtigungs-Spooler dient dem zentralen Versand von Benachrichtigungen, hier beim Verbindungsaufbau durch eine Remote-Instanz (optional aktivierbar) |
Checkmk Appliance Cluster
Sie können zwei Checkmk-Appliances ("Knoten") zu einem Cluster zusammenschließen. Dabei werden alle Konfigurationen und Daten zwischen den beiden Geräten abgeglichen.
Die folgenden Ports müssen von beiden Knoten aus ein- und ausgehend freigegeben sein.
| Port | Protokoll | Bezeichnung | Ergänzende Informationen |
|---|---|---|---|
|
3121 |
TCP |
Pacemaker |
Pacemaker Cluster resource manager |
|
4321 |
UDP |
Corosync |
Corosync Cluster Engine |
|
4323 |
UDP |
Corosync |
Corosync Cluster Engine |
|
7789 |
TCP |
DRBD |
Synchronisierung der DRDB (Distributed Replicated Block Device) |
Firewall Regeln (wenn eine Firewall Konfiguriert ist, hinzufügen, hier am Beispiel am CheckMK-Server nicht Agent)
FIrewalld
Installation:
#Install
yum install firewalld # für RHEL-basierte Systeme
apt-get install firewalld # für Debian-basierte Systeme
#Add Systemstart
systemctl start firewalld
systemctl enable firewalld
Folgende Regeln hinzufügen, falls die Firewall auch gerade erst installiert wurde habe Ich Port 22 (SSH) einfach mit zugepackt, weil sonst sind wir gleich ausgesperrt. Das Permanent bedeutet das auch nach einem neustart des Servers die Regeln wieder geldaen werden sollen
firewall-cmd --zone=public --add-port=8000/tcp --permanent
firewall-cmd --zone=public --add-port=6559/udp --permanent
firewall-cmd --zone=public --add-port=514/udp --permanent
firewall-cmd --zone=public --add-port=514/tcp --permanent
firewall-cmd --zone=public --add-port=162/udp --permanent
firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --zone=public --add-port=443/tcp --permanent
firewall-cmd --zone=public --add-port=22/tcp --permanent
Alle Regeln auflisten lassen
firewall-cmd --list-all
Output
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0 eth1
sources:
services: cockpit dhcpv6-client http https ssh
ports: 3000/tcp 8005/tcp 5665/tcp 8000/tcp 6559/udp 514/udp 514/tcp 162/udp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Nun ein relaod der Firewall durchführen
firewall-cmd --reload
ufw Firewall
Install.
#Install
apt-get install ufw # für Debian-basierte Systeme
yum install ufw # für RHEL-basierte Systeme
#Enable at Systemstart
ufw enable
Regeln hinzufügen
ufw allow 8000/tcp
ufw allow 6559/udp
ufw allow 514/udp
ufw allow 514/tcp
ufw allow 162/udp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 22/tcp
Installation auf Debian 11 Bullseye
1. Vorrausetzung ist ein Debian 11 mit ssh Zugang via Schlüsseldatei.
Auf dei Website https://checkmk.com/de
Und oben rechts auf Downloads.
Nun Checkmk für Linux auswählen -> Free / Enterprise -> Version 2.1 bzw die Aktuellste -> Debian -> Debian 11 -> geschäftlich
Emailadresse (Kann auch ne Fake Email sein, denn die Installationsanleitung kommt danach eingeblendet)
eintragen und auf Download & install drücken
Jetz werden die Befehle zur Installation angezeigt. Ich habe diese aber zum kopieren im nächsten Schritt angefügt
DIe Debdatei per WGET downloaden. Zur Zeitpunkt der erstellung des Artikels Version 2.1
wget https://download.checkmk.com/checkmk/2.1.0p16/check-mk-free-2.1.0p16_0.bullseye_amd64.deb
Nun das Paket installieren
apt install ./check-mk-free-2.1.0p16_0.bullseye_amd64.deb
Zum Schluss kommt ein Hinweis, da wir die installation ja schon als root ausgeführt haben.
Dies ist kein Fehler
Ausgabe...
N: Der Download wird als root und nicht Sandbox-geschützt durchgeführt,
da auf die Datei »/root/check-mk-free-2.1.0p16_0.bullseye_amd64.deb« durch den Benutzer
»_apt« nicht zugegriffen werden kann. - pkgAcquire::Run (13: Keine Berechtigung)
Überpüfen ob korrekt installiert wurde
omd version
Die Ausgabe sollte so aussehen
OMD - Open Monitoring Distribution Version 2.1.0p16.cfe
Nun eine Checkmk instanz erstellen. Eine Intenz wäre zum Beispiel Kunde oder ein Projekt.
Checkmk ist sogesehen Multi Mandant fähig.
Jede Instanz kann auch verschiedene Versionsnummern haben.
Z.b Eine Test umgegbung mit der schon Version 2 getestet wird und ne Prod die noch auf 1.6 läuft
Instanz erstellen
omd create <namederinstanz>
Beispiel
omd create monitoring
Hier bekommen wir den Hinweis, das wir zu wenig VCPUs haben.
Ist halt ne Testumgebeung. Gleichzeitig sehen wir hier das Kennwort für den Webadmin
Ausgabe:
Creating temporary filesystem /omd/sites/monitoring/tmp...OK
Updating core configuration...
Generating configuration for core (type cmc)...
WARNING: The number of configured checkers is higher than the number of available CPUs. To avoid unnecessary context switches, the number of checkers should be limited to the number of CPUs. Recommended number of checkers: 2
Starting full compilation for all hosts Creating global helper config...OK
Creating cmc protobuf configuration...OK
Executing post-create script "01_create-sample-config.py"...OK
Restarting Apache...OK
Created new site monitoring with version 2.1.0p16.cfe.
The site can be started with omd start monitoring.
The default web UI is available at http://checkmk/monitoring/
The admin user for the web applications is cmkadmin with password: **** wird natürlcih in klartext angezeigt ****
For command line administration of the site, log in with 'omd su monitoring'.
After logging in, you can change the password for cmkadmin with 'cmk-passwd cmkadmin'.
Damit wäre die Installation abgeschlossen.
Wie im oberen text zu sehen.
ist das Kennwort ändern übers Terminal jederzeit möglich.
omd su <instanzname>
dann
cmk-passwd <nuntername>
Beispiel :
omd su monitoring
cmk-passwd cmkadmin
Nun einloggen über IP/Domain Instanzname
Beispiel https://checkmk.io/monitoring
Installation auf Redhat / CentOS 8
1. Vorrausetzung ist ein Debian 11 mit ssh Zugang via Schlüsseldatei.
Auf dei Website https://checkmk.com/de
Und oben rechts auf Downloads.
Nun Checkmk für Linux auswählen -> Free / Enterprise -> Version 2.1 bzw die Aktuellste -> Red Hat /Centos -> red Hat / Alma Linux -> geschäftlich
Emailadresse (Kann auch ne Fake Email sein, denn die Installationsanleitung kommt danach eingeblendet)
eintragen und auf Download & install drücken
Jetz werden die Befehle zur Installation angezeigt. Ich habe diese aber zum kopieren im nächsten Schritt angefügt
DIe Debdatei per WGET downloaden. Zur Zeitpunkt der erstellung des Artikels Version 2.1
wget https://download.checkmk.com/checkmk/2.1.0p20/check-mk-free-2.1.0p20-el8-38.x86_64.rpm
Nun das Paket installieren
rpm --install ./check-mk-free-2.1.0p20-el8-38.x86_64.rpm
Wenn wir einen haufen depencies Fehler bekommen. Sind die Abbhängigkeiten noch nicht installiert
warning: ./check-mk-free-2.1.0p20-el9-38.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID c4503261: NOKEY
error: Failed dependencies:
dialog is needed by check-mk-free-2.1.0p20-el9-38.x86_64
freeradius-utils is needed by check-mk-free-2.1.0p20-el9-38.x86_64
graphviz-gd is needed by check-mk-free-2.1.0p20-el9-38.x86_64
libgsf is needed by check-mk-free-2.1.0p20-el9-38.x86_64
perl-IO-Zlib is needed by check-mk-free-2.1.0p20-el9-38.x86_64
perl-Locale-Maketext-Simple is needed by check-mk-free-2.1.0p20-el9-38.x86_64
perl-Net-Ping is needed by check-mk-free-2.1.0p20-el9-38.x86_64
poppler-utils is needed by check-mk-free-2.1.0p20-el9-38.x86_64
rpm-build is needed by check-mk-free-2.1.0p20-el9-38.x86_64
rsync is needed by check-mk-free-2.1.0p20-el9-38.x86_64
time is needed by check-mk-free-2.1.0p20-el9-38.x86_64
uuid is needed by check-mk-free-2.1.0p20-el9-38.x86_64
Nun mit dem Paketmanger dnf installieren, der installiert die Abbhängigkeiten gleich mit.
dnf install check-mk-free-2.1.0p20-el8-38.x86_64.rpm
Sollte da folgender Fehler kommen:
CentOS Linux 8 - AppStream 157 B/s | 38 B 00:00
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist
Cent OS 8, ist eigentlich End of Life. Nun die Repo austauschen um das Cent OS 8 zu aktualisieren.
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*
Nun den DNF Befehl nochmals ausführen und alle Abhängigkeiten werden mit installiert.
Ausgabe:
[root@catl02v406 ~]# dnf install check-mk-free-2.1.0p20-el8-38.x86_64.rpm
CentOS Linux 8 - AppStream 11 MB/s | 8.4 MB 00:00
CentOS Linux 8 - BaseOS 15 MB/s | 4.6 MB 00:00
CentOS Linux 8 - Extras 124 kB/s | 10 kB 00:00
CentOS Linux 8 - PowerTools 8.6 MB/s | 2.3 MB 00:00
ICINGA (stable release for epel) 61 kB/s | 2.9 kB 00:00
Extra Packages for Enterprise Linux Modular 8 - x86_64 53 kB/s | 30 kB 00:00
Extra Packages for Enterprise Linux Modular 8 - x86_64 1.1 MB/s | 733 kB 00:00
Extra Packages for Enterprise Linux 8 - x86_64 45 kB/s | 24 kB 00:00
Extra Packages for Enterprise Linux 8 - x86_64
....
Upgraded:
elfutils-libelf-0.185-1.el8.x86_64 elfutils-libs-0.185-1.el8.x86_64 graphviz-2.40.1-43.el8.x86_64 ima-evm-utils-1.3.2-12.el8.x86_64 openssl-1:1.1.1k-5.el8_5.x86_64 openssl-devel-1:1.1.1k-5.el8_5.x86_64
openssl-libs-1:1.1.1k-5.el8_5.x86_64 python3-rpm-4.14.3-19.el8.x86_64 rpm-4.14.3-19.el8.x86_64 rpm-build-libs-4.14.3-19.el8.x86_64 rpm-libs-4.14.3-19.el8.x86_64 rpm-plugin-selinux-4.14.3-19.el8.x86_64
rpm-plugin-systemd-inhibit-4.14.3-19.el8.x86_64
Installed:
bzip2-1.0.6-26.el8.x86_64 check-mk-free-2.1.0p20-el8-38.x86_64 dialog-1.3-13.20171209.el8.x86_64 elfutils-0.185-1.el8.x86_64
freeradius-3.0.20-10.module_el8.5.0+1057+66764497.x86_64 freeradius-utils-3.0.20-10.module_el8.5.0+1057+66764497.x86_64 gc-7.6.4-3.el8.x86_64 gdb-headless-8.2-16.el8.x86_64
graphviz-gd-2.40.1-43.el8.x86_64 guile-5:2.0.14-7.el8.x86_64 libatomic_ops-7.6.2-3.el8.x86_64 libbabeltrace-1.5.4-3.el8.x86_64
libgsf-1.14.41-5.el8.x86_64 libipt-1.6.1-8.el8.x86_64 nspr-4.32.0-1.el8_4.x86_64 nss-3.67.0-7.el8_5.x86_64
nss-softokn-3.67.0-7.el8_5.x86_64 nss-softokn-freebl-3.67.0-7.el8_5.x86_64 nss-sysinit-3.67.0-7.el8_5.x86_64 nss-util-3.67.0-7.el8_5.x86_64
patch-2.7.6-11.el8.x86_64 perl-DBI-1.641-3.module_el8.3.0+413+9be2aeb5.x86_64 perl-IO-Zlib-1:1.10-420.el8.noarch perl-Locale-Maketext-1.28-396.el8.noarch
perl-Locale-Maketext-Simple-1:0.21-420.el8.noarch perl-Math-BigInt-1:1.9998.11-7.el8.noarch perl-Math-Complex-1.59-420.el8.noarch perl-Net-Ping-2.55-420.el8.noarch
perl-Time-HiRes-4:1.9758-2.el8.x86_64 poppler-20.11.0-3.el8_5.1.x86_64 poppler-data-0.4.9-1.el8.noarch poppler-utils-20.11.0-3.el8_5.1.x86_64
rpm-build-4.14.3-19.el8.x86_64 rsync-3.1.3-12.el8.x86_64 time-1.9-3.el8.x86_64 tpm2-tss-2.3.2-4.el8.x86_64
uuid-1.6.2-43.el8.x86_64 xinetd-2:2.3.15-24.el8.x86_64 zstd-1.4.4-1.el8.x86_64
Complete!
Überpüfen ob korrekt installiert wurde
omd version
Die Ausgabe sollte so aussehen
OMD - Open Monitoring Distribution Version 2.1.0p16.cfe
Nun eine Checkmk instanz erstellen. Eine Intenz wäre zum Beispiel Kunde oder ein Projekt.
Checkmk ist sogesehen Multi Mandant fähig.
Jede Instanz kann auch verschiedene Versionsnummern haben.
Z.b Eine Test umgegbung mit der schon Version 2 getestet wird und ne Prod die noch auf 1.6 läuft
Instanz erstellen
omd create <namederinstanz>
Beispiel
omd create monitoring
Hier bekommen wir den Hinweis, das wir zu wenig VCPUs haben.
Ist halt ne Testumgebeung. Gleichzeitig sehen wir hier das Kennwort für den Webadmin
Ausgabe:
Creating temporary filesystem /omd/sites/monitoring/tmp...OK
Updating core configuration...
Generating configuration for core (type cmc)...
WARNING: The number of configured checkers is higher than the number of available CPUs. To avoid unnecessary context switches, the number of checkers should be limited to the number of CPUs. Recommended number of checkers: 2
Starting full compilation for all hosts Creating global helper config...OK
Creating cmc protobuf configuration...OK
Executing post-create script "01_create-sample-config.py"...OK
Restarting Apache...OK
Created new site monitoring with version 2.1.0p16.cfe.
The site can be started with omd start monitoring.
The default web UI is available at http://checkmk/monitoring/
The admin user for the web applications is cmkadmin with password: **** wird natürlcih in klartext angezeigt ****
For command line administration of the site, log in with 'omd su monitoring'.
After logging in, you can change the password for cmkadmin with 'cmk-passwd cmkadmin'.
Damit wäre die Installation abgeschlossen.
Wie im oberen text zu sehen.
ist das Kennwort ändern übers Terminal jederzeit möglich.
omd su <instanzname>
dann
cmk-passwd <nuntername>
Beispiel :
omd su monitoring
cmk-passwd cmkadmin
Nun einloggen über IP/Domain Instanzname
Beispiel https://checkmk.io/monitoring
HTTPS aktivieren mit Selbsigniertem Zertifikat
Da http Verbindungen auch im Internen LAN mitgeschnitten werden können, HTTPS einrichten.
Dazu ein reciht uns ein selbstsigniertes Zertifikat.
Hauptsache, verschlüsselt
Zertifikat anlegen, dazu erstellen wir uns ein neues Verzeichnis
mkdir -p /etc/apache2/ssl
Nun den Privaten Schlüssel erstellen
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.pem -out /etc/apache2/ssl/apache.pem
Unser Beispiel mit höherer sicherheit und 100 Jhre gültigkeit
openssl req -x509 -nodes -days 36500 -newkey rsa:4096 -keyout /etc/apache2/ssl/apache.pem -out /etc/apache2/ssl/apache.pem
Nun die Zertifikatsfragen beantworten.
Bei common Name habe ich checkmk.local.lan eingegeben, da eh lokal
enerating a RSA private key
............................................++++
.....................................++++
writing new private key to '/etc/apache2/ssl/apache.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:checkmk.local.lan
Email Address []:
Beschreibung zu oberen Parameters
| – SSL/TLS-Zertifikat Typ X.509, dient zur Authentifizierung und Verifizierung der Identität eines Hosts oder einer Website (.pem) – RSA-Key mit 2048 Bit, bietet eine sichere Verschlüsselung von Daten (Wir testen mal 4096 – days gibt die Gültigkeitsdauer des Zertifikats in Tagen an (Wir enehmen 100 Jahre = 36500 Tage) – keyout / -out, legt den Speicherpfad des neu generierten privaten Keys und des Zertifikates fest |
Neues Zertifikat verlinken
ln -sf /etc/apache2/ssl/apache.pem /etc/apache2/ssl/`/usr/bin/openssl x509 -noout -hash < /etc/apache2/ssl/apache.pem`.0
Nun haben wir eine Verlinkung des Zertifikat mit Hashnummer
ls /etc/apache2/ssl/
17691c22.0 apache.pem
rechte des Zertifikates anpassen
chmod 600 /etc/apache2/ssl/apache.pem
Überprüfen ob in den Ports die Eintrage für 443 vorhanden sind
cat /etc/apache2/ports.conf
So sollte es aussehen
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Apache Server neu starten, a2enable ssl und neustarten des apache2
service apache2 reload
a2enmod ssl
service apache2 restart
Eine neue config datei erstellen
nano /etc/apache2/sites-available/ssl.conf
Inhalt
<virtualhost *:443>
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem
DocumentRoot /var/www/html
</virtualhost>
Nun die Site aktivieren und apache neustarten
a2ensite ssl.conf
service apache2 restart
Nun ist die Website per https erreichbar.
Allerings fehlt noch ein redirekt auf https wenn http eingebeben wird
Dazu die /etc/apache2/sites-enabled/000-default.conf editieren
nano /etc/apache2/sites-enabled/000-default.conf
Und folgendes hinzufügen über Serveradmin
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [L]
Nun speichern und apach2 neustarten
service apache2 restart
Einrichten Emailversand mit Postfix
Damit auch Emailbenachrichtungen raus gehen, richten wir uns einen Postfix SMTP Server ein.
Abhängigkeiten installieren
apt-get install -y postfix bsd-mailx
NunInternet Site auswählen
Email Name ausfüllen: checkmk.local.lan
Nun den Emailempfänger für root eingeben.
weitere zeile, einfach so lassen
bei Synchrone Aktualiseirungen... Nein auswählen
Postfachgröße 0 einfach weiter klicken
Zeichen für Adresserweiterung
Alle auswählen
nun die Postfix datei /etc/postfix/main.cf öffnen
nano /etc/postfix/main.cf
Inhalt unter smtp_tls session diese 3 Zeilen einfügen
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
Nun noch den relyhost anpassen. Bei mir ist es rs001871.fastrootserver.de
Nun die Password File anlegen
nano /etc/postfix/sasl_passwd
Inhalt, SMTP Host, Benutzername, Kennwort
[rs001871.fastrootserver.de]:587 monitoring@star-module.com *****
Nun die Password File eine Postmap draus machen
postmap /etc/postfix/sasl_passwd
Nun den Postfix-Server neustarten
service postfix restart
Testemail senden
echo "Dies ist eine Test E-Mail vom checkmk-Server" | mailx -s "Test" <ihre_notification_e-mail-adresse@gmail.com>
in der /var/log/mail.log kann man das ergebnis sehen.
hier ein Fehler beispiel, bei der Authentifizierung. Ganz am ende steht authetication failed. So weiß man, okay Kennwort falsch.
Nov 29 11:38:45 checkmk postfix/postfix-script[26039]: starting the Postfix mail system
Nov 29 11:38:45 checkmk postfix/master[26041]: daemon started -- version 3.5.13, configuration /etc/postfix
Nov 29 11:40:53 checkmk postfix/postfix-script[26644]: stopping the Postfix mail system
Nov 29 11:40:53 checkmk postfix/master[26041]: terminating on signal 15
Nov 29 11:40:54 checkmk postfix/postfix-script[27198]: starting the Postfix mail system
Nov 29 11:40:54 checkmk postfix/master[27200]: daemon started -- version 3.5.13, configuration /etc/postfix
Nov 29 11:41:10 checkmk postfix/pickup[27201]: A9F0D2075B: uid=0 from=<root>
Nov 29 11:41:10 checkmk postfix/cleanup[27249]: A9F0D2075B: message-id=<20221129104110.A9F0D2075B@checkmk.local.lan>
Nov 29 11:41:10 checkmk postfix/qmgr[27202]: A9F0D2075B: from=<root@checkmk.local.lan>, size=440, nrcpt=1 (queue active)
Nov 29 11:41:10 checkmk postfix/smtp[27251]: A9F0D2075B: to=<bonkersdeluxe@gmail.com>, relay=rs001871.fastrootserver.de[213.202.247.147]:25, delay=0.24, delays=0.02/0.02/0.21/0, dsn=4.7.8, status=deferred (SASL authentication failed; server rs001871.fastrootserver.de[213.202.247.147] said: 535 5.7.8 Error: authentication failed: authentication failure)
So sähe ein erfolgreicher Versand aus
Jan 20 10:22:03 checkmk postfix/pickup[603605]: 317CB20BB6: uid=0 from=<root>
Jan 20 10:22:03 checkmk postfix/cleanup[606550]: 317CB20BB6: message-id=<20230120092203.317CB20BB6@checkmk.local.lan>
Jan 20 10:22:03 checkmk postfix/qmgr[1102]: 317CB20BB6: from=<root@checkmk.local.lan>, size=443, nrcpt=1 (queue active)
Jan 20 10:22:03 checkmk postfix/smtp[606552]: 317CB20BB6: to=<monitoring@star-module.com>, relay=rs001871.fastrootserver.de[213.202.247.147]:25, delay=0.36, delays=0.02/0.01/0.19/0.14, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 65D0A18806E2)
Jan 20 10:22:03 checkmk postfix/qmgr[1102]: 317CB20BB6: removed
Einrichtung Email mit dem Nullmailer (Eine alternative zu Postfix)
Beschreibung
Der Nullmailer ist ein einfaches SMTP-Forwarding-System, das Sie verwenden können, um Benachrichtigungen aus Checkmk an Ihre E-Mail-Adresse weiterzuleiten. Hier sind die Schritte, wie Sie den Nullmailer in Checkmk einrichten.
Installation
-
Installieren Sie Nullmailer auf dem System, auf dem Checkmk installiert ist. Je nach Ihrem Betriebssystem finden Sie hier Anweisungen zur Installation:
- Debian/Ubuntu:
sudo apt-get install nullmailer mailutils - Red Hat/CentOS:
sudo yum install nullmailer - SUSE:
sudo zypper install nullmailer Sollte auf Ihrem System ein Konfigurationsassistent kommen, den Hostnamen kann man so lassen. Und im zweiten Feld den Server und den Benutzer, Verschlüsselung, Kennwort und weiter benötigte Parameter eintragen. Am Ende des Artikels gibts noch Beispiele für verschiedene SMTP Server Beispiele.
- Debian/Ubuntu:
- Konfigurieren Sie Nullmailer, indem Sie einen gültigen SMTP-Server angeben. Dies können Sie in der Datei
/etc/nullmailer/remotestun. Wenn auf Ihrem System der Assistent bei Installtion des Pakets schon aufgerufen wurde, kann dieser Teil übersprungen werden.
Hier ist ein Beispiel:
smtp.example.com smtp --port=587 --starttls --user=username --pass=password - Überprüfen Sie, ob Nullmailer korrekt funktioniert, indem Sie eine Test-E-Mail senden:
echo "Dies ist eine Test-E-Mail." | mail -s "Test-E-Mail" recipient@example.com - Wenn alles ordnungsgemäß eingerichtet ist, sollte die Test-E-Mail an Ihre E-Mail-Adresse gesendet werden. Von nun an sollte Checkmk Benachrichtigungen über Nullmailer an die angegebene E-Mail-Adresse senden.
Beispiele für die Verwendung von Parametern in der /etc/nullmailer/remotes
SMTP-Server ohne Authentifizierung:
smtp.example.com smtp --port=25
SMTP-Server mit Authentifizierung (Base64-verschlüsselt):
smtp.example.com smtp --port=587 --user=username --pass=password
SMTP-Server mit Authentifizierung und SSL/TLS (Port 465):
smtp.example.com smtp --port=465 --ssl --user=username --pass=password
SMTP-Server mit Authentifizierung und STARTTLS (Port 587):
smtp.example.com smtp --port=587 --starttls --user=username --pass=password
Bitte beachten Sie, dass Sie für Ihre spezifische SMTP-Konfiguration möglicherweise weitere Optionen oder abweichende Portnummern verwenden müssen. Vergewissern Sie sich daher, dass Sie die richtigen Informationen von Ihrem E-Mail-Provider oder Systemadministrator erhalten, bevor Sie die /etc/nullmailer/remotes-Datei bearbeiten.
Der "auth login"-Parameter
in der /etc/nullmailer/remotes-Datei wird verwendet, um den SMTP-Authentifizierungstyp anzugeben, der beim Verbinden mit dem SMTP-Server verwendet werden soll.
Wenn der SMTP-Server die "SMTP AUTH LOGIN"-Authentifizierung unterstützt, können Sie den "auth login"-Parameter wie folgt verwenden:
smtp.example.com smtp --port=587 --auth-login --user=username --pass=password
Mit dem "auth login"-Parameter wird angegeben, dass die Authentifizierung über die "SMTP AUTH LOGIN"-Methode durchgeführt werden soll, bei der Benutzername und Passwort in Base64-verschlüsselter Form übertragen werden.
Bitte beachten Sie, dass nicht alle SMTP-Server die "SMTP AUTH LOGIN"-Authentifizierung unterstützen. Stattdessen können Sie andere Authentifizierungsmethoden wie "SMTP AUTH PLAIN" oder "SMTP AUTH CRAM-MD5" verwenden, aber das hängt von Ihrem SMTP-Provider ab. Es ist daher wichtig, die richtigen Informationen von Ihrem E-Mail-Provider oder Systemadministrator zu erhalten, bevor Sie die /etc/nullmailer/remotes-Datei bearbeiten.
Fehlersuche
Wenn das Versenden einer Email nicht funktioniert, können Sie in der /var/mail.log nachschauen.
Nullmailer legt die Logdatei dort rein.
Ein Fehlerbeispiel:
cat /var/log/mail.log
Feb 9 11:22:40 checkmk nullmailer-send[20616]: Rescanning queue.
Feb 9 11:24:02 checkmk nullmailer-send[20616]: Trigger pulled.
Feb 9 11:24:02 checkmk nullmailer-send[20616]: Rescanning queue.
Feb 9 11:24:02 checkmk nullmailer-send[20616]: Starting delivery, 1 message(s) in queue.
Feb 9 11:24:02 checkmk nullmailer-send[20616]: Starting delivery: host: meinedomain.de protocol: smtp file: 1675938242.21098
Feb 9 11:24:02 checkmk nullmailer-send[20616]: From: <root@checkmk.local.lan> to: <dest@gmail.com>
Feb 9 11:24:02 checkmk nullmailer-send[20616]: Message-Id: <1675938242.567604.21097.nullmailer@checkmk.local.lan>
Feb 9 11:24:02 checkmk nullmailer-send[21099]: smtp: Failed: Server SSL/TLS certificate does not match hostname
Feb 9 11:24:02 checkmk nullmailer-send[20616]: Sending failed: Temporary error in sending the message
Feb 9 11:24:02 checkmk nullmailer-send[20616]: Delivery complete, 1 message(s) remain.
Feb 9 11:25:02 checkmk nullmailer-send[20616]: Rescanning queue.
Feb 9 11:25:02 checkmk nullmailer-send[20616]: Starting delivery, 1 message(s) in queue.
Feb 9 11:25:02 checkmk nullmailer-send[20616]: Starting delivery: host: meinedomain.de protocol: smtp file: 1675938242.21098
Feb 9 11:25:02 checkmk nullmailer-send[20616]: From: <root@checkmk.local.lan> to: <dest@gmail.com>
Feb 9 11:25:02 checkmk nullmailer-send[20616]: Message-Id: <1675938242.567604.21097.nullmailer@checkmk.local.lan>
Feb 9 11:25:02 checkmk nullmailer-send[21137]: smtp: Failed: Server SSL/TLS certificate does not match hostname
Feb 9 11:25:02 checkmk nullmailer-send[20616]: Sending failed: Temporary error in sending the message
Feb 9 11:25:02 checkmk nullmailer-send[20616]: Delivery complete, 1 message(s) remain.
Feb 9 11:27:03 checkmk nullmailer-send[20616]: Rescanning queue.
Feb 9 11:27:03 checkmk nullmailer-send[20616]: Starting delivery, 1 message(s) in queue.
Feb 9 11:27:03 checkmk nullmailer-send[20616]: Starting delivery: host: meinedomain.de protocol: smtp file: 1675938242.21098
Feb 9 11:27:03 checkmk nullmailer-send[20616]: From: <root@checkmk.local.lan> to: <dest@gmail.com>
Feb 9 11:27:03 checkmk nullmailer-send[20616]: Message-Id: <1675938242.567604.21097.nullmailer@checkmk.local.lan>
Feb 9 11:27:03 checkmk nullmailer-send[21197]: smtp: Failed: Server SSL/TLS certificate does not match hostname
Feb 9 11:27:03 checkmk nullmailer-send[20616]: Sending failed: Temporary error in sending the message
Feb 9 11:27:03 checkmk nullmailer-send[20616]: Delivery complete, 1 message(s) remain.
Feb 9 11:31:03 checkmk nullmailer-send[20616]: Rescanning queue.
Feb 9 11:31:03 checkmk nullmailer-send[20616]: Starting delivery, 1 message(s) in queue.
Feb 9 11:31:03 checkmk nullmailer-send[20616]: Starting delivery: host: meinedomain.de protocol: smtp file: 1675938242.21098
Feb 9 11:31:03 checkmk nullmailer-send[20616]: From: <root@checkmk.local.lan> to: <dest@gmail.com>
Feb 9 11:31:03 checkmk nullmailer-send[20616]: Message-Id: <1675938242.567604.21097.nullmailer@checkmk.local.lan>
Feb 9 11:31:03 checkmk nullmailer-send[21328]: smtp: Failed: Server SSL/TLS certificate does not match hostname
Feb 9 11:31:03 checkmk nullmailer-send[20616]: Sending failed: Temporary error in sending the message
Feb 9 11:31:03 checkmk nullmailer-send[20616]: Delivery complete, 1 message(s) remain.
Was ist hier passiert. Der Domainname passt nicht zum Zertifikat. Warum. Wir haben als SMTP-Server
meinedomain.de angeben. Auf eminedomain.de lauscht zwar der smtp Server.
Aber das Zertifikat ist auf mail.meinedomaine.de ausgestellt.
Also muss in der remotesdatei als smtpserver mail.meinedomain.de angeben werden.
Und schon klappt der Versand.
Die Änderungen in der remotes Datei sind sofort wirksam, da nullmailer diese beim senden immer wieder neu einliest.
Also kein Dienst muss neugestartet werden.
Logauzug (Hier sind jetzt zwei Nachrichten drin, weil wir noch eine Email versendet haben) :
Starting delivery, 2 message(s) in queue.
Feb 9 11:42:39 checkmk nullmailer-send[20616]: Starting delivery: host: mail.mainedomain.de protocol: smtp file: 1675938242.21098
Feb 9 11:42:39 checkmk nullmailer-send[20616]: From: <root@checkmk.local.lan> to: <dest@gmail.com>
Feb 9 11:42:39 checkmk nullmailer-send[20616]: Message-Id: <1675938242.567604.21097.nullmailer@checkmk.local.lan>
Feb 9 11:42:40 checkmk nullmailer-send[21760]: smtp: Succeeded: 250 2.0.0 Ok: queued as 016091881A7C
Feb 9 11:42:40 checkmk nullmailer-send[20616]: Sent file.
Feb 9 11:42:40 checkmk nullmailer-send[20616]: Starting delivery: host: mail.meinedomain.de protocol: smtp file: 1675939359.21759
Feb 9 11:42:40 checkmk nullmailer-send[20616]: From: <root@checkmk.local.lan> to: <dest@gmail.com>
Feb 9 11:42:40 checkmk nullmailer-send[20616]: Message-Id: <1675939359.525504.21758.nullmailer@checkmk.local.lan>
Feb 9 11:42:40 checkmk nullmailer-send[21761]: smtp: Succeeded: 250 2.0.0 Ok: queued as 465411881AAF
Feb 9 11:42:40 checkmk nullmailer-send[20616]: Sent file.
Feb 9 11:42:40 checkmk nullmailer-send[20616]: Delivery complete, 0 message(s) remain.
Zustellung Erfolgreich.
Einrichtung Email mit msmtp (nullmailer alternative auf CentOS)
Beschreibung
msmtp ist ein MTA für deinen reinen Versand über sendmail.
Nullmailer ist auf Debian Systemen verfügbar, allerdings nicht auf CentOS.
Somit machen wir hier von msmtp gebrauch, da es auch in den Paketmanager dnf Verfügbar ist.
Installation
Einloggen auf dem system und den Befehl
dnf install msmtp
Ausgabe, Frage mit y beantworten:
Dependencies resolved.
================================================================================
Package Architecture Version Repository Size
================================================================================
Installing:
msmtp x86_64 1.8.10-1.el8 epel 181 k
Installing dependencies:
libgsasl x86_64 1.8.0-8.el8 epel 137 k
libntlm x86_64 1.6-1.el8 epel 99 k
Transaction Summary
================================================================================
Install 3 Packages
Total download size: 417 k
Installed size: 1.3 M
Is this ok [y/N]:
Ausgabe:
Downloading Packages:
(1/3): libntlm-1.6-1.el8.x86_64.rpm 876 kB/s | 99 kB 00:00
(2/3): libgsasl-1.8.0-8.el8.x86_64.rpm 1.1 MB/s | 137 kB 00:00
(3/3): msmtp-1.8.10-1.el8.x86_64.rpm 1.2 MB/s | 181 kB 00:00
--------------------------------------------------------------------------------
Total 408 kB/s | 417 kB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : libntlm-1.6-1.el8.x86_64 1/3
Installing : libgsasl-1.8.0-8.el8.x86_64 2/3
Running scriptlet: libgsasl-1.8.0-8.el8.x86_64 2/3
Installing : msmtp-1.8.10-1.el8.x86_64 3/3
Running scriptlet: msmtp-1.8.10-1.el8.x86_64 3/3
Verifying : libgsasl-1.8.0-8.el8.x86_64 1/3
Verifying : libntlm-1.6-1.el8.x86_64 2/3
Verifying : msmtp-1.8.10-1.el8.x86_64 3/3
Installed:
libgsasl-1.8.0-8.el8.x86_64 libntlm-1.6-1.el8.x86_64
msmtp-1.8.10-1.el8.x86_64
Complete!
Konfiguration
Für eine Systemweite Konfiguration legen wir eine Konfig Datei in /etc/msmtprc an.
nano /etc/msmtprc
Über diese Konfiguration kann aber nur root senden.
Möchte man aber weiteren Benutzern gestatten Emails zu senden, dann muss eine Konfigurationsdatei im Home-Verzeichnis des Benutzers angelegt werden.
nano ~/.msmtprc
Inhaltlich sind die Konfigurationsdateien, System und Benutzer gleich.
Für unsere Konfig loggen wir uns in unsere Checkmk instanz ein.
omd su catmonitoring
Nun eine beispielkonfig für eine Emailadresse ohne Auth. Aber es kann ganz einfach angeschaltet werden.
Es ist mit Dokumentiert
# Standardwerte für alle Konten setzen
defaults
# SMTP-Port auf 25, 465 oder 587 setzen
port 587
# Immer TLS aktivieren
tls on
#Pfad zur Logfile
logfile /var/log/msmtp.log
# Mail-Konto Name, hier als Liste angegeben
# Endet mit Passwort, und bei einem neuen Eintrag mit Konto-Name
# handelt es sich um ein zweites E-Mail-Konto
account user@email.de
# Hostname oder IP des SMTP-Servers
host <ip_oder_hostname>
# From-Header setzen (wichtig für 1&1, GMX, web.de usw.)
# Mögliche Werte: on oder off
set_from_header on
# Absender-Adresse
from user@email.de
# Authentifizierung nutzen (on oder off)
auth off
# Authentifizierungs-Benutzername, ignorieren, wenn auth off
user user@email.de
# Passwort für das Konto, ignorieren, wenn auth off
password wirhabenkeins
# Standardkonto festlegen
account default: user@email.de
# Lokale Benutzer auf Mail-Adressen mappen
aliases /etc/aliases
Speichern und die Rechte der Datei anpassen.
chmod 600 .msmtprc
Logfile erstellen
touch /var/log/msmtp.log
chmod 666 /var/log/msmtp.log
Sendmailprogram festelegen. Dazu das original sendmail eine Backupkopie speichern.
mv /usr/sbin/sendmail /usr/sbin/sendmail.original
Nun den alias auf sendmail erstellen
ln -s /usr/bin/msmtp /usr/sbin/sendmail
Soll das normale Mail Programm auch umgestellt werden dann die datei .mailrc im Homeverzeichnis bearbeiten
set sendmail="/usr/bin/msmtp"
set message-sendmail-extra-arguments="-a default"
Testen
echo "Testtext" | mail -S msmtp -s "Betreff" empfaenger@zieldomain.de
In der Log nachschauen ob geklappt
Einrichtung Email Adresse und Einrichtung Contact Group und testen der Notification
Login in CheckMK
Dann unter Setup -> Users gehen
Dann bei den Benutzer(n) die Emailadresse hinterlegen und auf speichern klicken
Nun die Änderungs wirksam werden lassen, oben rechts auf change klicken
Nun die Änderungen aktivieren
Wenn nicht schon vorhanden eine neue Gruppe anlegen. Dazu gehen wir unter Setup-> Contact Groups.
Hier legen wir wenn nicht schon vorhanden die Gruppe all an, indem wir auf add klciken.
Nun vergeben wir den namen all, als Alias Everthing und unten whole tree auswählen, dann auf speichern klicken
Nun wieder die Änderungen aktivieren
Nun die Änderungen aktivieren
Wenn wir zur Liste zurück gehen sieht das ganze dann so aus
Nun müssen wir nur noch unseren Benutzer der Contactgruppe hinzufügen. Dazu wieder
Setup -> Users
Den Benutzer bearbeiten und ganz unter unter Contact Group, die Gruppe auswählen
Nun wieder speichern und die Änderungen aktivieren.
Nun die Änderungen aktivieren
Fertig, nun werden die Meldungen von checkmk an alle Benutzer gesendet die eine Emailadresse hinterlegt haben und in der gruppe Everything sind.
Um zu Testen ob die Notifcation funktioniert, obwohl gar kein Fehler/Warnung vorliegt können wir mit folgenden Schritten tun.
Melden Sie sich auf der Webseite Checkmk-System
Klicken Sie nun auf Service OK in der Übersicht
Nun auf irgendeinen Service klicken hier CheckMK
Nun oben im Menü auf Command und dann Custom Notification anklicken.
Nun die Nachricht eingeben und auf Send klicken
Senden bestätigen, fertig
Maximum Checkmk checkers anpassen
.AufSetup -> Global settings klicken
Dann auf Maximum concurrent Checkmk checkers klicken
Und den wert auf die ANzahl vorhandener CPU - 1 setzen.
Beispiel 4 Cores - 1. Den Wert 3 setzen
Auf change open rechts klicken
Auf activiate on selected sites klicken
Fertig
API User Einrichten
Unter Users das API Kennwort für den Benutzer automation ändern bzw. festlegen.
Dazu unter Setup -> Users
Dann in der Liste auf den Stift beim Benutzer automation klicken.
Nun ein neues secret generieren. Dazu auf den grünen würfel klicken. Dann wird das neue Kennwort im Textfeld angezeigt.
Dieses rauskopieren und abspeichern in einem Passwordsafe zum beispiel. Dieses wird für die Agents gebraucht.
Dazu aber später.
Nun auf Save klicken
Und die changes übernehmen
Und auf activate on selected site klicken
Erledigt
Check MK Plugins / Extensions - Exchange (mpk)
Packages downloaden und installieren
Es gibt im Checkmk Exchange verschiedene Plugins / Extensions die man nutzen kann.
Suchbegriff eingeben und nun sehen wir links openvpn clients, dort drauf klicken
und dann auf herunterladen klicken.
Nun befindet sich die Datei im Downloadordner.
mpk können auf zwei Arten installiert werden:
- Über die GUI (Nur Enterprise Edition)
- Übers Terminal
Installations übers Terminal bzw. MKP auf dem Terminal:
Installation eines Packages, dazu die downgeloade mkp per scp z.b ins /tmp Verzeichnis auf den checkmk server übertragen
oder den link von cer exchange Seite kopieren und per wget auf den server ins /tmp Verzeichnis holen.
Wie beliebt.
ich machs per wget
cd /tmp
wget https://exchange.checkmk.com/packages/openvpn-clients/897/openvpn_clients-0.4.mkp
Ausgabe:
Wird in »openvpn_clients-0.4.mkp« gespeichert.
openvpn_clients-0.4.mkp 100%[=========================================================================================================================================>] 3,80K --.-KB/s in 0s
2022-11-21 19:10:45 (212 MB/s) - »openvpn_clients-0.4.mkp« gespeichert [3893/3893]
Nun liegt unser Package im /tmp Verzeichnis mit dem Namen
openvpn_clients-0.4.mkp
Nun in die OMD instaz wo das Plugin installiert werden soll einloggen:
omd su <instanzname>
beispiel : omd su monitoring
Programmhilfe, der befehl lautet mkp ohne Parameter :
OMD[mysite]:~$ mkp
Usage: check_mk [-v] -P|--package COMMAND [ARGS]
Available commands are:
create NAME ... Collect unpackaged files into new package NAME
pack NAME ... Create package file from installed package
release NAME ... Drop installed package NAME, release packaged files
find ... Find and display unpackaged files
list ... List all installed packages
list NAME ... List files of installed package
list PACK.mkp ... List files of uninstalled package file
show NAME ... Show information about installed package
show PACK.mkp ... Show information about uninstalled package file
install PACK.mkp ... Install or update package from file PACK.mkp
remove NAME ... Uninstall package NAME
-v enables verbose output
Package files are located in /omd/sites/mysite/var/check_mk/packages/.
mittel mkp und Parameter install, können wir das Package installieren
mkp install /tmp/openvpn_clients-0.4.mkp
Wenn alles glatt gelaufen ist bleibt die Ausgabe leer.
root@checkmk:/tmp# omd su monitoring
OMD[monitoring]:~$ mkp install /tmp/openvpn_clients-0.4.mkp
OMD[monitoring]:~$
Überpüfen ob das Package installiert wurde
OMD[monitoring]:~$ mkp list
Ausgabe:
openvpn_clients
OMD[monitoring]:~$
Packages installieren über die GUI
im Checkmk einloggen dann auf
Setup -> un den Button show more anklicken
Nun wird die Liste voller, dann auf Maintenance und Extension Packages
Nun dort auf Upload package, über die Extension Seite kann übringes auch der Exchange markt aufgerufen werden.
Jetzt gibst nochmal den Hinweis das man Pakete nur aus vertrauenswürdigen Quellen hochladen sollte.
Also am besten immer nur Plugins ausm Exchange Markt neben weil die werden von tribe29 überpüft.
Nun über den durchsuchen button die mpk aus dem Doenload Ordner wählen
Nun ist die Datei im durchsuchen Button.
jetzt kann auf Upload geklickt werden
Nun ist das Paket unten in der Liste.
Rechts oben auf change klicken
Und wieder aktivieren
Nun zurück wieder unter Maintenance -> Extension Packages
Bei der Extension die wie aktivieren wollen auf den Stecker klicken
Nun steht es oben in der Liste und wieder die changes bestätigen
Fertig installiert
Packages entfernen
Übers Terminal
Übers Terminal wieder in die OMD einloggen.
Mit dem Befehl mkp list den Package namen auflisten lassen, den man entfernen möchte. Diesen merken oder kopieren
MD[monitoring]:~$ mkp list
openvpn_clients
Nun mit folgendem befehl das Package wieder entfernen, wird nix zurücggeben, war es erfolgreich.
OMD[monitoring]:~$ mkp disable openvpn_clients
Packages auflisten lassen.
Wenn es das einzige war, ist die Liste leer ansonsten ist nur unser Package aus der Liste verschwunden.
Nun noch übrig gebliebene Dateien wegräumen.
unter
/omd/sites/<instanzname>/local/lib/check_mk/base/plugins/agent_based/
/omd/sites/monitoring/local/share/check_mk/checks/
/omd/sites/monitoring/local/share/check_mk/agents/plugins/
/omd/sites/monitoring/local/share/check_mk/web/plugins/wato/
/omd/sites/monitoring/local/lib/check_mk/base/cee/plugins/bakery/
liegen eventuell noch reste von packages, die gelöscht werden müssen.
Bei den openvpn_clienst plugins sind es die
openvpn_clients.py
openvpn_clients
openvpn_clients_cee.py
in den jeweiligen Verzeichnissen
Diese einfach löschen
rm /omd/sites/monitoring/local/lib/check_mk/base/plugins/agent_based/openvpn_clients.py
rm /omd/sites/monitoring/local/share/check_mk/checks/openvpn_clients
rm /omd/sites/monitoring/local/share/check_mk/agents/plugins/openvpn_clients
rm /omd/sites/monitoring/local/share/check_mk/web/plugins/wato/openvpn_clients_cee.py
rm /omd/sites/monitoring/local/lib/check_mk/base/cee/plugins/bakery/openvpn_clients.py
Über die GUI
Im Webfrontend einloggen -> Maintenence -> Extensian Packages gehen
Dort auf das Rote x bei aktiviertem Plugin klicken was entfernt werden soll.
Nun sieht die Liste so aus, und die changes wieder bestätigen
Nun auf die Mülltonne klicken
Frage ob wirklich entfernen mit ja beantworten
Nun ist das Plugin vollständig deinstalliert
Einrichtung der Infrastruktur
Installation Agent für Betriebsysteme mit apt Packetmanager
Nun agents für die Hosts installieren
Auf dem zu überwachenen des Host wo der Agent installiert werden soll, ein Verzeichnis checkmk_setup im root verzeichnis erstellen
mkdir -p /root/checkmk_setup
Nun mit dem Webbrowser auf dem Checkmk Server einloggen und dann
Dazu auf Setup -> Agents -> Windows, Linux, Solaris , AIX anklicken
Nun auf DEB mit dem Ubuntu Symbol anklicken und downloaden
Nun per scp die datei auf den server ins Home Verzeichnis von root/checkmk_stup übertragen check_mk übertragen
scp Downloads/check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb root@192.168.0.30:/root/checkmk_setup
Nun auf dem Server einloggen und in das Verzeichnis /root/checkmk_setup gehen und die rpm Datei installieren
cd /root/checkmk_setup
apt install ./check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb
Ausgabe:
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Hinweis: »check-mk-agent« wird an Stelle von »./check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb« gewählt.
Vorgeschlagene Pakete:
time
Die folgenden NEUEN Pakete werden installiert:
check-mk-agent
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen noch 0 B von 4.517 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 4.555 kB Plattenplatz zusätzlich benutzt.
Holen:1 /root/checkmk_setup/check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb check-mk-agent all 2.1.0p16-1.d88c216c6ad53a29 [4.517 kB]
Vormals nicht ausgewähltes Paket check-mk-agent wird gewählt.
(Lese Datenbank ... 35073 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.
deb ...
Entpacken von check-mk-agent (2.1.0p16-1.d88c216c6ad53a29) ...
check-mk-agent (2.1.0p16-1.d88c216c6ad53a29) wird eingerichtet ...
Deploying systemd units: check-mk-agent.socket cmk-agent-ctl-daemon.service chec
k-mk-agent-async.service check-mk-agent@.service
Deployed systemd
Creating/updating cmk-agent user account ...
WARNING: The agent controller is operating in an insecure mode! To secure the co
nnection run `cmk-agent-ctl register`.
Activating systemd unit 'check-mk-agent.socket'...
Created symlink /etc/systemd/system/sockets.target.wants/check-mk-agent.socket →
/lib/systemd/system/check-mk-agent.socket.
Activating systemd unit 'cmk-agent-ctl-daemon.service'...
Created symlink /etc/systemd/system/multi-user.target.wants/cmk-agent-ctl-daemon
.service → /lib/systemd/system/cmk-agent-ctl-daemon.service.
Activating systemd unit 'check-mk-agent-async.service'...
Created symlink /etc/systemd/system/multi-user.target.wants/check-mk-agent-async
.service → /lib/systemd/system/check-mk-agent-async.service.
N: Der Download wird als root und nicht Sandbox-geschützt durchgeführt, da auf die Datei »/root/checkmk_setup/check-mk-agent_2.1.0p16-d88c216c6ad53a29_all.deb« durch den Benutzer »_apt« nicht zugegriffen werden kann. - pkgAcquire::Run (13: Keine Berechtigung)
!!!NUR durchführen wenn die Agents später NICHT regestriert werden sollen, was im Kaptitel Grundkonfiguration beschrieben wird!!!
Siehe hier !!!
Um Agents auch auf ipv4 lauschen zu lassen in der config file folgendes ändern.
Aber erstmal die Dienste stoppen und terminieren
systemctl stop check-mk-agent.socket
killall cmk-agent-ctl
killall check_mk_agent
Nun die Datei /lib/systemd/system/check-mk-agent.socket bearbeiten
nano /lib/systemd/system/check-mk-agent.socket
Und folgendes auskommentieren
#ListenStream=/run/check-mk-agent.socket
Und genau unter der Auskommentierten Zeile diese einfügen
ListenStream=0.0.0.0:6556
Speichern, systemctl reloaden und dienst n eustarten
systemctl daemon-reload
systemctl restart check-mk-agent.socket
Installation Agent für Betriebsysteme mit rpm Packetmanager
Nun agents für die Hosts installieren
Auf dem zu überwachenen des Host wo der Agent installiert werden soll, ein Verzeichnis checkmk_setup im root verzeichnis erstellen
mkdir -p /root/checkmk_setup
Nun mit dem Webbrowser auf dem Checkmk Server einloggen und dann
Dazu auf Setup -> Agents -> Windows, Linux, Solaris , AIX anklicken
Nun auf RPM mit dem Redhat Symbol anklicken und downloaden
Nun per scp die datei auf den server ins Home Verzeichnis von root/checkmk_stup übertragen check_mk übertragen
scp Downloads/check-mk-agent-2.1.0p16-d88c216c6ad53a29.noarch.rpm root@192.168.0.30:/root/checkmk_setup
Nun auf dem Server einloggen und in das Verzeichnis /root/checkmk_setup gehen und die rpm Datei installieren
cd /root/checkmk_setup
rpm -i check-mk-agent-2.1.0p16-d88c216c6ad53a29.noarch.rpm
Ausgabe:
Removing deployed systemd units: check-mk-agent-async.service, check-mk-agent.socket, cmk-agent-ctl-daemon.service, check-mk-agent@.service
Deploying systemd units: check-mk-agent-async.service check-mk-agent.socket cmk-agent-ctl-daemon.service check-mk-agent@.service
Deployed systemd
Creating/updating cmk-agent user account ...
WARNING: The agent controller is operating in an insecure mode! To secure the connection run `cmk-agent-ctl register`.
Activating systemd unit 'check-mk-agent-async.service'...
Created symlink /etc/systemd/system/multi-user.target.wants/check-mk-agent-async.service → /lib/systemd/system/check-mk-agent-async.service.
Activating systemd unit 'check-mk-agent.socket'...
Created symlink /etc/systemd/system/sockets.target.wants/check-mk-agent.socket → /lib/systemd/system/check-mk-agent.socket.
Activating systemd unit 'cmk-agent-ctl-daemon.service'...
Created symlink /etc/systemd/system/multi-user.target.wants/cmk-agent-ctl-daemon.service → /lib/systemd/system/cmk-agent-ctl-daemon.service.
2022-11-20 16:34:32,252 - ha-helper[28335] - INFO - Synchronizing to node 192.168.177.2
2022-11-20 16:34:32,253 - ha-helper[28335] - INFO - Synchronizing... / -> root@192.168.177.2:/
2022-11-20 16:34:32,510 - ha-helper[28335] - INFO - Synchronization / -> root@192.168.177.2:/ done
280 run_parts async call
!!!NUR durchführen wenn die Agents später NICHT regestriert werden sollen, was im Kaptitel Grundkonfiguration beschrieben wird!!!
Um Agents auch auf ipv4 lauschen zu lassen in der config file folgendes ändern.
Aber erstmal die Dienste stoppen und terminieren
systemctl stop check-mk-agent.socket
killall cmk-agent-ctl
killall check_mk_agent
Nun die Datei /lib/systemd/system/check-mk-agent.socket bearbeiten
nano /lib/systemd/system/check-mk-agent.socket
Und folgendes auskommentieren
#ListenStream=/run/check-mk-agent.socket
Und genau unter der Auskommentierten Zeile diese einfügen
ListenStream=0.0.0.0:6556
Speichern, systemctl reloaden und dienst n eustarten
systemctl daemon-reload
systemctl restart check-mk-agent.socket
Installation Agent für andere Betriebsysteme ohne systemd / xinetd (Anbindung per ssh) tar.gz
Beschreibung
Es gibt Systeme auf denen gibt es kein Systemd und xinetd.
Der Checkmk Service lauscht normalerweise auf einen TCP Port.
Da es aber keine Services ohne xinetd und systemd gibt, gibt es eine weitere Methode.
und zwar das abrufen des Agents über ssh.
Allerdings funktioniert für diese Methode die Agnet Bakery natürlich nicht.
Agents für die Hosts installieren / entpacken
Auf dem zu überwachenden des Host wo der Agent installiert werden soll, ein Verzeichnis checkmk_setup im root verzeichnis erstellen
mkdir -p /root/checkmk_setup
Nun mit dem Webbrowser auf dem Checkmk Server einloggen und dann
Dazu auf Setup -> Agents -> Windows, Linux, Solaris , AIX anklicken
Nun auf tar gz bei Linux mit dem gelben Symbol anklicken und downloaden
Nun per scp die Datei auf den zu überwachenden Server ins Home Verzeichnis von root/checkmk_stup übertragen check_mk übertragen
scp Downloads/check-mk-agent_2.1.0p16-d88c216c6ad53a29.tar.gz root@192.168.0.30:/root/checkmk_setup
Nun die check-mk-agent_2.1.0p16-d88c216c6ad53a29.tar.gz tar auf dem zu überwachendem Host entpacken
tar -xf check-mk-agent_2.1.0p16-d88c216c6ad53a29.tar.gz -C /
SSH Schlüssel falls nicht schon vorhanden auf der Checkmkinstanz erstellen
Auf dem Checkmk server inloggen.
Dann in die instanz einloggen
omd su <instanzname>
Beispiel
omd su monitoring
Nun den Schlüssel erstellen ohne passphrase
ssh-keygen -t ed25519
Ausgabe
OMD[monitoring]:~$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/omd/sites/monitoring/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /omd/sites/monitoring/.ssh/id_ed25519.
Your public key has been saved in /omd/sites/monitoring/.ssh/id_ed25519.pub.
The key fingerprint is:
cc:87:34:d2:ed:87:ed:f7:1b:ec:58:1f:7c:23:00:e2 monitoring@mycmkserver
The key's randomart image is:
+--[ED25519 256--+
| |
| . . |
| ..+.. |
| .=.+.o |
| ES +.o |
| . o. o |
| ...B.|
| .=.*|
| . o+|
+-----------------+
Die Schlüssel liegen dann im .ssh Verzeichnis des Monitoring Verzeichnisses.
Dateien anzeigen
ll .ssh
Ausgabe
OMD[monitoring]:~$ ll .ssh
total 8
-rw------- 1 monitoring monitoring 1679 Feb 20 14:18 id_ed25519
-rw-r--r-- 1 monitoring monitoring 398 Feb 20 14:18 id_ed25519.pub
Der private Schlüssel heißt id_ed25519 und ist nur für den Instanzbenutzer lesbar (-rw-------) — und das ist auch gut so! Der öffentliche Schlüssel id_ed25519.pub sieht etwa so aus:
Ausgabe:
OMD[monitoring]:~$ cat .ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGb6AaqRPlbEmDnBkeIW3Q6Emb5lr2QEbWEQLmA5pb48 monitoring@mycmkserver
Nun auf dem zu überwachendem Host in einer zweiten SSH-Sitzung einloggen.
und die authorized_keys Datei bearbeiten
nano /root/.ssh/authorized_keys
Dort am ende den öffentlichen Schlüssel eintragen.
Davor aber noch ein command, der dient dazu, das nur der Agent aufgerufen werden kann und auch gleichzeitig beim einloggen aufgerufen wird.
Die ganze zeile in der authorized_keys Datei sähe dann so aus
command="/usr/bin/check_mk_agent" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGb6AaqRPlbEmDnBkeIW3Q6Emb5lr2QEbWEQLmA5pb48 monitoring@mycmkserver
Nun ausloggen.
Testen der Verbindung
Nun auf dem Checkmkserver wieder in die instanz einloggen, wenn nicht noch von der vorherigen Sitzung eingeloggt
omd su <instanzname>
Beispiel
omd su monitoring
Nun einfach ssh root@<iphostname> und den Fingerprint des Schlüssels mit der Eingabe von yes bestätigen.
Der Fingerprint wird nur beim ersten mal abgefragt.
ssh root@<ipfromtargetserver>
Ausgabe
OMD[monitoring]:~$ ssh root@myhost23
The authenticity of host 'myhost23 (10.11.12.13)' can't be established.
ECDSA key fingerprint is SHA256:lWgVK+LtsMgjHUbdsA1FK12PdmVQGqaEY4TE8TEps3w.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
<<<check_mk>>>
Version: 2.1.0b6
AgentOS: linux
Hostname: myhost123
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
<<<df>>>
fertig, Verbindung steht.
Einbinden des Hosts in Checkmk
Nun da die SSH Verbindung hergestellt ist, muss jetzt die SSH verbindung im Host in Checkmk eingetragen werden.
Dazu in der Weboberfläche von check mk gehen, den Host anlegen wenn noch nicht geschehen.
Sollte der Host schon bestehen. Kann das anlegen natürlich übersprungen werden.
Wichtig ist nur das in den Host Einstellungen folgendes gemacht ist
Hostanpassen
Dazu wieder auf Setup -> Hosts
Nun auf edit Host für den Host den man editieren will gehen (Stift)
Nun unter Monitoring Agents / API intergation: API integrations if configured, else Checkmk agent auswählen
Wenn die Einstellungen beim Host getätigt sind
Geht es weiter auf : Setup -> Agents -> Other integrations
-> Custom integrations -> Individual program call instead of agent access klicken
Nun auf Add rule klicken
Hier nun folgende Sachen ausfüllen:
Description : Agent connection through SSH
Command to Execute : ssh -T root@$HOSTADDRESS$
Explicit Hosts: unser(e) Server die, die Verbindung über SSH aufbauen sollen.
Hinweis: Wir nutzen hier als Variable die $HOSTADDRESS$ dies bedeutet, dazu zum verbinden die IP vom Host genommen wird.
nun auf save klicken.
Nun wieder oben rechts auf change klicken
Nun auf activate on selected sites
Nun wieder auf Setup -> Hosts
Nun auf edit Services für den Host gehen (gelber Würfel)
Nun wenn gewünscht über das X Services deaktivieren, die NICHT überwacht werden sollen.
Soll alles übernommen werden einfach auf Accept all
Fertig
Installation Agent für Windows
Beschreibung:
Installation Agent für Windows. Dieser wird dann ähnlich wie bei Linux über die Kommandozeile installiert.
Installation Agent
Auf der Check MK Seite anmelden und dann auf Setup -> Agents -> Windows, Linux, Solaris, AIX
Dort auf das Windows MSI Paket klicken.
Nun erscheint der Download Dialog eures Webbrowsers kann bei jedem anders aussehen, auf jeden Fall die Datei speichern.
Nun liegt diese Datei im Download Ordner. Dort ein Doppelklick drauf
Nun startet das Setup, auf Next klicken
Lizenbedinnungen akzeptieren und auf Next klicken
Clean install auswählen, alles andere abwählen und auf next klicken
Nun auf Install klicken
Nun auf Finish klicken
Registrieren
Anlegen von Hostgruppen und deren Verzeichnisse
Nach dem Einloggen sehen wir die Hauptseite
Im Menü links auf Setup -> Hosts ->Host Groups.
und einen Gruppennamen vergeben.
bei uns RVS-SERVERS
Dann auf Save
Nun eine weitere Gruppe anlegen namens PROXMOX-SERVERS
Auf save klicken. Nun haben wir zwei gruppen.
Nun oben rechts auf den Button changes klicken.
Denn unsere Änderungen die wir gemacht haben sind noch nicht aktiv.
Die Zahl zeigt an wie viele Änderungen wir gemacht haben.
Nun auf Activate on selected sites klicken
Nun gehen wir wieder auf Setup -> Hosts -> Hosts
Dort erstellen wir Verzeichnisse mit den gleichen Namen wie die Gruppen.
Dazu klicken wir auf Add folder
Nun den Verzeichnisnamen eingeben. RVS-SERVERS (im Screenshot steht server hab das s vergessen)
Das gleiche auch für PROXMOX-SERVERS
Dann sieht das ganze so aus.
Wieder Änderungen übernehmen
Nun auf Activate on selected sites klicken
Fertig.
Anlegen von Hosts
Nun die Hosts anlegen.
Falls noch nicht getan die Agents auf die Hosts die überwacht werden sollen installieren
Siehe abschnitt Einrichtung
Nun Auf -> Setup -> Hosts klicken
Nun haben wir eine Übersicht unserer Verzeichnisse
In das Verzeichnis reinklicken wo wir gerne den / die Host(s) erstellen möchten und auf Add Host to the monitoring klicken.
Nun auszufüllen
Hostname : name des hostes rein.
IPv4 Adresse Haken rein und die ip Adresse eintargen
Checkmk agent / API integration : haken rein
Label : sinnvolle label vergeben, können auch mehrer sein.
Wir definieren hier ein neues Label mit einem wert servertyp : rvs
Nun auf Save & go to services configuration
Nun bekommen wir eine Liste mit allen Diensten.
Es werden auch zwei neue Labels erstellt: devicetyp und os_family
Wenn wir Dienste nicht überwacht ahben wollen klicken wir auf das rote x bei dem jeweiligen Dienst
Hier gibt es eine Checkmk Warnung weil wir den Agent noch nicht registriert haben, kommt später.
Wir sehen hier einen Fehler beim Dienst Postfix und beim systemd clam av.
Den Postfix fehler bekommen wir auch nicht weg, da auf diesem System Postfix unkonfiguriert ist. Entweder postfix konfigurieren wenn benötigt oder den Dienst von der Überwachung ausschließen. Wir klicken hier auf das rote X bei Postfix, weil wir den Dienst hier nicht brauchen.
Um die in der Vergagngenheit liegenden Fehler von Systemd zu löschen einfach im Terminal mit dem Befehl.
systemctl reset-failed
Das nur so nebenbei.
Nun ist der Postfix Dienst ausgeschlossen, weil wir diesen ja mit dem roten X entfernet haben.
Dieser steht unter Diabled Service, durch klick auf das grüne plus können wir diesen jederzeit wieder hinzufügen. Auch später, falls wir uns entscheiden doch postfix auf dem System zu nutzen
Wenn alle Dienste aussortiert, die nicht gerbaucht werden. Hier nur postfix dann auf Accept all klicken.
Nun die Änderungen wieder bestätigen
Wieder active on selected sites
Nun Auf Monitor und dann Main Dashboard.
Ein Dienst Critical, und eine Warnung. Die Warnung kommt noch vom nicht registriertem Client.
Das kommt im nächsten Abschnitt, denn damit ein Client registriert werden kann muss er erst im System angelegt sein, was wir in diesem Abschnitt gemacht haben
Agents am CheckMK Server registrieren
Beschreibung:
Wenn im Service AGENT diese Warnung steh, ist der Host mit seinem agent beim Checkmk Server noch nicht registriert.
Der host wird erst im Checkmk angelegt und dann übers Terminal registriert. Ansosten steht diese Meldung hier.
Denn der Host kann den Agent ja erreichen, aber unverschlüsselt und fur jeden.
Warum das ganze?
Wenn der Agent unverschlüsselt läuft, kann jeder über den Port Daten vom Hostabgreifen
Befehl:
telnet 192.168.0.34 6556
Die Ausgabe
<<<check_mk>>>
Version: 2.1.0p16
AgentOS: linux
Hostname: rvs6-tecmata
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
FailedPythonReason:
SSHClient:
<<<cmk_agent_ctl_status:sep(0)>>>
{"version":"2.1.0p16","agent_socket_operational":true,"ip_allowlist":[],"allow_legacy_pull":true,"connections":[]}
<<<checkmk_agent_plugins_lnx:sep(0)>>>
pluginsdir /usr/lib/check_mk_agent/plugins
localdir /usr/lib/check_mk_agent/local
<<<labels:sep(0)>>>
<<<df>>>
tmpfs tmpfs 1616236 1568 1614668 1% /run
/dev/mapper/rvs6test--vg-root ext4 243008916 169841472 60750420 74% /
tmpfs tmpfs 8081168 46800 8034368 1% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
/dev/nvme0n1p2 ext2 481642 124858 331799 28% /boot
/dev/nvme0n1p1 vfat 523248 3512 519736 1% /boot/efi
/dev/fuse fuse 131072 52 131020 1% /etc/pve
tmpfs tmpfs 1616232 0 1616232 0% /run/user/0
<<<df>>>
[df_inodes_start]
tmpfs tmpfs 2020292 1131 2019161 1% /run
/dev/mapper/rvs6test--vg-root ext4 15507456 61994 15445462 1% /
tmpfs tmpfs 2020292 106 2020186 1% /dev/shm
tmpfs tmpfs 2020292 21 2020271 1% /run/lock
/dev/nvme0n1p2 ext2 124928 352 124576 1% /boot
/dev/nvme0n1p1 vfat 0 0 0 - /boot/efi
/dev/fuse fuse 262144 38 262106 1% /etc/pve
tmpfs tmpfs 404058 20 404038 1% /run/user/0
[df_inodes_end]
[df_lsblk_start]
{
"blockdevices": [
{"name":"/dev/sda", "uuid":null},
{"name":"/dev/sda1", "uuid":"77085686-971d-498a-8692-0fd8048da3a0"},
{"name":"/dev/sr0", "uuid":null},
{"name":"/dev/mapper/nvme0n1p3_crypt", "uuid":"ZZLFwZ-JMTb-Qdcu-akhk-5gEc-d2kd-6idwqE"},
{"name":"/dev/mapper/rvs6test--vg-root", "uuid":"da0060ca-629b-4f24-96e4-2bc3dd1dde9a"},
{"name":"/dev/mapper/rvs6test--vg-swap_1", "uuid":"08efe098-7e3a-4ab0-b961-5154eb194d89"},
{"name":"/dev/nvme0n1", "uuid":null},
{"name":"/dev/nvme0n1p1", "uuid":"04B7-49AB"},
{"name":"/dev/nvme0n1p2", "uuid":"0c954140-e9ed-457d-8833-f4564326cdd5"},
{"name":"/dev/nvme0n1p3", "uuid":"663f7527-3144-4b54-9768-454e65aad4b4"}
]
}
[df_lsblk_end]
<<<systemd_units>>>
[list-unit-files]
...
<<<timesyncd>>>
Server: 129.70.132.34 (2.debian.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 2
Reference: 81468952
Precision: 1us (-24)
Root distance: 3.287ms (max: 5s)
Offset: +2.726ms
Delay: 15.787ms
Jitter: 5.769ms
Packet count: 2634
Frequency: -9.423ppm
[[[1674394719]]]
<<<timesyncd_ntpmessage:sep(10)>>>
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-24, RootDelay=381us, RootDispersion=3.097ms, Reference=81468952, OriginateTimestamp=Sun 2023-01-22 14:38:39 CET, ReceiveTimestamp=Sun 2023-01-22 14:38:39 CET, TransmitTimestamp=Sun 2023-01-22 14:38:39 CET, DestinationTimestamp=Sun 2023-01-22 14:38:39 CET, Ignored=no PacketCount=2634, Jitter=5.769ms }
Timezone=Europe/Berlin
<<<local:sep(0)>>>
Connection closed by foreign host.
Nachdem der Server registriert wurde, sieht die Ausgabe nun so aus. Nun kann nur noch der Checkmk Server mit dem Zertifkat die Daten abrufen und keine dritten mehr. Denn das wäre ja noch so ohne Probleme gegangen, wie die obere Ausgabe ja zeigt.
oot@checkmk:~# telnet 192.168.0.34 6556
Trying 192.168.0.34...
Connected to 192.168.0.34.
Escape character is '^]'.
16
Is still waiting here...
No Output anymore
Wie registrieren wir den Server nun?
Unter Linux:
Dazu auf Sem Server einloggen wo der Agent läuft und mit cmk-agent-ctl hinzufügen
Hier einmal die Hilfe die wir mit Paramter -h bekommen. Keine Panik, weiter unten zeige ich ein Beispiel.
Der Befehl
cmk-agent-ctl -h
Ausgabe:
cmk-agent-ctl 2.1.0p16
Checkmk agent controller.
USAGE:
cmk-agent-ctl <SUBCOMMAND>
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
SUBCOMMANDS:
daemon Run as daemon and handle all pull and push connections
delete Delete a connection to a Checkmk instance
delete-all Delete all connections to Checkmk sites
dump Collect monitoring data and write it to standard output
help Prints this message or the help of the given subcommand(s)
import Import a pull connection from file or standard input
proxy-register Register with a Checkmk site on behalf of another host
pull Handle incoming connections from Checkmk sites collecting monitoring data
push Push monitoring data to all Checkmk sites configured for 'push'
register Register with a Checkmk site
status Query the registration status of this host
Hier die Parameter für den Befehl register aus der Hilfe
cmk-agent-ctl register -h
Ausgabe:
cmk-agent-ctl-register 1.0.0
Register with a Checkmk site
Register with a Checkmk instance for monitoring. The required information can be read from a config file or must be
passed via command line.
USAGE:
cmk-agent-ctl register [FLAGS] [OPTIONS]
FLAGS:
-d, --detect-proxy Detect and use proxy settings configured on this system for outgoing HTTPS connections.
The default is to ignore configured proxies and to connect directly
-h, --help Prints help information
--trust-cert Blindly trust the server certificate of the Checkmk site
--validate-api-cert Enable TLS certificate validation for querying the agent receiver port from the Checkmk
REST API. By default, certificate validation is disabled because it is not security-
relevant at this stage, see werk #14715
-V, --version Prints version information
-v, --verbose Enable verbose output. Use once (-v) for logging level INFO and twice (-vv) for logging
level DEBUG
OPTIONS:
-H, --hostname <host-name> Name of this host in the monitoring site
-P, --password <password> Password for API user. Can also be entered interactively
-s, --server <server> Address of the Checkmk site in the format "<server>" or "<server>:<port>"
-i, --site <site> Name of the Checkmk site
-U, --user <user> API user to use for registration
Welche Parameter brauchen wir?
Da wir ein selbstsigniertes Zertifikat haben brauchen wir folgende Parameter
--trust-cert
--password <password>
--server <server>
--site <sitename/instanzname>
--user <user>
Also würde unser Befehl so aussehen:
cmk-agent-ctl register --trust-cert --password *****unsersischerspass**** --hostname rvs6-tecmata --server 192.168.0.33 --site monitoring --user automation
Erläuterung der Paramter:
--password das automation user api password
--hostname der Hostname des Servers den wir registrieren wollen, dieser name muss identisch mit dem im checkmk sein, im Feld hostname hier rvs6-tecmata
--server : unser checkmkserver an dem wir den client registrieren wollen
--site unsere site / intanz auf dem checkmk server hier monitoring
--user der api user hier automation
Unter Windows
Eine Eingabeaufforderung mit Admin rechten Öffnen
Nun den Client mit -h öffnen um die Parameter zu bekommen.
C:\WINDOWS\system32>"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" -h
cmk-agent-ctl 2.1.0p16
Checkmk agent controller.
USAGE:
cmk-agent-ctl.exe <SUBCOMMAND>
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
SUBCOMMANDS:
daemon Run as daemon and handle all pull and push connections
delete Delete a connection to a Checkmk instance
delete-all Delete all connections to Checkmk sites
dump Collect monitoring data and write it to standard output
help Prints this message or the help of the given subcommand(s)
import Import a pull connection from file or standard input
proxy-register Register with a Checkmk site on behalf of another host
pull Handle incoming connections from Checkmk sites collecting monitoring data
push Push monitoring data to all Checkmk sites configured for 'push'
register Register with a Checkmk site
status Query the registration status of this host
C:\WINDOWS\system32>
Dann lassen wir uns die Hilfe für den Parameter register anzeigen
C:\WINDOWS\system32>"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" register -h
cmk-agent-ctl.exe-register 1.0.0
Register with a Checkmk site
Register with a Checkmk instance for monitoring. The required information can be read from a config file or must be
passed via command line.
USAGE:
cmk-agent-ctl.exe register [FLAGS] [OPTIONS]
FLAGS:
-d, --detect-proxy Detect and use proxy settings configured on this system for outgoing HTTPS connections.
The default is to ignore configured proxies and to connect directly
-h, --help Prints help information
--trust-cert Blindly trust the server certificate of the Checkmk site
--validate-api-cert Enable TLS certificate validation for querying the agent receiver port from the Checkmk
REST API. By default, certificate validation is disabled because it is not security-
relevant at this stage, see werk #14715
-V, --version Prints version information
-v, --verbose Enable verbose output. Use once (-v) for logging level INFO and twice (-vv) for logging
level DEBUG
OPTIONS:
-H, --hostname <host-name> Name of this host in the monitoring site
-P, --password <password> Password for API user. Can also be entered interactively
-s, --server <server> Address of the Checkmk site in the format "<server>" or "<server>:<port>"
-i, --site <site> Name of the Checkmk site
-U, --user <user> API user to use for registration
Welche Parameter brauchen wir?
Da wir ein selbstsigniertes Zertifikat haben brauchen wir folgende Parameter
--trust-cert
--password <password>
--server <server>
--site <sitename/instanzname>
--user <user>
Also würde unser Befehl so aussehen:
"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" register --trust-cert --password *****unsersischerspass**** --hostname rvs6-tecmata --server 192.168.0.33 --site monitoring --user automation
Wenn alles geklappt hat wird nichts als Ausgabe zurück gegeben.
Nun können wir den Status überpüfen:
"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" status
Version: 2.1.0p16
Agent socket: operational
IP allowlist: any
Connection: ip:8000/monitoring
UUID: 00bf5de9-7d67-4c76-a9c5-886310581f19
Local:
Connection type: pull-agent
Certificate issuer: Site 'monitoring' local CA
Certificate validity: Wed, 08 Mar 2023 12:14:56 +0000 - Mon, 09 Jul 3021 12:14:56 +0000
Remote:
Connection type: pull-agent
Registration state: operational
Host name: jtl-wawiclient
C:\WINDOWS\system32>
Nun ist die Warnung weg.
Ob dieser abschnitt noch beötigt wird weiß ich nicht, ich lasse es erstmal stehen
Bleibt der Fehler bestehen und es ist noch eine CRIT Warnung dazu gekommen die lautet
[agent] Host is registered for TLS but not using itCRIT, Got no information from hostCRIT, execution time 0.1 sec
Checks Schwellenwerte / Limits anpassen
Beschreibung:
Es gibt situationen da passen die Standard Schwellenwerte / Limits einfach nicht.
Zum Beispiel weil ein Server zu wenig Festplattenspeicher für eine Temporäre Zeit hat oder der RAM übern Limit ist. Aber es eigentlich noch okay ist. Da kein weiterer RAM dazu gekauft wird.
Auszug aus den Emails.
Von OK auf Warning
Danach wieder von Warning auf OK
Einstellen der Limits
Auf dem Dashboard hat man unten rechts eine Schnellübersicht der Alarme der letzten 7 Tage.
Klickt man auf den Hosteintrag bekommt, man alle service Alerts. Klickt man auf den Service bekommt man die Alerts nur vom Service für den Host. Wir klicken auf Memory und bekommen dann folgende Ansicht.
Hier sehen wir Limits von 79,95% - 80% bei RAM und Commit change 70- 72% gerundet
Nun klicken wir oben im Menü auf Service
Nun auf Das Burgermenu beiService Icons und dann auf Parameters for this service klicken
Nun haben wir eine Neue Übersicht.
Im Blauen Rahmen Rechts sieht man das dieser Check schon Standardwerte hat, nämlich Warnung bei 80% und Critical bei 90%.
Im roten Rahmen steht der Name des Checks. Diesen klicken wir an, um eine neue Regel zu erstellen.
Nun klicken wir auf Add Rule
Nun geben wir eine Beschreibung für die Rule ein.
unter Value können wir ankreuzen, welche Werte wir definieren wollen.
Wir wollen in diesem Beispiel den Memory und die Commit Change anpassen.
Unsere Werte waren gerundet, 79,95% - 80% bei RAM und Commit change 70- 72%
Also legen wir RAM auf 88% Warn und 95% Crit um ein bisschen Puffer zu haben.
Und commit belieben auf standard auf 80% Warn und 90% Crit.
Wir stellen fest, das Commit mit den Standardwerten ausreicht.
Also Kreuz wieder raus.
unten bei Explicit Hosts ein Kreuz rein und den Host auswählen.
Will man das ganze für eine Gruppe Wählt man die Gruppe aus. Anstatt Main, irgendine andere.
Dazu muss der Haken dann bei explicit Host natürlich wieder raus.
Nun auf Save klicken
Nun auf Change klicken
Nun auf Activate on selected sites
Fertig.
Benachrichtungen für bestimmte Checks deaktivieren
Beschreibung:
Wer kennt sie nicht die Windows Ereignisanzeige. Da werden Fehler und Warnungen geloggt, die eigentlich nicht von belang sind. Sind aber im Log als Critical und Checkmk schickt auch sofort ein Alert raus.
Man möchte die Alters natürlich im Checkmk System behalten. Aber eben keine Emailbenachrichtung.
Wie also rausnehemn?
Emailbenachrichtung für einen Service rausnemen:
In der Checkmk Oberfläche anmelden.
Dann unter Setup -> Hosts den Host raussuchen
Dort dann auf Services klicken
Bei den Service den man ändern möchte auf die Balken klicken
(man kann in diesem Atemzug auch mehrere Services in eine Rule packen. Dann einfach die Anderen Servicenamen wie hier
Log Application, dann noch hinzufügen.) Sehen wir später im Rule Editor
Nun auf Enable Disable notification for services klicken
Nun Auf add Rule
Nun eine Beschreibung ausfüllen
Enable Diable notification for Services auf disabled stellen, denn das wollen wir ja
Bei Condition wieder angeben für wen das gelten soll, Gruppe oder Host etc. In unserem beispiel ein Host.
Hätten wir mehr Windows Server hätten wir das anhand eines Labels wie zum Beispiel Windows machen können.
nun die Services, wir können mehre definieren. Einfach den Service Namen eintragen.
Nun aus Save oben links klicken.
Nun auf change oben rechts klicken
Nun auf Activate on selected sites
Fertig nun werden für die Dienste keine Notifcations mehr rausgesendet.
Wenn man jetzt die Services wieder aufruft.
Dazu einfach in der Suche den host eingeben und drauf klicken
Dann sieht man alle Services und bei denen wo wir die deaktiviert ahben, sieht man ein duchgestrichendes Lautsprechersymbol.
Geht man mit der Maus drücber, steht da Notiifications are disabled for this service
Fertig.
Wartungszeiten - geplante Downtimes festlegen
Beschreibung:
Es kommt immer mal wieder vor das ein Dienst offline genommen wird.
Oder sogar jeden Tag ein Gerät nicht mehr erreichbar ist, zum Beispiel über ein Backup was nachts läuft, oder
eine Zwangstrennung den internet Providers.
Hier kommen Wartungszeiten ins Spiel, die sogenannten "Scheduled Downtimes"
Hier gibt es zwei Kategorien.
Einmal Host und Service.
Es muss ja nur bei einem Update der SQL Datenbank zum Beispiel ja nicht der ganze Host weg sein.
Dann würde man da für einen oder mehrere Services eine Downtime einrichten.
Einrichtung:
Downtime eines Host definieren
Dazu loggen wir uns in der Checkmk Oberfläche ein.
Dann auf Setup ->Host monitoring rules
Dann ganz rechts auf Recurring downtimes for Hosts
Dann auf Add rule klicken
Hier definieren wir ein beispiel das jeden tag um 23:50 - 00:05 eine Downtime stattfindet, wegen Backups und so die Maschine nicht verfügbar ist.
Nun eine beschreibung vergeben für de Rule vergeben
Nun eine beschreibung vergeben, die die Downtime beschreibt
Wann die Downtime zum ersten mal stattfindet, hier 2023.05.04 um 23:50:00 UHR
Will man das die Downtime nur einmal ist, würde man den Haken downtime will not start anymore after einhaken. Was wir aber nicht wollen denn sie soll ja täglich ablaufen.
Dazu dann in repaet this downtime im dropdown menu das intervall auswählen, in diesem Fall day für täglich.
Nun angeben, wie lang die Downtime sein soll. Hier 0 Stunden und 15 min.
Damit beginnt unsere Downtime 23:50 - 0:05 UHR
Jetzt wieder wie bei allen Regeln auswählen ob es Pro Host oder Gruppe oder sonst irgendwelchen Kretierien gelten soll.
Nun auf Save klicken
Nun auf change klicken
Und auf activate klicken
Downtime eines Service definieren
Den Namen des Service herausbekommen.
Damit wir die Regel anhand des Servicenamens definieren können brauchen wir zuerst den Namen der Regel.
In Unserem Beispiel geht es um einen HTTP Check.
Nun Auf Setup -> HTTP, TCP Email Checks klicken
Nun auf Check HTTP Service klicken
Nun sehen wir eine Liste mit den Checks und rechts die Service namen stehen.
Manchmal packt Checkmk noch was vor den den namen. Bei hTTP Check ist es das Wort HTTP oder HTTPS.
Je nachdem ob der Check HTTP oder HTTPS checkt. Darum setzten wir ein .* davor und am ende ein $
Denn dann ist egal ob der check später mal in HTTP oder HTTPS geändert wird. Weil der Name bleibt ja gleich.
Jetzt haben wir den Namen und können die Downtime regel angelegen
Downtime anlegen
Auf Setup-> Services -> Service monitoring rules klicken
Dann runterscrollen bis Notifcations und dann Recurring downtimes for Services anklicken
Dann auf Add rule klicken
Hier definieren wir ein beispiel das jeden tag um 23:50 - 00:05 eine Downtime stattfindet, wegen Backups und so die Maschine nicht verfügbar ist.
Nun eine beschreibung vergeben für de Rule vergeben
Nun eine beschreibung vergeben, die die Downtime beschreibt
Wann die Downtime zum ersten mal stattfindet, hier 2023.05.04 um 23:50:00 UHR
Will man das die Downtime nur einmal ist, würde man den Haken downtime will not start anymore after einhaken. Was wir aber nicht wollen denn sie soll ja täglich ablaufen.
Dazu dann in repeat this downtime im dropdown menu das intervall auswählen, in diesem Fall day für täglich.
Nun angeben, wie lang die Downtime sein soll. Hier 0 Stunden und 15 min.
Damit beginnt unsere Downtime 23:50 - 0:05 UHR
Jetzt wieder wie bei allen Regeln auswählen ob es Pro Host oder Gruppe oder sonst irgendwelchen Kretierien gelten soll.
hier wählen wir service aus und geben den Service Namen an.
Beim Service wird immer der Anfang genommen und am Ende muss ein $ Zeichen sein, damit das System weiß hier ist Ende.
In unserem Beispiel : .*check-rvs-prod-https-available$
Nun die Condition einstellen.
Dann auf Save klicken
Dann auf change klicken.
Nun activate on selected site anklicken.
Fertig
Discovery anpassen -> Netzwerkkarten ausschliessen
Beschreibung:
Manchmal möchte man Geräte nicht erfassen, so wie die tap Adapter von VPNs oder Virtuellen machinen.
Dazu gibt es eine Möglichkeit Discovery Rules anzulegen.
In dem gleichen Menü kann man noch andere Discovery eigenschaften festlegen.
Hier werden wir die Netzwerkkarten festlegen.
Neue Rule erstellen
Dazu auf Setup -> Discovery Rules gehen.
Dort in unserem Fall auf Network interface and switch port discovery klicken
Add Rule anklicken
Nun folgendes ausfüllen:
Description: was die rule machen soll
Appearance of network interface : Use alias
Conditions for this rule to apply : specify matching condition
Match interface alias (regex) : anhaken
und dort alle interfaces rein die gefunden werden sollen. Im regex format ist .* ein asterisk
Diese dann speichern und übernehmen.
Diese Rule wird dann in Zukunft angewandt.
Sollten die Devices schon erkannt worden sein, die man nicht haben möchte müssen diese trotzdem noch manuell entfernt werden. Diese Rule gillt für Zukünftige Devices.
Fertig
Checks und wie Sie funktionieren
Was sind Checks?
In Checkmk sind Checks Prozesse, die bestimmte Informationen von einem Host oder einer Dienstleistung sammeln und diese Informationen dann an die Checkmk-Überwachungsplattform senden. Checks können auf verschiedene Weise ausgeführt werden, wie z.B. durch die Ausführung von Skripten oder durch das Senden von SNMP-Anfragen an einen Host. Es gibt verschiedene Arten von Checks, die von Checkmk unterstützt werden, z.B. System-Checks, Netzwerk-Checks, Anwendungs-Checks und Benutzerdefinierte Checks. Jeder Check hat einen bestimmten Zweck und liefert bestimmte Informationen über den Status des Hosts oder der Dienstleistung. Beispielsweise kann ein CPU-Check den Auslastungsgrad der CPU auf einem bestimmten Host überwachen.
Checks sind ein wichtiger Bestandteil von Checkmk, da sie dazu beitragen, den Status von Hosts und Diensten zu überwachen und potenzielle Probleme frühzeitig zu erkennen.
In Checkmk können Sie die Einstellungen für jeden Check konfigurieren, um die Überwachung an Ihre Anforderungen anzupassen. Dazu gehört zum Beispiel die Festlegung von Zeitintervallen, in denen der Check ausgeführt wird, oder die Konfiguration von Benachrichtigungsregeln, die ausgelöst werden, wenn der Check ein bestimmtes Ergebnis liefert.
Einige der in Checkmk enthaltenen Checks sind von Haus aus aktiviert, während andere deaktiviert sein können und nur aktiviert werden müssen, wenn sie benötigt werden. Sie können auch benutzerdefinierte Checks erstellen, um spezifische Anforderungen zu erfüllen, die nicht von den vorhandenen Checks abgedeckt werden.
Es ist auch möglich, mehrere Checks für einen bestimmten Host oder einen bestimmten Dienst zu konfigurieren, um eine umfassendere Überwachung zu erreichen. So können Sie zum Beispiel mehrere Netzwerk-Checks konfigurieren, um die Verfügbarkeit und die Leistung von verschiedenen Netzwerkschnittstellen auf einem Host zu überwachen.
In kurz, Checks sind Prozesse die dazu dienen die Eigenschaften von Hosts und Diensten zu überwachen und Informationen zu sammeln, die zur Diagn von Problemen verwendet werden können. Checkmk ermöglicht es Ihnen, die Überwachung von Checks an Ihre spezifischen Anforderungen anzupassen und benutzerdefinierte Checks zu erstellen.
Integrierte Checks
Wenn ein Host hinzugefügt wird und das Discovery durchläuft und auf dem Host ein agent ist, werden in der Regel diese Standard Services (Checks ) gefunden, können je nach System mehr oder weniger sein, je nachdem was verbaut ist.
Es gibt aber auch Checks die müssen Explizit aktiviert werden.
Unter Setup -> Services -> Service monitoring rules
Sind alle Checks zu finden
Eigene Checks erstellen
Einleitung. Muss es immer ein echtes Plugin sein?
Beschreibung:
Checkmk umfasst fast 2.000 fertige Checkplugins für alle nur denkbare Hardware und Software. Diese werden vom Checkmk-Team gepflegt, und jede Woche kommen neue dazu. Daneben gibt es auf der Checkmk Exchange weitere Plugins, die von unseren Anwendern beigesteuert werden.
Und trotzdem gibt es immer wieder Situationen, in denen ein Gerät, eine Anwendung oder einfach nur eine bestimmte Metrik, die für Sie wichtig ist, noch von keinem dieser Plugins erfasst ist — vielleicht auch einfach deshalb, weil es sich dabei um etwas handelt, dass in Ihrer Firma entwickelt wurde und es daher niemand anders haben kann.
| Methode | So geht’s | Vorteile | Nachteile |
|---|---|---|---|
|
Lokaler Check |
Checkmk-Agent um einfaches Skript erweitern |
Geht sehr einfach, ist in allen Programmiersprachen möglich, welche das Betriebssystem des überwachten Hosts anbietet, unterstützt sogar Serviceerkennung |
Konfiguration der Schwellwerte nur beim Agenten selbst, für komplexere Dinge unkomfortabel, keine Unterstützung für SNMP |
|
Nagios-kompatibles Checkplugin |
Plugin per MRPE vom Windows- oder Linux-Agenten aufrufen lassen |
Zugriff auf alle vorhandenen Nagios-Plugins, auch hier freie Wahl der Programmiersprache |
Konfiguration der Schwellwerte nur beim Agenten selbst, Keine SNMP-Unterstützung durch Checkmk, keine Serviceerkennung möglich |
|
Logmeldungen auswerten |
Meldungen überwachen per Event Console |
Keine Entwicklung notwendig sondern nur aufstellen von Regeln in der Event Console |
Geht nur, wenn passende Logmeldungen vorhanden sind, kein gesicherter aktueller Status, kein Erfassen von Metriken, keine konfigurierbaren Schwellwerte |
|
Echtes Checkmk-Plugin |
Wird in diesem Artikel erklärt |
Fügt sich zu 100% in Checkmk ein, automatische Serviceerkennung, zentrale Konfiguration der Schwellwerte über die grafische Oberfläche, sehr performant, unterstützt SNMP, automatische Host- und Servicelabels möglich, unterstützt HW/SW-Inventur, Unterstützung durch Standardbibliotheken von Checkmk |
Erfordert mehr Einarbeitungszeit sowie Kenntnisse in der Programmsprache Python |
Lokaler Check
Skript erstellen
Sie können einen lokalen Check in jeder beliebigen Programmiersprache schreiben, die der Zielhost unterstützt. Das Skript muss so konstruiert sein, dass es pro Check eine Statuszeile ausgibt, die aus vier Teilen besteht. Hier ist ein Beispiel:
0 "My service" myvalue=73 My output text which may contain spaces
Die vier Teile sind durch Leerzeichen getrennt und haben folgende Bedeutung:
| Beispielwert | Bedeutung | Beschreibung |
|---|---|---|
|
|
Status |
Der Zustand des Services wird als Ziffer angegeben: |
|
|
Service-Name |
Der Name des Services, wie er in Checkmk angezeigt wird, in der Ausgabe des Checks in doppelten Anführungszeichen. Falls der Service-Name keine Leerzeichen enthält, können Sie sich die Anführungszeichen sparen. |
|
|
Wert und Metriken |
Metrikwerte zu den Daten. Sie finden im Kapitel zu den Metriken näheres zum Aufbau. Alternativ können Sie ein Minuszeichen setzen, wenn der Check keine Metriken ausgibt. |
|
|
Statusdetail |
Details zum Status, wie sie in Checkmk angezeigt werden. Dieser Teil kann auch Leerzeichen enthalten. |
Zwischen den einzelnen Teilen der Ausgabe und dem ersten Text des Statusdetails muss immer ein Leerzeichen stehen. Alles danach wird zum Statusdetail gezählt, weswegen dann auch Leerzeichen erlaubt sind.
Wenn Sie wegen einer möglichen Ausgabe unsicher sind, können Sie diese einfach testen, indem Sie ein kleines Skript mit dem Kommando echo schreiben. Fügen Sie in das echo-Kommando Ihre Ausgabe ein, die Sie testen möchten. Achten Sie darauf, die Anführungszeichen für den Service-Namen mit \ zu maskieren, damit diese Zeichen nicht vom echo-Kommando interpretiert werden:
Linux:
#!/bin/bash
echo "0 \"My 1st service\" - This static service is always OK"
Windows:
@echo off
echo 0 "My 1st service" - This static service is always OK
Beide Skripte führen in der Ausgabe zum gleichen Ergebnis:
0 "My 1st service" - This static service is always OK
Für Checkmk ist nur diese Ausgabe relevant, nicht wie Sie diese Ausgabe erzeugt haben.
Sie können übrigens beliebig viele Ausgaben in einem Skript erzeugen. Für jede ausgegebene Zeile wird dann ein eigener Service in Checkmk erstellt. Daher sind in der Ausgabe auch keine Zeilenumbruchzeichen erlaubt — es sei denn, sie sind maskiert, zum Beispiel für eine mehrzeilige Ausgabe in Checkmk.
Wie Sie prüfen, ob das lokale Skript vom Agenten richtig aufgerufen wird, sehen Sie in der Fehleranalyse.
Skript verteilen
Nachdem das Skript geschrieben ist, können Sie es an die entsprechenden Hosts verteilen. Der Pfad unterscheidet sich je nach Betriebssystem. Eine Liste der Pfade finden Sie in Dateien und Verzeichnisse weiter unten.
Vergessen Sie nicht, das Skript auf unixoiden Systemen ausführbar zu machen. Der Pfad in dem Beispiel bezieht sich auf Linux:
root@linux# chmod +x /usr/lib/check_mk_agent/local/mylocalcheck
Wenn Sie die Agentenbäckerei nutzen, können Sie das Skript auch regelbasiert verteilen. Mehr zur Regelerstellung erfahren Sie im Kapitel Verteilung über die Agentenbäckerei.
Den Service ins Monitoring aufnehmen
Bei jedem Aufruf des Checkmk-Agenten wird auch der im Skript enthaltene lokale Check ausgeführt und an die Ausgabe des Agenten angehängt. Die Service-Erkennung funktioniert also wie bei anderen Services auch automatisch:
Eigene Check Bilbliothek
Hier landen eigen gebaute Checks
Endian VPN Überwachung
Beschreibung:
Ein Custom Check für ein python Script zur endian VPN überwachung.
Dieses script gibt Graphen mit Anzahl der Verbindung für jede VPN Instanzen aus.
und eine Gesamtverbindungsübersicht für alle VPN Instanzen.
Das Script:
Endian RVS5
#!/bin/bash
STRING=$(python /root/checkmk_setup/check_metrics4_rvs5.py openvpn_users | grep openvpn)
IFS=' ' read -ra vpn_array <<< "$STRING"
LEN=${#vpn_array[@]}
printf "0 \"OPENVPN Users\" "
for (( i=5; i<$LEN; i++))
do
IFS=' ' read -ra part <<< ${vpn_array[$i]}
printf "VPNCONF-${part[0]}"
if [ $i -lt $(expr $LEN - 1) ]
then
printf "|"
fi
done
printf "\n"
#echo "0 \"OpenVPN Users\" metric=10|metric1=20|metric3=40"
Endian RVS6
#!/bin/bash
STRING=$(python /root/checkmk_setup/check_metrics4.py openvpn_users | grep openvpn)
IFS=' ' read -ra vpn_array <<< "$STRING"
LEN=${#vpn_array[@]}
printf "0 \"OPENVPN Users\" "
for (( i=5; i<$LEN; i++))
do
IFS='=' read -ra part <<< ${vpn_array[$i]}
printf "VPNCONF-${part[0]}=${part[1]}"
if [ $i -lt $(expr $LEN - 1) ]
then
printf "|"
fi
done
printf "\n"
#echo "0 \"OpenVPN Users\" metric=10|metric1=20|metric3=40"
Es ruft
python /root/checkmk_setup/check_metrics4.py openvpn_users | grep openvpn
Ausgabe:
openvpn_users_total: 7 users (OK) | openvpn.2.conf_rvs6test_UDP_tecmata=6 openvpn.1.conf_rvs6test_TCP_tecmata=1 total_vpn_users=7
Diese Ausgabe muss dann nur noch in das Checkmk Format gebracht werden. Das macht das Script.
Die Ausgabe vom Script sieht dann so aus.
Befehl
. /usr/lib/check_mk_agent/local/vpn
Ausgabe:
0 "OPENVPN Users" VPNCONF-openvpn.2.conf_rvs6test_UDP_tecmata=6|VPNCONF-openvpn.1.conf_rvs6test_TCP_tecmata=1|VPNCONF-total_vpn_users=7
Überarbeitet Script mit Metriken für Schwellwerte. Der Doppelpunkt hinter einem Wert heißt darunter und nicht darüber.
Endian RVS5
#!/bin/bash
WARN=8
CRIT=1
STRING=$(python /root/checkmk_setup/check_metrics4_rvs5.py openvpn_users | grep openvpn)
IFS=' ' read -ra vpn_array <<< "$STRING"
LEN=${#vpn_array[@]}
printf "P \"OPENVPN Users Metrik\" "
for (( i=5; i<$LEN; i++))
do
IFS=' ' read -ra part <<< ${vpn_array[$i]}
printf "VPNCONF-${part[0]}"
if [ $i -lt $(expr $LEN - 1) ]
then
printf "|"
else
printf ";$WARN:;$CRIT:"
fi
done
printf "\n"
#echo "0 \"OpenVPN Users\" metric=10|metric1=20|metric3=40;8:;1:"
Endian RVS6
#!/bin/bash
WARN=8
CRIT=1
STRING=$(python /root/checkmk_setup/check_metrics4.py openvpn_users | grep openvpn)
IFS=' ' read -ra vpn_array <<< "$STRING"
LEN=${#vpn_array[@]}
printf "P \"OPENVPN Users Metrik\" "
for (( i=5; i<$LEN; i++))
do
IFS='=' read -ra part <<< ${vpn_array[$i]}
printf "VPNCONF-${part[0]}=${part[1]}"
if [ $i -lt $(expr $LEN - 1) ]
then
printf "|"
else
printf ";$WARN:;$CRIT:"
fi
done
printf "\n"
#echo "0 \"OpenVPN Users\" metric=10|metric1=20|metric3=40;8:;1:"
Installation des VPN Python Script im System
In endian RVS5
Der unterschied in RVS5 zu 6 sind die Pfade für die OPENVPN Log
In RVS5 liegen diese unter os.chdir("/var/volatile/tmp")
Somit muss im Script der Pfad angepasst werden.
Nach os.chdir im Abschnitt openvpnuser suchen und anpassen nach os.chdir("/var/volatile/tmp")
Wurde aber schon gemacht in der Datei : check_metrics4_rvs5.py
Die check_metrics4_rvs5.py auf den RVS kopieren.
Zum Beispiel nach ~/checkmk_setup/
Das Script erstellen mit
nano /usr/lib/check_mk_agent/local/vpn
Das das Script rein, mit oder Ohne Metrik. Halt was gewünscht ist.
Wenn mit Metrik, nicht vergessen die Metrik Werte anzupassen.
Und den Pfad zur Checkmetric4 Python File anpassen, da es ja RVS5 oder 6 sein kann
nun das Script noch ausführbar machen
chmod +x /usr/lib/check_mk_agent/local/vpn
Nun erscheint der Service in den Services vom Host
In endian RVS6
Der unterschied in RVS5 zu 6 sind die Pfade für die OPENVPN Log
In RVS6 liegen diese unter os.chdir("/run/openvpn")
Somit muss im Script der Pfad angepasst werden.
Nach os.chdir im Abschnitt openvpn suchen und anpassen nach os.chdir("/run/openvpn")
Wurde aber schon gemacht in der Datei : check_metrics4.py
Die check_metrics4.py auf den RVS kopieren.
Zum Beispiel nach ~/checkmk_setup/
Das Script erstellen mit
nano /usr/lib/check_mk_agent/local/vpn
Das das Script rein, mit oder Ohne Metrik. Halt was gewünscht ist.
Wenn mit Metrik, nicht vergessen die Metrik Werte anzupassen.
Und den Pfad zur Checkmetric4 Python File anpassen, da es ja RVS5 oder 6 sein kann
nun das Script noch ausführbar machen
chmod +x /usr/lib/check_mk_agent/local/vpn
Nun erscheint der Service in den Services vom Host
MongoDB Größen überwachung
Beschreibung:
Ein lokal check, der alle collections durchgeht und ausgibt.
Der Check muss auf dem MongoDB Server eingefügt werden, da er eijne Localhostverbindung
zum MongoDB Server aufbaut.
Das Script
#!/usr/bin/python3
from pymongo import MongoClient
# Konstanten für Schwellwerte
WARNUNGSGROESSE_GB = 0.5
KRITISCHGROESSE_GB = 1.0
# Verbindung zur MongoDB herstellen
client = MongoClient('mongodb://localhost:27017/')
# Alle Datenbanknamen abrufen
db_names = client.list_database_names()
# Durch jede Datenbank iterieren und die Statistiken abrufen
for db_name in db_names:
db = client[db_name]
stats = db.command('dbstats')
# Größe in Gigabytes umrechnen
groesse_gb = stats['dataSize'] / (1024**3)
# Prüfe die Größe gegen Schwellwerte und gebe entsprechenden Status aus
if groesse_gb > KRITISCHGROESSE_GB:
status = 2 # Kritisch
status_message = "CRITICAL"
elif groesse_gb > WARNUNGSGROESSE_GB:
status = 1 # Warnung
status_message = "WARNING"
else:
status = 0 # OK
status_message = "OK"
#Zeile um den Status ausgeben, wenn checkmk nicht benutzt wird, hier auskommentiert da es ja ein checkmk Check wird
#print(f"{status} MongoDB_{db_name}_Groesse - {status_message} - Groesse: {groesse_gb:.2f} GB")
#Zeile die Augegeben wird für Check_MK
print(f"P \"MongoDB_{db_name}_Groesse\" size={groesse_gb:.2f};{WARNUNGSGROESSE_GB};{KRITISCHGROESSE_GB}")
# MongoDB-Verbindung schließen
client.close()
Hier auchnochmals als download: mongodbsizes.py
Installation:
Das script in folgendem Pfad anlegen bzw. hin kopieren
/usr/lib/check_mk_agent/local/mongodbsizes.py
Nun noch ausführbar machen.
chmod +x /usr/lib/check_mk_agent/local/mongodbsizes.py
Fertig
Process Speicherüberwachung
Beschreibung:
Ein lokal check der alle Prozesses nach Speichergröße sortiert.
Auf Grund der Prozessmenge auf 20 Stück Limitiert.
Bei diesem Check gehts auch nur darum die Speicherfresser zu finden.
Die Schwellwerte WARN und CRIT können über die Variablen WARN und CRIT gesetzt werden. Die Einheit ist MB
Das Script
Einmal als Einzelauflistung:
#!/usr/bin/python3
import subprocess
import re
# Schwellenwerte in Megabyte
WARN = 1000 # Beispiel: 1000 MB
CRIT = 2000 # Beispiel: 2000 MB
COUNT_PROC = 20 # Anzahl der Prozesse, die ausgeben werden sollen - maximal 20
# Programmvariablen, bitte nicht verändern
output = "P \"Speicherverbrauch der Prozesse in MB\" "
# Führe den `ps`-Befehl aus, um Prozessname und Speicherverbrauch (RSS) zu bekommen
process = subprocess.Popen(['ps', '-eo', 'rss,comm', '--sort=-rss'], stdout=subprocess.PIPE)
stdout = process.communicate()[0]
# Verarbeite jede Zeile der Ausgabe
for i, line in enumerate(stdout.decode('utf-8').strip().split('\n')[1:]): # Überspringe die Kopfzeile
if i >= COUNT_PROC: # Limit auf COUNT_PROC Prozesse
break
parts = line.split(None, 1)
memory = int(parts[0]) // 1000 # Konvertiere RSS von KB zu MB
process = re.sub('[^a-zA-Z0-9]', '_', parts[1]) # Ersetze alle nicht alphanumerischen Zeichen durch Unterstriche
# Hinzufügen der Performance-Daten für jeden Prozess zum Output
output += f"NR-{i:02d}-{process}={memory};{WARN};{CRIT}|"
# Entferne das letzte Semikolon
output = output.rstrip('|')
# Entferne Kommas und Unterstriche (wenn nötig)
output = output.replace(',', '').replace('_', '')
# Ausgabe des gesammelten Outputs
print(output)
Ausgabe:
P "Speicherverbrauch der Prozesse in MB" NR-00-kvm=67338;1000;2000|NR-01-kvm=4382;1000;2000|NR-02-kvm=4307;1000;2000|NR-03-cephosd=3305;1000;2000|NR-04-cephosd=3099;1000;2000|NR-05-cephosd=2875;1000;2000|NR-06-cephosd=2679;1000;2000|NR-07-kvm=1879;1000;2000|NR-08-kvm=1264;1000;2000|NR-09-kvm=916;1000;2000|NR-10-java=576;1000;2000|NR-11-cephmon=491;1000;2000|NR-12-kvm=436;1000;2000|NR-13-kvm=420;1000;2000|NR-14-cephmgr=325;1000;2000|NR-15-mongod=167;1000;2000|NR-16-corosync=165;1000;2000|NR-17-pveproxy=157;1000;2000|NR-18-launcher=154;1000;2000|NR-19-pveproxy=144;1000;2000
Als Gesamtspeicherzusammenfassung:
#!/usr/bin/python3
import subprocess
import re
# Schwellenwerte in Megabyte
WARN = 1000 # Beispiel: 1000 MB
CRIT = 2000 # Beispiel: 2000 MB
COUNT_PROC = 20 # Anzahl der Prozesse, die ausgegeben werden sollen - maximal 20
# Programmvariablen, bitte nicht verändern
output = "P \"Speicherverbrauch der Prozesse in MB\" "
# Führe den `ps`-Befehl aus, um Prozessname und Speicherverbrauch (RSS) zu bekommen
process = subprocess.Popen(['ps', '-eo', 'rss,comm', '--sort=-rss'], stdout=subprocess.PIPE)
stdout = process.communicate()[0]
# Speichere Speicherverbrauch pro Prozessname in einem Wörterbuch
memory_usage = {}
# Verarbeite jede Zeile der Ausgabe
for line in stdout.decode('utf-8').strip().split('\n')[1:]: # Überspringe die Kopfzeile
parts = line.split(None, 1)
memory = int(parts[0]) // 1000 # Konvertiere RSS von KB zu MB
process_name = re.sub('[^a-zA-Z0-9]', '_', parts[1]) # Ersetze alle nicht alphanumerischen Zeichen durch Unterstriche
# Addiere den Speicherverbrauch für gleiche Prozessnamen
if process_name in memory_usage:
memory_usage[process_name] += memory
else:
memory_usage[process_name] = memory
# Sortiere Prozesse nach Speicherverbrauch, beschränke auf COUNT_PROC Einträge
sorted_processes = sorted(memory_usage.items(), key=lambda x: x[1], reverse=True)[:COUNT_PROC]
# Generiere die Ausgabezeile für die Prozesse
for i, (process, mem) in enumerate(sorted_processes):
output += f"{process}={mem};{WARN};{CRIT}|"
# Entferne das letzte Semikolon
output = output.rstrip('|')
# Ausgabe des gesammelten Outputs
print(output)
Ausgabe:
P "Speicherverbrauch der Prozesse in MB" kvm=80987;1000;2000|ceph_osd=12535;1000;2000|java=588;1000;2000|ceph_mon=485;1000;2000|pvedaemon_worke=423;1000;2000|pveproxy_worker=423;1000;2000|ceph_mgr=325;1000;2000|corosync=165;1000;2000|mongod=165;1000;2000|pveproxy=157;1000;2000|launcher=154;1000;2000|pvedaemon=136;1000;2000|pvescheduler=113;1000;2000|pve_ha_crm=111;1000;2000
Installation
Auf dem zu überwachenden Server nach
nano /usr/lib/check_mk_agent/local/process.py
chmod +x /usr/lib/check_mk_agent/local/process.py
kopieren oder editieren über einfügen
Pushover - Notifications
Konto und API-KEY anlegen
Beschreibung:
Um Pushover notifications nutzen zu können braucht man ein konto dort.
Die App kostet einmalif 5 USD Dollar pro Platform (ioS,Andoird,Desktop)
und ist zu verschmerzen.
Anmelden unter https://pushover.net/
Registrierung:
Nach anmeldung und Freischaltung durch Emailbestätigung, wieder einloggen und auf das Pushover logo klicken.
Oben rechts steht unser User Key den brauchen wir auch später, also den auch im Passwortsafe speichern
Danach auf Create an Application/API Token klicken
Nun einen Namen und eine Beschreibung vergeben.
Die AGB akzeptieren und auf Create Application klicken
Nun bekommen wir unseren API KEY, diesen kopieren wir uns zum Beispiel in einen Passwortsafe
Pushover - Android App einrichten
BeschreibunG:
Ap aus dem App Store installieren, dazu Playstore öffnen oder link folgen
https://play.google.com/store/apps/details?id=net.superblock.pushover
Auf installieren klicken
Nun auf login klciken
Emailadresse und Passwort zum Account eingeben und wieder auf Login klicken
Einen Gerätenamen vergeben und auf Add Device klicken
Fertig Programm kann geschlossen werden.
Pushover in Checkmk konfigurieren
Beschreibung:
Pushover Application in Checkmk konfigurieren.
Einrichtung:
Checkmk Webseite öffnen , dann auf Setup dort notific eingeben und dann auf Setup -> Notifications
Dort dann auf add Rule
Nun Decription ausfükken
Den APi KEy : da kommt der Appkey rein
Nun User / Group Key : Da kommt der User Key rein. Im Pushoverdashboard rechts oben zu finden
Danach auf save
Nun haben wir eine neue Notification pushover
Testen Der Benachrichtigung:
test ausführen
Dazu gehen wir auf irgendeinen Service
Dann auf Commands und Custom notification
Nun einen test Text eintragen und auf send klicken
Noch auf confirm klicken....
....und schon geht die Nachricht raus
In der App auf dem Android Phone andere Platformen ähnlich.
Push Benachrichtigung
Oder in der Pushover App auf das Burgermenü, dann auf Checkmk
Nun sieht man alle jemsld empfangenden Nachrichten
Plugins die explicit konfiguriert werden müssen
CheckMK Mongo DB Plugin
Beschreibung:
Um die MongoDB Plugins zu nutzen müssen A das Plugin Aktiviert werden und B der Agent neu gebacken werden.
Mit den MongoPlugins lassen sich Verbindungen Größe etc. Monitoren.
in unserem Beispiel wird der Server schon mit dem Standard agent überwacht und ist in Checkmk schon eingebunden. Der Server hört auf den Namen mongodb
Einrichtung MongoDB, wenn nicht schon geschehen:
Anleitung zum installieren, hier klicken
DB und Tabelle erstellen wenn nicht vorhanden:
Wenn wir keine Datenbank und Tabelle haben zum überwachen dann erstellen wir eine Dummy DB mit Einträgen um diese wachsen zu lassen.
in diesem Kaptiel der Mongo db, Können wir eine Testdatenbank mit einer Tabelle und eintragen erstellen lassen.
Wenn das Fill script ausgeführt wird, kann man die Tabelle wachsen lassen.
Mit dem löschen und db_free script den speicher wieder freigeben.
Nun kann man damit die Datenbankgröße zum testen ändern, damit das Monitoring auch Werte zum testen hat.
Einrichtung CheckMK:
Plugin aktivieren
Dazu in checkmk auf Setup -> Agents -> Windows , linux, Solaris -> AIX gehen
Dort dann auf Agent Rules klicken
Nun aus den Agent rules mongodb Linux auswählen / anklicken
Nun eine Rule erstellen durch anklicken von add rule
Nun folgende Einstellungen ausfüllen, die Host oder Gruppenauswahl an eure Bedürfnisse anpassen.
Dann auf Save klicken.
Nun die Changes übernehmen.
Nun wieder auf Setup -> Agents -> Windows , linux, Solaris -> AIX gehen
Dort dann auf bake Agents klicken
Jetz einen Moment warten, dann erscheint eine neue Agent Kategorie. Vorne der Typ Linux mongodb in der Mitte dann wieder den Agent downloaden für das System vom Server. Und zum Schluss in der letzten Spalte steht auch für welche Server dieser Agent zutrifft, in unserem Fall mongodb.
Jetzt wieder wie gewohnt mit scp oder anderen mittels diesen Agent installieren.
Nachdem der Agent installiert ist, testen wir ob der Mongo Teil erkannt wurde.
Dazu geben wir einfach check_mk_agent ein im terminal auf dem mongodbserver ein.
check_mk_agent
Ausgabe, dort sieht man unsere Testdatenbank mit der Testtabelle
Somit ist sichergestellt der Agent funktioniert.
Jetzt können wir unseren Host konfigurieren
Dazu gehen wir auf Setup -> Host
Dann klicken wir in der Gruppe wo die Hosts aufgelistet werden auf die gelbe Kiste
und tadaaa, unsere MongoDB steht drin.
Jetzt nur noch die Services die wir haben wollen hinzufügen
Die Änderungen wieder übernehmen.
und in der Hostview ist die MongoDB drin:
Der Gesamtspeicher einer Collection besteht aud Dokumentspeicher und Indexes
Allocated for document storage: 3.81 MB, Total size of indexes: 1.27 MB
3,81 MB + 1,27 MB = 5,08 MB
Siehe Cli Ausgabe:
test> show databases
admin 64.00 KiB
config 108.00 KiB
local 64.00 KiB
meineTestDatenbank 5.08 MiB
test>
Fertig