Überwachen via SNMP

Router, Switches, Firewalls, Drucker, Appliances, USVs, Hardwaresensoren und viele andere Geräte erlauben keine Installation eines Checkmk-Agenten. Dafür haben sie aber bereits vom Hersteller aus eine eingebaute Schnittstelle für das Monitoring: einen SNMP-Agenten. Dieser ist über das Simple Network Management Protocol (SNMP) erreichbar. Checkmk nutzt SNMP, um solche Geräte zu überwachen. Der Vorteil für Sie: Das Einrichten der Überwachung ist sehr einfach.

Es gibt übrigens auch SNMP-Agenten für Windows und Linux. Es ist allerdings nicht zu empfehlen, diese anstelle des Checkmk-Agenten zu nutzen. SNMP ist nicht sehr performant und für die Überwachung benötigt der Checkmk-Server generell mehr CPU und Speicher pro Host, als wenn er mit seinem eigenen Agenten arbeitet. Außerdem sind die per SNMP bereitgestellten Daten unvollständig. In einigen Fällen kann allerdings die Überwachung per SNMP zusätzlich zum Checkmk-Agenten sinnvoll sein. Im Kapitel über SNMP und Checkmk-Agent finden Sie mehr zu diesem Thema.

Sollte allerdings für eine Hard- oder Software-Komponente (beispielsweise ein RAID-Controller) kein Checkmk-Agenten-Plugin zur Überwachung, dafür jedoch eine SNMP-Schnittstelle existieren, können Sie selbstverständlich über SNMP zusätzliche Monitoring-Daten erheben. Achten Sie in diesem Fall auf hinreichend lange Abfrageintervalle.

Das Überwachen von SNMP-Geräten mit Checkmk ist sehr einfach. Wenn Sie einfach nur schnell mit SNMP starten möchten, genügt Ihnen wahrscheinlich der kurze Abschnitt über SNMP im Leitfaden für Einsteiger. Dieser Artikel hingegen geht deutlich mehr in die Tiefe und zeigt Ihnen alle Einzelheiten und Sonderfälle der SNMP-Überwachung mit Checkmk.

Das SNMP-Protokoll gibt es in verschiedenen Versionen. Diese sind nicht miteinander kompatibel, und so müssen sich das Monitoring-System und das überwachte Gerät immer einig sein, welche Protokollversion sie gerade verwenden. Checkmk unterstützt die Versionen v1, v2c und v3. In der Praxis wird in geschätzt 99 % der Fälle v2c eingesetzt. Hier ist eine Übersicht über alle relevanten Versionen von SNMP:

Checkmk nutzt für die SNMP-Überwachung aktive Anfragen – also eine Pull-Methode. Dabei sendet Checkmk ein UDP-Paket (Port 161) mit einer SNMP-Anfrage an das Gerät mit der Bitte, bestimmte Daten zu liefern. Das Gerät antwortet dann seinerseits mit einem UDP-Paket, das die Daten (oder eine Fehlermeldung) enthält.

Aber SNMP hat noch eine zweite Spielart: SNMP-Traps. Das sind spontane Meldungen, die Geräte an konfigurierte Adressen per UDP (Port 162) im Push-Verfahren versenden. Traps haben viele Nachteile gegenüber aktiven Anfragen, weswegen sie für das Monitoring keine große Bedeutung haben. Einige der Nachteile von SNMP-Traps sind:

Falls Sie dennoch mit Traps arbeiten wollen oder müssen, bietet die Event Console dafür eine Lösung: Sie kann Traps empfangen und daraus Events generieren.

Der erste Schritt ist das Vorbereiten des Gerätes. Jedes Gerät, das SNMP unterstützt, hat in seiner Konfiguration dafür irgendwo eine Maske. Nehmen Sie dort folgende Einstellungen vor:

Die Community ist eine Art Passwort, nur mit dem Unterschied, dass es bei SNMP keinen Benutzernamen gibt. Es gibt eine Konvention, nach der die Community public lautet. Das ist bei vielen Geräten — und auch bei Checkmk — der Standard. Nun kann man natürlich argumentieren, dass das unsicher ist und man eine andere Community vergeben sollte. Allerdings wird bei SNMP die Community im Klartext übertragen (außer bei SNMP Version 3). Jeder, der Pakete mithören kann, kann also sehr einfach die Community herausfinden. Andererseits haben Sie den Zugriff ja auf reine Lesezugriffe begrenzt, und meist sind die Informationen, die man per SNMP abrufen kann, nicht sehr kritisch.

Ferner führt die Verwendung von unterschiedlichen Communities bei mehreren Geräten zu einer sehr umständlichen Handhabung. Denn diese müssen ja dann nicht nur in den Geräten gepflegt werden, sondern auch im Monitoring-System. Deswegen ist es in der Praxis so, dass Anwender meist überall die gleiche Community verwenden — oder zumindest überall in einer Region, einer Abteilung, einem Rechenzentrum etc.

Tipp: Wenn Sie die Sicherheit auch ohne SNMP Version 3 erhöhen möchten, ist es sinnvoll, das Netzwerkkonzept so zu erweitern, dass man den Datenverkehr mit den Management-Diensten (und somit auch SNMP) in ein eigenes Management-VLAN legt und den Zugriff darauf via Firewall absichert.

Nehmen Sie die zu überwachenden Geräte in Checkmk wie gewohnt als Hosts auf. Wenn Sie Ihre Ordnerstruktur so gewählt haben, dass in einem Ordner jeweils nur SNMP-Geräte sind, dann können Sie die weiteren Einstellungen direkt am Ordner vornehmen. Das vereinfacht später das Aufnehmen von weiteren Hosts und vermeidet zudem Fehler.

Setzen Sie jetzt in den Eigenschaften des Hosts (oder Ordners) im Kasten Monitoring agents die Einstellung Checkmk agent / API integrations auf No API integrations, no Checkmk agent.

Im selben Kasten aktivieren Sie außerdem den Punkt SNMP und wählen als SNMP-Protokoll SNMP v2 or v3 aus. Die Auswahl von Protokollversion 1 ist nur für sehr alte Geräte eine Notlösung. Sie sollten das nur dann verwenden, wenn Sie wissen, das v2 wirklich nicht unterstützt wird oder die Implementierung auf dem Gerät dafür defekt ist (dies kann in der Praxis vereinzelt vorkommen). SNMP in Version 1 ist vor allem sehr langsam, da sie keine Bulk-Zugriffe unterstützt – der Unterschied ist gravierend.

Die dritte Einstellung heißt SNMP credentials. Hier ist zunächst wieder eine Wahl der Protokollversion notwendig, da sich v2c und v3 voneinander unterscheiden. Die Version 3 erläutern wir weiter unten. Wenn Sie nicht sehr hohe Sicherheitsanforderungen haben, liegen Sie mit v2c richtig, bzw. können die SNMP-Kommunikation in ein Management-VLAN legen und so absichern. SNMP v2c erfordert die Eingabe der oben besprochenen Community.

Für die Konfiguration der SNMP-Credentials gibt es noch einen alternativen Weg, falls Sie diese nicht einfach über ihre Ordnerstruktur vererben können: den Regelsatz Setup > Agents > SNMP rules > SNMP credentials of monitored hosts. Damit können Sie die Credentials anhand von Host-Merkmalen, Labels und ähnlichen Eigenschaften vergeben. Dabei gilt der Grundsatz, dass eine Community, die direkt beim Host oder Ordner festgelegt ist, immer Vorrang hat vor den Regeln.

Wenn Sie mit den Einstellungen fertig sind, bietet sich der kleine Umweg über die Diagnoseseite an. Dazu speichern Sie mit dem Aktionsknopf Save & go to connection test. Hier ist ein Beispiel der Diagnose für einen Switch. Dabei werden verschiedene Protokollversionen von SNMP gleichzeitig ausprobiert und zwar:

Ein normales modernes Gerät sollte auf alle vier Varianten mit den gleichen Daten antworten, wobei das je nach Konfiguration eingeschränkt sein kann. Das sieht dann z.B. so aus:

Die ausgegebenen vier Informationen bedeuten im Einzelnen:

Es scheint tatsächlich so zu sein, dass jeder denkbare Fehler, den man theoretisch beim Implementieren von SNMP machen kann, auch von irgendeinem Hersteller irgendwann gemacht wurde. Und so gibt es Geräte, bei denen SNMP zwar einigermaßen funktioniert, aber bestimmte Teile des Protokolls nicht oder falsch umgesetzt wurden.

Wenn Sie ein SNMP-Gerät in die Überwachung aufnehmen und Checkmk erkennt lediglich die Services SNMP Info, SNMP Uptime und die Interfaces, so kann das verschiedene Ursachen haben:

Falls der Ping geht, aber keine einzige SNMP-Protokollversion funktioniert, gibt es mehrere mögliche Ursachen:

SNMP ist standardmäßig unverschlüsselt und nur sehr schwach authentifiziert durch eine im Klartext übertragene Community. Für ein lokales abgeschottetes Netzwerk ist dieses Niveau eventuell trotzdem ausreichend, da für das Monitoring der Zugriff auf rein lesende Operationen beschränkt ist.

Wenn Sie trotzdem ein höheres Sicherheitsniveau möchten, dann benötigen Sie SNMP in der Version 3. Diese bietet Verschlüsselung und eine echte Authentifizierung. Allerdings ist dafür auch eine entsprechende Konfiguration notwendig.

SNMP v3 kennt verschiedene Stufen der Sicherheit:

Die Sicherheitsstufe konfigurieren Sie da, wo Sie auch die Community eingestellt haben, also entweder bei den Host-Eigenschaften oder in der Regel SNMP credentials of monitored hosts. Dort wählen Sie anstelle von SNMP Community eine der drei Stufen von v3 aus und konfigurieren die notwendigen Werte:

SNMP v3 führt das Konzept der Kontexte ein. Dabei kann ein Gerät an derselben Stelle im SNMP-Baum unterschiedliche Informationen zeigen — je nachdem, welche Kontext-ID bei der Abfrage mitgegeben wird.

Falls Sie ein Gerät haben, das mit solchen Kontexten arbeitet, benötigen Sie in Checkmk zwei Einstellungen:

Zum Glück gibt es sehr selten Situationen, in denen man mit Kontexten arbeiten muss, denn es ist leider nicht möglich, dass das Monitoring diese automatisch erkennt. Eine manuelle Konfiguration der Kontexte ist immer notwendig.

Performance spielt immer eine Rolle — vor allem in Umgebungen mit vielen Hosts. Und die Überwachung mit SNMP benötigt mehr CPU und Speicher als die mit Checkmk-Agenten.

Während die Raw Edition SNMP-Anfragen auf klassische Weise über die Kommandozeilenbefehle snmpget bzw. snmpbulkwalk macht, haben die kommerziellen Editionen eine eingebaute SNMP-Engine, die SNMP-Anfragen sehr performant durchführt ohne weitere Prozesse zu erzeugen. Die CPU-Last für die SNMP-Verarbeitung halbiert sich dadurch in etwa. Und durch die kürzeren Abfragezeiten reduziert sich auch die Anzahl der gleichzeitig benötigten Checkmk-Prozesse und damit auch der Speicherbedarf.

Falls Sie mit Ihren Ressourcen an die Grenzen stoßen bzw. die Abfrage eines einzelnen Gerätes länger als 60 Sekunden dauert, können Sie das Intervall reduzieren, mit dem Checkmk den oder die Hosts abfragt. Mit dem Regelsatz Normal check interval for service checks, den Sie gezielt auf die Checkmk-Services von Hosts anwenden, können Sie das generelle Intervall von einer Minute auf z.B. 2 oder 5 Minuten verlängern.

Speziell für SNMP-Checks gibt es darüber hinaus noch den Regelsatz Check intervals for SNMP checks. Mit diesem können Sie das Intervall für einzelne Check-Plugins herabsetzen. Wichtig ist, dass Sie es nie schneller einstellen können, als es das Intervall für die generelle Überwachung durch den Checkmk-Service vorgibt.

Insgesamt empfehlen wir aber, das Monitoring so auszulegen, dass das Standardintervall von einer Minute beibehalten werden kann und nur in Ausnahmefällen für einzelne Hosts oder Checks erhöht wird.

Standardmäßig erwartet Checkmk auf eine SNMP-Anfrage eine Antwort innerhalb von einer Sekunde. Außerdem verschickt die Monitoring-Software insgesamt drei Anfragen, bevor sie aufgibt. Bei Geräten, die nur sehr langsam antworten oder über ein sehr langsames Netzwerk erreichbar sind, kann es notwendig sein, diese Parameter zu ändern. Das machen Sie über den Regelsatz Timing settings for SNMP access:

Beachten Sie, dass sich diese Einstellungen auf eine einzelne SNMP-Anfrage beziehen. Der komplette Überwachungsvorgang eines Hosts besteht aus vielen Einzelanfragen. Der gesamte Timeout ist daher ein Vielfaches der hier angegebenen Einstellungen.

SNMP überträgt pro GetBulk-Anfrage in der Voreinstellung 10 Antworten in einem Paket. Mit dem experimentellen Regelsatz Bulk walk: Number of OIDs per bulk können Sie ausprobieren, ob ein höherer Wert eine bessere Performance bringt. Das wird allerdings nur dann der Fall sein, wenn bei dem Host große Tabellen übertragen werden — z.B. wenn es sich um einen Switch mit sehr vielen Ports handelt.

Das liegt daran, dass SNMP die Pakete immer auf die eingestellte Zahl mit den jeweils nächsten Datensätzen auffüllt. Und wenn nur wenige benötigt werden, werden somit nutzlos Daten übertragen, und der Overhead steigt.

Andererseits kann es in der Praxis auch vereinzelt vorkommen, dass Geräte mit dem voreingestellten Wert von 10 OIDs per bulk Probleme haben. Dann kann es sinnvoll sein, die Anzahl zu senken.

Checkmk arbeitet normalerweise so, dass es immer die Informationen zu allen Switch Ports holt, auch wenn nicht alle überwacht werden. Das ist auch gut so, denn im Normalfall ist das schneller, denn Einzelabfragen können nicht mit den effizienten Bulk-Anfragen gemacht werden. Zudem ist es aus unserer Sicht sowieso empfehlenswert, grundsätzlich alle Ports zu überwachen, um defekte Ports oder Kabel mit hohen Fehlerraten zu finden. Wenn Ports nicht zuverlässig UP sind, können Sie auch den Linkstatus DOWN als OK werten lassen.

Nun gibt es aber Einzelfälle, wo Switches sehr viele Ports haben und aus irgendeinem Grund nur sehr langsam antworten oder SNMP sehr ineffizient verarbeiten, so dass eine Überwachung bei einem vollständigen Abrufen aller Port-Informationen nicht mehr möglich ist.

Für solche Fälle gibt es den Regelsatz Bulk walk: Limit SNMP OID Ranges. Mit diesem können Sie die Liste der abgefragten Daten (z.B. Ports) statisch begrenzen. Im Wert der Regel legen Sie jeweils für ein bestimmtes Check-Plugin fest, welche Indizes der jeweiligen Tabelle geholt werden sollen.

Der übliche Check-Typ für Switch Ports heißt SNMP interface check with 64 bit counters (using v2c). Folgendes Beispiel zeigt eine Einstellung, bei der nur die ersten beiden Ports per SNMP geholt werden:

Hinweis: Diese Filterung findet dann quasi vor der Service-Erkennung und dem Monitoring statt. Je nach Einstellung von Network interface and switch port discovery bedeutet das noch nicht automatisch, dass diese beiden Ports auch wirklich überwacht werden.

Die SNMP-Engine von Checkmk hat ein sehr praktisches Feature: Sie können von einem überwachten Gerät einen kompletten Abzug aller seiner SNMP-Daten in eine Datei schreiben lassen (einen SNMP-Walk). Diese Datei können Sie später verwenden, um die Überwachung des Geräts auf einem anderen Checkmk-Server zu simulieren, auch wenn dieser überhaupt keine Netzwerkverbindung zu dem Gerät hat.

Wir verwenden das z.B. ganz intensiv in unserem Support, um für unsere Kunden neue Check-Plugins zu entwickeln. So benötigen unsere Entwickler keinen Zugriff auf Ihre Geräte, sondern lediglich einen SNMP-Walk.

Sie können einen SNMP-Walk direkt über die GUI erstellen. Die Funktion finden Sie im Kontextmenü des Checkmk-Services der Hosts und auch im Menü der Hosts (Eintrag Download SNMP walk):

Die Erstellung des Walks dauert im besten Fall einige Sekunden, ein paar Minuten sind aber auch nicht ungewöhnlich. Wenn das Erstellen abgeschlossen ist, können Sie die Datei in der Zeile Result herunterladen.

Alternativ können Sie Walks auch auf der Kommandozeile erzeugen. Melden Sie sich dazu auf der Instanz an, von der aus das Gerät überwacht wird. Das Erstellen des Walks geht dort einfach mit dem Befehl cmk --snmpwalk und der Angabe des überwachten Hosts (der dazu im Monitoring konfiguriert sein muss):

Verwenden Sie zusätzlich den Schalter -v, um ausführlichere Ausgaben über den Fortschritt zu sehen:

Die Datei wird dann im Verzeichnis var/check_mk/snmpwalks abgelegt und trägt den Namen des Hosts. Es handelt sich dabei um eine Textdatei. Wenn Sie neugierig sind, können Sie diese z.B. mit less betrachten; Sie beenden das Programm mit der Taste Q:

Der Befehl cmk --snmpwalk kennt noch weitere nützliche Optionen:

Wenn Sie nun auf einer anderen (oder auf derselben) Checkmk-Instanz diesen Walk für eine Simulation verwenden möchten, dann legen Sie die Walk-Datei auf dieser Instanz wieder unter var/check_mk/snmpwalks mit dem Namen des Hosts ab. Stellen Sie sicher, dass der Instanzbenutzer Eigentümer der Datei ist und die Berechtigungen auf 0600 (nur der Eigentümer darf lesen und schreiben) gesetzt sind.

Legen Sie jetzt eine Regel im Regelsatz Simulating SNMP by using a stored SNMP walk an, die für den oder die betroffenen Hosts greift.

Ab sofort wird bei der Überwachung des Hosts nur noch die gespeicherte Datei verwendet. Es erfolgt kein Netzwerkzugriff auf den Host mehr — außer der Ping für den Host Check und eventuell konfigurierte aktive Checks. Diese können Sie einfach auf den Checkmk-Server umbiegen, indem Sie den Hosts die IP-Adresse 127.0.0.1 geben.