Alerthandler


1. Einleitung

1.1. Soll das Monitoring eingreifen?

Man möchte meinen, es sei offensichtlich, dass ein Moni­toringsystem 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 Alerthandlern anfangen können.

1.2. Alerthandler in Check_MK

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

Alerthandler sind sehr ähnlich zu Alarmierungen und werden auch ähnlich konfiguriert, aber es gibt ein paar wichtige Unterschiede:

  • Alerthandler sind unabhängig von Wartungszeiten, Alarmierungsperioden, Quittierungen und ähnlichen Einschränkungen.
  • Alerthandler werden auch schon beim ersten Wiederholversuch aufgerufen (falls Sie mehrere Checkversuche konfiguriert haben).
  • Alerthandler sind unabhängig von Benutzern und Kontaktgruppen.
  • Alerthandler gibt es nur in der  Check_MK Enterprise Edition.

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

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

Noch ein Hinweis für Benutzer der  Check_MK 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. Alerthandler einrichten

2.1. Skripte in das richtige Verzeichnis legen

Alerthandler sind Skripten, die auf dem Check_MK-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.0i1: 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 Alerthandler zum Testen

Wie bei den Alarmierungen bekommt das Skript alle Informationen über den Host oder Service als Umge­bungs­variablen, 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. Alerthandler aktivieren

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

  1. Legen das obige Skript unter ~/local/share/check_mk/alert_handlers/debug an.
  2. Machen Sie es mit chmod +x debug ausführbar.
  3. Rufen Sie das WATO-Modul Alert handlers auf.
  4. Legen Sie dort mit eine neue Regel an.

Bis Version 1.2.8 müssen Sie den Namen des Handlers von Hand in der Regel eingeben. Geben Sie als Name hier debug an, speichern Sie und und aktivieren Sie die Änderungen.

Bei der Auswahl des Alerthandlers können Sie ihm Aufrufargumente mitgeben (Call with the following paramaters). Diese kommen beim Skript als Kommandozeilenargumente an. In der Shell können Sie darauf mit $1, $2 usw. zugreifen.

Ab Version 1.4.0 erlaubt die Maske direkt eine Auswahl des Alerthandlers und zeigt dazu jeweils die in der zweiten Zeile der Skripten hinterlegten Titel an:

Nach dem Speichern der Regel ist der Alerthandler 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 Alerthandler 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 Alerthandler auf der Standardausgabe ausgibt, erscheinen in der Logdatei neben Output:.
  • Auch der Exitcode des Skripts wird geloggt (exited with exit code 0).
  • Alerthandler sind erst wirklich nützlich, wenn Sie auf dem Zielhost ein Kommando ausführen. Für Linux bietet Check_MK 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 Alerthandler auslösen sollen. Das Ganze funktioniert völlig analog zu den Alarmierungen, 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 Alerthandler für ganz bestimmte Hosts und Services festlegt:

Der Alerthandler wird nur aufgerufen, wenn

  • einer der Hosts server123 oder myserver123 betroffen ist,
  • es um den Service JVM CaramaKern 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 eine Alarmierung 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 Alarm mehr notwendig sein.

Noch ein Hinweis: Anders als an anderen Stellen von Check_MK, wird bei den Alerthandlern 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 Alerthelper 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 Alerthandler ausgeführt werden

4.1. Asynchrone Ausführung

Sehr oft werden Alerthandler 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 Alerthandler aufgehalten werden dürfen, werden Alerthandler grundsätzlich asynchron ausgeführt. Verantwortlich dafür ist ein Hilfsprozess – der Alerthelper – welcher vom CMC automatisch gestartet wird. Um Overhead zu vermeiden, geschieht dies allerdings nur, wenn Sie mindestens eine Regel für Alerthandler 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 Alerthelper bekommt vom CMC bei jeder Zustandsänderung eines Hosts oder Services eine Alert­benachrichtigung mit allen Informationen zu dem Ereignis. Nun wertet er alle Alertregeln 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 Alerthelper 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 Alerthandlers ein Timeout von (einstellbar) 60 Sekunden. Nach Ablauf dieser Zeit wird der Handler beendet. Ab Version 1.4.0i1 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.0i1 verhindert Check_MK die gleichzeitige Ausführung von Alerthelpern, 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

Bis zur Version 1.2.8 werden Ausgabe und Exitcode der Alerthandler lediglich in alerts.log protokolliert. Ab Version 1.4.0i1 werden diese Informationen sauber ausgewertet, zum Core zurück transportiert und dort in die Historie des Monitorings geschrieben. Außerdem können sie zu einer Alarmierung führen (siehe unten).

4.6. Globale Einstellungen

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

Das Logging of the alert processing in the core bezieht sich auf die Phase, bis der CMC eine Nachricht an den Alerthelper schickt (cmc.log). Das Alert handler log level hingegen beeinflusst das Logging im Alerthelper (alerts.log).

4.7. Master control

Mit einem Klick in der Master control können Sie Alert­handler 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. Alerthandler in der Historie

Ab Version 1.4.0i1 erzeugen Alerthandler 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 Alerthandler gestartet wird und auch wenn er sich beendet.

Die Alerthandler 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 "OK - 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):

Neu ist auch die globale Ansicht Other ➳ Alert handler executions, welche alle Ausführungen von Alerthandlern global darstellt.

6. Alarmierung über Alerthandler

Neu in Version 1.4.0i1 ist auch, dass das Ausführen eines Alerthandlers – genauer gesagt die Beendigung der Ausführung – ein Ereignis ist, das zu einer Alarmierung 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 Alarmierungsregel filtern können:

Sie können also auch zwischen erfolgreich ausgeführten Handlern (Exitcode 0 - OK) und gescheiterten (alle anderen Codes) unterscheiden. Die Emailalarmierung von Check_MK wurde so angepasst, dass Alerthandleralarme, anstelle der Ausgabe des Checks, nun die Ausgabe des Alerthandlers zeigen.

7. Handler bei jeder Checkausführung

Normalerweise werden Alerthandler 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 Alerthandler 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 Alerthandler aus. Sie können das z. B. Nutzen, um die laufenden Monitoringdaten 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. Check_MK kann spielend 1000 Checks pro Sekunde durchführen – aber 1000 Alerthandlerskripten pro Sekunde schafft Linux ganz sicher nicht.

Um das Ganze dennoch sinnvoll möglich zu machen, bietet Check_MK die Möglichkeit, Alerthandler 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 funktio­nierendes 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 Umgebungs­variablen, 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 Check_MK-Instanz.

Die Funktionen handle_init() und handle_shutdown() werden von Check_MK 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 Alerthelper von Check_MK ruft Ihre Funktionen synchron auf. Achten Sie darauf, dass keine Wartezustände entstehen!

8. Remoteausführung unter Linux

8.1. Grundprinzipien

Version 1.4.0i1 bringt einen Alerthandler 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 Agentbakery aufgesetzt werden.

Die Linux Remote Alert Handler bestehen aus folgenden Einzelteilen:

  • Der Alerthandler linux_remote mit dem Titel „Linux via SSH“ auf dem Check_MK-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.
  • Alerthandlerregeln, 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 Agentbakery arbeiten, legen Sie das Skript auf dem Check_MK-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 Alerthandler dies als CRIT werten wird.

Agentenpaket mit dem Handler vorbereiten

Wir beschreiben hier das Vorgehen mit der Agentenbakery. Hinweise für ein Aufsetzen von Hand finden Sie weiter unten. Legen Sie eine Regel unter Monitoring Agents ➳ Install 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üssel­paar für den Aufruf des Handlers „ausgewürfelt“, dessen Fingerprint in der Regel angezeigt wird:

Der öffentliche Schlüssel ist für den Agenten vorgesehen. Der private Schlüssel wird vom Check_MK-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 Check_MK-Agent installiert den SSH-Schlüssel nur auf Systemen, wo dieser Benutzer bereits existiert.

Agenten backen

Backen Sie nun neue Agenten mit . In der Liste der fertigen Agenten muss nun ein Eintrag auftauchen, in dem Sie wieder Ihren Remotehandler und SSH-Schlüssel sehen:

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.

Alerthandler per Regel aufrufen

Sie sind fast am Ziel. Der Agent ist bereit. Nun fehlt nur noch eine Regel, um den Alerthandler 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 Servicealarm 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 Check_MK hat eine Alarmierung ausgelöst, da sich ein Alerthandler 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 -oStrictHostKeyChecking=false aufgerufen. Bei der ersten Verbindung wird der Schlüssel dann für die Zukunft gespeichert.

8.3. Aufsetzen ohne Agentbakery.

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 Agentbakery 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 Agentbakery 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 Alerthandler 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 Check_MK-Server

Pfad Bedeutung
var/log/alerts.log Logdatei mit allen Ereignissen rund um die Alerthandler (vom Alerthelper geschrieben).
var/log/cmc.log Logdatei des Cores. Auch hier landen teilweise Informationen zu Alerthandlern.
local/share/check_mk/alert_handlers/ Legen Sie hier Ihre selbst geschriebenen Alerthandler 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-Alerthandler, die auf Linux-Systemen ausgeführt werden sollen.

9.2. Dateien und Verzeichnisse auf dem überwachten Linuxsystem

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