NetApp Monitoring, v3.8.1

RC1 für 3.8.1 verfügbar

Am Q-Portal erscheint heute die Version 3.8.0_03 als der erste Releasecandiate für die Version 3.8.1 von check_netapp_pro mit folgenden Änderungen:

  • StorageUtilization output units can be controlled by --factor=ki|Mi|Gi|...
  • New check: check_netapp_quotas.pl – monitors quotas on a cdot filer.
  • ShelfEnvironment: False positive for voltage-sensors in DataONTAP 9.1P1 (solved with temporary switch --DataONTAP_91P1)
  • DiskPaths: Bugfix and additional switch --port_pattern_ok=AAAA | BBBB | ...

Feedback wie bitte an developer@netapp-monitoring.info.

NetApp Monitoring, Quotas, v3.9.0

Quota Check

Zur Überwachung der Quotas auf einem Cluster Mode Filer haben wir den Check check_netapp_quotas entwickelt und planen diesen im nächsten Release zu veröffentlichen. Sehr gerne stellen wir Ihnen diesen Check aber auch ab sofort in Form eines Testing-Releases zur Verfügung. Die Version 3.8.0_02 wird heute im Laufe des Tages am Q-Portal zur Verfügung stehen, wenn Sie für Beta-Releases frei geschalten sind. Bitte kontaktieren Sie den Distributor um sich gegebenenfalls berechtigen zu lassen.

Checklogik und Parameter

Wie schaut der Quotacheck nun aus? Wir haben diesen wie schon in der Vorversion (check_netapp 2.x) sehr einfach gehalten. Übergeben wird lediglich der Hostname. Schwellwerte sind nicht nötig, das Plugin prüft basierend auf Basis des Soft- und Hardlimits am Filer.

./check_netapp_quotas.pl -H filer91
All checked quotas within limits on filer91.
| srv1.vol1_disk-used=0kiB;0;0;0; srv1.vol1_files-used=6;0;0;0; srv1.vol1.*_disk-used=0kiB;0;51200;0; srv1.vol1.*_files-used=0;0;0;0;

Allerdings kann über --qtree oder --volume eingeschränkt werden, wo genau geprüft werden soll.

Soweit der aktuelle Stand. Falls Sie Änderungen wünschen können Sie diese gerne hier als Kommentar anfügen oder Sie schreiben an developer@netapp-monitoring.info.

NetApp Monitoring, SnapMirror

SnapMirrorMetrics und nicht finalisierte Transfers

Mir liegt ein Featurerequest zu SnapMirrorMetrics vor:

Da bei uns des Öfteren Lagtime False Positives auftreten weil der Transfer zwar fertig ist aber am Volume noch finalisiert wird, hätten wir gerne einen Schalter für den SnapMirrorMetrics-Check:‑‑finalizing_relation_is_ok

Derzeit sind dafür zwei Lösungsvarianten in Diskussion:

Die einfache Lösung: --finalizing=OK|WARN

Dieser Schalter würde den Check auch dann mit OK (oder WARNING) beenden, wenn die Lagtime überschritten wurde, vorausgesetzt der Status des betreffenden Transfers ist schon finalizing.

An dieser Stelle sollten wir uns vielleicht vor Augen halten, was finalzing genau meint. Dazu lesen wir im SDK:

‚finalizing‘ – SnapMirror transfers are enabled, currently in the post-transfer phase for vault or extended data protection incremental transfers

Die sehr gründliche Lösung:--finalizing_plus=12h

Im Gegensatz zu der oben schon vorgestellten Lösung würde hier der Schwellwert abhängig vom Status des Transfers um bis zu maximal 12 Stunden verlängert werden. Damit würden wir verhindern, dass im Falle eines endlos in einer finalizing-Schleife hängen gebliebenen Transfers, dieser auf ewig OK und damit vom Monitoring unerkannt bleiben würde.

Ein vollständigeres Beispiel zur Erläuterung:

SnapMirrorMetrics ... --what=lag_time -w 1d -c 2d --finalizing_plus=12h

Das obige Beispiel ergäbe dann mit einer lag-time > 36h immerhin ein WARNING und nach 2,5 Tagen einen CRITICAL Alarm, selbst dann wenn der relationship-status ‚finalizing‘ ist. In allen anderen relationship-status wird wie bisher nach einem Tag ein WARNING und nach zwei Tagen ein CRITICAL Alarm ausgelöst.

Ihre Meinung?

Mir persönlich sagt die zweite, gründlichere Variante mehr zu. Das Verhindern von false-positives also Fehlalarmen ist sicherlich ein wichtiges Anliegen sollte jedoch keinesfalls dazu führen, dass false-negatives, also unentdeckte Fehler dadurch ermöglicht werden – auch dann wenn diese unwahrscheinlich sind. Letztendlich richten wir uns aber nach den Kundenwünschen. Bei Interesse an einem dieser Schalter kommentieren Sie bitte diesen Artikel oder senden ein E-Mail an developer@netappmonitoring.info.

NetApp Monitoring, tmp, v3.8.0

Stable Release 3.8.0 verfügbar

Heute konnten wir die Tests für das nächste Stable Release 3.8.0 abschliessen und dieses für unsere Kunden am Q-Portal veröffentlichen.

Die meiner Meinung nach bedeutsamsten  Änderungen sind:

  • New check: FCPAdapter checks fcp-adapters status (online, …)
  • Usage-check: --check_only=500GiB..1TiB (ranges to specify different thresholds depending on the volumes total size)

Weiters sollte man wissen, dass die  Getter temp-Verzeichnisse ignorieren und – sehr praktisch –  der neue ShelfEnvironment-getter benötigt keinen --node Switch mehr.

Detaillierte Information zu den Änderungen in 3.8.0

Alle Änderungen finden Sie wie immer in der History.

Alle Blog-Artikel zum Release 3.8.0 .

DiskPaths, NetApp Monitoring, tmp

Soll DiskPaths flexibler werden?

Folgende Anfrage um Erweiterung des Checks DiskPaths ist eingegangen.

Wir haben bei einem Kunden einen Single Node Metro Cluster – also pro Seite gibt es nur einen Node anstelle eines HA-Pärchens. Damit meckert der Check es an dass nur zwei statt der 4 Pfade verfügbar sind. Das gleiche Problem besteht auch bei einem Single Node Cluster (Entry Level System) welcher für die internen Disken nur einen statt der zwei Pfade sieht.

Für solche Situationen hätten wir gerne einen Schalter mit dem wir festlegen könne, wieviele Pfade OK sind.

Somit steht also zur Debatte, den Check DiskPaths um einen Schalter --paths=1|2|4|8 zu erweitern. Der Aufruf auf der Kommandozeile würde dann z.B. lauten:

$ ./check_netapp_pro.pl DiskPaths -H filer
# default wäre weiterhin 8 Pfade

$ ./check_netapp_pro.pl DiskPaths -H filer --paths=2
# dedizierte Angabe für eine Single Node Metro Cluster

Wenn Sie Interesse an dieser geplanten Erweiterung haben, kommentieren Sie bitte diesen Artikel oder senden Sie ein E-Mail an developer@netapp-monitoring.info.

Logfile Monitoring, NetApp Monitoring, tmp

Logchecker – neues Testing-Release

Der Check für das Event-Log (EMS) wurde leicht verbessert. Nach wie vor handelt es sich dabei um eine Testversion, die Sie bitte direkt beim Entwickler anfordern (developer@netapp-monitoring.info).

Neuerungen

  • Datum und Zeit werden ausgegeben – in der ersten Version hatten wir den UNIX-Stimestamp („Epochensekunden“).
  • Die Source wird je Eintrag angezeigt.
  • Die Option --severity haben wir Syslog-konform gestaltet.
  • Die Dokumentation wurde verbessert: INSTALL.txt erklärt die Installation, --examples gibt einige Konfigurationsbeispiele aus.

Weitere Informationen zum Logfile-Check finden Sie in der Kategorie NetApp Logfile Monitoring.

NetApp Monitoring, v3.8.0

RC1 für 3.8.0

Die unstable Version 3.7.1_04 ist der erste  Releasecandidate für die Version 3.8.0 (und nicht der zweite, wie in einem früheren Artikel hier irrtümlich geschrieben).

Wesentliche Änderungen sind:

Erhältlich ist diese unstable Version wie immer am Q-Portal für BETA-berechtige Kunden.

Weiterführende Information

Alle Blog-Einträge die sich auf Änderungen in 3.8.0 beziehen

Release History