NetApp Plugins für Icinga

10. März 2011

Icinga Screenshot in dem die nach stderr ausgegebenen Meldungen zu sehen sind.Erstmals sind die Nagios Plugins für NetApp auf einem Icinga System zur Überwachung zweier NetApp-Filer im Einsatz. Die Tests verliefen erwartungsgemäß ohne große Aufregung. Lediglich bei den Hardware-Tests gibt es ein kleine Besonderheit: Icinga sendet nicht nur stdout sindern auch stderr an das Monitoring-System weiter. Damit landen einige Warnungen der Perl-Scripts, die bewusst auch ausgegeben werden, in der Icinga-Webobefläche.

Der Workaround dafür schaut so aus:

define service {
	use                  netapp-service
        host_name            san.mycomp.net
	service_description  Temperature-Sensors
        check_command	     check_netapp!Hardware!-o temp 2>/dev/null
 }

Für alle die neugierig sind, was wir denn da für Warnungen ausgeben: Bei einigen NetApp-Modellen gibt es „potentielle“ Hardware-Komponenten, die aber auch einfach fehlen dürfen. Die werden von DataONTAP dann als missing ausgegeben. Damit die Checks das einerseits nicht laufend als Fehler alarmieren andererseits der Admin über diese fehlenden Komponenten zumindest auf der Kommandozeile hingewiesen wird, geben wir diese Hinweise nach stderr aus.

Nagios-Plugins für NetApp (und Icinga)


Nagios-Plugins für NetApp stabil

17. Februar 2010

So, jetzt ist es so weit: Die erste, sorgfältig getestete und wahrlich stabile Version der Nagios-Plugins für NetApp ist offiziell erhältlich.
Und schon arbeiten wir daran, die zahlreichen Ideen und Vorschläge aus dem Kundenfeedback einzuarbeiten – die Version 2.x ist bereits im ALPHA-Stadium.

http://www.netapp-monitoring.info/de/nagios-plugins-roadmap.html


Monitoring Snapshots

2. November 2009

Damit Snapshots auf einem NetApp-Filer nicht in den Himmel wachsen, muss man deren Größe regelmässig überprüfen. Um dies zu automatisieren und im Falle des Überschreitens definierter Grenzwerte alarmiert zu werden, haben wir ein Nagios-Plugin entwickelt, das diese Werte regelmäßig abfrägt, mit  Schwellwerten vergleicht und auch die Grundlagen für eine kontinuierliche Aufzeichnung (Trending) liefert. Im praktischen Betrieb hat sich dann gezeigt, dass die Situation nicht immer ganz so einfach ist und verschiedene Szenarien zu unterscheiden sind: Zum einen kann das Volume keine Snapreserve definiert haben. In diesem Fall wäre der durch die Snapshots verbrauchte Platz wohl am besten relativ zur Größe des Volumes zu berechnen. Anders, wenn es eine definierte Snapreserve gibt; dann sollte die Auslastung dieser Reserve als Basis für die prozentualen Schwellwerte genommen werden. Ein Beispiel zur Verdeutlichung:

Volume A, 100 GB, keine Snapreserve: Wenn durch die Snapshots insgesamt 18 GB belegt werden, ergibt dies eine relative Auslastung von 18% berechnet auf Basis der Volumegröße.

Volume B, 100 GB, davon sind 20GB als Snapreserve reserviert: Wenn die SnapShots hier 18 GB belegen, ergibt dies eine relative Auslastung von 90% (genau 100/20*18) auf Basis der Snapreserve.

Man sieht also, dass die Definition der einzelnen Szenarien durchaus kompliziert werden kann. Wir wollen aber letztendlich zu einer möglichst einfachen Lösung gelangen, die es uns erlaubt mit einigen wenigen Service-Checks alle vorhandenen und auch zukünftig noch angelegten Volumes zu prüfen. Was uns nicht interessiert, ist bei jedem Anlegen eines neuen Volumes am NetApp-Filer die Nagios-Konfiguration anpassen zu müssen.

Im Allgemeinen wird man dafür mit zwei Servicechecks auskommen, um alle Volumes am Filer prüfen zu können. Man muss nur die beiden Szenarien unterscheiden: Volumes mit definierter Snapreserve und solche ohne. Und genau dafür gibt es den Schalter –check_only, dem entweder der Wert with_reserve oder no_reserve zugwiesen werden kann.

Die in die Nagioskonfiguration zu übertragenden Checks würde dann so aussehen:

Check A erfasst alle Volumes ohne definierter Snapreserve. In diesem Fall wird man die Standardvorgaben für die Schwellwerten von 80% bzw. 95% wohl geringer ansetzen, denn wenn die Snapshots einmal 80% des Volumes verbrauchen, ist es für eine Warnung meist schon zu spät.

$ ./check_netapp_snapshots.pl -H sim -f auth --base=vol
 --check_only=no_reserve -w 20% -c 30%

Check B erfasst alle Volumes mit defninierter Snapreserve. Hier können die Standardvorgaben für die Schwellwerte durchaus passen, da sie ja jetzt relativ zur Snapreserve berechnet werden. Daher entfallen hier -w und -c.

$ ./check_netapp_snapshots.pl -H sim -f auth --base=reserve
 --check_only=with_reserve

Und falls man dann noch die Volumegröße in den Performancedaten haben will, um diese in den RRD-Graphen hübsch darzustellen, setze man den Schalter –perf_volume dazu. Dieser wird ergänzt durch –perf_abs, welcher in den Performancedaten auch die Snapshot-Größe in Blöcken statt Prozent ausgibt.

Eine gute Beschreibung des Themas: http://broadcast.oreilly.com/2009/02/understanding-snapshot-consump.html


Monitoring NetApp: SNMP vs. NetApp API

28. Oktober 2009

Überblick über NetApp-Service-Checks in NagiosZahlreiche Tools zur Überwachung von NetApp basieren auf dem Monitoring-Defacto-Standard SNMP. Dieses Protokoll ist praktisch, da allgemein bekannt, weit unterstützt und leider auch uralt. Das zeigt sich zum Beispiel darin, dass heutige komplexe Systeme wie die Speichergeräte von NetApp eigene APIs bereitstellen, die auch bei komplexen Operationen noch übersichtlich programmatisch angesprochen werden können. Die NetApp-API ist unter anderem mit C, Java oder Perl anzusprechen. Somit war es für mich logisch, die NetApp-Plugins für Nagios in Perl zu entwicklen und dabei aber auf diese API zurück zu greifen.

NetApp Manage ONTAP SDK (NetApp Community Blog Article)


Wieviele Kommastellen bei prozentualen Werten?

5. Mai 2009

Kundenwünsche können auch ins Detail gehen und lösen dann mitunter interessante Diskussionen aus. So zum Beispiel die Frage eines Nagios-Admins, der unser Plugin zur Prüfung der Auslastung von Aggregaten und Volumes auf  NetApp-Filern  check_netapp_usage einsetzt: Seine Frage war, ob es wirklich sinnvoll sei einen Prozentwerten auf zwei oder gar drei Nachkommastellen genau zu runden. Letztendlich haben wir uns dazu entschlossen, für die Anzeige im Nagios auf eine Nachkommastelle zu runden mit der durchaus sinnvollen Begründung, dass bei kleinen Werten die Aussage „Auslastung beträgt 0,1%“ deutlich signalisiert, dass das Plugin noch arbeitet während ein Meldung wie „Die Auslastung is 0%“ doch eine gewisse Unsicherheit vermittelt. Monitoring NetApp mit Nagios: Scrrenshot Volume Usage


Follow

Get every new post delivered to your Inbox.