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
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. 
