Posted on by | Posted in synyx Blog | Tagged , ,

Warum wird ein Benachrichtigungsmanagement benötigt?

Monitoring ist wichtig, aber nicht alle Monitoring-Tests sind (nur) für System Administratoren interessant. Oft interessieren sich auch Entwickler zum Beispiel über den Zustand ihrer Anwendung und wollen darüber benachrichtigt werden, falls diese ausfällt. Die Gruppenverwaltung über Nagios gestaltet sich allerdings kompliziert und wenig Anwenderfreundlich.

Außerdem nimmt die Zahl an Nagios Checks immer weiter zu, so dass ein einfacher E-Mail Versand bei einem fehlgeschlagenen Test zu einer Überflutung des E-Mail Postfaches führen kann. Eine Limitierung und Priorisierung von Nachrichten ist hier hilfreich.

Was ist mit Benachrichtigungsmanagement gemeint?

Mit dem Benachrichtigungsmanagement ist eine Webanwendung gemeint, die es ermöglicht, aus einem Pool an Personen, Gruppen zu erstellen.
Diese Gruppen können wiederum für bestimmte Nagios Checks registriert werden, über deren Ergebnis die Mitglieder der Gruppe anschließend Benachrichtigt werden.

Was muss an Nagios vorgenommen werden, um das Benachrichtigungsmanagement zu verwenden?

Nagios wird zur Verwendung des Benachrichtigungsmanagements um zwei "commands" erweitert.
Siehe Nagios Dokumentation: Command Definition

define command {
command_name service-notify-by-notification-management
command_line curl -X POST -H "Content-Type: application/json" "http://benachrichtigungs-management.synyx.de/notifications" -d '{"nagiosCheck":{"hostname":"$HOSTALIAS$",   "servicename":"$SERVICEDESC$"}, "type":"$NOTIFICATIONTYPE$", "state":"$SERVICESTATE$"}'
}


define command {
command_name host-notify-by-notification-management
command_line curl -X POST -H "Content-Type: application/json" "http://benachrichtigungs-management.synyx.de/notifications" -d '{"nagiosCheck":{"hostname":"$HOSTNAME$"}, "type": "$HOSTSTATE$"}'
}

Diese sorgen dafür, dass das Ergebnis eines Nagios Checks per HTTP-POST an das Benachrichtigungsmanagement übertragen wird.
Nun muss noch ein "contact" definiert werden, der diese commands verwendet.
Siehe Nagios Dokumentation: Contact Definition

define contact {
contact_name notificationManagement
alias notificationManagement
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands service-notify-by-notification-management
host_notification_commands host-notify-by-notification-management
email admin@synyx.de
}

Wenn dieser contact für alle Nagios Checks registriert ist, sendet Nagios nun jedes Ergebnis per HTTP-POST an das Benachrichtigungsmanagement, in dem die Benachrichtigung weiter verarbeitet werden kann.

Wie funktioniert dieses Benachrichtigungsmanagement?

Das Prinzip des Benachrichtigungsmanagements ist, dass eine Benachrichtigung von Nagios empfangen und an interessierte Personen unter Berücksichtigung von Limitierung und Priorisierung weitergeleitet wird. Es verfügt sowohl über eine graphische Benutzeroberfläche als auch über eine RESTful API.

Gruppenverwaltung

Die Gruppenverwaltung ist derzeit so umgesetzt, dass alle Mitarbeiter aus einem LDAP abgefragt werden. Diese sind also der vorhin erwähnte Personen-Pool anhand derer Gruppen erstellt werden können. Zudem werden automatisch Gruppen anhand der LDAP-Gruppen erstellt.
Sollten diese nicht ausreichen, lassen sich weitere Gruppen über die API oder über die graphische Oberfläche bilden.

Diesen Gruppen können dann explizit Nagios Checks zugewiesen werden, so dass die Mitglieder der Gruppe über den Status des Nagios Checks per E-Mail informiert werden.
Damit diese E-Mails nicht das E-Mail Postfach überfluten, existiert eine Möglichkeit, die Anzahl an E-Mails in einem selbst definierten Zeitintervall einzuschränken.
Dies ist ebenfalls, sowohl über die API als auch über die graphische Oberfläche möglich.

Um dies zu veranschaulichen, folgt nun ein Beispiel.
NNM_Checks

Im Bild wird aus der Liste der verfügbaren Nagios Checks nach "Urlaub" gefiltert. Anschließend soll einem dieser Nagios Checks die Gruppe "Urlaubsverwaltung" zugeordnet werden, die über Änderungen am Zustand des Checks informiert werden soll. Dies ist im nächsten Bild zu sehen.
NNM_Map_UV

Sobald die Gruppe ausgewählt wurde, wird sie als zugeordnete Gruppe angezeigt. Alle Mitglieder der Gruppe "Urlaubsverwaltung" werden nun über Zustandsänderungen dieses Nagios Checks benachrichtigt.
NNM_UV_Mapped

Limitierung von Nachrichten

Die Limitierung von Nachrichten funktioniert, anhand einer nutzerspezifischen Konfiguration. Es besteht hier die Möglichkeit die Anzahl an E-Mails in einem selbst definierten Zeitintervall einzuschränken. Standardmäßig werden bis zu 10 Benachrichtigungen in einem Zeitraum von 30 Minuten verschickt. Alle Benachrichtigungen, die über dieses Limit hinaus eintreffen, werden in eine Queue geleitet, die alle 10 Sekunden überprüft wird.

Zu Berücksichtigen ist hierbei, dass Benachrichtigungen über ein positives Ergebnis eines Nagios Checks ('RECOVERY' oder 'UP') nicht von dieser Limitierung betroffen sind. Wenn also ein Test in der Zwischenzeit wieder erfolgreich durchlaufen werden konnte, wird darüber auf jeden Fall informiert. Ebenso zählen diese Erfolgsbenachrichtigungen nicht in das Limit der versandten Nachrichten hinein. Sollten noch Fehlerbenachrichtigungen (PROBLEM, DOWN) in der Queue sein, werden diese bei einer später eintreffenden Erfolgsbenachrichtigung aus der Queue entfernt.

Priorisierung von Nachrichten

Damit wichtige Benachrichtigungen nicht von unwichtigeren bereits versandten Benachrichtigungen blockiert werden, existiert zudem eine Priorisierung von Benachrichtigungen basierend auf dem Host des Nagios Checks. Befindet sich beim Abarbeiten der Queue eine Nachricht mit höherer Priorität als eine der bereits versandten Benachrichtigungen, wird diese dennoch verschickt. Dabei wird die unwichtigste Benachrichtigung aus der List der bereits versandten Benachrichtigungen mit der Neuen ersetzt.

Zur Priorisierung werden alle zu überwachenden Hosts abgefragt und mit Tags versehen. Diese Tags sind selbst zu erstellen und mit einer Gewichtung zu versehen. Die Zuweisung der Tags funktioniert automatisch über selbst definierbare Namensregeln. So kann zum Beispiel jedem Host mit einem Hostnamen, der "-test" enthält das Tag "Testsystem" zugewiesen werden. Jeder Host, der kein "-test" in einem Hostnamen hat wird dagegen mit dem Tag "Produktivsystem", welches eine höhere Gewichtung haben könnte, versehen.
Die Verwaltung von Tags und Regeln ist ebenfalls sowohl über die API als auch über die graphische Oberfläche möglich.

Temporäres deaktivieren von Nagios Checks via Ticketsystem

Oft kommt es auch dazu, dass bestimmte Nagios Checks zeitweise uninteressant werden. Zum Beispiel dann, wenn ein Projekt pausiert und die Maschine daher keine Priorität mehr hat. Man möchte in dieser Zeit keine weiteren Benachrichtigungen über fehlgeschlagene Nagios Checks erhalten. Daher wurde eine Möglichkeit geschaffen, einem Nagios Check ein Ticket aus dem Ticketsystem zuzuordnen. Dies sorgt dafür, dass der Nagios Check deaktiviert wird, bis das Ticket geschlossen wird. So hat man einen Überblick darüber, welche Nagios Checks aus welchen Gründen und für welche Dauer ausgeschaltet sind.

Was ist noch denkbar?

Überlegungen sind unter anderem zusätzliche Benachrichtigungswege (SMS,IRC, ..), so dass zum Beispiel bei Benachrichtigungen besonders hoher Priorität zu bestimmten Uhrzeiten SMS verschickt werden können, um über kritische Zustände zu informieren.
Ebenso ist eine nutzerspezifische Priorisierung von expliziten Nagios Checks denkbar.



Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.