Offline-Modus für check_nwc_health

Offline-Betrieb von check_nwc_health

Der eine oder andere check_nwc_health-Anwender dürfte --mode walk schon kennen. Damit kann man sich eine Liste von snmpwalk-Anweisungen ausgeben lassen, deren Resultat mir beim Debugging hilft.

check_nwc_health --mode walk --hostname 172.23.60.28 --community public
rm -f /tmp/snmpwalk_check_nwc_health_172.23.60.28
snmpwalk -ObentU -v2c -c public 172.23.60.28 1.3.6.1.2.1 >> /tmp/snmpwalk_check_nwc_health_172.23.60.28
snmpwalk -ObentU -v2c -c public 172.23.60.28 1.3.6.1.4.1.9 >> /tmp/snmpwalk_check_nwc_health_172.23.60.28
snmpwalk -ObentU -v2c -c public 172.23.60.28 1.3.6.1.4.1.9.1 >> /tmp/snmpwalk_check_nwc_health_172.23.60.28
snmpwalk -ObentU -v2c -c public 172.23.60.28 1.3.6.1.4.1.9.2 >> /tmp/snmpwalk_check_nwc_health_172.23.60.28
...

Die resultierende Datei snmpwalk_check_nwc_health_172.23.60.28 lade ich dann in einen SNMP-Simulator und kann damit rumexperimentieren, als hätte ich die Hardware des Anwenders hier bei mir rumstehen. Was ich aber auch machen kann, ist:

check_nwc_health --mode cpu-load --snmpwalk /tmp/snmpwalk_check_nwc_health_172.23.60.28
OK - cpu 0 usage (5 min avg.) is 21.00% | 'cpu_0_usage'=21%;80;90

Anstelle der Parameter --hostname und --community kann ich also --snmpwalk verwenden, um die benötigten OIDs aus einer Datei zu lesen.

Dieses Feature setzen wir seit Neuestem jetzt auch bei einem Kunden ein. Das Problem war hier, dass einige SAN-Switches endlos lang brauchten, um SNMP-Requests zu beantworten. Dies führte immer wieder zu Timeouts und somit UNKNOWN-Fehlern. Die Idee war daher, im Hintergrund und ohne Eile die Daten von den SNMP-Agenten zu holen und in eine Cache-Datei zu schreiben. Das Monitoring würde dann gegen diese Datei laufen.

Einsammeln der OIDs

Es gibt eine neue Kommandozeilenoption --offline, die check_nwc_health anweist, die snmpwalk-Befehle nicht auszugeben, sondern sie direkt auszuführen.

check_nwc_health --mode walk --hostname 172.23.60.28 --community public \
    --timeout 600 --offline
OK - all requested oids are in /tmp/snmpwalk_check_nwc_health_172.23.60.28

In dieser Form aufgerufen, sammelt check_nwc_health haufenweise OIDs ein, zum Teil auch solche, die nicht benötigt werden. Das hat seinen Grund darin, dass check_nwc_health nicht nur die im abgefragten Gerät implementierten Mibs vorschlägt, sondern mehrere Mibs des betreffenden Herstellers. Dies lässt sich vermeiden, indem man eine Liste von OIDs angibt:

check_nwc_health --mode walk --hostname 172.23.60.28 --community public \
    --timeout 600 --offline \
    --oids 1.3.6.1.2.1.2.2.1,1.3.6.1.2.1.1.1,1.3.6.1.2.1.1.3,1.3.6.1.4.1.9.9.109.1.1.1,1.3.6.1.4.1.9.9.305.1.1.2,1.3.6.1.4.1.9.9.91.1.1.1,1.3.6.1.4.1.9.9.91.1.2.1

Damit schont man auch den SNMP-Agenten. Falls man in einer geclusterten Umgebuung arbeitet, kann man mit Hilfe des Parameters --snmpwalk filename die Datei auch auf einem gesharten Verzeichnis ablegen lassen.

Cronjob zum Einsammeln der OIDs

Wir wollen, dass automatisch snmpwalk-Dateien mit möglichst aktuellen Daten vorliegen. Dazu habe ich das Script local/bin/walk_sanswitches erstellt.

#! /bin/bash

# liste der devices
IPS="172.23.60.28 172.23.60.29"
# liste der tatsaechlich benoetigten tables
OIDS="1.3.6.1.2.1.2.2.1,1.3.6.1.2.1.1.1,1.3.6.1.2.1.1.3,1.3.6.1.4.1.9.9.109.1.1.1,1.3.6.1.4.1.9.9.305.1.1.2,1.3.6.1.4.1.9.9.91.1.1.1,1.3.6.1.4.1.9.9.91.1.2.1"

if [ -n "$1" ]; then
  $OMD_ROOT/local/lib/nagios/plugins/check_nwc_health --mode walk \
      --hostname $1 --community public \
      --timeout 600 --offline --oids $OIDS
else
  IFS=" "
  for ip in $IPS
  do
    # die geraete sollen parallel abgefragt werden
    nohup $0 $ip >/dev/null 2>&1 &
  done
fi

In etc/cron.d/walk_sanswitches trägt man nun noch folgende Zeile ein:

*/2 * * * * $OMD_ROOT/local/bin/walk_sanswitches

Wenn man jetzt mit omd restart crontab den Cron-Daemon durchstartet, werden alle zwei Minuten frische Daten von den San-Switches geholt.

Monitoring der Cache-Dateien

Weiter oben steht der Aufruf von check_nwc_health mit dem Parameter --snmpwalk, für den produktiven Betrieb ist es aber unerlässlich, das Alter der Cache-Datei zu prüfen. Es könnte ja sein, dass die snmpwalks keine Verbindung bekommen und keine neuen Daten wegschreiben können. Daher kommt auch hier wieder der Parameter --offline ins Spiel. Mit seiner Hilfe gibt man an, wie alt die Cache-Datei maximal sein darf (in Sekunden).

In diesem Beispiel liegt der letzte erfolgreiche Lauf von --mode walk länger als zwei Minuten zurück.

check_nwc_health --mode cpu-load \
    --snmpwalk /tmp/snmpwalk_check_nwc_health_172.23.60.28 --offline 120
UNKNOWN - snmpwalk file /tmp/snmpwalk_check_nwc_health_172.23.60.28 is too old

Im Normalfall sieht es aber so aus:

check_nwc_health --mode cpu-load \
    --snmpwalk /tmp/snmpwalk_check_nwc_health_172.23.60.28 --offline 120
OK - cpu 0 usage (5 min avg.) is 26.00% | 'cpu_0_usage'=26%;80;90

Verwendung des Offline-Modus ohne Änderung der check_commands

Normalerweise wird ja check_snmp_health mit --hostname und --community aufgerufen. Um die Abfragemethode mit der Cache-Datei zu verwenden, kann man --snmpwalk einfach an die Parameterliste dranhängen. --hostname und --community können dann zwar vorhanden sein, werden aber nicht mehr beachtet. Eleganter ist es allerdings, das alte check_command weiterzuverwenden, also mit ausschliesslich --hostname und --community und den snmpwalk-Parameter per Environment zu übergeben.

NAGIOS__SERVICESNMPWALK=/tmp/snmpwalk_check_nwc_health_172.23.60.28 \
NAGIOS__SERVICEOFFLINE=120 \
check_nwc_health --mode cpu-load --hostname 172.23.60.28 --community public
UNKNOWN - snmpwalk file /tmp/snmpwalk_check_nwc_health_172.23.60.28 is too old

Diese Environmentvariablen werden erzeugt, indem man den entspr. Servicedefinitionen die Custom-Macros _SNMPWALK und _OFFLINE hinzufügt.

Den Offline-Modus von check_nwc_health kann man übrigens auch verwenden, um Netzwerkgeräte in strengstens abgeschotteten Netzsegmenten zu überwachen. Wenn noch nicht mal erlaubt ist, einen Mod-Gearman-Worker dort aufzustellen und einen Port in der Firewall freizuschalten, kann man eventuell die Cache-Dateien transferieren.

Monitoring-Workshop 2017 12./13.9. Düsseldorf