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
Letzte Aktualisierung: 20. November 2019

Verwandte Artikel

Suche im Handbuch

1. Was ist SNMP?

1.1. SNMP anstelle des Checkmk-Agenten

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 braucht 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.

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 hingegen 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 nicht miteinander kompatibel, 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 relevanten Versionen von SNMP:

Version Features Checkmk Bedeutung in der Praxis
v1 ja Findet man nur bei sehr alten Geräten (eher 10 Jahre und älter), die v2c nicht unterstützen oder deren v2c-Unterstützung 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“, die bei SNMP die Rolle eines Passworts spielt. Die 64-Bit-Counter sind essenziell 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, meinen dann aber 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, bei dem im gleichen Bereich der SNMP-Datenstruktur (OID) je nach Kontext-ID unterschiedliche Informationen sichtbar sind. Dies wird zum Beispiel beim Partitionieren von Fibre-Channel-Switches verwendet.

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, 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) 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:

  • 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 von Switches 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 überlastet, wenn man es am meisten brauchen würde.
  • Bei einer Änderung der IP-Adresse des Trap-Empfängers müssen alle Geräte neu konfiguriert werden.
  • Traps sind nur schwer testbar. Die wenigsten 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 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.

2. Einrichten von SNMP in Checkmk

2.1. Gerät vorbereiten

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:

  1. Gehen Sie zur Konfiguration für aktive Abfragen (SNMP GET). (Verwechseln Sie das 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 Testinstanz von Checkmk vorzusehen. Wichtig: Falls Sie mehrere redundante Checkmk-Server betreiben, vergessen Sie nicht, auch die IP-Adressen 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 des 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, wenn die Protokollversionen 1 und v2c verwendet werden.

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 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ändlich Handhabung. 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, 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.

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 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 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, etwa wenn Sie auf einem Server einen Hersteller-Agenten für die Hardwareüberwachung installiert haben, der seine Daten per SNMP bereitstellt, wie das z. B. bei Fujitsu ServerView der Fall ist.

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 (kann in der Praxis vereinzelt vorkommen). 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 voneinander unterscheiden. Die Version 3 besprechen wir weiter unten. Wenn Sie nicht sehr hohe Sicherheitsanforderungen haben, liegen Sie mit Version 2c richtig, bzw. können die SNMP-Kommunikation in ein Management-VLAN legen und so absichern. Version 2c 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 Access to Agents ➳ SNMP credentials of monitored hosts. Damit können Sie die Credentials 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 verschiedene 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, wobei das je nach Konfiguration eingeschränkt sein kann. Das sieht dann z. B. so aus:

Die ausgegebenen vier Informationen bedeuten im Einzelnen:

sysDescr Die Beschreibung des Gerätes, wie sie vom Hersteller in der Firmware 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ätes von Ihnen festgelegt.
sysName Hier steht der Hostname des Gerätes. Auch dieses Feld wird im Gerät konfiguriert. Für das Monitoring spielt der Name keine weitere Rolle und wird nur informativ angezeigt. Es ist aber durchaus sinnvoll und hilfreich, wenn der Hostname mit dem Hostnamen in Checkmk übereinstimmt.
sysLocation Das ist ein Feld für eine rein informative Angabe, und Sie können einen frei wählbaren Text zum Standort des Gerätes eintragen.

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 Check-Plugins – die interessanten Items finden. Bei SNMP ist etwas mehr Arbeit notwendig. Zwar könnte Checkmk bei der Erkennung einen kompletten Abzug aller SNMP-Daten (SNMP-Walk) machen und darin nach interessanten Informationen Ausschau halten. Aber es gibt Geräte, bei denen 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-Check-Plugins, ob das Gerät dieses Plugin überhaupt unterstützt. Diese Phase nennt Checkmk den SNMP-Scan. Als Ergebnis gibt die Software eine Liste von Check-Plugins aus, 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 Überwachung 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 Check-Plugins, die bei dem Host aktuell schon zum Einsatz kommen. Die SNMP-Walks liegen dann bereits durch das normale Monitoring als Cache-Dateien vor, und die Erkennung dauert nicht lange. Nun 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 einen muss das Gerät haben (und der muss 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.

Im Einsteigerhandbuch finden Sie übrigens einen Abschnitt zu Handlungsempfehlungen beim Überwachen von Switchports.

Das zweite ist der Service SNMP Info, der 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 in der Voreinstellung immer OK; Sie können aber untere und obere Schwellwerte 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 Check-Plugins 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 Bulk-Anfragen scheitern

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

Bei einem solchen 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, bei dem das so ist, können Sie diesen mit v2c, aber ohne Bulk-Anfragen betreiben. Konfigurieren Sie einen solchen 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).

Dadurch wird der Host gezwungen, trotz eingestellter Version 1 das Protokoll SNMP v2c zu verwenden, allerdings ohne Bulkwalk. Wir empfehlen übrigens nicht den Einsatz von SNMP v1 – selbst wenn das Protokoll 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 kann es helfen, 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 Firmware-Upgrade 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 einzelnen 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 das verschiedene Ursachen haben:

a) Es gibt keine Plugins

Checkmk liefert fast 1.000 Check-Plugins für SNMP-Geräte aus, aber natürlich ist selbst diese Liste nie vollständig. So kommt es 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 Website Checkmk Exchange fündig, wo Anwender ihre eigenen Plugins veröffentlichen können.
  • Sie entwickeln selbst Plugins. Dazu finden Sie im Handbuch mehrere Artikel.
  • Sie kontaktieren unseren Support oder einen unserer Partner und geben die Entwicklung der passenden Plugins in Auftrag.

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 gar nicht auf SNMP antworten

Falls der Ping geht, aber keine einzige SNMP-Protokollversion funktioniert, gibt es mehrere 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 ü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:

noAuthNoPriv Keine echte User-basierte Authentifizierung, keine Verschlüsslung. Der Vorteil gegenüber v2c ist, dass das Passwort nicht mehr im Klartext, sondern gehasht übertragen wird.
authNoPriv User-basierte Authentifizierung mit Name (Security name) und Passwort, trotzdem keine Verschlüsselung.
authPriv User-basierte Authentifizierung wie bei authNoPriv, und zusätzlich werden alle Daten verschlüsselt. Hierzu müssen Sie manuell einen Schlüssel austauschen und ihn sowohl im Gerät als auch in Checkmk hinterlegen.

Die Sicherheitsstufe konfigurieren Sie da, wo Sie auch die Community einstellt haben, also entweder bei den Hosteigenschaften 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 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 im vorigen Abschnitt beschrieben).
  • Dann benötigen Sie noch eine Regel im Regelsatz SNMPv3 contexts to use in requests. Hier wählen Sie das Check-Plugin 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, die SNMP-Anfragen sehr performant durchführt, ohne weitere Prozesse zu erzeugen. Der CPU-Verbrauch 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 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 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.

5.3. Timing settings for SNMP access

Standardmäßig erwartet Checkmk auf eine SNMP-Anfrage eine Antwort innerhalb von einer Sekunde. Außerdem verschickt die Monitoringsoftware 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.

5.4. Bulk walk: Number of OIDs per bulk

SNMP überträgt pro GetBulk-Anfrage in der Voreinstellung 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.

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.

5.5. Limit SNMP OID Ranges

Checkmk arbeitet normalerweise so, dass es immer die Informationen zu allen Switchports 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 die Regelkette Limit SNMP OID Ranges. Mit dieser 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.

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 findet dann quasi vor der Serviceerkennung und dem Monitoring statt. 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 des SNMP-Walks

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 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.

6.2. Erstellen eines Walks über die GUI

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.

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

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

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

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 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:

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

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

Option Wirkung
--extraoid <OID> Wenn Checkmk einen Walk auf einem Host ausführt, dann ruft es generell zwei Teilbäume aus dem SNMP-Datenbereich ab. Diese werden im SNMP-Baum über sogenannte OIDs (object identifier) spezifiziert. Diese sind MIB-2 und enterprises – also zum einen ein Standardbereich, der für alle SNMP-Geräte normiert und gleich ist, und zum anderen einen herstellerspezifischen Bereich.

Bei einer korrekten Implementierung von SNMP sollte das Gerät alle Daten senden, die es bereitstellt. Falls das nicht der Fall ist und Sie nach einem bestimmten Bereich Ausschau halten, können Sie dessen OID mit dieser Option zum Walk hinzufügen, z. B. cmk --snmpwalk --extraoid .1.2.3.4 myswitch01. Vergessen Sie nicht den Punkt am Anfang der OID.

--oid Diese Option arbeitet ähnlich wie --extraoid, ruft aber dann nur die angegebene OID ab. Dies ist zu Testzwecken interessant. Beachten Sie, dass der Walk dann unvollständig ist.
-v Das v steht für verbose und sorgt für einige informative Ausgaben, während der Walk läuft.
-vv Das vv steht hier für very verbose und gibt noch deutlich mehr Informationen aus.

6.4. Gespeicherte Walks zur Simulation verwenden

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.

Legen Sie jetzt eine Regel im Satz 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 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.