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, wenn es 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.
Verfasst von lanti 
Zahlreiche 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 
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. 
