Nagios-Plugins für MultiStore vFiler

31. Januar 2012

Die MultiStore Software von NetApp ermöglich ein physisches NetApp Gerät in mehrere virtuelle vFiler aufzuteilen. Jeder dieser vFiler kann für sich von den anderen strikt getrennt verwaltet werden –  wie wenn es sich jeweils um ein eigenes, physisches Gerät handeln würde:

  • Der Administrator eines vFilers kann nur dessen Dateien verwalten
  • Die Daten fremder vFiler sind für den vFiler-Admin nicht sichtbar.
  • Volumes und Qtrees können einem vFiler exklusiv zugeteilt werden.

Der physische Storage wird damit mandantenfähig.

Für das Monitoring kann es natürlich interessant sein, die Volumes eines bestimmten vFilers zu überwachen. Das um so mehr als dank „Over-All“-Checks dynamisch erkannt wird, welche Volumes am Filer gerade existieren.

Um die Überwachung ebenfalls mandantenfähig gestalten zu können, muss es möglich sein gezielt den vFiler ansprechen zu können, dessen Volumes überwacht werden sollen.

Die Nagios-Plugins für NetApp ermöglichen dies seit der Version 2.3.0. Bei jedem Check kann mittels der Option –vfiler=My_vFiler angegeben werden, welcher der vFiler in einer MultiStore-Umgebung geprüft werden soll.

Link: Leistungsbeschreibung Nagios Plugins für NetApp(mit vFiler-Switch).pdf

Kommentar schreiben » | MultiStore, Nagios Plugins für NetApp, NetApp, NetApp Monitoring | Mit Tag(s) versehen: , , , , , , | Permalink
Verfasst von lanti

NetApp SLA-Monitoring mit Nagios?

9. Juni 2011

Ist ein Storage-System nun verfügbar oder nicht? Das ist auch eine Frage des Standpunktes. Aus Benutzersicht ist er nur dann verfügbar, wenn auch alle Services am Weg dorthin „up and running“ sind. Dafür gibt es Nagios-Plugins, die dies regelmäßig überprüfen und aufzeichnen (z.B. check_diskwrite2 [1]).

Doch was, wenn die Storage-Gruppe nachweisen will oder muss, dass die Volumes grundsätzlich schreib- und lesbar sind? Hier wäre ein Check gefragt, der je Volume eine Datei anlegt, liest und löscht – und das ganze am direkten Weg über die NetApp API. Dieser Check wäre von anderen Services (wie z.B. einem Domaincontroller) weitestgehend unabhängig.

Um herauszufinden, ob Bedarf an einem solcher Check besteht, haben wir eine Umfrage gestartet:

Nagios SLA-Monitoring-Plugin für NetApp: http://netapp-monitoring.info/de/umfragen/sla.html

Links:

[1] http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/check_diskwrite2/details

 

 

Kommentar schreiben » | SLA | Permalink
Verfasst von lanti

Monitoring verwaister Snapshots (SMVI, …)

10. Mai 2011

Monitoring Snapshot-Age – veraltete Snapshots finden und überwachen

NetApps’s SnapManager for Virtual Infrastructure (SMVI) zum Beispiel macht es: Snapshots im Volume zu hinterlassen, die manuell gelöscht werden müssten. Diese verwaisten Snapshots verbrauchen mehr und mehr Platz am Volume und binnen kurzem kann dieses voll sein. Für diese und ähnliche Anwendungsfälle wird nun das Check-Module Snapshots der  Nagios Plugins für NetApp erweitert. So soll es möglich werden, die zu überwachenden Snapshots nach Alter zu filtern. Somit wäre es beispielsweise möglich, dass man sich warnen lässt, wenn auf einem Volume über 50% der Snapreserve für Snapshots älter als 14 Tage belegt werden.

Aber auch ein Filter nach Namen wäre denkbar. Dann könnten nur jene Snapshots in die Alarmierung miteinbezogen werden, die einem bestimmten Muster entsprechen wie bespielsweise  ’*smvi*’ oder ‘hourly*’.

Gerne können Sie Ihre Wünsche dazu mittels dieser Umfrage deponieren:

http://netapp-monitoring.info/de/umfragen/snapshot-age.html

Kommentar schreiben » | Age of Snapshots, Alarmierung, Nagios Plugins für NetApp, snapshot date, Snapshots | Mit Tag(s) versehen: | Permalink
Verfasst von lanti

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)

Kommentar schreiben » | Icinga, NetApp Überwachung, NetApp Monitoring | Permalink
Verfasst von lanti

SNMP-Traps als Alternative zur ZAPI?

3. Dezember 2010

Vor kurzem erreichte mich eine Anfrage, ob denn nicht das NetApp-Monitoring auch über die SNMP-Traps möglich sei. Der Ansatz erschien mir ungewöhnlich doch gerade deswegen wollte ich der Sache auf den Grund gehen. So hielt ich zunächst einmal Rücksprache mit meinem Kollegen Christian Rusa. Des längeren Telefonates kurze Zusammenfassung lautet in etwa so: SNMP-Traps waren noch nie für die laufende Überwachung oder gar Aufzeichnungen zur Trendanalyse gedacht. Auf Grund ihrer Natur,  aktive Meldungen des zu überwachenden Systems zu sein, bekommen wir bei Systemausfall keine Traps mehr. Es muss also das Monitoringsystem erst einmal auf Grund des Ausbleibens von Meldungen die richtigen Schlüsse ziehen. Die große Frage, sollte man sich dennoch dazu entschliessen diesen Weg zu gehen: Kann das zu  überwachende System überhaupt regelmäßig Traps senden?

In der Praxis ist es dann oft so, dass ein System sich sang- und klanlos verabschiedet und wenn der zugrundeliegende Fehler dann endlich erkannt und behoben ist  so dass das System wieder hochfährt, dann versendet es frisch fröhlich jene Traps, die es ausfallsbedingt zuvor nicht mehr losgeworden ist.

Diese grundlegenden Probleme von Traps kommen zu den SNMP-spezifischen Schwierigkeiten wie in dem Artikel „Monitoring NetApp: SNMP vs. NetApp API“ beschrieben noch hinzu. Ich habe daher darauf verzichtet, noch genauer nachzuforschen, inwieweit die komplexe NetApp-Technik durch definierte Traps abgedeckt wird.

Kommentar schreiben » | NetApp Monitoring, SNMP | Permalink
Verfasst von lanti

Disk-Utilization auf Aggregatebene

26. August 2010

Der Version 2-Check PerfDisk macht verglichen mit seinem Vorgänger check_netapp_utilization nichts Neues: er misst in regelmässigen Abständen die utilization je vorhandener Disk.

Utilization: Percentage of time there was at least one outstanding request to the disk

Neu ist, dass bei Perfdisk ein Filter für das Aggregat gesetzt werden kann. Sinnvoll ist das vor allem um heraus zu finden, ob für ein Aggregat weitere Festplatten nötig sind, um der Belastung gewachsen zu sein.

Nagios-Plugins für NetApp

Kommentar schreiben » | disk utilization, NetApp Monitoring, Performance | Permalink
Verfasst von lanti

Latenz („per volume latency“) mit Nagios überwachen

16. Juni 2010

NetApp empfiehlt[1] die Überwachung der „per-volume-latency“ (Latenz je Volume) als primären Indikator für zu erwartende Performance-Engpässe. Da dieser Indikator über SNMP nicht verfügbar war, gibt es meines Wissens nach kein Nagios-Plugin, das sich dafür geeignet hätte.

Es lag daher nahe, auf Basis des NetApp SDK ein Nagios-Plugin zu entwickeln, das die Latenz eines Volumes regelmäßig prüft und aufzeichnet. Mit PerfVolume steht ein solches seit heute zur Verfügung.

Unterstützte Counter

Wie auch die anderen Plugins, verfügt PerfVolume.pm über eine Option zur Erkennung der auf einem NetApp-System angebotenen Leistungskennzahlen.

Aufgerufen wird dieses Check-Plugin übrigens mit dem zu der Version 2 gehörigen Startskript check_netapp.pl.

$ ./check_netapp.pl PerfVolume -H sim8a -f ../auth --explore=counters
Volume Performance Counters available on this filer:
================================================================================
Counter-Name                Description (Unit, Privilege)
--------------------------------------------------------------------------------
read_latency                Average time for reads to the volume (microsec,
			    basic)

avg_latency                 Average latency in microseconds for all operations
			    on the volume (microsec, basic)

total_ops                   Number of operations per second serviced by the
			    volume (per_sec, basic)

other_latency               Average time for other operations to the volume
			    (microsec, basic)

other_ops                   Number of other operations per second to the volume
			    (per_sec, basic)

write_ops                   Number of writes per second to the volume (per_sec,
			    basic)

write_latency               Average time for writes to the volume (microsec,
			    basic)

read_ops                    Number of reads per second to the volume (per_sec,
			    basic)

Beispiel

Nehmen wir den Counter avg_latency als Beispiel. Folgend der Aufruf über die Komandozeile und die Ausgabe.

$ ./check_netapp.pl PerfVolume -H sim8a -f ../auth -z avg_latency -n vol0 -w 20 -c 200
NETAPP OK - avg_latency: 3.2 µs | avg_latency=3.20µs;20;200

Verdächtig flott – aber dieser Filer hat nicht viel zu tun …

Link

[1]
Storage Performance Management

Kommentar schreiben » | latency, NetApp Monitoring, Performance | Mit Tag(s) versehen: , , , , | Permalink
Verfasst von lanti

SSL für die Nagios-NetApp-Kommunikation

12. April 2010

Die NetApp API (ZAPI) kommuniziert mittels HTTP mit den sie aufrufenden Programmen. Selbstverständlich ist das auch über Secure Socket Layer (ssl), also HTTPS möglich und eigentlich auch einfacher, da dann die ab Werk eingestellten Optionen auf einem NetApp-Filer nicht verändert werden müssen. Hinzu kommt, dass diese Einstellung natürlich die sicherere ist. Es lag also nahe, HTTPS als Kommunikationsprotokoll in die Nagios Plugins für NetApp zu integrieren. Und das wurde heute auch erfolgreich für die Plugins der Version 2.x implementiert.

Vorsichtshalber sehe ich noch nach, ob auch wirklich verschlüsselt wird. Folgend die durchaus beruhigenden Screenshots aus meinem Wireshark.

XML-Ausschnitt: size-total und Anzahl der Bytes im Klartext

Unverschlüsselte HTTP-Kommunikation: Ein Sniffer sieht alle Daten im Klartext.

wireshark: http-credentials im Klartext

HTTP ohne Verschlüsselung: Benutzernahme und Passwort werden im Klartext übertragen.

Networktrace HTTPS

Mit Schalter --ssl=yes werden die XML-Daten verschlüsselt übertragen.

Implementiert wurde für check_netapp.pl ein zusätzlicher Schalter

 --ssl=yes|no

Default ist yes . Lässt man diesen Schalter weg oder stellt ihn auf yes, muss man am Filer eigentlich gar nichts mehr konfigurieren da die Option httpd.admin.ssl.enable ab Werk auf on steht. Der Filer kann somit out-of-the-box mittels dieser Plugins überwacht werden. Das geht dann auch problemlos über WAN-Links, die vielleicht unsicher sind oder SNMP gar nicht erst erlauben.

Kommentar schreiben » | Nagios Plugins für NetApp, NetApp Monitoring | Permalink
Verfasst von lanti

Schwellwerte gegen Datenreihen vergleichen

2. März 2010

Das in dem Artikel Monitoring the Area Under the Curve skizzierte Verfahren zur besseren Erkennung von Alarmsituationen hatte zunächst einmal ein sehr einfaches Perl-Modul zur Folge, das einfach ein zeitlich definiertes Fenster an vorhergehenden Messwerten mit-berücksichtigt und daraus den Durchschnitt berechnet. Dieses Verfahren, das vor allem in der Finanzmathematik als Simple Moving Average (SMA) bezeichnet wird, hat aber so seine Tücken: Alle mir bisher untergekommenen Implementierungen gehen davon aus dass die Messwerte regelmäßig eintreffen. Das ist ok, wenn wir von Börsenkursen ausgehen, die gibt es immer und wenn es sie einmal nicht gibt, dann wurde nicht gehandelt und damit sind diese Perioden einfach nicht zu berücksichtigen. Das geht bei den Messwerten im IT-Umfeld nicht. Stellen wir uns folgende (natürlich vereinfachte) Messreihe  vor:

Uhrzeit   Messwert
------------------
12:00 --> 25MB/s
12:01 --> 24MB/s
Ausfall des Monitoring (Leitung, …)
13:00 --> 2 MB/s
13:01 --> 3 MB/s

Das ergibt um 13:01 einen „geglättenen“ Durchschnitt von 13,5 MB/s – whow, da wäre der nicht geglättete aber um einiges näher an  der Realität.

Das Problem bei herrkömmlichen SMA-Implementierungen ist, dass einfach die letzten x-Werte genommen werden, egal von wann die sind. Da ist die Implementierung in dem von mir erstellten Modul schon besser, denn dort werden nur die die Werte der letzten x Stunden verwertet. Extremfälle, wie dass Messwerte die mehrere Monate alt sind noch mit einfliessen, können somit ausgeschlossen werden. Aber auch diese Form der SMA-Berechnung ist suboptimal, denn um bei dem obigen Beispiel zu bleiben: Ein 2-h Fenster darauf angewendet, würde immer noch den viel zu hohen Wert von 13,5 ergeben.

Abhilfe könnte ein anderes Verfahren bieten: Der Exponential Moving Average (EMA) gewichtet die aktuelleren Messwerte stärker. Das Problem bei den vorliegenden Implementierungen (egal ob Perl-Module oder R): Der Zeitfaktor fliesst nicht ein – d.h. bei unregelmäßig eingetroffenen Messwerten kommt es unter Umständen zu bösen Verzerrungen.

Ein besonders schöner Ansatz wäre Holt-Winters (Exponential Smooting), das in der Wirtschaft gerne für die Vorhersagen zu erwartender Nachfrage nach einem bestimmten Produkt oder ähnlichem verwendet wird. Der besondere Charm liegt in der Möglichkeit sowohl Trends als auch saisonale Faktoren einfliessen zu lassen. Während mir das Berücksichtigen von Trends bei der Alarmierung (nicht vergessen, wir befassen uns gerade mit Alarmen und nicht mit Trendanalyse!) im Bereich des Systemmonitoring eher nicht sinnvoll erscheinen ist es natürlich sehr spannend, die unterschiedliche Basisauslastung um Laufe eines Tages oder einer Woche bei den Schwellwerten zu berücksichtigen. Und noch etwas spricht für Holt-Winters: Die rrd-tools haben diese schon implementiert – ich denke, da sollte man sich noch genauer damit befassen.

Aberrant Behavior Detection with Holt-Winters Forecasting

Time series Forecasting using Holt-Winters Exponential Smoothing

2 Kommentare | Alarmierung, Messwertglättung, NetApp Monitoring | Permalink
Verfasst von lanti

Autodiscovery für Perf-Counter

24. Februar 2010

Mit dem Plugin check_netapp_ops.pl lassen sich verschiedene Systemcounter wie beisielsweise total_ops, nfs_ops, net_data_sent eines NetApp Filers überwachen und bei Überschreiten Alarme via Nagios versenden. Doch nicht alle Counter sind auf jedem System vorhanden und nicht alle vorhandenen Counter werden vom Plugin unterstützt. Das Herausfinden der Schnittmenge aus vorhandenen und unterstützten Countern war eine eher mühsame Aufgabe bei der Implementierung der Plugins.

In der Version 2 verfügt das diesem Check nachfolgende Check-Modul Ops.pm diese Aufgabe für den Admin: Durch Angabe von explore anstelle eines Counternamens, bekommt man eine Liste aller verfügbaren und vom Plugin auch überwachbaren Counter  - gleich zusammen mit der Maßeinheit.

Hier ein Beispiel:

$ ./check_netapp.pl Ops -f auth -H toaster01 -z explore


System Performance Counters available _and_ supported on this filer:


================================================================================


Counter-Name                Description (Unit, Privilege)


--------------------------------------------------------------------------------cifs_ops                    CIFS operations per second (per_sec, basic)


nfs_ops                     NFS operations per second (per_sec, basic)


net_data_sent               Network KB sent per second (kb_per_sec, basic)


total_ops                   Total operations per second (per_sec, diag)


net_data_recv               Network KB received per second (kb_per_sec, basic)


write_ops                   Write operations per second (per_sec, basic)


fcp_ops                     FCP operations per second (per_sec, basic)


iscsi_ops                   iSCSI operations per second (per_sec, basic)


read_ops                    Read operations per second (per_sec, basic)


disk_data_written           Disk KB written per second (kb_per_sec, basic)


http_ops                    HTTP operations per second (per_sec, basic)


streaming_pkts              Netcache streaming media packets serviced per


second (per_sec, diag)


disk_data_read              Disk KB read per second (kb_per_sec, basic)


cifs_ops                    CIFS operations per second (per_sec, basic)
nfs_ops                     NFS operations per second (per_sec, basic)
net_data_sent               Network KB sent per second (kb_per_sec, basic)
total_ops                   Total operations per second (per_sec, diag)
net_data_recv               Network KB received per second (kb_per_sec, basic)
write_ops                   Write operations per second (per_sec, basic)
fcp_ops                     FCP operations per second (per_sec, basic)
iscsi_ops                   iSCSI operations per second (per_sec, basic)
read_ops                    Read operations per second (per_sec, basic)
disk_data_written           Disk KB written per second (kb_per_sec, basic)
http_ops                    HTTP operations per second (per_sec, basic)
streaming_pkts              Netcache streaming media packets serviced per                            second (per_sec, diag)
disk_data_read              Disk KB read per second (kb_per_sec, basic)
http://www.netapp-monitoring.info/de/nagios-plugins.html

Kommentar schreiben » | Nagios Plugins für NetApp, NetApp Monitoring, Performance | Permalink
Verfasst von lanti

« Vorherige Beiträge
Follow

Get every new post delivered to your Inbox.