Einfache Methode zur algorithmischen Identifizierung einer Spitze in aufgezeichneten Fehlern

Wir brauchen ein Frühwarnsystem. Ich habe es mit einem Server zu tun, bei dem Leistungsprobleme unter Last bekannt sind. Fehler werden zusammen mit einem Zeitstempel in einer Datenbank aufgezeichnet. Es gibt einige manuelle Eingriffsschritte, mit denen die Serverauslastung verringert werden kann, aber nur, wenn jemand das Problem kennt ...

Wie kann ich unter Berücksichtigung der Häufigkeit, mit der Fehler aufgetreten sind, den Beginn einer Fehlerspitze (in Echtzeit) identifizieren? Wir können periodisch oder bei jedem Fehlerauftritt rechnen.

Wir sind nicht besorgt über gelegentliche Fehler, haben aber keinen bestimmten Schwellenwert. Ich könnte einfach jemanden benachrichtigen, sobald wir in fünf Minuten drei Fehler erhalten, aber ich bin mir sicher, dass es einen besseren Weg gibt ...

Ich möchte in der Lage sein, die Empfindlichkeit des Algorithmus basierend auf dem Feedback der Sysadmins anzupassen. Im Moment möchten sie, dass es ziemlich sensibel ist, auch wenn wir wissen, dass wir einige falsche Positive erwarten können.

Ich bin kein Statistiker, was sicher offensichtlich ist, und die Implementierung muss mit unseren vorhandenen Tools relativ einfach sein: SQL Server und ASP JScript der alten Schule. Ich suche keine Antwort im Code, aber wenn es zusätzliche Software erfordert, funktioniert es wahrscheinlich nicht für uns (obwohl ich aus Neugier unpraktische, aber ideale Lösungen als Kommentar begrüße).

Es ist 5 Monate her, seit Sie diese Frage gestellt haben, und Sie haben hoffentlich etwas herausgefunden. Ich werde hier einige andere Vorschläge machen, in der Hoffnung, dass Sie in anderen Szenarien eine Verwendung für sie finden.

Für Ihren Anwendungsfall müssen Sie sich meines Erachtens nicht mit Algorithmen zur Spike-Erkennung befassen.

Also los geht's: Beginnen wir mit einem Bild der Fehler, die auf einer Timeline auftreten:

Was Sie wollen, ist ein numerischer Indikator, ein "Maß" dafür, wie schnell die Fehler kommen. Und diese Maßnahme sollte für Schwellenwerte geeignet sein - Ihre Systemadministratoren sollten in der Lage sein, Grenzwerte festzulegen, die steuern, mit welcher Empfindlichkeit Fehler zu Warnungen werden.

Maßnahme 1

Sie haben "Spikes" erwähnt. Der einfachste Weg, einen Spike zu erhalten, besteht darin, alle 20 Minuten ein Histogramm zu zeichnen :

Ihre Systemadministratoren würden die Empfindlichkeit basierend auf der Höhe der Balken einstellen, dh den meisten Fehlern, die in einem 20-Minuten-Intervall toleriert werden.

(An dieser Stelle können Sie sich fragen, ob das 20-Minuten - Fensterlänge nicht eingestellt werden kann. Es kann, und Sie können als Definition des Wortes der Fensterlänge denken zusammen in den Satz Fehler erscheinen zusammen .)

Was ist das Problem mit dieser Methode für Ihr bestimmtes Szenario? Nun, Ihre Variable ist eine Ganzzahl, wahrscheinlich weniger als 3. Sie würden Ihren Schwellenwert nicht auf 1 setzen, da dies nur bedeutet, dass "jeder Fehler eine Warnung ist", für die kein Algorithmus erforderlich ist. Sie haben also die Wahl zwischen 2 und 3. Dies gibt Ihren Systemadministratoren nicht die größtmögliche Kontrolle.

Maßnahme 2

Anstatt Fehler in einem Zeitfenster zu zählen, verfolgen Sie die Anzahl der Minuten zwischen dem aktuellen und dem letzten Fehler. Wenn dieser Wert zu klein wird, bedeutet dies, dass Ihre Fehler zu häufig werden und Sie eine Warnung auslösen müssen.

Ihre Systemadministratoren setzen das Limit wahrscheinlich auf 10 (dh, wenn Fehler in einem Abstand von weniger als 10 Minuten auftreten, ist dies ein Problem) oder 20 Minuten. Vielleicht 30 Minuten für ein weniger unternehmenskritisches System.

Diese Maßnahme bietet mehr Flexibilität. Im Gegensatz zu Measure 1, für das es einen kleinen Wertesatz gab, mit dem Sie arbeiten konnten, haben Sie jetzt ein Measure, das gute 20-30 Werte liefert. Ihre Sysadmins haben daher mehr Spielraum für die Feinabstimmung.

Freundlicher Rat

Es gibt einen anderen Weg, um dieses Problem anzugehen. Anstatt die Fehlerhäufigkeiten zu betrachten, können die Fehler möglicherweise vorhergesagt werden, bevor sie auftreten.

Sie haben erwähnt, dass dieses Verhalten auf einem einzelnen Server auftritt, bei dem Leistungsprobleme bekannt sind. Sie können bestimmte Leistungsindikatoren auf diesem Computer überwachen und sich mitteilen lassen, wann ein Fehler auftreten wird. Insbesondere werden die CPU-Auslastung, die Speichernutzung und die KPIs für die Datenträger-E / A untersucht. Wenn Ihre CPU-Auslastung 80% überschreitet, wird das System langsamer.

(Ich weiß, dass Sie gesagt haben, dass Sie keine Software installieren möchten, und es stimmt, dass Sie dies mit PerfMon tun können. Es gibt jedoch kostenlose Tools, die dies für Sie tun, wie Nagios und Zenoss .)

Und für Leute, die hierher kamen, in der Hoffnung, etwas über die Spike-Erkennung in einer Zeitreihe zu finden:

Spitzenerkennung in einer Zeitreihe

$x_1, x_2,...$

$M_k = (1 - \alpha) M_{k-1} + \alpha x_k$

$\alpha$$x_k$ .

Wenn sich Ihr neuer Wert zum Beispiel zu weit vom gleitenden Durchschnitt entfernt hat

$\frac{x_k - M_k}{M_k} > 20\%$

dann machst du eine Warnung.

Gleitende Durchschnitte sind beim Arbeiten mit Echtzeitdaten hilfreich. Angenommen, Sie haben bereits eine Reihe von Daten in einer Tabelle und möchten nur SQL-Abfragen ausführen, um die Spitzen zu finden.

Ich würde vorschlagen:

1. Berechnen Sie den Mittelwert Ihrer Zeitreihen
2. $\sigma$
3. $2\sigma$

Noch mehr Spaß mit Zeitreihen

1. Viele reale Zeitreihen zeigen zyklisches Verhalten. Es gibt ein Modell namens ARIMA, mit dem Sie diese Zyklen aus Ihren Zeitreihen extrahieren können.

2. Gleitende Durchschnitte, die das zyklische Verhalten berücksichtigen: Holt und Winters

+1 Für die statistische Prozesskontrolle finden Sie hier einige nützliche Informationen zur Schritterkennung .

Für SPC ist es nicht allzu schwer, eine Implementierung der Western Electric Rules oder der Nelson Rules zu schreiben .

Erstellen Sie einfach einen USP in SQL Server, der einen Datensatz durchläuft und jeden Punkt mit seinen Nachbarpunkten mit den Regeln vergleicht. Fassen Sie möglicherweise die Anzahl der Fehler pro Stunde zusammen (je nach Ihren Anforderungen).

Diese Art von bezieht sich auf eine Frage, die ich vor einiger Zeit auf Stack Overflow gestellt habe (habe gerade eine schnelle Antwort geschrieben, wenn es hilft): Statistische Prozesssteuerungsdiagramme in SQL Server 2008 R2

Eine Suche nach Online-Erkennungsalgorithmen wäre ein Anfang.

Weitere Informationen zum Stackoverflow: Peak Dection des gemessenen Signals

Eine Python-Implementierung einer naiven Peak-Detektionsroutine ist bei github zu finden

Vielleicht möchten Sie sich die statistische Prozesskontrolle ansehen. Oder Zeitreihenüberwachung. Es gibt Unmengen von Arbeit in diese Richtung, und die optimale Antwort hängt wahrscheinlich stark davon ab, was genau Sie tun (müssen Sie jährliche oder wöchentliche Saisonalitäten in der Last herausfiltern, bevor Sie Anomalien usw. erkennen).