Best Practice - Distributed Monitoring - Timeouts - SNMP - stale

Version: checkmk-raw 1.6.0p9
Setup: distributed, cmk-slaves via docker
Problem: stale services bei snmp-devices

Hallo Forum,
ich bin gerade dabei, ein distributed Monitoring aufzubauen. Funktioniert alles soweit sehr gut, leider habe ich nur immer wieder stale services bei snmp-devices. Die Anbindung des Standortes kann ausgeschlossen werden, site ist i. d. R. immer available.

Die duration der service-checks ist gerade bei diesen snmp-devices einfach zu lang. Gibt es dazu Erfahrungen, best practices etc. wie man sowas debuggen oder mit Regeln steuern kann?

Vielen Dank vorab schon mal, jeder Input hilft :wink:

Viele Grüße aus dem hohen Norden…

Also die folgenden Tests sollte man machen wenn es den Verdacht gibt, dass die SNMP Geräte zu langsam antworten.

  • cmk --debug -vvn hostname
    Dabei schauen bei welchen Checks er langsam ist.
  • Bei Bedarf einzelne Check Typen vom Discovery ausnehmen. Achtung es bringt nix bei Interfaces zum nur einige zu überwachen. CMK holt immer den ganzen Interface Table (jedenfalls in der RAW gibt es dazu keine Möglichkeit :wink:)
  • Gibt es einen Unterschied bei dir ob die Instanz in einem Container läuft oder normal als Hardware/VM?
1 Like

Moin Andreas,

vielen Dank schon mal für deinen Input. Ich hänge hier mal den Output von cmk --debug -vvn ran, habe ich auf 2 Devices laufen lassen, sehe dort keine gravierenden Unterschiede im Output. Was mich ebenfalls wundert ist, dass es so aussieht, als würden die Services auf den besagten SNMP-Devices gar nicht mehr angefragt werden, sobald diese auf stale sind. Last service check time ist hier 18 h, oder interpretiere ich das falsch?

Output CMK --debug

### SNMP-Device das ständig stale service hat ###

cmk --debug -vvn xxx.20.52.xx

[cpu_tracking] Start with phase ‘busy’
Check_MK version 1.6.0p9
Try aquire lock on /omd/sites/cmk/tmp/check_mk/counters/xxx.20.52.xx
Got lock on /omd/sites/cmk/tmp/check_mk/counters/xxx.20.52.xx
Releasing lock on /omd/sites/cmk/tmp/check_mk/counters/xxx.20.52.xx
Released lock on /omd/sites/cmk/tmp/check_mk/counters/xxx.20.52.xx

  • FETCHING DATA
    [cpu_tracking] Push phase ‘snmp’ (Stack: [‘busy’])
    [snmp] No persisted sections loaded
    [snmp] Not using cache (Does not exist)
    [snmp] Execute data source
    [snmp] Write data to cache file /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.52.xx
    Try aquire lock on /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.52.xx
    Got lock on /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.52.xx
    Releasing lock on /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.52.xx
    Released lock on /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.52.xx
    [cpu_tracking] Pop phase ‘snmp’ (Stack: [‘busy’, ‘snmp’])
    [cpu_tracking] Push phase ‘agent’ (Stack: [‘busy’])
    [piggyback] No persisted sections loaded
    [piggyback] Execute data source
    No piggyback files for ‘xxx.20.52.xx’. Skip processing.
    No piggyback files for ‘xxx.20.52.xx’. Skip processing.
    [cpu_tracking] Pop phase ‘agent’ (Stack: [‘busy’, ‘agent’])
    [cpu_tracking] End
    OK - [snmp] Success, execution time 0.0 sec | execution_time=0.015 user_time=0.010 system_time=0.000 children_user_time=0.000 children_system_time=0.000 cmk_time_snmp=0.002 cmk_time_agent=0.001

### SNMP-Device das funktioniert ###

cmk --debug -vvn xxx.20.12.xx

[cpu_tracking] Start with phase ‘busy’
Check_MK version 1.6.0p9
Try aquire lock on /omd/sites/cmk/tmp/check_mk/counters/xxx.20.12.xx
Got lock on /omd/sites/cmk/tmp/check_mk/counters/xxx.20.12.xx
Releasing lock on /omd/sites/cmk/tmp/check_mk/counters/xxx.20.12.xx
Released lock on /omd/sites/cmk/tmp/check_mk/counters/xxx.20.12.xx

  • FETCHING DATA
    [cpu_tracking] Push phase ‘snmp’ (Stack: [‘busy’])
    [snmp] No persisted sections loaded
    [snmp] Not using cache (Does not exist)
    [snmp] Execute data source
    [snmp] Write data to cache file /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.12.xx
    Try aquire lock on /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.12.xx
    Got lock on /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.12.xx
    Releasing lock on /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.12.xx
    Released lock on /omd/sites/cmk/tmp/check_mk/data_source_cache/snmp/xxx.20.12.xx
    [cpu_tracking] Pop phase ‘snmp’ (Stack: [‘busy’, ‘snmp’])
    [cpu_tracking] Push phase ‘agent’ (Stack: [‘busy’])
    [piggyback] No persisted sections loaded
    [piggyback] Execute data source
    No piggyback files for ‘xxx.20.12.xx’. Skip processing.
    No piggyback files for ‘xxx.20.12.xx’. Skip processing.
    [cpu_tracking] Pop phase ‘agent’ (Stack: [‘busy’, ‘agent’])
    [cpu_tracking] End
    OK - [snmp] Success, execution time 0.0 sec | execution_time=0.018 user_time=0.010 system_time=0.000 children_user_time=0.000 children_system_time=0.000 cmk_time_snmp=0.004 cmk_time_agent=0.002

Es macht keinen Unterschied, ob auf einer VM oder Container. Ich habe andere Standorte, absolut identische Config (Docker) wo das reibungslos funktioniert.

Werden “stale services” von checkmk als unmonitored interpretiert?

Hier noch ein kurzer Auszug aus cmk --check-discovery xxx.20.52.xx

cmk --check-discovery xxx.20.52.xx
WARN - 27 unmonitored services (hp_webmgmt_status:1, snmp_uptime:1, hp_procurve_cpu:1, hp_procurve_mem:1, hp_procurve_sensors:2, snmp_info:1, if:20)(!), no vanished services found, no new host labels
unmonitored: if: Interface Switch loopback interface 4327
unmonitored: if: Interface 3
unmonitored: if: Interface Switch loopback interface 4328
usw.

Beide Abfragen finden eigentlich nicht statt :smiley:
Zu sehen bei beiden Devices an den

Die Abfragen müssen natürlich vom jeweiligen Slave aus erfolgen von wo aus das Gerät auch sonst überwacht wird.

Die Services sind alle Stale da der Check_MK Service in einen Timeout läuft. Alle anderen Services bis auf den Check_MK Discovery werden ja als passive Services mit Daten vom Check_MK Service versorgt.

Genau so hier wurde der Discovery Check auf dem Master oder Slave ausgeführt. Auf dem Master wäre das Ergebnis korrekt da dieser ja sonst den Switch nicht überwacht denke ich mal.

1 Like

ah ok… ich teste das gleich mal von dem jeweiligen slave… macht auch eigentlich mehr sinn :wink:

Hallo Andreas, diesen Output bekomme ich jetzt bei Ausführung der Kommandos auf dem zugehörigen Slave…

OMD[pekk]:~$ cmk --check-discovery xxx.20.52.xx
OK - no unmonitored services found, no vanished services found, no new host labels

OMD[pekk]:~$ cmk --debug vvl xxx.20.52.xx
OK - execution time 0.0 sec | execution_time=0.017 user_time=0.010 system_time=0.010 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=0.001

OMD[pekk]:~$ cmk --debug vvn xxx.20.52.xx
OK - execution time 0.0 sec | execution_time=0.017 user_time=0.010 system_time=0.000 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=0.001

OMD[pekk]:~$ cmk -D xxx.20.52.xx

xxx.20.52.xx
Addresses: xxx.20.52.xx
Tags: [address_family:ip-v4-only], [agent:no-agent], [criticality:prod], [if_by_alias_by_desc:if_alias], [ip-v4:ip-v4], [networking:lan], [piggyback:auto-piggyback], [site:pekk], [snmp:snmp], [snmp_ds:snmp-v1]
Labels: [system:switch]
Host groups: PKD-SWITCHES
Contact groups: all, check-mk-notify
Agent mode: No agent
Type of agent:
SNMP (Community: ‘public’, Bulk walk: no, Port: 161, Inline: no)
Process piggyback data from /omd/sites/pekk/tmp/check_mk/piggyback/172.20.52.11
Services:
checktype item params description groups


hp_procurve_cpu None (80.0, 90.0) CPU utilization
if 1 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 1
if 10 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 10
if 2 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 2
if 3 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 3
if 4 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 4
if 5 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 5
if 6 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 6
if 7 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 7
if 8 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 8
if 9 {‘state’: None, ‘errors’: (0.01, 0.1), ‘speed’: None, ‘unit’: ‘bit’} Interface 9
if DEFAULT_VLAN {‘state’: [u’1’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface DEFAULT_VLAN
if Switch loopback interface 4324 {‘state’: [u’1’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface Switch loopback interface 4324
if Switch loopback interface 4325 {‘state’: [u’2’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface Switch loopback interface 4325
if Switch loopback interface 4326 {‘state’: [u’2’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface Switch loopback interface 4326
if Switch loopback interface 4327 {‘state’: [u’2’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface Switch loopback interface 4327
if Switch loopback interface 4328 {‘state’: [u’2’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface Switch loopback interface 4328
if Switch loopback interface 4329 {‘state’: [u’2’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface Switch loopback interface 4329
if Switch loopback interface 4330 {‘state’: [u’2’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface Switch loopback interface 4330
if Switch loopback interface 4331 {‘state’: [u’2’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface Switch loopback interface 4331
if VLAN11 {‘state’: [u’1’], ‘errors’: (0.01, 0.1), ‘speed’: 0, ‘unit’: ‘bit’} Interface VLAN11
hp_procurve_mem {‘levels’: (‘perc_used’, (80.0, 90.0))} Memory
snmp_info None None SNMP Info
hp_procurve_sensors 1 None Sensor 1
hp_procurve_sensors 2 None Sensor 2
hp_webmgmt_status 1 None Status 1
snmp_uptime None {} Uptime

Hier wieder das Gleiche wie vorher. Der macht nix. 0 Sekunden Laufzeit.
In deinen Commands fehlt überall ein kleines bisl was :wink:
cmk --debug -vvI hostname und cmk --debug -vvn hostname

Ein was am Rande - warum ist der Procurve Switch als v1 Gerät konfiguriert. Der kann v2c und damit auch Bulkwalk.

1 Like

oh man ich bin ein depp… ich prüfe… :slight_smile:

Hallo Andreas,
konnte mich jetzt noch mal dem Thema widmen.

Auszug der letzten Zeilen aus…

cmk --debug -vvn xxx.20.52.xx

OK - [snmp] Success, execution time 3.9 sec | execution_time=3.864 user_time=0.120 system_time=0.110 children_user_time=0.270 children_system_time=0.090 cmk_time_snmp=3.026 cmk_time_agent=0.002

Zum Zeitpunkt der Ausführung war der Switch in diesem Zustand:

Außerdem tauchen jetzt durch die Umstellung auf snmpv2 auch die if64-services auf und ich bekomme die Meldung bei Übernahme der Änderungen, dass es duplikate in den Services gibt…

Was zu sehen ist, dass es bei der service check duration immer wieder timeouts gibt…

Irgendwie drehe ich mich gefühlt im Kreis… :thinking:

Ok wenn du die if64 nun hast einfach mal ein cmk -II auf der Maschine machen.
Dann sollte das wieder ok sein. Warum aber bei nur 3.9 Sekunden Ausführungszeit dein Check_MK selber in Timeout läuft kann ich natürlich nicht sagen.

1 Like

Ok, aber trotzdem danke für den Input.
Vielleicht kann man noch mit der einen oder anderen Regel an der Performance schrauben.
Hast Du dazu vielleicht noch einen best practice tip?

VG
Dennis

SNMP Performance hängt einzig und allein vom abgefragten Gerät ab.
Man kann nur sagen normal ist v1 “meist” etwas langsamer da kein Bulkwalk möglich ist.
Bei der Benutzung von Bulkwalk mit v2 oder v3 ist es noch möglich die Anzahl der mit einer Abfrage eingesammelten OID’s zu optimieren. Default war hier glaub ich 10. Es ist aber durchaus möglich bei Geräten hier 20 od. 30 zu nehmen. Das Tuning ist hier nicht so einfach da so ein ganzer Pack an OID’s immer in einen bestimmten Buffer passen muss - keine Ahnung wie groß der ist :wink:

Normal sollte der Unterschied zwischen normalen Walk und Bulkwalk am größten sein.

2 Likes

Moin Andreas,

wollte nur mal kurz zurück melden, dass ich seit der gestrigen Umstellung auf snmpV2 und die Anzahl der mit einer Abfrage eingesammelten OID’s auf 20 gesetzt, scheinbar im Moment die Ausführungszeiten der ServiceChecks von >60 sek (=timeout) auf nun 30-40 sek bekommen habe. Ich hoffe das bleibt so… :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.