Zeitgewichteter Durchschnitt

11. März 2010

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: , , , , , , , | Permalink
Verfasst von lanti

Schwellwerte gegen Datenreihen vergleichen

2. März 2010

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

Monitoring „The Area Under the Curve“

17. Februar 2010

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.

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

1 Kommentar | Alarmierung, Messwertglättung, NetApp Monitoring | Mit Tag(s) versehen: , , , , , | Permalink
Verfasst von lanti

Follow

Get every new post delivered to your Inbox.