aus PUG, der Penguin User Group
Navigation
Benachrichtigungen
- Im Idealfall ist die Welt friedlich und alle Computer der Welt gehen einem tadellosen Job nach. Im Idealfall. Leider geht dieser Wunsch nur selten in Erfüllung, so auch in der Computerwelt. Nagios gibt uns die Möglichkeiten an die Hand, dafür zu sorgen, bei Problemen möglichst schnell einzugreifen. Damit dies geschieht, müssen wir über einen Vorfall informiert werden. Dies kann zum einen über die Webseite geschehen, oder über andere Wege. Dabei spielt es keine Rolle, ob dies eine E-Mail ist, eine SMS, oder gar mit einer waschechten Ampel. Dank des Benachrichtigungssystems und dem Eventhandler (löst eine Aktion auf ein Ereignis aus), stehen uns vielfältige Möglichkeiten zur Verfügung.
- Die Herausforderung besteht nicht so sehr darin, überhaupt eine Nachricht zu erhalten, sondern dafür Sorge zu tragen, dass der Mitarbeiter (in der Regel derjenige, der Nagios eingerichtet hat) nicht in Nachrichten ertrinkt. Zuviele Nachrichten lassen den Empfänger schnell Filter einrichten, um sich dieser Meldungen zu entledigen. Da kann es schnell passieren, dass wichtige Meldungen unter den Tisch fallen (od. eben in den Papierkorb).
- In diesem Teil der Anleitung wird eine Möglichkeit aufgezeigt, um der Meldungen Herr zu werden und auch zu bleiben.
Benachrichtigungs-Plan
- Alles Überwachen nützt nichts, wenn nicht klar ist, wer diese Nachrichten empfangen soll. Dafür gibt es unterschiedliche Strategien. In diesem Plan stellt der Autor folgende Kriterien auf:
- Es gibt vier Gruppierungen
- Jede Gruppe steht für eine bestimmte Priorität
- Warnmeldungen werden ausschließlich auf der Webseite angezeigt und nicht versandt
- In der höchsten Priorität werden die Administratoren per SMS, per direkter Mail und per Ticketsystem informiert. In allen weiteren Prioritäten nur noch per Ticketsystem.
- Meldungen gehen verzögert raus, für den Fall, dass das Problem sich erledigt, oder der Administrator das Problem bereits kennt.
- Jeder Plan lässt sich optimieren, so auch dieser. Besonders Punkt 3. Dies ist dem Fall geschuldet, dass das Ticketsystem selbst betroffen sein sollte und das Handy nicht in Reichweite liegt. Auf diese Weise bleibt zumindest noch die Chance, über ein Problem informiert zu werden, sofern der Benutzer nicht schon selbst diese Aufgabe übernommen hat.
OTRS - Der Grund
- Für den Einsatz eines Ticketsystems sprachen vielerlei Dinge und vor allem ein Grund sticht dabei heraus: man kann es :-) Ein Ticketsystem stellt sicher, dass ein Problem nicht nur gemeldet, sondern auch abgearbeitet wird. Zu schnell wird eine Aufgabe nach unten delegiert und gerät damit leicht in Vergessenheit.
- Des weiteren ist ein Ticketsystem immer von Vorteil, wenn es darum geht, die Flut von Aufgaben in die richtige Richtung zu lenken und nach Priorität sowie Eingangszeit abzuarbeiten.
- Hat sich dieses System erst einmal mit Nagios etabliert, kann es parallel auch für andere Einsätze verwendet werden.
- Die Wahl von OTRS liegt darin begründet, dass es ein ausgewachsenes System ist, welches sich in vielen Bereichen etabliert hat. Ein besonders interessanter Grund ist das Monitoring-Modul, welches seit geraumer Zeit verfügbar ist. Es untersucht eingehende Nachrichten und durchsucht sie auf bestimmte Schlüsselwörter. Im Falle von Nagios auf Wörter wie Warning und Critical etc. . Findet es eine entsprechende Nachricht, so können diverse Filtermöglichkeiten in Aktion treten.
- In unserem Fall sorgt dieses Modul dafür, dass nicht nur automatisch Tickets erzeugt werden - sofern nicht bereits eines zu dem selben Problem besteht - sondern auch in die passende Warteschlange (Queue) verschoben werden. Von dort können dann die Ticket weitergeleitet werden, welches auch eine automatische Eskalation nach sich ziehen kann.
Die Umsetzung
- Dank der Templates können wir recht einfach und schnell unsere Services und Hosts mit unseren gewünschten Benachrichtigungen ausstatten. Ein Beispiel für die Services:
- /usr/local/nagios/etc/objects/templates.cfg
|
|
[...]
notifications_enabled 1 ; Benachrichtigungen aktivieren
contact_groups otrs ; an die Gruppe OTRS
check_period 24x7 ; 24 Stunden, 7 Tage die Woche prüfen
max_check_attempts 4 ; Nach wie vielen fehlgeschlagenen Checks ist ein Zustand als ''Hart'' definiert.
normal_check_interval 10 ; Alle 10 Minuten prüfen
retry_check_interval 5 ; Bei Problemen alle 5 Minuten testen
notification_options u,c,r ; Wann geht eine Nachricht raus
notification_interval 180 ; Eine neue Nachricht wird erneut alle 180 gesendet.
notification_period 24x7 ; Nachrichten gehen zu jeder Zeit raus.
|
- In diesem exemplarischen Beispiel würde die erste Mail - sofern ein Problem auftritt - nach 20 Minuten versandt werden. Ob diese zeitliche Spanne zu lang ist, muss jeder Nagios-Administrator für sich entscheiden.
|
|
notifications_enabled 1 ; Benachrichtigungen aktivieren
event_handler_enabled 1 ; Eventhandler aktivieren
flap_detection_enabled 1 ; Schnell wechselnde Zustände anzeigen
check_period 24x7 ; Rund um die Uhr prüfen
check_interval 5 ; Alle 5 Minuten nachschauen, ob der Rechner noch lebt
retry_interval 1 ; bei Problemen jede Minute erneut prüfen
max_check_attempts 10 ; max. 10 Mal prüfen
notification_period 24x7 ; Wann sollen die Administratoren aus ihrem Schlaf geholt werden dürfen
notification_interval 120 ; Alle zwei Stunden eine neue Nachricht.
notification_options d,u,r ; Nachricht bei Down, Up, Recover
contact_groups otrs ; Mails gehen an das OTRS
|
- Jeder dieser Einträge in der Template kann entsprechend von dem jeweiligen Host od. Service-Eintrag überschrieben werden. Dies ist in jedem Fall sinnvoll, wenn von vornherein klar ist, dass bestimmte Hosts od. Services nicht immer verfügbar sind, weil sie z.B. nach Feierabend ausgeschaltet werden.
- Daher gilt es im Vorfeld abzuklären, wie der Benachrichtigungs-Plan aussehen soll.
|
|
- Per Default sind bereits in der Datei /usr/local/nagios/etc/objects/commands.cfg die entsprechenden Kommandos definiert, welche die Mails versenden. Dafür wird das Kommando /bin/mail aufgerufen, welches unter Debian aber unter /usr/bin/mail zu finden ist. Daher entweder die Kommandos notify-host-by-email und notify-service-by-email korrigieren, od. einen Symlink erstellen.
|
- Nun müssen wir OTRS vorbereiten, damit es die entsprechenden Tickets erstellt und auch bei einer Wiederherstellung des Dienstes od. Rechners, dieses auch wieder selbsttätig geschlossen wird.
- Als nächstes benötigen wir, gemäß unserer Strategie, entsprechende Queues im OTRS. Sie sind schnell im Admin-Menü über »Queues« angelegt. Dabei habe ich folgende Aufteilung gewählt:
|
|
Einmal erstellte Benutzer, Queues etc. können nicht mehr gelöscht werden. Sie lassen sich lediglich als Ungültig deklarieren.
|
- In der Queue »Nagios« landen alle Nagios-Tickets, welche noch nicht einer Priorität zugeordnet wurden. Auf diese Weise kann man zwischen "Weniger wichtig" und "Sehr wichtig" sortieren lassen.
- Dafür wird OTRS um ein Modul erweitert, welches SystemMonitoring heißt und hier zu beziehen ist. Es durchsucht eingehende Nachrichten und fahndet nach Schlüsselwörtern wie »OK« »Down« »Recover« etc. . Kommt eine weitere Nachricht hinein, die einem vorher erstellten Ticket entspricht, so wird die Nachricht entweder kommentarlos gelöscht, od. im positiven Fall: das Ticket geschlossen.
- Damit dies funktioniert, bedarf es eines E-Mail Kontos, welches vom OTRS abgerufen werden kann. Es sollte ein POP3-Zugang sein, da IMAP nur über fetchmail funktioniert.
- Dazu begeben wir uns im OTRS-Admin-Menü zum »PostMaster POP3 Account« und richten dort den entsprechenden Benutzer ein. Die Einstellungen sollten in etwa ausschauen, wie auf diesem Bild:
- Um die E-Mails dem richtigen Benutzer zustellen zu können, bedarf es noch einer Bekanntmachung der E-Mail-Adresse im System. Dazu begeben wir uns erneut im Admin-Menü auf »E-Mail Adressen« und weisen ihr die entsprechende Haupt-Queue Nagios zu.
- Als nächstes sollte das SystemMonitoring-Modul installiert werden. Wer - wie in unserem Fall - Apache2 und mod_perl2 verwendet, darf das Modul über die Webseite installieren. Dafür reicht es im Admin-Menü den Punkt »Paket Verwaltung« auszuwählen und das Modul hochzuladen.
- Wer nur Apache1.x mit mod_perl nutzen kann od. darf, kann die Erweiterung auch über die Konsole nachinstallieren.
- Davon ausgehend, dass das Modul im /tmp-Ordner des OTRS-Rechners liegt, ist folgender Befehl von Nöten:
|
|
master: ~# /usr/local/otrs/bin/opml.pl -a install -p /tmp/SystemMonitoring-1.0.2.opm
|
- Auf die selbe Weise können auch alle anderen Module installiert werden. Es muss im Anschluss nicht konfiguriert werden, da es bereits mit Nagios zusammenarbeitet. Es muss lediglich die Adresse vom Nagios eingetragen werden. Daher finden wir die Konfiguration ein wenig versteckt unter »Admin -> SysConfig -> Gruppe SystemMonitoring (1) (Links Mitte) -> Core::PostMaster«
- Es zeigt sich dann folgendes Bild:
- In der »FromAddressRegExp« wird dann die Adresse eingetragen.
- Ist das geschehen, bedarf es nur noch der Konfiguration der Filter. Dafür zeichnet das Modul »PostMaster Filter« verantwortlich, natürlich ebenfalls nur im Admin-Menü zu finden.
- Dort können wir nun die entsprechenden Filter konfigurieren. Ein Beispiel findet sich auf diesem Bild:
- Kommt nun eine entsprechende Mail, wird sie in die Queue Nagios/prio1 einsortiert. Löst sich das Problem auf, so wird das Ticket dort verschwinden.
Quellen, ToDo Liste etc.
- Da natürlich heute ohne Quellen auskommt, folgt auf dieser Seite die entsprechenden Links und auch die toDo Liste.
