Alert Handler - Auf Probleme automatisiert reagieren

1. Einleitung

1.1. Soll das Monitoring eingreifen?

Man möchte meinen, es sei offensichtlich, dass ein Monitoringsystem niemals ins Geschehen eingreift, sondern eben nur — tja — monitort. Und wahrscheinlich ist es auch eine gute Idee, es dabei zu belassen.

Nun ist es aber zugegeben eine verlockende Vorstellung, dass ein System, das zuverlässig Probleme erkennen kann, diese auch selbst behebt, sofern das automatisch geht. Dafür finden sich leicht einige Beispiele:

Das Starten eines Dienstes, wenn dieser abgestürzt ist.
Das Auslösen eines Garbagecollectors, wenn der Speicher einer Java-VM knapp ist.
Das Neuaufbauen eines VPN-Kanals, wenn dieser definitiv tot ist.

Wer sich auf so etwas einlässt, muss natürlich Monitoring anders denken. Aus einem System, das einfach nur zuguckt und für den Betrieb „nicht notwendig“ ist, wird Schritt für Schritt ein lebenswichtiges Organ des Rechenzentrums.

Aber das Beheben von Problemen ist nicht das Einzige, was das Monitoring automatisiert tun kann, wenn es ein Problem feststellt. Ebenfalls sehr nützlich und gleichzeitig viel harmloser ist das Sammeln von zusätzlichen Diagnosedaten genau in dem Augenblick des Fehlers! Und sicher fallen Ihnen auf Anhieb noch etliche weitere Dinge ein, die Sie mit Alert Handlern anfangen können.

1.2. Alert Handler in Checkmk

Alert Handler sind von Ihnen selbst geschriebene Skripten, die Checkmk für Sie ausführt, wenn ein Problem festgestellt wird — oder genauer ausgedrückt: wenn ein Host oder Service seinen Zustand ändert.

Alert Handler sind sehr ähnlich zu Benachrichtigungen und werden auch ähnlich konfiguriert, aber es gibt ein paar wichtige Unterschiede:

Alert Handler sind unabhängig von Wartungszeiten, Benachrichtigungsperioden, Quittierungen und ähnlichen Einschränkungen.
Alert Handler werden auch schon beim ersten Wiederholversuch aufgerufen (falls Sie mehrere Checkversuche konfiguriert haben).
Alert Handler sind unabhängig von Benutzern und Kontaktgruppen.
Alert Handler gibt es nur in den Checkmk Enterprise Editions.

Man kann auch sagen, dass Alert Handler sehr „low level“ sind. Sobald ein Host oder Service seinen Status ändert, werden sofort die von Ihnen konfigurierten Alert Handler aufgerufen. Auf diese Art kann ein Alert Handler auch erfolgreich etwas reparieren, bevor es überhaupt zu einem Alert kommt.

Natürlich können Sie — wie immer bei Checkmk — durch Regeln genaue Bedingungen festlegen, wann welcher Handler ausgeführt werden soll. Wie das geht und auch alles Andere über Alert Handler erfahren Sie in diesem Artikel.

Noch ein Hinweis für Benutzer der CRE Checkmk Raw Edition: Auch Sie können das Monitoring automatisiert Aktionen ausführen lassen. Verwenden Sie dazu die „Event Handler“ von Nagios. Konfigurieren Sie diese mit manuellen Konfigurationsdateien in Nagios-Syntax unterhalb von ~/etc/nagios/conf.d/. Die Event Handler sind gut dokumentiert. Hinweise dazu finden Sie durch einfaches Googeln.

2. Alert Handler einrichten

2.1. Skripte in das richtige Verzeichnis legen

Alert Handler sind Skripten, die auf dem Checkmk-Server ausgeführt werden. Diese müssen im Verzeichnis ~/local/share/check_mk/alert_handlers/ liegen und können in jeder von Linux unterstützen Sprache geschrieben sein, z.B. in BASH, Python oder Perl. Vergessen Sie bitte nicht, die Skripten ausführbar zu machen (chmod +x …).

Neu ab 1.4.0: Wenn Sie im Skript in der zweiten Zeile einen Kommentar einfügen (mit einer #/Raute), dann erscheint dieser als Name des Skripts in der Auswahlliste bei der Regel:

~/local/share/check_mk/alert_handlers/myhandler

#!/bin/bash
# Foobar handler for repairing stuff
...

2.2. Ein einfacher Alert Handler zum Testen

Wie bei den Benachrichtigungen bekommt das Skript alle Informationen über den Host oder Service als Umgebungsvariablen, wobei diese hier alle mit dem Präfix ALERT_ beginnen. Um zu testen, welche Umgebungsvariablen genau beim Skript ankommen, können Sie folgenden Alert Handler zum Testen verwenden:

~/local/share/check_mk/alert_handlers/debug

#!/bin/bash
# Dump all variables to ~/tmp/alert.out

env | grep ^ALERT_ | sort > $OMD_ROOT/tmp/alert.out

env gibt alle Umgebungsvariablen aus.
grep ^ALERT_ wählt daraus diejenigen aus, die mit ALERT_ beginnen.
sort sortiert dann die verbleibende Liste alphabetisch.

2.3. Alert Handler aktivieren

Das Scharfschalten des Handlers geht über das Setup-Modul icon alert handlers Alert handlers. Gehen Sie wie folgt vor:

Legen das obige Skript unter ~/local/share/check_mk/alert_handlers/debug an.
Machen Sie es mit chmod +x debug ausführbar.
Rufen Sie das über Setup > Events die Konfiguration der Alert handlers auf.
Legen Sie dort mit Add rule eine neue Regel an.

Die Maske erlaubt eine direkte Auswahl des Alert Handlers. Die zweite Zeile in dem ausgewählten Skript wird als Titel benutzt. Zusätzlich können Sie Aufrufargumente mitgeben, die sie in die Freitextfelder eintragen. Diese kommen beim Skript als Kommandozeilenargumente an. In der Shell können Sie darauf mit $1, $2 usw. zugreifen.

Wichtig: Nach dem Speichern der Regel ist der Alert Handler sofort wirksam und wird bei jeder Zustandsänderung irgendeines Hosts oder Services ausgeführt!

2.4. Test und Fehlerdiagnose

Zum Testen setzen Sie z.B. einen Service mit Fake check results von Hand auf CRIT. Nun sollte die Datei mit den Variablen angelegt worden sein. Hier die ersten 20 Zeilen davon:

OMD[mysite]:~$ head -n 20 ~/tmp/alert.out
ALERT_ALERTTYPE=STATECHANGE
ALERT_CONTACTNAME=check-mk-notify
ALERT_CONTACTS=
ALERT_DATE=2016-07-19
ALERT_HOSTADDRESS=127.0.0.1
ALERT_HOSTALIAS=myserver123
ALERT_HOSTATTEMPT=1
ALERT_HOSTCHECKCOMMAND=check-mk-host-smart
ALERT_HOSTCONTACTGROUPNAMES=all
ALERT_HOSTDOWNTIME=0
ALERT_HOSTFORURL=myserver123
ALERT_HOSTGROUPNAMES=check_mk
ALERT_HOSTNAME=myserver123
ALERT_HOSTNOTESURL=
ALERT_HOSTNOTIFICATIONNUMBER=1
ALERT_HOSTOUTPUT=Packet received via smart PING
ALERT_HOSTPERFDATA=
ALERT_HOSTPROBLEMID=0
ALERT_HOSTSHORTSTATE=UP
ALERT_HOSTSTATE=UP

Eine Logdatei über die (Nicht-)Ausführung der Alert Handler finden Sie unter var/log/alerts.log. Der Abschnitt für die Ausführung des Handlers debug für den Service Filesystem / auf dem Host myserver123 sieht etwa so aus:

var/log/alerts.log

2016-07-19 15:17:22 Got raw alert (myserver123;Filesystem /) context with 60 variables
2016-07-19 15:17:22 Rule ''...
2016-07-19 15:17:22  -> matches!
2016-07-19 15:17:22 Executing alert handler debug for myserver123;Filesystem /
2016-07-19 15:17:22 Spawned event handler with PID 6004
2016-07-19 15:17:22 1 running alert handlers:
2016-07-19 15:17:22 PID: 6004, object: myserver123;Filesystem /
2016-07-19 15:17:24 1 running alert handlers:
2016-07-19 15:17:24 PID: 6004, object: myserver123;Filesystem /
2016-07-19 15:17:24 Handler [6004] for myserver123;Filesystem / exited with exit code 0.
2016-07-19 15:17:24 Output:

Noch einige nützliche Hinweise:

Texte, die der Alert Handler auf der Standardausgabe ausgibt, erscheinen in der Logdatei neben Output:.
Auch der Exitcode des Skripts wird geloggt (exited with exit code 0).
Alert Handler sind erst wirklich nützlich, wenn Sie auf dem Zielhost ein Kommando ausführen. Für Linux bietet Checkmk eine fertige Lösung, die weiter unten erklärt wird.

3. Regelbasierte Konfiguration

Wie im einführenden Beispiel gezeigt, legen Sie über Regeln fest, welche Ereignisse Alert Handler auslösen sollen. Das Ganze funktioniert völlig analog zu den Benachrichtigungen, nur etwas vereinfacht. Im Beispiel haben Sie überhaupt keine Bedingungen festgelegt, was in der Praxis natürlich unrealistisch ist. Folgendes Beispiel zeigt eine Bedingung, die einen Alert Handler für ganz bestimmte Hosts und Services festlegt:

Der Alert Handler wird nur aufgerufen, wenn

einer der Hosts myhost123 oder myhost124 betroffen ist,
es um den Service JVM CaramKern Memory geht,
der Zustand von OK oder WARN auf CRIT wechselt und
das alles beim zweiten Checkversuch passiert.

Damit der Handler überhaupt aufgerufen wird, ist es in diesem Beispiel also notwendig, dass per Regel Maximum number of check attempts for service die Anzahl der Versuche mindestens auf 2 eingestellt wird. Um einen Alert im Falle eines erfolgreichen Garbagecollectors zu vermeiden, sollte die Anzahl auf 3 eingestellt werden. Denn wenn der Handler direkt nach dem zweiten Versucht das Problem beheben konnte, sollte der dritte Versuch wieder den Zustand OK feststellen und somit kein Alert mehr notwendig sein.

Noch ein Hinweis: Anders als an anderen Stellen von Checkmk, wird bei den Alert Handlern jede Regel ausgeführt, deren Bedingung erfüllt ist. Sogar wenn zwei zutreffende Regeln jeweils den gleichen Handler auswählen, wird dieser also auch tatsächlich zweimal angetriggert. Der Alert Helper wird dann die zweite Ausführung in der Regel wieder mit einer Fehlermeldung unterdrücken, da der gleiche Handler niemals mehrfach gleichzeitig laufen soll. Trotzdem ist es besser, wenn Sie Ihre Regeln so schreiben, dass dieser Fall nicht auftritt.

4. Wie Alert Handler ausgeführt werden

4.1. Asynchrone Ausführung

Sehr oft werden Alert Handler dazu benutzt, sich remote per SSH oder einem anderen Protokoll auf der betroffenen Maschine anzumelden und dort skriptgesteuert eine Aktion auszuführen. Da die Maschine ja gerade ein Problem hat, ist es nicht ausgeschlossen, dass die Verbindung sehr lange dauert oder sogar in einen Timeout läuft.

Da während dieser Zeit natürlich weder das Monitoring stehen bleiben darf noch andere Alert Handler aufgehalten werden dürfen, werden Alert Handler grundsätzlich asynchron ausgeführt. Verantwortlich dafür ist ein Hilfsprozess — der Alert Helper — welcher vom CMC automatisch gestartet wird. Um Overhead zu vermeiden, geschieht dies allerdings nur, wenn Sie mindestens eine Regel für Alert Handler angelegt haben. Im cmc.log sehen Sie dann folgende Zeile:

var/log/cmc.log

2016-07-19 15:17:00 [5] Alert handlers have been switched on

Der Alert Helper bekommt vom CMC bei jeder Zustandsänderung eines Hosts oder Services eine Benachrichtigung mit allen Informationen zu dem Ereignis. Nun wertet er alle Alert-Regeln aus und stellt so fest, ob ein Handler aufgerufen werden soll. Falls ja, wird das entsprechende Skript als externer Prozess gestartet und im Hintergrund ausgeführt.

4.2. Stoppen des Cores

Wenn Sie den CMC stoppen (z.B. durch omd stop oder durch Herunterfahren des Monitoringservers), werden alle noch laufenden Alert Helper abgebrochen. Diese werden später nicht wiederholt. Denn wer weiß schon, wie viel später dieses „später“ sein wird. Eventuell ist dann ein Neustart von einem Dienst oder dergleichen eher schädlich als nützlich!

4.3. Timeouts

Um sich im Fall eines Fehlers vor zu vielen Prozessen zu schützen, gilt für die Laufzeit eines Alert Handlers ein Timeout von (einstellbar) 60 Sekunden. Nach Ablauf dieser Zeit wird der Handler beendet. Ab Version 1.4.0 ist das so geregelt, dass nach Ablauf des Timeouts ein Signal 15 (SIGTERM) an den Handler geschickt wird. So hat dieser die Gelegenheit, sich sauber zu beenden. Nach weiteren 60 Sekunden (doppelter Timeout) wird er dann mit Signal 9 (SIGKILL) endgültig „abgeschossen“.

4.4. Überlagerung

Ab Version 1.4.0 verhindert Checkmk die gleichzeitige Ausführung von Alert Helpern, wenn diese den gleichen Host/Service betreffen und das gleiche Skript mit den gleichen Parametern ausführen würden. So ein Fall deutet darauf hin, dass der erste Handler noch am Laufen ist und es keinen Sinn macht, einen zweiten gleichen Handler zu starten. Der zweite Handler wird dann sofort abgebrochen und als gescheitert gewertet.

4.5. Exitstatus und Ausgabe von Handlern

Ausgaben und Exitcodes der Alert Handler werden sauber ausgewertet, zum Core zurück transportiert und dort in die Historie des Monitorings geschrieben. Außerdem können sie zu einer Benachrichtigung führen (siehe unten).

4.6. Globale Einstellungen

Für die Ausführung der Alert Handler gibt es etliche globale Einstellungen:

Das Alert handler log level hingegen beeinflusst das Logging im Alert Helper (alerts.log).

4.7. Master control

Mit einem Klick in der Master control können Sie Alert Handlers global deaktivieren. Bereits laufende Handler sind davon nicht betroffen und werden noch fertig ausgeführt.

Bitte vergessen Sie nicht, den kleinen Schalter beizeiten wieder auf grün zu stellen! Sie könnten sich sonst zu Unrecht in Sicherheit wiegen, dass das Monitoring alles wieder repariert …

5. Alert Handler in der Historie

Ab Version 1.4.0 erzeugen Alert Handler Einträge in der Monitoringhistorie. Damit haben Sie eine bessere Nachvollziehbarkeit, als allein durch die Logdatei alerts.log. Es wird ein Eintrag erzeugt, sobald ein Alert Handler gestartet wird und auch wenn er sich beendet.

Die Alert Handler werden dabei so betrachtet wie klassische Monitoringplugins. Das heißt, sie sollen eine Zeile Text ausgeben und als Exitcode einen der vier Werte 0 (OK), 1 (WARN), 2 (CRIT) oder 3 (UNKNOWN) zurückgeben. Alle Fehler, die eine Ausführung des Handlers von vornherein verhindern (Abbruch wegen Doppelausführung, Skript nicht vorhanden, Timeout, etc.), werden automatisch mit UNKNOWN bewertet.

Der Aufruf von folgendem sehr einfachen Handler …

local/share/check_mk/alert_handlers/dummy

#!/bin/bash
# Dummy handler for testing

sleep 3
echo "Everything is fine again"
exit 0

... sieht in der Historie des betroffenen Services dann z.B. so aus (wie immer sind die neuen Meldungen oben):

In der allgemeinen Ansicht Monitor > System > Alert handler executions werden zudem alle Ausführungen von Alert Handlern zusammen darstellt.

6. Benachrichtigungen über Alert Handler

Die Ausführung eines Alert Handlers — genauer gesagt die Beendigung der Ausführung — ist ein Ereignis, das zu einer Benachrichtigung führt. So können Sie sich informieren lassen, wenn ein Handler seine Arbeit verrichtet hat. Dazu gibt es zwei neue Ereignistypen, auf die Sie in einer Benachrichtigungsregel filtern können:

Sie können also auch zwischen erfolgreich ausgeführten Handlern (Exitcode 0 - OK) und gescheiterten (alle anderen Codes) unterscheiden. Die E-Mail-Benachrichtigung von Checkmk wurde so angepasst, dass Alert Handler-Benachrichtigungen, anstelle der Ausgabe des Checks, nun die Ausgabe des Alert Handlers zeigen.

7. Handler bei jeder Checkausführung

Normalerweise werden Alert Handler nur aufgerufen, wenn sich der Zustand eines Hosts oder Services ändert (oder während der Wiederholversuche bei Problemen). Einfache Checkausführungen ohne Zustandsänderung lösen keinen Alert Handler aus.

Über die globale Option Alert handlers > Types of events that are being processed > All check executions! können Sie genau das umstellen. Jede Ausführung eines Checks löst dann potentiell Alert Handler aus. Sie können das z.B. Nutzen, um die laufenden Monitoring-Daten in andere Systeme zu übertragen.

Bitte seien Sie mit dieser Einstellung vorsichtig! Das Starten von Prozessen und Aufrufen von Skripten sind sehr CPU-lastige Operationen. Checkmk kann spielend 1000 Checks pro Sekunde durchführen — aber 1000 Alert Handler-Skripten pro Sekunde schafft Linux ganz sicher nicht.

Um das Ganze dennoch sinnvoll möglich zu machen, bietet Checkmk die Möglichkeit, Alert Handler als Pythonfunktionen zu schreiben, welche dann inline laufen — ohne Prozesserzeugung. So einen Inlinehandler legen Sie einfach im gleichen Verzeichnis ab wie die normalen Handlerskripten. Folgendes funktionierendes Beispiel zeigt die Struktur eine Inlinehandlers:

local/share/check_mk/alert_handlers/foo

#!/usr/bin/python
# Inline: yes

# Do some basic initialization (optional)
def handle_init():
    log("INIT")

# Called at shutdown (optional)
def handle_shutdown():
    log("SHUTDOWN")

# Called at every alert (mandatory)
def handle_alert(context):
    log("ALERT: %s" % context)

Das Skript hat keine Hauptfunktion, sondern definiert lediglich drei Funktionen. Dabei ist nur die Funktion handle_alert(…) vorgeschrieben. Sie wird nach jeder Checkausführung aufgerufen und bekommt im Argument context ein Python-Dictionary mit Variablen wie "HOSTNAME", "SERVICEOUTPUT" usw. Dies entspricht den Umgebungsvariablen, die auch die normalen Handler bekommen — allerdings ohne den Präfix ALERT_. Sie können das Beispiel verwenden, um sich den Inhalt von context anzusehen.

Alle Ausgaben, die die Hilfsfunktion log() erzeugt, landen in var/log/alert.log. Die beiden globalen Variablen omd_root und omd_site sind gesetzt auf das Homeverzeichnis bzw. den Namen der Checkmk-Instanz.

Die Funktionen handle_init() und handle_shutdown() werden von Checkmk beim Starten bzw. Stoppen des Monitoringkerns aufgerufen und ermöglichen Ihnen eine Initialisierung, z.B. den Aufbau einer Verbindung zu einer Datenbank.

Weitere Hinweise:

Bitte beachten Sie das # Inline: yes in der zweiten Zeile.
Nach jeder Änderung in dem Skript muss der Core neu gestartet werden (omd restart cmc).
import-Befehle sind erlaubt.
Der Alert Helper von Checkmk ruft Ihre Funktionen synchron auf. Achten Sie darauf, dass keine Wartezustände entstehen!

8. Remoteausführung unter Linux

8.1. Grundprinzipien

Version 1.4.0 bringt einen Alert Handler mit, der die sichere Ausführung von Skripten auf überwachten Linux-Systemen ermöglicht. Wichtigste Eigenschaften dieser Lösung sind:

Die Skripte werden per SSH mit Command restriction aufgerufen.
Es können keine beliebigen Befehle, sondern nur die von Ihnen definierten Kommandos aufgerufen werden.
Das Ganze kann komplett mit der Agent Bakery aufgesetzt werden.

Die Linux Remote Alert Handler bestehen aus folgenden Einzelteilen:

Der Alert Handler linux_remote mit dem Titel „Linux via SSH“ auf dem Checkmk-Server.
Das Skript mk-remote-alert-handler auf dem Zielsystem.
Von Ihnen geschriebene Skripten („Remotehandler“) auf dem Zielsystem.
Einträge in .ssh/authorized_keys desjenigen Benutzers auf dem Zielsystem, der diese ausführen soll.
Regeln in Monitoring agents > Rules > Linux Agent > Install remote alert handlers (Linux), welche SSH-Schlüssel generieren.
Alert Handler-Regeln, welche linux_remote aufrufen.

8.2. Aufsetzen

Angenommen, Sie möchten auf dem Linux-System myserver123 das Skript /etc/init.d/foo restart ausführen, wann immer der Service Process FOO kritisch wird (welchen Sie bereits eingerichtet haben). Gehen Sie wie folgt vor:

Remotehandler schreiben

Schreiben Sie zunächst das Skript, das auf dem Zielsystem ausgeführt werden soll. Da Sie mit der Agent Bakery arbeiten, legen Sie das Skript auf dem Checkmk-Server an (nicht auf dem Zielsystem!). Das korrekte Verzeichnis dafür ist local/share/check_mk/agents/linux/alert_handlers. Auch hier sorgt der Kommentar in der zweiten Zeile für einen Titel zur Auswahl in der Benutzeroberfläche:

local/share/check_mk/agents/linux/alert_handlers/restart_foo

#!/bin/bash
# Restart FOO service

/etc/init.d/foo restart || {
    echo "Could not restart FOO."
    exit 2
}

Machen Sie das Skript ausführbar:

OMD[mysite]:~$ cd local/share/check_mk/agents/linux/alert_handlers
OMD[mysite]:~$ chmod +x restart_foo

Das Beispielskript ist so gebaut, dass es sich im Fehlerfalle mit dem Code 2 beendet, so dass der Alert Handler dies als CRIT werten wird.

Agentenpaket mit dem Handler vorbereiten

Wir beschreiben hier das Vorgehen mit der Agentenbäckerei. Hinweise für ein Aufsetzen von Hand finden Sie weiter unten. Legen Sie eine Regel unter Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Linux Agent > Remote alert handlers (Linux) an. In den Eigenschaften sehen Sie den Remotehandler Restart FOO service, den Sie gerade angelegt haben. Wählen Sie diesen zur Installation aus:

Nachdem Sie gespeichert haben, sehen Sie die Regel in der Liste: Es wurde automatisch ein SSH-Schlüsselpaar für den Aufruf des Handlers „ausgewürfelt“, dessen Fingerprint in der Regel angezeigt wird. In dem Screenshot wurde er aus Gründen der Darstellung gekürzt:

Der öffentliche Schlüssel ist für den Agenten vorgesehen. Der private Schlüssel wird vom Checkmk-Server später benötigt, um das so installierte Skript ohne Eingabe eines Passworts aufrufen zu können.

Sie können auch einen anderen Benutzer als root verwenden — natürlich nur wenn dieser ausreichend Rechte für die benötigte Aktion hat. Der Checkmk-Agent installiert den SSH-Schlüssel nur auf Systemen, wo dieser Benutzer bereits existiert.

Agenten backen

Backen Sie nun neue Agenten mit button bake agents . In der Liste der fertigen Agenten muss nun ein Eintrag auftauchen, in dem Sie wieder Ihren Remotehandler und SSH-Schlüssel sehen. Auch hier wurde der Screenshot — um die Anzahl der möglichen Pakete, die Sie herunterladen können — gekürzt:

Agent installieren

Installieren Sie nun das RPM- oder DEB-Paket auf Ihrem Zielsystem (die TGZ-Installation kann die SSH-Schlüssel nicht aufsetzen und ist deshalb unvollständig). Bei der Installation geschehen folgende Dinge:

Ihr Remotehandlerskript wird installiert.
Das Hilfsprogramm mk-remote-alert-handler wird installiert.
Beim gewählten Benutzer (hier root) wird ein Eintrag in authorized_keys gemacht, der die Ausführung des Handlers ermöglicht.
Das Verzeichnis .ssh und die Datei authorized_keys werden bei Bedarf automatisch angelegt.

Bei der Installation via DEB sieht das etwa so aus:

root@myserver123:~# dpkg -i check-mk-agent_2016.07.19-9d3ab34905da4934_all.deb
Selecting previously unselected package check-mk-agent.
(Reading database ... 515080 files and directories currently installed.)
Preparing to unpack ...check-mk-agent_2016.07.19-9d3ab34905da4934_all.deb ...
Unpacking check-mk-agent (2016.07.19-9d3ab34905da4934) ...
Setting up check-mk-agent (2016.07.19-9d3ab34905da4934) ...
Reloading xinetd...
 * Reloading internet superserver configuration xinetd                            [ OK ]
Package 9d3ab34905da4934: adding SSH keys for Linux remote alert handlers for user root...

Ein Blick in die SSH-Konfiguration von root zeigt:

root@myserver123:~# cat /root/.ssh/authorized_keys
command="/usr/bin/mk-remote-alert-handler restart_foo",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-rsa  AAAAB3NzaC1yc2EAAAADAQABAAACAQCqoDVNFEbTqYEmhSZhUMvRy5SqGIPp1nE+EJGw1LITV/rej4AAiUUBYwMkeo5aBC6VOXkq78CdRuReSozec3krKkkwVbgYf98Wtc6N3WiljS85PLAVvPadJiJCkXFctbxyI2xeF5TQ1VKDRvzbBjXE9gjTnLWbPy77RC8SVXLoOQgabixpWQquIIdGyccPsWGTRgeI7Ua0lgWZQUJt7OIKQ0X7Syv2VHKJNqtW28IWu8y2hBEY/TERip5EQoNT/VclhHqjDG2y3F45PswcXD5in6y30EnfHGcwk+PD6fgp7jPGbO2+QBUwYgW67GmRpbaVQ97CqXFJvORNF+C6+O8DNweyH3ogspjfKvM7eN+M4NIJzjMRyNBMzqF3VmrMeqpzRjfFj2BS/8UbXGgHzZRapwrK3+GXX1pG49n77cIs+GWos9xb1DxX1pEu2tgQwRBBhYcTkk2eKkH18LKzFUyObxtQmf40C24cdQOp6USbwzsniqehsLIHH2unQ7bW6opF/GiaEjZamGbgsPOe8rmey5Vcd//e8cS+OsmcPZNybsTJpBeHpes+5bw0e1POw9GD9qptylrQLYIO5R467Ov8YlRFgYKyaDFHD40j5/JHPzmtp4vjH8Si7YZZOzvTRgBYEoEgbLS5dgdr/I5ZMRKfDPCpRUbGhp9kUEdGX99o5Q== mk-remote-alert-handler-9d3ab34905da4934

Bitte beachten Sie noch, dass Ihr System eventuell so eingestellt ist, dass ein SSH-Zugriff als root generell nicht möglich ist. In diesem Fall können Sie über einen anderen Benutzer gehen und dort mit sudo arbeiten, was so konfiguriert ist, dass der gewünschte Befehl ohne Passwort ausgeführt werden kann.

Alert Handler per Regel aufrufen

Sie sind fast am Ziel. Der Agent ist bereit. Nun fehlt nur noch eine Regel, um den Alert Handler auch wirklich aufzurufen. Das Vorgehen ist wie am Anfang dieses Artikels beschrieben und geschieht über das Anlegen einer entsprechenden Regel. Wählen Sie als Handler dieses Mal Linux via SSH aus, tragen Sie den Benutzer ein, bei dem der SSH-Schlüssel installiert wurde und wählen Sie Ihren Remotehandler aus:

Setzen Sie bitte auch eine sinnvolle Bedingung in der Regel, denn sonst wird bei jedem Service-Alert versucht, eine SSH-Verbindung zum Zielhost aufzubauen!

Test

Wenn Sie den betroffenen Service jetzt z.B. von Hand auf CRIT setzen, sehen Sie nach kurzer Zeit in der Historie des Services:

Da es natürlich keinen Dienst foo gibt, klappt auch /etc/init.d/foo restart nicht. Aber Sie können daran sehen, dass dieser Befehl ausgeführt und auch der Fehlerstatus korrekt zurückgemeldet wurde. Und Checkmk hat eine Benachrichtigung ausgelöst, da sich ein Alert Handler beendet hat.

Die Meldung Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts. ist übrigens harmlos und tritt nur beim ersten Kontakt mit dem Host auf. Um den aufwendigen manuellen Austausch des Hostkeys zu vermeiden, wird SSH mit -o StrictHostKeyChecking=false aufgerufen. Bei der ersten Verbindung wird der Schlüssel dann für die Zukunft gespeichert.

8.3. Aufsetzen ohne Agent Bakery

Ein Präparieren des Agenten von Hand geht natürlich auch. Für diesen Fall empfehlen wir, dass Sie auf einem Testsystem das Verfahren mit der Agent Bakery durchführen und sich dann die betroffenen Dateien ansehen und auf Ihrem System von Hand nachbauen. Eine Liste der Pfade finden Sie hier.

Wichtig dabei ist, dass Sie auch in diesem Fall in der Agent Bakery eine Regel für die Installation der Remotehandler anlegen. Denn in dieser Regel werden die SSH-Schlüssel für dem Zugriff generiert und auch vom Alert Handler verwendet! Den Publickey für die Installation in authorized_keys finden Sie in der Konfigurationsdatei etc/check_mk/conf.d/wato/rules.mk (oder in rules.mk in einem Unterordner).

9. Relevante Dateien und Verzeichnisse

9.1. Dateien und Verzeichnisse auf dem Checkmk-Server

Pfad	Bedeutung
var/log/alerts.log	Logdatei mit allen Ereignissen rund um die Alert Handler (vom Alert Helper geschrieben).
var/log/cmc.log	Logdatei des Cores. Auch hier landen teilweise Informationen zu Alert Handlern.
local/share/check_mk/alert_handlers/	Legen Sie hier Ihre selbst geschriebenen Alert Handler ab.
var/check_mk/core/history	Logdatei der Monitoringhistorie, wird vom Core geschrieben und auch ausgewertet.
local/share/check_mk/agents/linux/alert_handlers/	Remote Alert Handler, die auf Linux-Systemen ausgeführt werden sollen.

Pfad

Bedeutung

var/log/alerts.log

Logdatei mit allen Ereignissen rund um die Alert Handler (vom Alert Helper geschrieben).

var/log/cmc.log

Logdatei des Cores. Auch hier landen teilweise Informationen zu Alert Handlern.

local/share/check_mk/alert_handlers/

Legen Sie hier Ihre selbst geschriebenen Alert Handler ab.

var/check_mk/core/history

Logdatei der Monitoringhistorie, wird vom Core geschrieben und auch ausgewertet.

local/share/check_mk/agents/linux/alert_handlers/

Remote Alert Handler, die auf Linux-Systemen ausgeführt werden sollen.

9.2. Dateien und Verzeichnisse auf dem überwachten Linuxsystem

Pfad Bedeutung

Pfad	Bedeutung
/usr/bin/mk-remote-alert-handler	Hilfsskript zur Ausführung der Remotehandler
/usr/lib/check_mk_agent/alert_handlers/	Von Ihnen geschriebene Remotehandler
/root/.ssh/authorized_keys	SSH-Konfiguration für den Benutzer `root`
~harri/.ssh/authorized_keys	SSH-Konfiguration für einen Benutzer `harri`

/usr/bin/mk-remote-alert-handler

Hilfsskript zur Ausführung der Remotehandler

/usr/lib/check_mk_agent/alert_handlers/

Von Ihnen geschriebene Remotehandler

/root/.ssh/authorized_keys

SSH-Konfiguration für den Benutzer root

~harri/.ssh/authorized_keys

SSH-Konfiguration für einen Benutzer harri

Auf dieser Seite

1. Einleitung
- 1.1. Soll das Monitoring eingreifen?
- 1.2. Alert Handler in Checkmk
2. Alert Handler einrichten
3. Regelbasierte Konfiguration
4. Wie Alert Handler ausgeführt werden
5. Alert Handler in der Historie
6. Benachrichtigungen über Alert Handler
7. Handler bei jeder Checkausführung
8. Remoteausführung unter Linux
9. Relevante Dateien und Verzeichnisse
- 9.1. Dateien und Verzeichnisse auf dem Checkmk-Server
- 9.2. Dateien und Verzeichnisse auf dem überwachten Linuxsystem