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.

Auslastung-Graph mit Spikes

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.

Auslastunggraphik mit großer Fläche unter der Kurve

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.

Wikipedia zu AUC