Wir nutzen Cookies, um Ihnen eine optimale Nutzung dieser Webseite zu ermöglichen. Mehr Informationen finden Sie im Datenschutzhinweis. Wir nehmen an, dass Sie damit einverstanden sind, falls Sie diese Webseite weiter besuchen.

Ihre Cookie-Einstellungen
Ihre Einstellungen wurden aktualisiert.
Damit die Änderungen wirksam werden, löschen Sie bitte Ihre Browser-Cookies und den Cache und laden dann die Seite neu.

Überwachen via SNMP

Checkmk Manual

Verwandte Artikel

Suche im Handbuch

Dieser Artikel ist noch nicht fertig und nur ein Entwurf!

1. Was ist SNMP?

1.1. SNMP anstelle des Checkmk-Agenten

Router, Switche, 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 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. Dieser anstelle des Checkmk-Agenten zu nutzen ist allerdings nicht zu empfehlen. SNMP ist nicht sehr performant und für die Überwachung braucht der Checkmk-Server generell mehr CPU und Speicher pro Host als wenn er seinen eigenen Agenten arbeitet. Außerdem sind die per SNMP bereitgestellten Daten unvollständig.

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 Einsteigerhandbuch. Dieser Artikel hingeben geht deutlich mehr in die Tiefe und zeigt Ihnen alle Einzelheiten und Sonderfälle der SNMP-Überwachung mit Checkmk.

1.2. SNMP-Versionen

Das SNMP-Protokoll gibt es in verschiedenen Versionen. Diese sind alle untereinander inkompatibel, und so müssen sich das Monitoringsystem 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 relvanten Versionen von SNMP:

Version Features Checkmk Bedeutung in der Praxis
v1 ja Verwendung nur bei sehr alten (eher 10 Jahre und älter) Geräten, welche v2c nicht unterstützen oder die Unterstützung dafür Fehler hat.
v2c Bulk-Abfragen,
64-Bit-Counter
ja Dies ist der Standard in der Praxis. v2c ist eine „Light“-Variante von v2 und das C steht hier für Community, welche bei SNMP die Rolle eines Passworts spielt. Die 64-Bit-Counter sind essentiell bei der Überwachung von Switchports mit 1 GBit/sec und mehr. Die Bulk-Abfragen beschleunigen das Monitoring um bis zu Faktor 10.
v2 Security nein Version 2 bietet zusätzlich zu den Features von v2c noch bessere Security-Möglichkeiten. In der Praxis ist Version 2 von SNMP nicht anzutreffen. Deswegen unterstützt Checkmk diese Protokollversion nicht. Wenn Sie Security benötigen, verwenden Sie stattdessen Version 3.

Achtung: Da die „echte“ Version 2 keine Relevanz hat sprechen viele Masken in Checkmk einfach von v2, meine aber dann immer v2c.

v3 Security,
Kontexte
ja Version 3 kommt zum Einsatz, wenn der SNMP-Datenverkehr verschlüsselt werden soll. Bei v2c und v1 läuft dieser im Klartext – inklusive der Community. In der Praxis ist Version 3 eher weniger verbreitet, weil diese Version deutlich mehr Rechenleistung benötigt und auch der Aufwand für die Konfiguration deutlich höher ist als bei v2c. Die Kontexte sind ein Konzept wo im gleichen Bereich der SNMP-Datenstruktur (OID) je nach Kontext-ID unterschiedliche Informationen sichtbar sind.

1.3. SNMP-Traps

Checkmk nutzt für die SNMP-Überwachung aktive Anfragen. 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, welche die Antwortdaten enthält (oder eine Fehlermeldung).

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

  • Traps sind nicht zuverlässig. UDP-Pakete können verloren gehen. Es gibt keine Empfangsquittung.
  • Meist werden nur Fehler-Meldungen versendet, aber keine Recovery-Meldungen. Somit ist der aktuelle Status im Monitoring unklar.
  • Wenn tausende Switche gleichzeitig Traps senden (z. B. wenn für diese ein wichtiger Upstream-Dienst nicht verfügbar ist), kann der Trap-Empfänger sich dieser nicht erwehren und unter der Last einbrechen. Dann ist das Monitoring genau dann tot, wenn man es am meisten brauchen würde.
  • Bei einer Änderung der IP-Adresse des Trap-Empfängers müssen alle Geräte umkonfiguriert werden.
  • Traps sind nur schwer testbar. Die wenigstens Geräte haben überhaupt eine Funktion, um eine generische Test-Trap zu versenden – vom Test realer Fehlermeldungen ganz zu schweigen. Daher kann man nur schwer vorhersagen, ob eine wichtige Trap dann richtig verarbeitet wird, wenn es nach ein paar Monaten oder Jahren das erste mal soweit ist.

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

2. Einrichten von SNMP in Checkmk

2.1. Gerät vorbereiten

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

  1. Gehen Sie zur Konfiguration für aktive Abfragen (SNMP GET). (Verwechseln Sie das bitte nicht mit den Traps. Die Begrifflichkeit in den Konfigurationsdialogen kann sehr verwirrend sein).
  2. Aktivieren Sie SNMP für lesende Anfragen.
  3. Tragen Sie als erlaubte IP-Adressen die Adressen Ihrer Checkmk-Server ein. Es kann auch nützlich sein, hier noch eine Test-Instanz von Checkmk vorzusehen. Wichtig: Falls Sie mehrere redundante Checkmk-Server betreiben, vergessen Sie nicht, auch die IP-Adresse(n) anzugeben, die nach einem Failover verwendet werden. Speziell bei der Checkmk-Appliance ist es so, dass diese im Cluster-Betrieb als Quell-IP-Adresse bei ausgehenden Verbindungen jeweils die IP-Adresse der aktiven Node verwendet – und nicht die Service-IP-Adresse. In einer verteilten Umgebung ist die IP-Adresse derjenigen Slave-Site entscheidend, von der aus das Gerät überwacht wird.
  4. Vergeben Sie eine Community für die Verwendung der Protokollversionen 1 und v2c.

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 Default. Nun kann man natürlich argumentieren, dass das unsicher ist und man eine andere Community vergeben soll. Das ist sicher sinnvoll, allerdings sollten Sie wissen, dass bei SNMP die Community im Klartext übertragen wird (außer bei SNMP Version 3). Jeder, der Pakete mithören kann, kann also die Community sehr einfach abhören. 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 ist die Verwendung von unterschiedlichen Communities pro Gerät ist in der Handhabung sehr umständlich. Denn diese müssen ja dann nicht nur in den Geräten gepflegt werden, sondern auch im Monitoringsystem. Deswegen ist es in der Praxis so, dass Anwender meist überall die gleiche Community verwenden – oder zumindest überall in einer Region, Abteilung, Rechenzetrum, etc.

2.2. Gerät in Checkmk aufnehmen

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 machen. Das vereinfacht später das Aufnehmen von Hosts und vermeidet zudem Fehler.

Setzen Sie jetzt in den Eigenschaften des Hosts (oder Ordners) im Kasten Data sources die Einstellung Check_MK Agent auf No agent. Eine Ausnahme wäre, wenn Sie einen Host gleichzeitig mit dem normalen Checkmk-Agent und SNMP überwachen möchten. Dafür gibt es gelegentlich einen Grund: nämlich dass Sie auf einem Server einen Hersteller-Agenten für die Hardwareüberwachung installiert haben, welcher seine Daten per SNMP bereitstellt, wie das z. B. bei Fujitsu ServerView der Fall ist.

Im gleichen Kasten aktivieren Sie außerdem den Punkt SNMP und wählen das 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 (kann in der Praxis sehr selten vorkommen). Denn die SNMP-Version 1 ist vor allem eines: sehr langsam, da sie keine Bulk-Zugriffe unterstützt. Der Unterschied ist wirklich gravierend.

Die dritte und letzte Einstellung heißt SNMP credentials. Hier ist zunächst wieder eine Wahl der Protokollversion notwendig, da sich v2c und v3 eben darin unterscheiden. Die Version 3 besprechen wir [snmp#v3|weiter unten]. Wenn Sie nicht sehr hohe Sicherheitsanforderungen haben, liegen Sie mit Version 2c richtig. Version 2c erfordert die Eingaben 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 Access to Agents ➳ SNMP credentials of monitored hosts. Damit können Sie die Credentials dann anhand von Hostmerkmalen, 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.

2.3. Diagnose

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

  • SNMP v1
  • SNMP v2c
  • SNMP v2c ohne Bulk-Anfragen
  • SNMP v3

Ein normales modernes Gerät sollte auf alle vier Varianten mit den gleichen Daten anworten. Das sieht dann z. B. so aus:

Und hier ist die Bedeutung der vier ausgegebenen Informationen:

sysDescr Die Beschreibung des Gerätes, wie sie vom Hersteller in der Gerätefirmware fest eingebrannt ist. Dieser Text ist für Checkmk sehr wichtig für die automatische Serviceerkennung.
sysContact Dieses Feld ist vorgesehen für die Angabe einer Kontaktperson und wird in der Konfiguration des Geräts von Ihnen festgelegt.
sysName Hier steht der Hostname des Geräts. Auch dieses Feld wird beim Gerät konfiguriert. Für das Monitoring spielt der Name keine weitere Rolle und wird nur informativ angezeigt.
sysLocation Dies ein Feld für eine rein informative Freitextangabe, in der Sie den Standord des Geräts eintragen können.

2.4. Die Servicekonfiguration

Besonderheiten bei SNMP-Geräten

Nach dem Speichern der Hosteigenschaften (und optional der Diagnose) ist wie gewohnt der nächste Schritt die Konfiguration der Services. Dort gibt es einige Besonderheiten, denn bei SNMP-Geräten erfolgt die Serviceerkennung intern ganz anders als bei Hosts, die mit dem Checkmk-Agenten überwacht werden. Checkmk kann bei diesen einfach in die Ausgabe des Agenten schauen und darin – mithilfe der einzelnen Checkplugins – die interessanten Items finden. Bei SNMP ist etwas mehr Arbeit notwendig. Zwar könnte Checkmk bei der Erkennung einen kompletten Abzug aller SNMP-Daten machen (SNMP-Walk) machen und darin nach interessanten Informationen Ausschau halten. Aber es gibt Geräte, wo dann eine einzige Erkennung mehrere Stunden dauern würde!

Daher geht Checkmk intelligenter vor. Es ruft zunächst vom Gerät nur die allerersten beiden Datensätze (OIDs) auf: die sysDescr und sysObjectID. Danach folgen je nach Bedarf daraus resultierende weitere Abfragen. Anhand der Ergebnisse entscheidet dann jedes der fast 1.000 mitgelieferten SNMP-Checkplugins, ob das Gerät dieses Plugin überhaupt unterstützt. Diese Phase nennt Checkmk den SNMP-Scan und hat als Ergebnis eine Liste von Checkplugins, die als Kandidaten für die eigentliche Serviceerkennung dienen.

In einem zweiten Schritt läuft dann die eigentliche Erkennung. Die gefundenen Plugins rufen per örtlich begrenzten SNMP-Abfragen gezielt genau die Daten ab, die sie benötigen, und ermitteln daraus die zu überwachenden Services. Die abgerufenen Daten sind genau die Gleichen, die später auch regelmäßig für die Über­wachung geholt werden.

Bei Geräten im LAN dauert der ganze Vorgang in der Regel nicht sehr lange – mehrere Sekunden sind schon eher die Ausnahme. Wenn Sie aber Geräte über WAN-Strecken mit einer hohen Latenz überwachen, kann der komplette Scan einige Minuten dauern. Auch bei Switches mit hunderten von Ports dauert der Scan natürlich länger. Nun wäre es sehr unpraktisch, wenn Sie jedes Mal, wenn Sie die Seite der Services öffnen, so lange warten müssten.

Daher überspringt WATO den Scan im Normalfall und macht die Erkennung nur mit den Checkplugins, die bei dem Host aktuell schon zum Einsatz kommen. Die SNMP-Walks liegen dann bereits durch das normale Monitoring als Cachedateien vor und die Erkennung geht in Sekundenbruchteilen. Nur können Sie so zwar neue Items von bestehenden Plugins finden (z. B. neue Switchports, Festplatten, Sensoren, VPNs, usw.), aber keine ganz neuen Plugins.

Der Knopf Full scan erzwingt einen SNMP-Scan und anschließendes Holen von frischen Daten via SNMP. Dadurch werden dann auch Services von ganz neuen Plugins gefunden. Bei langsam antwortenden Geräten kann eine Wartezeit entstehen.

Standardservices

Egal welches Gerät sie per SNMP überwachen – es sollten zumindest die folgenden drei Services in der Konfiguration auftauchen:

Das erste ist ein Check, der die Netzwerkports überwacht. Und zumindest eines muss das Gerät haben und auch aktiv sein – sonst würde ja SNMP auch nicht funktionieren. Generell ist Checkmk dabei so voreingestellt, dass es alle Ports in die Überwachung aufnimmt, die zum Zeitpunkt der Serviceerkennung aktiv sind (operational status „up“). Sie können das mit dem Regelsatz Parameters for discovered services ➳ Discovery – automatic service detection ➳ Network Interface and Switch Port Discovery beeinflussen.

Das zweite ist der Service SNMP Info, welcher die gleichen vier Informationen anzeigt, die Sie auch bei der Diagnose gesehen haben. Er hat rein informelle Funktion und ist immer OK.

Und schließlich gibt es den Service SNMP Uptime, der Ihnen zeigt, wann das Gerät zum letzten mal neu gestartet wurde. Dieser Service ist per Default immer OK, Sie können aber untere und obere Schwellen für die Uptime setzen.

3. Wenn Geräte Probleme machen

3.1. Defekte SNMP-Implementierungen

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.

Keine Antwort auf Anfrage nach sysDescr

Ein möglicher Fehler ist, wenn SNMP-Agenten nicht auf die Anfrage nach den Standardinformationen wie z. B. der sysDescr antworten. Diese Geräte sind in der Diagnose wie tot. Und auch in der Serviceerkennung werden sie keine Resultate liefern, wenn Sie nicht durch eine spezielle Konfiguration nachhelfen. Legen Sie dazu für die betroffenen Hosts eine Regel unter Access to agents ➳ Hosts without system description OID mit einem Positive outcome an. Checkmk geht dann einfach davon aus, dass alles in Ordnung ist und überspringt den Test mit der sysDescr. Zwar werden dann auch keine Checkplugins erkannt, die bestimmte Teile in diesem Text erwarten, aber das spielt in der Praxis keine Rolle, da die betroffenen Plugins so entwickelt wurden, dass sie diesen Fall berücksichtigen.

V2c geht, aber keine Bulk-Anfragen

Einige Geräte unterstützen zwar Version v2c – und werden in der Diagnose darauf auch eine Anwort liefern – allerdings fehlt im Protokoll die Umsetzung des Befehl GetBulk. Dieser wird von Checkmk dazu verwendet, mit einer Anfrage möglichst viele Informationen auf einmal zu bekommen und ist sehr wichtig für die Performance.

Bei so einem Host werden auch einige einfache SNMP-Checks funktionieren, wie z.B die SNMP Info oder die SNMP Uptime. Aber andere Services fehlen – insbesondere die Netzwerkschnittstellen, die eigentlich bei jedem Gerät vorhanden sein müssen.

Falls Sie tatsächlich einen Host haben, wo dies so ist, können sie diesen mit v2c aber ohne Bulk-Anfragen betreiben. Konfigurieren Sie so einen Host wie folgt:

  • Setzen Sie bei den Hosteigenschaften die SNMP Version auf SNMP v1
  • Legen Sie in der Regelkette Access to agents ➳ Legacy SNMP devices using SNMP v2c eine Regel für den Host an und stellen in der Regel den Wert auf Positive match (Add matching hosts to the set).

Durch wird der Host gezwungen, trotz eingestellter Version 1 das Protokoll SNMP v2c allerdings ohne Bulkwalk zu verwenden. Wir empfehlen übrigens nicht den Einsatz von SNMP v1 – selbst wenn das unterstützt würde – denn hier werden keine 64-Bit-Counter unterstützt. Das kann zu fehlenden oder fehlerhaften Messdaten bei Netzwerkports führen, über die viel Verkehr läuft.

Geräte, die sehr langsam antworten

Es gibt Geräte bei denen manche SNMP-Abfragen sehr sehr lange brauchen. Teilweise liegt das an fehlerhaften Implementierungen. Hier hat teilweise geholfen, auf SNMP v1 zurückzugehen (was normalerweise viel langsamer ist, aber manchmal immer noch schneller ist, als ein kaputtes SNMP v2c). Bevor Sie das versuchen, sollten Sie jedoch prüfen, ob der Hersteller ein Firmwareupgrade bereitstellt, welches das Problem löst.

Eine zweite Ursache kann sein, dass das Gerät sehr viele Switchports hat und gleichzeitig eine langsame SNMP-Implementierung. Falls Sie von den Ports nur sehr wenige überwachen möchten (z. B. nur die ersten beiden), können Sie Checkmk manuell auf die Abfrage von manchen Ports begrenzen. Details finden Sie weiter unten im Abschnitt zu Performance.

3.2. Es werden nur die Standardservices gefunden

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 dies verschiedene Ursachen haben:

a) Es gibt keine Plugins

Checkmk liefert fast 1.000 Checkplugins für SNMP-Geräte aus, aber natürlich ist selbst diese Liste nie vollständig. So kommt es natürlich immer wieder vor, dass Checkmk für bestimmte Geräte keine spezifischen Plugins mit ausliefert und Sie dann nur die besagten Standardservices überwachen können. Hier haben Sie folgende Möglichkeiten:

  • Eventuell werden Sie auf der Checkmk Exchange fündig, wo Anwender ihre eigenen Plugins hochladen können.
  • Sie entwickeln selbst Plugins. Dazu finden Sie im Handbuch mehrere Artikel.
  • Sie kontaktieren unseren Support oder einen unserer Partner und lassen sich passende Plugins entwickeln.

b) Die Erkennung der Plugins funktioniert nicht

Manchmal kommt es vor, dass eine neuere Firmware von einem Gerät dazu führt, dass Checkmk-Plugins das Gerät nicht mehr erkennen – z. B. weil sich in der Systembeschreibung des Gerätes ein Text geändert hat. In diesem Fall müssen die bestehenden Plugins angepasst werden. Kontaktieren Sie dafür unseren Support.

c) Das Gerät liefert die benötigen Daten nicht aus

Manche (wenige) Geräte haben in ihrer SNMP-Konfiguration die Möglichkeit, den Zugriff auf bestimmte Informationsbereiche einzeln zu konfigurieren. Eventuell ist ihr Gerät so eingestellt, dass zwar die Standardinformationen geliefert werden, aber nicht die Bereiche für die gerätespezifischen Services.

Bei einigen wenigen Geräten müssen Sie SNMP v3 und Kontexte verwenden, um an die gewünschten Daten zu kommen.

3.3. Geräte, die garnicht auf SNMP antworten

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

  • Das Gerät ist überhaupt nicht per IP erreichbar. Das können Sie mit dem Ping-Test (erster Kasten) überprüfen.
  • Das Gerät unterstützt überhaupt kein SNMP.
  • Die SNMP-Freigabe ist nicht korrekt konfiguriert (Aktivierung, erlaubte Adressen, Community).
  • Eine Firewall unterbindet SNMP. Sie benötigen die Freischaltung von UDP Port 161.

4. SNMP v3

4.1. Security

SNMP ist standardmäßig unverschlüsselt und nur sehr schwach authentifiziert durch eine im Klartext im Netz lesbare Community. Für ein lokales abeschottetes 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, denn benötigen Sie SNMP in der Version 3. Dies bietet die Möglichkeit zu einer Verschlüsselung und einer echten Authentifikation. Allerdings ist dafür auch eine entsprechende Konfiguration notwendig.

SNMP v3 kennt verschiedene Stufen der Sicherheit:

noAuthNoPriv Keine echte userbasierte Authentifizierung, keine Verschlüsslung. Der Fortschritt zu v2c ist immerhin, dass das Passwort nicht mehr im Klartext sondern gehasht übertragen wird.
authNoPriv Userbasierte Authentifizierung mit Name (Security name) und Passwort, trotzdem keine Verschlüsselung.
authPriv Userbasierte Authentifizierung wie bei authNoPriv und zusätzlich werden alle Daten verschlüsselt, und zwar symmetrisch mit einem DES56-Algorithmus. Hier müssen Sie manuell einen Schlüssel austauschen – also sowohl im Gerät als auch in Checkmk hinterlegen.

Die notwendige Einstellung in Checkmk machen Sie an der gleichen Stelle, wo Sie auch die Community einstellt haben, also entweder bei den Hosteingenschaften oder im Regelsatz 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:

4.2. Kontexte

SNMP v3 führt das Konzept der Kontexte ein. Dabei kann ein Gerät an ein und 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:

  • Zunächst muss das Gerät mit SNMP v3 abgefragt werden (wie gerade im Vorabschnitt beschrieben).
  • Dann benötigen Sie noch eine Regel im Regelsatz SNMPv3 contexts to use in requests. Hier wählen Sie das Checkplugin aus, für das Kontexte aktiviert werden sollen und dann die Liste der Kontexte, die im Monitoring abgefragt werden sollen.

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.

5. Performance und Timing

5.1. Inline-SNMP

Performance spielt immer eine Rolle - vor allem in Umgebungen mit vielen Hosts. Und die Überwachung mit SNMP braucht 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 Enterprise Editions eine eingebaute SNMP-Engine, welche SNMP-Anfragen sehr performant ohne Prozesserzeugungen durchführt. Der CPU-Verbrauch für SNMP-Verarbeitung halbiert sich dadurch in etwa. Und durch die kürzere Abfragezeiten reduziert sich auch die Anzahl der gleichzeitig benötigten Checkmk-Prozesse und damit auch der Speicherverbrauch.

Wenn Sie neugierig sind, welchen Unterschied das macht, können Sie mit dem Regelsatz Hosts not using Inline-SNMP das Inline-SNMP für alle oder auch nur einzelne Hosts ausschalten.

5.2. Check intervals for SNMP checks

Falls Sie mit Ihren Ressourcen an Ihre Grenzen stoßen, können Sie das Interval reduzieren, mit welchem Checkmk die Hosts abfragt. Mit dem Regelsatz Normal check interval for service checks, den Sie gezielt auf die Check_MK-Services von Hosts anwenden, können Sie das generelle Intervall von einer Minute verlängern auf z. B. 2 oder 5 Minuten.

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

5.3. Timing settings for SNMP access

Standardmäßig erwartet Checkmk auf einem SNMP-Anfrage eine Antwort innerhalb einer Sekunde. Außerdem versucht es Anfragen insgesamt dreimal bevor es 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:

5.4. Bulk walk: Number of OIDs per bulk

SNMP überträgt pro GetBulk-Anfrage per Default 10 Antworten in einem Paket. Mit der experimentellen Regelkette 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.

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

5.5. Limit OID-Ranges

Checkmk arbeitet normalerweise so, dass es trotzdem immer die Informationen zu allen Switch-Ports holt, auch wenn nicht alle überwacht werden. Das im Normalfall schneller, denn Einzelabfragen können nicht mit den effizienten Bulk-Anfragen gemacht werden.

Aber wenn Sie viele Switches mit vielen Ports haben, von denen Sie grundsätzlich nur die ersten beiden Ports überwachen (z. B. die Uplinks) möchten, kann eine manuelle Optimierung sinnvoll sein. Dazu gibt es die Regelkette Limit SNMP OID ranges. Im Wert der Regel legen Sie jeweils für ein bestimmtes Checkplugin fest, welche Indizes der jeweiligen Tabelle geholt werden sollen.

Das übliche Plugin für Switchports heißt SNMP interface check with 64 bit counters. Folgendes Beispiel zeigt eine Einstellung, bei der nur die ersten beiden Ports per SNMP geholt werden:

Hinweis: Diese Filterung ist dann quasi vor der Serviceerkennung und dem Monitoring. Je nach Einstellung der Switch port discovery bedeutet das noch nicht automatisch, dass diese beiden Ports auch wirklich überwacht werden.

6. Simulation durch SNMP-Walks

6.1. Prinzip

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ätes auf einem anderen Checkmk-Server zu simulieren, auch wenn dieser überhaupt eine Netzwerkverbindung zu dem Gerät hat.

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

6.2. Erstellen eines Walks über die GUI

Sie können einen SNMP-Walk direkt über die GUI erstellen. Das finden Sie im Kontextmenü des Check_MK-Services des Hosts und auch im Menü des Hosts den 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 fertig ist, können sie die Datei in der Zeile Result herunterladen.

6.3. Erstellen eines Walks auf der Kommandozeile

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 (welcher dazu im Monitoring konfiguriert sein muss):

OMD[mysite]:~$ cmk --snmpwalk myswitch01

Fügen Sie -v hinzu, um Debugausgaben über den Fortschritt zu bekommen:

OMD[mysite]:~$ cmk -v --snmpwalk myswitch01
myswitch01:
Walk on ".1.3.6.1.2.1"...3664 variables.
Walk on ".1.3.6.1.4.1"...5791 variables.
Wrote fetched data to /omd/sites/mysite/var/check_mk/snmpwalks/myswitch01.

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

OMD[mysite]:~$ less var/check_mk/snmpwalks/myswitch01
.1.3.6.1.2.1.1.1.0 JetStream 24-Port Gigabit L2 Managed Switch with 4 Combo SFP Slots
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.11863.1.1.3
.1.3.6.1.2.1.1.3.0 560840147
.1.3.6.1.2.1.1.4.0 bi@mathias-kettner.de
.1.3.6.1.2.1.1.5.0 MKSW001
.1.3.6.1.2.1.1.6.0 Core Switch Serverraum klein
.1.3.6.1.2.1.1.7.0 3
.1.3.6.1.2.1.2.1.0 27

6.4. Gespeicherte Walks zur Simulation verwenden

Wenn Sie nun auf einer anderen (oder der gleichen) 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.

Legen Sie jetzt eine Regel im Satz Simulating SNMP by using a stored SNMP walk an, welche für den/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 Hostcheck 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.

7. Dateien und Verzeichnisse

Pfad Bedeutung
var/check_mk/snmpwalks Hier werden SNMP-Walk-Dateien erzeugt bzw. auch erwartet, falls Sie diese zum Simulieren von SNMP-Daten verwenden möchten.