NaNs im Zusammenhang mit Cacti und Spine

Zuerst ist es am besten die NaN-Debugging-Anleitung durchzuarbeiten.

Falls die NaNs anschließend immer noch auftreten und ein Cluster mit im Spiel ist hilft eventuell die folgende Beschreibung. Das ganze ist mir selbst passiert als ich ein Isilon storage cluster zu überwachen hatte.

Spine prüft die uptime des snmp-Dienstes auf dem überwachten Server. Solange der Dienst läuft nimmt diese Zeit natürlich konstant zu. Sobald aber der snmpd neugestartet wird beginnt sie wieder bei Null. Der neue Wert ist also kleiner als der vorhergehende. In diesem Fall verwirft Spine den aktuell per snmp geholten Wert für ALLE Grafen dieses Hosts und fügt stattdessen ein NaN ein.

Bei einer einzelnen Maschine sollte das so gut wie nie auftreten.

Als ich das Monitoring für das Cluster einrichten musste ging es um die Überwachung der Festplatten. Ich verwendete dazu den dns-Namen des Clusters. Dieser wurde mit round-robin-dns auf die einzelnen physischen Nodes aufgelöst. Da die Festplatten auf allen Nodes gemountet waren dachte ich, dass die Lastverteilung nichts ausmacht. Das war jedoch leider ein Trugschluss. Mit jedem Sprung zum nächsten physischen Host erhält snmp eine andere snmp-uptime, da es sich ja um einen anderen physischen Host und damit um einen anderen snmpd handelt! Und Spine verwirft entsprechend jedesmal die aktuellen Werte und fügt NaNs ein. Das Resultat waren NaNs überall in Grafen des Clusters.

Die Lösung war dann denkbar einfach. Statt des dns-Namens nahm ich die IP-Adressen der einzelnen Nodes und sofort waren alle NaNs verschwunden.

Um die Uptime zu testen einfach das folgende Kommando mehrmals hintereinander ausführen.

snmpwalk -v2c -c public IP/host sysUpTimeInstance

Inoffizielles Handbuch für Cacti
Nagios und Cacti