aktuell versuchen wir Netzwerkgeräte (Switche, Router usw.) in CheckMK per SNMP zu integrieren.
Das klappt bisher auch einwandfrei (wir haben 3 Switche zurzeit integriert), doch letzte Woche hatten wir dann die ersten Probleme als wir einen Router integreiren wollten.
Die Verbindung über SNMP funktioniert (laut Diagnostic in CheckMK) und ich bekomme auch Services, die ich aktivieren kann. Das habe ich dann auch gemacht und hier fing dann das Problem an. Und zwar waren alle Services im Status “Pending” und Stale. Hab dann CheckMK mal über Nacht rödeln lassen, doch kein Erfolg. Immer noch alle Services des Routers “Pending”. Ich habe dann einfach mal weniger Services aktiviert (30). Das hat dann soweit auch geklappt erstmal, doch irgendwann ging dann der Check_MK-Service wieder in “CRIT - (Service Check Timed Out)” und alle Services waren wieder Stale.
Wenn ich über die Commandline den Befehl “cmk --debug -vnn HOSTNAME” ausführe, zeigt er brav alle Services an und gibt mir ein “OK-[snmp] Success, execution time 143,5 sec”. Danach sind auch alle Services wieder aus dem Stale zustand “befreit”, aber nach ein paar Minuten springt alles wieder in Stale und der Check_MK Service ist wieder in “CRIT - (Service Check Timed Out)”.
Woran kann es liegen, dass er immer in den Timeout rennt? Liegt es daran, dass die Execution Time 143 Sekunden lang ist? Kann ich den Timeout Wert höher setzen, bzw. kann ich die Execution Time minimieren?
Vielen Dank!
Noch kurz ein paar Eckdaten zu unserem Setup.
CheckMK 1.6.0p9 Raw Edition (auf einer CentOS VM)
8 vCPUs
32 GB Ram
Aktuell haben wir 1200 Hosts und 24080 Services im Monitoring
Genau hier liegt das Problem eine Runtime von 143 Sekunden ist nicht nur ein bisl lang sondern viel zu lang.
Da die RAW Edition verwendet wird ist generell der Timeout erstmal bei 60 Sekunden.
Manuelle Anpassung wirkt sich hier immer auf alle Geräte im Monitoring aus.
Erstmal zu deinem Router. Bei dem Test auf der Commandline würde ich erstmal schauen bei welchem Teil der Abfrage er langsam ist. Ich vermute hier mal die Interface Liste. Kann aber auch was anderes sein das kann man ohne den Output halt schlecht sagen.
Einen Versuch kannst du mit dem Geräte wie folgt machen.
Mittels der Regel Disabled checks einfach mal alle Checktypen für diese Gerät deaktivieren und nur immer einige welche 1-2 Typen aktivieren welche auch jetzt schon gefunden wurden beim Discovery.
Damit sollte sich bei einem Router schnell rausfinden lassen was hier langsam ist.
Meiner Erfahrung nach lohnt es sich auch, mit der bulk size zu spielen. Per default nutzt checkmk 10. Ich habe Devices, bei denen führt das zu einem Timeout, aber wenn ich 5 benutze, geht es (klingt komisch, ist aber so). Andere Devices lassen sich problemlos mit einer bulk size von 100 abfragen.
Die Regel dazu heißt Bulk walk: Number of OIDs per bulk bzw. an der shell
snmpbulkwalk -Cr100 ...
Disclaimer: Ich weiß nicht, ob man das in der CRE überhaupt einstellen kann.
~$ cmk --debug -vnn HOSTNAME
Check_MK version 1.6.0p9
+ FETCHING DATA
[snmp] Execute data source
[piggyback] Execute data source
No piggyback files for 'HOSTNAME'. Skip processing.
No piggyback files for 'IPADRESSE'. Skip processing.
CPU utilization 6/0 OK - Utilization in the last 5 minutes: 1.0%
CPU utilization of Routing Processor 5 OK - Utilization in the last 5 minutes: 15.0%
DOM TenGigabitEthernet4/1 Receive Power Sensor OK - Status: OK, Signal power: -0.80 dBm
DOM TenGigabitEthernet4/1 Transmit Power Sensor OK - Status: OK, Signal power: -1.30 dBm
DOM TenGigabitEthernet4/5 Transmit Power Sensor OK - Status: OK, Signal power: -3.00 dBm
DOM TenGigabitEthernet4/7 Receive Power Sensor OK - Status: OK, Signal power: -4.40 dBm
FAN Chassis Fan Tray 1 OK - Status: normal
FRU Module Status 7000 WARN - [module 7] Operational status: OK but diag failed
HSRP Group XXX OK - Redundancy Group XXX is OK, Status: active
HSRP Group XXX OK - Redundancy Group XXX is OK, Status: active
Interface 0036 OK - [GigabitEthernet1/36] (up) MAC: XXX 1 Gbit/s, In: 2.87 kB/s (0.0%), Out: 1.76 kB/s (0.0%)
Interface 0146 OK - [TenGigabitEthernet4/2] (up) MAC: XXX, 4.29 Gbit/s, In: 0 B/s (0.0%), Out: 0 B/s (0.0%)
OK - [snmp] Success, execution time 110.4 sec | execution_time=110.411 user_time=0.790 system_time=0.130 children_user_time=0.630 children_system_time=0.690 cmk_time_snmp=102.403 cmk_time_agent=0.001
Der richtigere Befehl wäre cmk --debug -vvn hostname
Wichtig ist, dass festgestellt wird wo das Gerät lange braucht.
Mit deinem Output habe ich 2 Kandidaten welche lange brauchen.
Einmal die GBICs welche hier Ihren Power und Health Status melden da bei der Abfrage jeder GBIC einzeln vom Switch aus angefragt wird. Oder aber wie schon gesagt die Interfaces.
Kannst ja mal zum Test die Check Typen im WATO deaktivieren (Disabled Checks Rule).
So, ich habe jetzt mal nur die Interface-Checks als Regel deaktivert und siehe da, es klappt. Es gibts soweit keinen Timeout mehr.
Woran kann das denn jetzt liegen, dass er wohlmöglich bei der Abfrage der Interfaces in einen Timeout endet?
Liegt es am CheckMK, da dieser von der Hardware her zu schwach ist (8 vCPU/32 GB Ram).
Oder in dem Fall an dem Router, da er nicht schnell genug auf die SNMP-Anfragen antwortet?
Hintergrund der Frage ist auch, da wir vorhaben noch 600 weitere Netzwerkgeräte über SNMP in CheckMK aufzunehmen.Kann es da zu performance Problemen bei CheckMK kommen auf Dauer (in unserer jetzigen Hardware-Austattung)?
Ich schließe mich der Frage einfach mal an. Bei uns funktionieren alle Geräte einwandfrei, bis auf auf einen über SNMP v3 angebundenen HPE FF 5700-48G der über IRF mit einem identischen Modell zusammengeschlossen ist.
Die Einstellung ** Bulk walk: Number of OIDs per bulk** habe ich bereits verändert, dabei aber eher eine Verschlechterung festgestellt.
Der besagte Switch taucht permanent mit folgender Meldung im System auf:
CRIT - [snmp] SNMP Error on X.X.X.X: Timeout: No Response from X.X.X.X (Exit-Code: 1) **CRIT** , Got no information from host, execution time 11.9 sec
Der besagt Host besitzt 79 Services, davon 77 Interface Checks und SNMP Info und Uptime.
Über den Befehl time cmk -l HOSTNAME bekomme ich Zeiten von 0m0.1 bis 0m0.6 und mit dem Befehl time cmk -n HOSTNAME erscheint die oben erwähne Timeout Meldung mit “real” Zeiten von 0m36s
Wir benutzen Check MK RAW auf einer VM mit 4 vCPU’s und 4 GB RAM.
Zu beiden Fragen ein cmk --debug -vvn hostname
Zeigt der Reihe nach alle SNMP Abfragen welche gerade erfolgen an. Hier einfach etwas Augenmerk drauf legen wenn die Interface OIDs anfangen und mal schauen was er da langsam macht.
Mann kann zum Testen der verschiedenen Abfragen dann auch einfach mal manuell einen snmpwalk/snmpbulkwalk machen um zu testen ob dies zum Beispiel ein Bulkwalk Problem ist.
Kann manchmal passieren, dass snmpwalk stabil läuft und bulkwalk halt nicht.
Hier ist dann wirklich herausfinden angesagt was langsam ist. Wenn man großer Kunde ist und nicht nur 1-2 Switche von besagtem Hersteller hat hilft auch manchmal dort etwas Wind zu machen.
Langsames SNMP ist halt ein Software Problem auf dem Switch selbst.
So, ich hatte jetzt mal den “richtigeren” Befehl ( cmk --debug -vvn hostname) ausgeführt und gesehen, dass er bei den Interface-Checks länger braucht (knapp 1 Minute).
Desweiteren ist mir aber noch aufgefallen, dass die SNMP abfragen über “snmpwalk -v1 …” gemacht wurden. Deshalb habe ich dann im CheckMK bei dem Router jeweils die Regel für SNMP v2c und Bulkwalk gesetzt. Dann konnten auch die Interface-Checks empfangen werden und die Execution Time ging runter auf 27 Sekunden. Aktuell läuft der Router also nicht mehr in einem Timeout rein.
Ich werde morgen mal weitere 3-5 Netzwerkgeräte hinzufügen und das ganze über das Wochenende laufen lassen und am Montag dann gucken, ob über das Wochenende irgendein Timeout passiert ist.
Noch eine Frage zum Schluss:
Und zwar wenn wir weitere Netzwerkgeräte (geplant sind ca. 600) hinzufüge, kann es passieren dass ich irgendwann auch mit SNMP v2 wieder in einen Timeout lande? Da igendwann zu viele Services geprüft werden und CheckMK nicht mehr hinterher kommt?
27 Sekunden ist zwar nicht optimal aber immerhin besser als vorher die 1-2 Minuten.
Ich hoffe mal, dass nicht alle verwendeten Netzwerkgeräte so schlecht performen. Dann müsste man eher über einen Herstellerwechsel nachdenken
Zur Frage - die Timeouts beziehen sich immer nur auf ein Gerät - wenn das ordentlich abgefragt wird wird das auch weiterhin funktionieren. Wie ich glaub schon geschrieben hab sollte ordentliche Hardware so zwischen 1-5 Sekunden für eine Abfrage brauchen. Einzig die CPU Leistung des Monitoring Servers wird halt wesentlich mehr beansprucht bei 600 Geräten.
Es is aber ohne Probleme möglich auch Instanzen mit mehr als 1k Geräten zu betreiben, vorausgesetzt genug CPU ist vorhanden.
Hallo, SNMPv2 ist natürlich definitiv die bessere Wahl.
Nach dem wir einige Probleme mit einem sehr prominenten Hersteller ähnlicher Art hatten, haben wir den checkintervall auf 5 Minuten geändert, das inline SNMP abgeschaltet und folgende Timing settings für SNMP verwendet:
|Response timeout for a single query: |8.00 sec|
|Number of retries: |3|
Am besten kann man das Verhalten sehen wenn man einen snmpwalk über die gesamte MIB laufen lässt. Irgendwann stoppt der Durchlauf und es kommen nur noch tröpfchenweise Daten an.
Mittlerweile gibt es wohl die Regel ‘Check intervals for SNMP checks’ mit dem an das ganze noch granularer per check, also z.B. nur if64, eingestellt werden kann. Das habe ihc aber bisher noch nicht ausprobiert.
Wir haben auch einen Hersteller bei dem der SNMP Agent nach einer gewissen Zeit nicht mehr antwortet wenn er alle 60 sec abgefragt wird. Scheint wohl so eine Art DOS Schutz zu sein. Da haben wir auch auf 5 Minuten umgestellt.
Ja, wir machen ja auch nur die Fehlererkennung. Die Fehersuche macht dann die Fachabteilung mit ihren eigene Tools.
Leider Nein. Die offizielle Aussage vom Support ist, dass die Python Implementierung langsamer ist, dafür aber weniger Ressourcen verbraucht. Die von mir aufgezeigten Einstellungen wurden so nach Problemen mit größeren Switch Stacks vom Support bei uns eingestellt. Seit dem haben wir auch keine Timeouts mehr.
Ja, das kann man sicherlich versuchen. Aus eigener Erfahrung ist das aber leider nicht zielführend, da der Hersteller wegen so einer Kleinigkeit sicherlich keine neue Firmware für seine Geräte herausbringen wird. Darüber hinaus besteht dann noch das Risiko dass die neue Firmware Fehler enthalten kann die evtl. gravierendere Auswirkungen auf den Betrieb haben. Bei uns ist das noch etwas komplexer, da man zusätzlich die Fachabteilung davon überzeugen muss die neue Firmware zu Testen und freizugeben.
