Monitoring mit SNMP: Stories from hell

Wer mit SNMP seine Netzwerkumgebung überwacht, profitiert davon, dass viele Hersteller das Simple Network Management Protocol mit ihren Geräten unterstützen. Da sich das Protokoll seit seiner Einführung vor über 30 Jahren zum De-facto-Standard im Netzwerk-Monitoring etabliert hat, hat nahezu jeder Hersteller einen SNMP-Agenten auf seinen Geräten integriert. Leider handhaben jedoch einige die SNMP-Implementierung auf ihren Komponenten nicht so, wie es vom Standard vorgegeben ist.

Da viele Checkmk-Nutzer ihre Netzwerkumgebungen mit SNMP monitoren, wissen wir aus erster Hand, dass schlechte SNMP-Umsetzungen unter den Herstellern leider keine Seltenheit sind. In diesem Artikel wollen wir einige typische Beispiele von fehlerhaften SNMP-Implementierungen aus unserem Fundus vorstellen.

SNMP liefert falsche Daten

Setzen die Entwickler eines Herstellers das SNMP-Protokoll nicht sauber um, kann es passieren, dass der Agent unübersichtliche oder gar falsche Daten liefert, nicht performant ist, dem SNMP-Standard gar nicht entspricht beziehungsweise schlichtweg nicht funktioniert. Für das Monitoring der Netzwerkumgebung bringt das unterschiedliche Probleme mit sich, da es dadurch schwieriger ist, an die erforderlichen Daten zu gelangen.

Häufig ist es möglich, mit Checkmk über verschiedene Standard-MIBs, etwa Host-Resources und UCD, an die nötigen Monitoring-Informationen zu gelangen. Dies ist jedoch problematisch, wenn beide MIBs beispielsweise unterschiedliche Werte über den Arbeitsspeicher liefern. Das kann daran liegen, dass eine MIB einen falschen Wert bereitstellt, während die andere die richtige Information übermittelt. Theoretisch kann es auch passieren, dass beide MIBs falsche Werte bereitstellen. Wie OIDs und MIBs funktionieren, können Sie in unserem ersten Artikel zum Thema Network Monitoring mit SNMP nachlesen.

Liefert der SNMP-Agent widersprüchliche oder gar falsche Daten, muss der Administrator mit der Try-and-Error-Methode herausfinden, welcher Wert richtig oder falsch ist und die falsche Information aus dem Monitoring nehmen. Das hört sich sehr aufwendig an. Die gute Nachricht ist, dass Checkmk häufig schon weiß, welche Werte falsch sind, sodass es die Fehlinformationen automatisch ignoriert. Das hat damit zu tun, wie Checkmk beim SNMP-Monitoring vorgeht:

Beim SNMP-Monitoring ist Checkmk bei der Service-Erkennung in der Lage, einen kompletten Abzug aller SNMP-Daten (SNMP-Walk) zu machen und anschließend nach den interessanten Informationen Ausschau zu halten. Da dies bei einigen Geräten jedoch mehrere Stunden dauern würde, ruft Checkmk zunächst nur die beiden ersten OIDs auf, die sysDescr und sysObjectID. Bei der sysDescr handelt es sich um die Beschreibung des Geräts, die der Hersteller in der Firmware festgelegt hat. Dieser Text ist für Checkmk wichtig für die automatische Erkennung von Services. Abhängig vom erkannten Gerät erfolgen danach weitere Abfragen, um zu ermitteln, welche der über 1.000 mitgelieferten SNMP-Check-Plugins für das Gerät in Frage kommen. Das Ergebnis eines Scans auf einen Switch könnte zum Beispiel so aussehen:

SNMP scan found hr_mem if64 ucd_mem mgmt_snmp_uptime snmp_info snmp_uptime
SNMP filtered check plugin names hr_mem if64 snmp_info snmp_uptime

Wie wir sehen hat Checkmk relevante Daten teilweise an mehreren Stellen im OID-Baum gefunden, hier zum Beispiel mgmt_snmp_info und  snmp_uptime, daher wird die finale Liste der zutreffenden Checks gefiltert. Sollte bereits bekannt sein, dass eine dieser gefundenen OIDs fehlerhafte Werte liefert, sortiert Checkmk diese direkt aus. In diesem Beispiel hat sich Checkmk für hr_mem entscheiden, da dieses Gerät dafür bekannt ist, in ucd_mem fehlerhafte Daten bereitzustellen.

Im nächsten Schritt läuft dann die eigentliche Service-Erkennung. Die in der Scan-Phase ermittelten Check-Plugins rufen nun mit Hilfe von örtlich begrenzen SNMP-Anfragen gezielt die Daten ab, die sie benötigen. Basierend auf den erhaltenen Werten, ermitteln sie anschließend die zu überwachenden Services. Dies ist die sogenannte Discovery-Phase.

Hinweis: Die zugrunde liegende Checkmk-Funktion heißt aus historischen Gründen im Code noch inventory_function, mit der Einführung der Hard- und Software-Inventarisierung haben wir die Darstellung in der GUI auf Check_MK Discovery geändert, um Missverständnisse zu vermeiden.

Die dritte und letzte Phase ist die sogenannte Check-Phase. Diese wird bei jedem Check-Zyklus ausgeführt und ruft die OIDs ab, die Checkmk in der Discovery-Phase gefunden hat.

1⁄10 Äpfel oder Birnen?

Wie wir gesehen haben, kann es vorkommen, dass Geräte nicht nur einen oder mehrere falsche Werte liefern. Dies ist aber bei weitem nicht die einzige Fehlermöglichkeit. Für ausreichend Gesprächsstoff in der Entwickler-Kaffeeküche sorgen immer wieder undefinierte oder falsch deklarierte Einheiten. So kommt es immer mal wieder vor, dass der Gerätehersteller zwar Grad Celsius als Einheit angibt, der implementierende Entwickler jedoch Fahrenheit in der OID ausgibt.

Es gab auch schon die ganz kreative Umsetzung, dass in der Herstellerdokumentation zwar von Grad Celsius gesprochen wurde, jedoch der entscheidende Hinweis fehlte, dass der Ausgabewert 1⁄10  °C entspricht.

Eine mangelhafte Dokumentation beziehungsweise kreative Umsetzung auf Seiten des Herstellers kann darüber hinaus zu weiteren Verwirrungen führen. Die Ausgabe von „0°C“ dafür zu nutzen, um zu signalisieren, dass ein Sensor defekt oder nicht verfügbar ist, kann im Bereich der Messung von Umgebungstemperaturen schon zu Missverständnissen führen. Im schlimmsten Fall sogar zu gravierenden Fehlentscheidungen.

Diese beiden Beispiele zeigen, dass es für den Anwender trügerisch sein kann, sich auf die via SNMP abgefragten Daten blind zu verlassen. Es verdeutlicht, dass beim SNMP-Monitoring das nötige Knowhow vorhanden sein muss und sich auch keine allgemeingültige Formel für jedes SNMP-Gerät ableiten lässt. Stattdessen muss man jedes Gerät einzeln betrachten. Denn nur mit dem nötigen Kontextwissen lassen sich die gesammelten Daten richtig interpretieren.

„Welcher Tag ist heute?“ – „Februar!“

Es ist nicht überraschend, dass die die Implementierung des SNMP-Protokolls nicht vor typischen Programmierfehlern gefeit ist. Daher lassen sich gängige Fehler, die man aus der Softwareprogrammierung kennt, auch in SNMP-Implementierungen wiederfinden. Das lässt sich zum Beispiel gut am Datumsformat veranschaulichen. Statt dafür das ISO-Format zu verwenden, gibt es hier häufig einen Mix aus den verschiedenen lokal geläufigen Varianten: YYYYMMDD, MMDDYYYY oder DDMMYYYY. Die Angabe 05022020 kann so beispielsweise den 5. Februar 2020 oder den 2. Mai 2020 meinen. Wird die Jahresangabe auf zwei Stellen gekürzt, lässt sich das Datumsformat 050220 sogar noch als 20. Februar 2005 interpretieren.

Das heißt, dass der Anwender beziehungsweise Check-Entwickler sich auch in so einem Fall mit den Details beschäftigen muss. Wir hatten beispielsweise schon den Fall, dass ein Hersteller in seinem SNMP-Stack im Datumsformat drei Stellen für die Tagesangabe vorgesehen hat: 001 entsprach demnach jeweils dem ersten Tags eines Monats. Das kann man schon so machen...

See you in a minute...

Geht es um das Netzwerk-Monitoring mit SNMP, ist häufig von der ständigen Last durch die SNMP-Pollings – also der Abfrage der Daten in einem bestimmten Zeitintervall – auf den Geräten die Rede. In früheren Zeiten, als Monitoring-Systeme noch nicht so leistungsfähig waren und nur in Intervallen von mehreren Minuten abfragen konnten, hatte dies keine so große Auswirkung auf die Netzwerkkomponenten. Mittlerweile sind Monitoring-Lösungen jedoch viel leistungsfähiger geworden.

Standardmäßig fragt Checkmk die Geräte im Minutenintervall ab. Wie in diesem Artikel bereits beschrieben, erkennt es automatisch die benötigten OIDs für die zu überwachenden Services. Durch dieses effiziente Vorgehen hält Checkmk die Last auf den Geräten bereits möglichst gering. Glücklicherweise haben die meisten modernen Geräte keinerlei Probleme mit einem minütlichen Abfrageintervall. Die Praxis zeigt jedoch, dass ältere Geräte oder zum Beispiel Switch-Stacks ab einer gewissen Größe an ihre Leistungsgrenze kommen können.

OID-Allergie

Bei einer aktiven Anfrage kann es außerdem hin und wieder passieren, dass Geräte allergisch auf die in einem Check abgefragte OID-Reihenfolge reagieren. Fragt man beispielsweise in einem snmpbulkget bei einer Bulk size von 10 die OIDs ab, kann es vorkommen, dass der SNMP-Stack an einer gewissen Stelle abstürzt und keine oder nur unvollständige Werte liefert. In unserem nächsten Blogpost werden wir uns diesem Problem ausführlich widmen und erklären, wie man das Problem umgehen kann. Für Check-Entwickler kann es beispielsweise Lösung sein, die Reihenfolge der abgefragten OIDs zu ändern, um den Absturz des SNMP-Stacks zu vermeiden.

Ebenso kommt es manchmal vor, dass eine MIB nicht rückwärtskompatibel ist – was sie laut Standard eigentlich sein sollte. Das ist problematisch, wenn die Firmware die OID-Implementierung ändert. Je nachdem welche Firmware auf dem Netzwerkgerät installiert ist, muss man dann wissen, unter welcher OID der gesuchte Wert zu finden ist.

UDP-Odyssee

Aber nicht nur die SNMP-Pollings haben Nachteile. Auch SNMP-Traps funktionieren oftmals nicht wie versprochen. Eine fehlerhafte Implementation kann etwa verhindern, dass trotz eines Events kein automatischer Trap ausgelöst wird.

Das ist jedoch wiederum problematisch, wenn der Hersteller zwar für sein Gerät mit SNMP-Unterstützung bewirbt, jedoch nur eventbasierte Traps integriert hat und somit gar kein SNMP-Polling für die Monitoring-Daten ermöglicht. Im Zusammenspiel mit den weiteren Nachteilen von SNMP-Traps, kann dies ein Problem im Netzwerk-Monitoring bedeuten.

Schließlich ist das Monitoring mit Traps deutlich fehleranfälliger als die SNMP-Überwachung mittels aktiver Anfragen. Dies liegt unter anderem an der Unzuverlässigkeit von SNMP-Traps. Diese werden als UDP-Pakete versendet, die verloren gehen können. Aufgrund der fehlenden Empfangsquittungen bleibt der Paketverlust unerkannt – der Empfänger weiß nicht, dass überhaupt eine Benachrichtigung verschickt wurde. SNMP-Traps versenden zudem nur Fehlermeldungen, jedoch keine Recovery-Benachrichtigungen, sodass möglicherweise der aktuelle Status im Monitoring unklar bleibt.

Kommt es in einer großen Netzwerkumgebung zu einem Ausfall eines wichtigen Upstream-Dienstes, kann es zudem passieren, dass Tausende Switches gleichzeitig Traps senden. Unter der Last der vielen Meldungen besteht die Möglichkeit, dass der Trap-Empfänger zusammenbricht und das Monitoring genau dann nicht verfügbar ist, wenn es der Anwender eigentlich am dringendsten benötigt.

Die Event Console

Checkmk bietet mit der Event Console ein integriertes System, das eine solche Überlastung des Trap-Empfängers vermeiden soll. So verarbeitet die Event Console die durch ein Event ausgelösten Meldungen nicht durch den Monitoring-Kern, sondern mit dem Event Daemon (mkeventd). Zweck der Event Console ist es, dass sie aus einem großen Strom von Meldungen nur die relevanten Meldungen herausfiltert.

Dazu kann die Event Console unter anderem Meldungen per Syslog oder SNMP-Traps direkt empfangen und diese anhand von benutzerdefinierten Regeln klassifizieren. Dabei verfolgt die Engine den Ansatz, dass die erste zutreffende Regel aus der Meldung ein Event generiert. Ferner ist sie in der Lage, die Meldungen zu korrelieren, zusammenzufassen, zu zählen, zu annotieren, umzuschreiben und deren zeitliche Zusammenhänge zu berücksichtigen.

Hinweis: Checkmk verarbeitet Regeln als Regelketten, das heißt, dass es verschiedene Parameter aus mehreren Regeln des gleichen Regelsatzes zusammenführt. In der Event Console entscheidet ausschließlich die erste zutreffende Regel, ob eine Nachricht zu einem Event wird – oder ob sie verworfen wird.

Neben einem möglichen Overflow des Empfängers kann ein eventbasiertes Monitoring mit SNMP-Traps auch einen erheblichen Konfigurationsaufwand bedeuten. Ändert man die IP-Adresse des Trap-Empfängers, muss der Administrator alle Geräte neu konfigurieren. Noch ärgerlicher ist es, wenn ein Firmware-Update die Trap-OIDs ändert. Dann muss der Administrator alle Regeln umschreiben – sofern er die Änderung überhaupt bemerkt. Denn die fehlenden Testmöglichkeiten von Traps sind ein weiterer Nachteil eines eventbasierten Monitorings. Leider sind nur wenige Geräte überhaupt in der Lage, generische Traps oder gar Tests von realen Fehlermeldungen zu versenden. Auf diese Weise ist es schwierig zu prognostizieren, ob eine wichtige Trap überhaupt richtig funktioniert und eine Meldung bei einem auftretenden Event überhaupt ausgelöst wird.

Oldie but goldie

In der Summe lässt es sich also festhalten: SNMP ist zwar ein Protokoll aus den 80er Jahren, das sich – zumindest beim Netzwerk-Monitoring – als De-facto-Standard etabliert hat. Auch wenn es an der einen oder anderen Stelle gerne mal hakt, wird SNMP auch weiterhin ein zentraler Pfeiler für das Monitoring von Netzwerkkomponenten bleiben. Es ermöglicht trotz einiger Unzulänglichkeiten – vor allem in Zeiten von steigenden Device-Zahlen – ein schnelle Überwachung der eigenen IT-Infrastruktur.

Dennoch haben die gezeigten Beispiele verdeutlicht, dass es notwendig ist, sich mit jedem Gerät, das man in seine Monitoring-Umgebung integriert, einzeln zu beschäftigen. Generische SNMP-Checks können ansonsten schnell zu falschen Daten und Werten in der eigenen Monitoring-Instanz führen. Die Folge sind falsche Erkenntnisse und Rückschlüsse für den Zustand der zu überwachten Netzwerkumgebung.

Dies lässt sich nur mit speziell geschriebenen Checks vermeiden. Je nach gewählter Monitoring-Lösung kann es passieren, dass der Administrator dies manuell erledigen muss. Checkmk bietet hingegen die Möglichkeit, dass es mit Hilfe der über 1.000 mitgelieferten SNMP-Check-Plugins automatisiert die für das Monitoring relevanten Services erkennt. Auf diese Weise lässt sich innerhalb kurzer Zeit mit SNMP ein Monitoring aufsetzen.

Darüber hinaus gibt Checkmk Administratoren und Anwendern Werkzeuge an die Hand, einige der durch schlechte SNMP-Implementierungen hervorgerufenen Probleme zu beheben. Im nächsten Blogpost erfahren Sie alles über den „Gott-Modus“ und wie er Ihnen beim SNMP-Troubleshooting helfen kann.