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.
Kommentar schreiben » | 
NetApp Monitoring, Performance, disk utilization | 
Permalink
Verfasst von lanti
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.
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)
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 …
Kommentar schreiben » | NetApp Monitoring, Performance, latency | Mit Tag(s) versehen: latency, ops, Performance Indikatoren, read_ops, total_ops | Permalink
Verfasst von lanti
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.
Unverschlüsselte HTTP-Kommunikation: Ein Sniffer sieht alle Daten im Klartext.
HTTP ohne Verschlüsselung: Benutzernahme und Passwort werden im Klartext übertragen.
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
Wie wir in dem Artikel über SMA und EMA gesehen haben, sind die aus der Finanzwelt kommenden Funktionen zur Berechnung von moving averages (Durchschnittswert der letzen n Messungen) für Zeitreihen im Systemmonitoring-Kontext nicht so gut geeignet, da die Werte auch unregelmäßig eintreffen können. In Verbindung mit Round Robin Databases (RRD) lässt sich die Situation natürlich entschärfen, da diese die unregelmäßig eintreffenden Messwerte zu regelmäßigen Messwertreihen interpolieren können. Ich war dann aber doch auf der Suche nach einer generischen Lösung und bin so auf ein Verfahren gekommen, dass ich als Time Weighted Moving Average (TWMA) bezeichnen würde.
Vorraussetzung ist, dass die Messwert immer gemeinsam mit ihrem Zeitstempel erfasst und gespeichert werden. Moderne Systeme (konkret kenne ich das von NetApp) liefern diese Werte auch immer gleich mit Zeitstempel aus. So habe ich schon einen sehr genauen Wert, der durch die Übertragungsverzögerungen zum Monitoringsystem nicht mehr beeinflusst wird. Weiters gehe ich in der folgenden Erklärung davon aus, dass der Zeitstempel in Epochensekunden ausgedrückt wird.
Die Berechnung des TWMA erfolgt dann, indem die einzelnen Messwerte jeweils mit dem Zeitstempel des Messwertes multipliziert werden. Die Summe dieser Produkte dividiert durch die Summe der Zeitstempel ergibt dann einen Wert, der aktuelle Messwert stärker berücksichtigt als länger zurück liegende und auch kein Problem damit hat, wenn diese Wert nur sehr unregelmäßig eingetroffen sind.
Zur Illustration ein wenig Pseudocode:
Wenn der Hash %Messwert, die Schlüssel Wert und Timestamp enthält.
Wenn das Array @Messwertspeicher, je Element einen solchen Hash enthält.
Dann würde der Code in etwa so aussehen:
foreach $item (@Messwertspeicher) {
$wsum = $wsum + ( $item->Wert * $item->Timestamp )
$tsum = $tsum + $item->Timestamp
}
$twma = $wsum / $tsum
Dieses Perl-Modul setzt die TWMA-Funktion um. Zum Vergleich kann man damit auch den normalen SMA (Simple Moving Average) berechnen.
Kommentar schreiben » | Alarmierung, Messwertglättung, Moving Averages | Mit Tag(s) versehen: EMA, false positives, Fehlalarmvermeidung, Messwerte glätten, Performance Monitoring, SMA, TWMA, Zeitreihen | Permalink
Verfasst von lanti
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
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:
http://www.netapp-monitoring.info/de/nagios-plugins.html$ ./check_netapp.pl Ops -f auth -H toaster01 -z exploreSystem 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 persecond (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)
Kommentar schreiben » | Nagios Plugins für NetApp, NetApp Monitoring, Performance | Permalink
Verfasst von lanti
Ok, der Titel dieses Artikels klingt für erfahrene Systemüberwacher ein wenig fremd – doch wir betreten hier Neuland und daher bitte ich um ein wenig Geduld.
Um was geht es: Nach Installation eines Monitoring Systems geht es ans Kalibrieren, also darum die Schwellwerte so einzustellen, dass keine alarmierungswürdigen Ereignisse übersehen werden und andererseits die Admins nicht von Fehlalarmen überschwemmt werden. Das ist eine nicht ganz einfache Tätigkeit, die zunächst einmal eine genaue Kenntnis der überwachten Systeme verlangt. Hinzu kommt, dass die Monitoring Systeme über Funktionen verfügen, kurzfristige Engpässe von dauerhaften Problemfällen zu unterscheiden.
Nagios beispielsweise versendet erst dann eine Alarmmeldung, wenn ein Gerät trotz mehrfacher Versuche nicht erreicht werden konnte bzw. ein Schwellwert mehrfach hintereinander überschritten wurde. Ein feiner Mechanismus, wenne s um die Erreichbarkeit geht. Doch bei stark schwankenden Messwerten, wie zum Beispiel den operations per second wird es schwierig.
Folgend zwei (der Erklärung halber vereinfachte Graphen). zunächst einmal eine normale Auslastung – gelegentlich ist was los, dann aber wieder Ruhe.
normale Belastung - mit gelegentlichen Ausreissern
Wo würden wir hier die Schwellwerte setzen? Bereits bei 100 (gelbe Linie) und bis hinauf zu 150 haben wir gute Chancen auf mehrfache Fehlalarme in der dargestellten Periode. Erst ab 200 (rote Linie) wäre mit einiger Sicherheit Ruhe.
Doch nun passiert folgendes: Ein Prozess zuckt aus und sorgt für eine entsprechend hohe Dauerbelastung – in der Graphik wäre diese Anomalie auf den ersten Blick zu erkennen.
Dass hier im mittleren Bereich mächtig viel los war, sehen wir auf den ersten Blick - Nagios übersieht das aber.
Ein Monitoringsystem wie z.B. Nagios würde das aber übersehen. Denn wie wir oben festgestellt haben, würden Schwellwerte von 100 (gelbe Linie) zu permanenten Fehlalarmen im Normalbetrieb führen.
Also versuchen wir einen Kompromiss: Setzen wir den Schwellwert auf 150. Wie so oft bei Kompromissen, haben wir nun vor allem die Nachteile beider Fälle: Im Normalbetrieb die Fehlalarme (1-2 in unserem Beispiel) und die Abweichung in Sachen Grundbelastung im zweiten Graphen erkennt das System trotzdem nicht.
Der Grund ist eigentlich einfach: Die von Nagios angebotene Methode des „rechecking“ um Fehlalarme zu vermeiden, ist gut bei verbindungsorientierten Checks. Wenn es um Messwerte geht – vor allem wenn diese sehr volatil sind – ist diese Methode eigentlich ungeeignet. Hier bräuchten wir ein Messverfahren, dass die Area under the curve (engl. Fläche unter der Kurve, abgk. AUC) über einen längeren Zeitraum ermittelt und auf dieser Grundlage alarmiert.
Für die derzeit in Entwicklung befindliche Version 2 der Nagios Plugins für NetApp planen wir daher eine Funktion, die es ermöglicht, Schwellwerte auch für langfristige Trends zu setzen. Damit kann uns das Nagios rufen, wenn ein Performance-Graph aussergewöhnliche Maße annimmt und wir der Sache vielleicht auf den Grund gehen sollten.
Das Monitoring auf AUC-Basis ist meiner Meinung nach das für manche Fälle besser geeignete Verfahren und dann dem Monitoring von Einzelwerten überlegen.
Sicherlich wird es auch damit eine Kunst bleiben, ein Nagios richtig zu tunen – doch mit speziellen Auswertungsverfahren für volatile Messwerte, wird es leichter sein, sich dem Idealzustand anzunähern.
1 Kommentar | Alarmierung, Messwertglättung, NetApp Monitoring | Mit Tag(s) versehen: AUC, Grenzwerte, operations per second, Schwellerte, Schwellwerte, Thresholds | Permalink
Verfasst von lanti
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
Kommentar schreiben » | Nagios Plugins für NetApp, NetApp Monitoring, NetApp Überwachung | Mit Tag(s) versehen: Nagios Plugins, NetApp, NetApp Monitoring | Permalink
Verfasst von lanti
Wie auch immer man die Leistung eines NetApp-Filers überwacht, letztendlich greift man auf die Performance Counter zu. Diese sind nach einem klar strukturierten, hierarchischen Konzept [1] angelegt.
Die oberste Ebene stellen Objekte dar, wie zum Beispiel Volumes. Von diesen Objekten kann es nun mehrere Exemplare (engl. instances) geben, z.B. ‘vol0′, ‘backup-vol’, o.a. Jedes Exemplar besitzt wiederum ein durch das Objekt vorgegebenes Set an Zählern (engl. counter). So werden beispielsweise je Volume die read_ops, die read_latency usw. zur Verfügung gestellt.
Verwaltet werden alle diese Werte vom Counter Manager (CM), auf den über das NetApp eigene CLI aber auch via SNMP oder die NetApp-API zugegriffen werden kann.
Das Nagios-Plugin check_netapp_ops frägt zahlreiche dieser Werte ab und stellt sie für die weitere Verarbeitung in Nagios zur Verfügung.
So kann nun einfach beim Überschreiten von Schwellwerten alarmiert werden oder an Hand von Trends, die PNP4Nagios aufzeichnet anaysiert werden. Eine Erweiterung um Werte wie latency oder cache-age ist schon angedacht. Bei Interesse kontaktieren Sie mich bitte.
[1] partners.netapp.com - Abbildung Blockdiagramm
1 Kommentar | NetApp Monitoring, Performance | Mit Tag(s) versehen: cifs_ops, dafs_ops, disk_data_read, disk_data_written, http_ops fcp_ops, iscsi_ops, nfs_ops, read_ops, streaming_pkts, total_ops, write_ops | Permalink
Verfasst von lanti
Allenthalben hört und liesst man von der Möglichkeit, auf einem NetApp-Filer den Wert cache-age zu überwachen. Folgendes fällt mir dazu ein:
Das CLI-Werkzeug sysstat definiert den Wert cache-age so:
The age in minutes of the oldest read-only blocks in the buffer cache. Data in this column indicates how fast read operations are cycling through system memory; when the filer is reading very large files (larger than the machine’s memory size), buffer cache age will be very low.
Kurz zusammengefasst gibt der Wert also ein Alter in Minuten an - je größer um so besser sollte es um die Antwortzeiten für Leseanfragen bestellt sein. Auf die Write-Performance hat das keinen Einfluss.
Der NetApp System Administration Guide empfiehlt bei einem Absacken der cache-age auf unter 3 Minuten, die Werte für read-ahead auf den betroffenden Volumens anzupassen.
If the file access patterns of your clients are random (nonsequential) and the cache age is less than three, setting minimal read-ahead to ‘on‘ might improve performance.
1 Kommentar | Cache Age, NetApp Monitoring, Performance | Mit Tag(s) versehen: Cache Age, cacheage, chache-age monitoring, chache_age, monitoring cache age | Permalink
Verfasst von lanti
