SNMP-Traps als passive Dienste nutzen

Es gibt mehrere Möglichkeiten, mit SNMP-Traps umzugehen. Hier ist eine beschrieben, die ergänzend zu einigen anderen Verfahren wirken kann und im Prinzip die Lösung von Ethan umsetzt. Ob die Umsetzung dieser Art sinnvoll ist oder nicht, müsst Ihr für Eurer System selbst entscheiden.

In dieser Beschreibung wurden der SNMP Trap Translator und Nagtrap (hier optional) verwendet.

Durch den SNMP Trap Translator kann viel Handarbeit gespart werden. Der SNMPTRAPD aus dem NET-SNMP Paket nimmt die Traps entgegen, in seiner Konfigurationsdatei muss ein entsprechender „traphandle“ definiert sein, damit die Traps an SNMPTT weitergegeben werden. Dieser Artikel verzichtet auf eine ausführliche Installationsanleitung, da diese auf der SNMPTT-Homepage gut beschrieben ist.

Die Management Information Base sollte auf der CD/DVD oder auf der Homepage des Geräteherstellers zu finden sein. Die MIB kann mit Hilfe von snmpttconvertmib in das richtige Format konvertiert werden.

snmpttconvertmib --in=mib.file --out=dateiname.conf

Alternativ kann dem Befehl direkt ein EXEC-Statement mitgegeben werden:

snmpttconvertmib --net_snmp_perl --exec='/etc/nagios/eventhandlers/submit_check_result' Parameter' --in=mib.file --out=dateiname.conf

Wenn das Konvertieren erfolgreich war, sollte in jeder Trap-Definition eine Liste der Variablen, die der Trap enthält, angegeben sein. Dies ist im folgenden Beispiel zu sehen:

#
EVENT jobSuccess .1.3.6.1.4.1.1302.3.1.2.8.0.3 "Status Events" INFORMATIONAL
FORMAT Kein Eingriff erforderlich: $1 Auftrag:$3 $4
SDESC
Auftrag erfolgreich
Variables:
1: messageText
2: serverName
3: jobName
4: additionalText
EDESC
#

Es sollte beim Konvertieren auf den Status-Bericht des Tools geachtet werden: Ließen sich wirklich alle Traps konvertieren? Wenn Probleme beim Konvertieren auftreten, hilft vielleicht schon eine Suche im Nagios-Forum.

Nun könnte die fertig konvertierte MIB mit Hersteller- und Geräte Informationen ins Wiki geschrieben werden, um sie anderen zur Verfügung zu stellen

Die Datei mit den definierten Traps (im SNMPTT-Format) muss nun in die snmptt.ini eingetragen werden, damit diese beim Starten von SNMPTT bereit stehen.

Für zusätzliche Informationen zum MIB- und SNMPTT-Format ist hier im Wiki sicher immer Platz.

Dieses Skript von Ethan gehört zu den von Nagios mitgelieferten Skripten. Es setzt ein Ereignis in ein für Nagios verständliches Format um und schreibt es in die externe Verarbeitungsdatei. (Das heißt, das die Verarbeitung von externen Befehlen erlaubt sein muss.)

Das Skript erwartet die folgenden Parameter:

• Hostname
• service_description
• Return Status ( WARNING, CRITICAL, OK, UNKNOWN )
• service_output

Möglicherweise muss diese Skript noch auf die Systembedürfnisse angepasst werden (Pfade etc.). Wenn ein Gerät in seinen Traps seinen eigenen Hostnamen in Großbuchstaben übermittelt, kann es zu Problemen kommen. Dafür schafft diese kleine Erweiterung Abhilfe:

servername=`echo $1|tr '[:upper:]' '[:lower:]'`

Jetzt kann die konvertierte MIB-Datei bearbeitet werden, wir gehen hier von einem Windows 2003 Server aus, der eine Datensicherungssoftware installiert hat. Für jeden Status der Datensicherung schickt die Software mit Hilfe von SNMP einen Trap an den Nagios-Server.

Die Trap-Definition wurde hierbei um ein EXEC-Kommando erweitert, welches das submit_check_result-Skript ausführt.

EXEC /etc/nagios/eventhandlers/submit_check_result.sh "$2" "Datensicherung Status" 2 "Datensicherung $3 fehlgeschlagen"

Der erste zu übergebene Parameter ist der Hostname. Er ist die zweite Variable im eingegangenen Trap, gefolgt von der Servicebeschreibung, dem Returncode (Warning) und einer möglichst sprechenden Fehlermeldung.

Um das Ganze theoretisch durchzugehen:

• Backup läuft nicht durch
• System sendet ein SNMP-Trap-Paket an den Nagios-Server
• Der SNMPTRAPD nimmt das Paket entgegen, leitet es an SNMPTT weiter
• SNMPTT schaut in den gecached MIB-Files, ob die OID des Traps zu finden ist
• Es wird das EXEC-Statement ausgeführt (siehe oben)
• In Nagios wechselt innerhalb weniger Sekunden der Service auf WARNING
• Ein Mitarbeiter der IT wird darauf durch die üblichen Benachrichtigungen aufmerksam
• Der Mitarbeiter hat das Problem gelöst
  1. Er gibt mit „submit passive check results“ einen neuen Status des Services durch
  2. Oder er wirft die Datensicherung erneut an, der neue Trap überschreibt dann den Status des Services

Hier muss die aktive Dienstüberprüfung zu einer passiven gemacht werden, man siehe die folgenden Parameter. Die Option „is_volatile“ sollte hier aktiviert werden.

define service{
   use                     generic-service-traps
   host_name               Server
   service_description     Datensicherung Status
   is_volatile             1
   max_check_attempts      1
   passive_checks_enabled  1
   active_checks_enabled   0
   check_command           check_none
}

Wichtig ist hier das die Service Beschreibung, der im EXEC Statement definierten identisch ist. Nagios ordnet anhand dessen den Eintrag in der „nagios.cmd“, dem entsprechenden Service zu.

In diesem Beispiel gehören also alle Traps eines Gerätes zu einem Service. Der Service behält solange den gleichen Status, bis ein neuer Trap eintrifft oder er manuell über das Web-Frontend aktualisiert wird. ( submit passive check results )

Optional zu diesem Verfahren kann die Datenbank Funktion von SNMPTT eingeschaltet werden und Nagtrap installiert werden. So hat man eine zusätzliche Historie über die eingegangenen Traps. Das zu Nagtrap zugehörige Check Plugin könnte mit „urlize“ als service zu dem host eingebunden werden, so das bei Bedarf halt dem Link zu nagtrap gefolgt werden kann.

Es muss nicht immer sinnvoll sein die oben beschriebene Verfahrensweise anzuwenden. Zum einen Bedarf es sicherlich einigen Traps von anderen Geräten an etwas mehr Logik, wo zwischen dem SNMPTT und dem Skript von Ethan ein weiteres Shell Skript steht. Des weiteren ist die Frage ob alle Traps zu einem Gerät als 1 Service dargestellt werden sollen. Hier kann jeder selbst für sich die Vor- oder Nachteile entscheiden.