Veröffentlicht von Wäre es nicht ein Traum wenn unser Monitoring System nicht nur Probleme finden sondern auch fixen könnte? Mit Nagios Event Handler kommt man dem einen Schritt näher. Im Nagiosumfeld werden Event Händler ausgeführt, wenn sich der Status eines Checks ändert, ob von OK in WARNING oder CRITICAL oder zurück in OK ist dabei egal. So lassen sich z.B. Speicherprobleme auf einem Server beheben.
In diesem Beitrag geht es vor allem um Event Handler in der Check_MK RAW Edition, was im Hintergrund Nagios oder Icinga nutzt. Die Check_MK Enterprise Edition bringt sogenannte Alert Handlers mit. Die sind weitaus flexibler. Dafür muss für die Enterprise Edition aber auch gezahlt werden.
Folgenden Beispielcode in ~/etc/check_mk/main.mk brauchen wir um einen Eventhandler für den Check "Filesystem /" auf allen Linux Servern zu aktivieren:
extra_service_conf["event_handler_enabled"] = [
( "1", ["Linux"], ["Filesystem /"] ),
]
extra_service_conf["event_handler"] = [
( "cleanup", ["Linux"], ["Filesystem /"]),
]
extra_nagios_conf += r"""
define command{
command_name cleanup
command_line $USER2$/eventhandler_cleanup.sh $SERVICESTATE$ $SERVICESTATETYPE$ $HOSTADDRESS$
}
"""extra_service_conf["event_handler_enabled"] aktiviert Event Handler für den / die gefilterten Services.
extra_service_conf["event_handler"] bestimmt, welcher Event Handler für den / die gefilterten Services ausgeführt wird.
Wie Check_MK Filter funktionieren ist auf der Webseite von Matthias Kettner sehr gut erklärt.
Zum Schluss muss noch ein command definiert werden. In diesem Fall das Command cleanup.
Der Command übergibt dem Script $USER2$/eventhandler_cleanup.sh die Nagios Environment Variablen $SERVICESTATE$, $SERVICESTATETYPE$ und $HOSTADDRESS$.
Eine Liste aller Nagios Environment Variablen gibt es in der offiziellen Doku von Nagios3. Ebenso gibt es da natürlich die offizielle Doku zu den Event Handlers.
Das Beispielskript eventhandler_cleanup.sh gibt es in meinem Scripts Github Repository.
Es basiert auf dem Beispiel aus der Nagios3 Doku. Auf Basis von SERVICESTATE und SERVICESTATETYPE wird entschieden, wann welche Aktion ausgeführt wird.
Das Skript verbindet sich beim SERVICESTATE = WARNING/CRITICAL und SERVICESTATETYPE = HARD per SSH zur HOSTADDRESS und führt mit Unterstützung durch sudo ein cleanup.sh Skript aus.
Denn auch beim Monitoring gilt, nur so viele Rechte wie benötigt werden 😉 Das cleanup.sh Skript kann dann z.B. unnötige Logs löschen.
Wichtiger Hinweis: Nur beim ersten HARD SERVICESTATETYPE wird der Event Handler ausgeführt!
Fazit
Event Handler ermöglichen eine begrenzte Selbstheilung des Systems. Potentielle Probleme müssen aber vorher bekannt sein und Event Handler sollten immer nur gezielt eingesetzt werden. Da lässt sich dann drüber streiten, ob man nicht besser andere Mechanismen nutzt um manche Probleme gar nicht erst entstehen zu lassen. Dennoch geben die Event Handler einem viele Möglichkeiten auf Ereignisse reagieren zu können. Es muss ja nicht unbedingt ein cleanup Skript sein. Eine Art Autoscaling ließe sich damit z.B. auch umsetzen. Natürlich muss hierfür noch deutlich mehr eigener Entwicklungsaufwand reingesteckt werden 🙂
