Korrelation von Anomalien - Projekt dampf Teil 2

Ein einzelnes Problem innerhalb einer Anwendung kann natürlich viele Metriken auf einmal beeinflussen. Selbst wenn unsere Anomalie-Erkennung aus dem ersten Teil (falls ihr den Beitrag verpasst habt, könnt ihr ihn hier nachholen: Anomalie-Erkennung in Zeitserien – Projekt dampf Teil 1) immer perfekt funktioniert, kommt es also häufig dazu, dass man regelrecht mit Fehlermeldungen bombardiert wird, wenn für jede einzelne beeinflusste Metrik eine eigene Benachrichtigung verschickt wird. Wenn man ein Verfahren zur Korrelation von Anomalien hätte, um zusammengehörige Anomalien in Gruppen zusammenzufassen, könnte man die Menge an Benachrichtigungen erheblich reduzieren und gleichzeitig dem Nutzer die Suche nach Zusammenhängen abnehmen.

Bei einem gemeinsamen Brainstorming mit einigen Betreuern kamen wir zu dem Schluss, dass ein Clustering ein guter Ansatz zur Korrelation von Anomalien sein könnte. Beim Clustering geht es nämlich darum, dass man eine Menge an Objekten auf Basis einer Ähnlichkeitsfunktion in Cluster aufteilt, wobei Objekte im selben Cluster sich möglichst ähnlich sein sollen und Objekte in unterschiedlichen Clustern möglichst unähnlich. Die wichtigste Frage ist dabei, auf Basis welcher Eigenschaften (auch Features genannt) entscheidet man, dass sich Anomalien ähnlich sind, also zusammengehören?

Feature-Selection

Die ersten beiden, am stärksten gewichteten Features sind die Startzeit sowie die Endzeit einer Anomalie. Es ist schließlich wahrscheinlicher, dass zwei Anomalien zusammenhängen, wenn sie zu einer ähnlichen Zeit aufgetreten sind. Nehme man zum Beispiel einen Fehler, der die CPU-Auslastung eines Services in die Höhe treibt. Dieser würde sehr schnell auch die Antwortzeiten des Services in die Höhe treiben. Oder ein Fehler, der übermäßig viele Anfragen an einen Service verschickt. Dieser würde damit vermutlich sehr schnell die CPU des entsprechenden Services und damit dann wiederum die Antwortzeiten in die Höhe treiben. Und wenn die Fehler jeweils aufhören, sollten auch die zusammenhängenden Anomalien relativ zeitnah enden.

Mit der Kommunikation zwischen Services sind wir auch schon beim nächsten Feature. Das dritte Feature ist nämlich der Abstand der Services, zu denen zwei Anomalien jeweils gehören. Der Abstand ist hierbei als Anzahl von Hops zwischen den Services innerhalb eines Service-Graphen definiert. Es ist schließlich wahrscheinlicher, dass zwei Anomalien zusammenhängen, wenn die betroffenen Services sich durch hin- und hergeschickte Anfragen gegenseitig beeinflussen (oder natürlich wenn sie beide zum selben Service gehören), was wiederum bei einer geringeren Anzahl an Hops wahrscheinlicher wird.

Beispiel für einen Service-Graphen aus der weiter unten beschriebenen Demo-Anwendung

Neben diesen Software-Abhängigkeiten bleiben noch Hardware-Abhängigkeiten. In verteilten Anwendungen laufen Services schließlich teilweise auf der gleichen Hardware (hier als Host bezeichnet). Wenn also ein Service durch einen Fehler die komplette CPU eines Hosts ausnutzt, kann es bei anderen Services, die auf dem gleichen Host laufen, zu weiteren Anomalien kommen, obwohl die Services im Service-Graphen sehr weit auseinander liegen. Also sollten Anomalien, die in Services auf dem gleichen Host laufen, mit größerer Wahrscheinlichkeit in einem Cluster landen.

Generieren von Test-Daten

inspectIT Ocelot – Logo

Um unser Verfahren zu testen, haben wir uns eine kleine Anwendung gebaut, in der wir bewusst Fehler auslösen und somit gelabelte Daten generieren können. Als Basis diente dafür die Demo für inspectIT Ocelot, ein von der Novatec entwickelter konfigurationsloser open-source Java-Agent zum Sammeln von Monitoring-Daten. Diese basiert wiederum auf der Spring Petclinic Microservices-Demo. Dabei handelt es sich um eine kleine Web-Anwendung, in der man Haustiere, deren Besitzer und Tierarztbesuche erstellen kann, die dann in einer Datenbank abgelegt werden.

Screenshot aus dem Web-Interface der Demo-Anwendung

In die Anwendung wurden also einige typische Fehler eingebaut, die man über eine REST-API für jeden Service einzeln auslösen kann und deren Labels (aktiv oder deaktiviert) in einer Zeitserien-Datenbank abgespeichert werden. Darunter befanden sich:

• Maximale CPU-Auslastung durch rekursive Fibonacci-Berechnungen
• Maximale RAM-Auslastung mit Bytebuffern
• Viele http-Fehler-Codes bei Anfragen durch Exceptions, die zufällig geworfen werden
• Hohe Antwortzeiten durch sleep()-Befehle zufälliger Dauer

Die so erzeugten gelabelten Daten konnten wir dann in Kombination mit den gefundenen Anomalien verwenden, um unser Clustering zu testen. In folgender Abbildung sind zum Beispiel die Punkte jeweils eine Anomalie, wobei Anomalien in der Darstellung aufgrund der x- und y-Achse einander auch überlagern oder genau übereinander liegen können. Die Farbe zeigt, welchem Cluster sie zugeordnet wurden. Die roten Markierungen zeigen, wann tatsächlich ein Fehler aktiviert war.

Scatter-Plot, in dem die Ergebnisse der Korrelation von Anomalien dargestellt werden

Durch die Korrelation von Anomalien konnten wir hier also hunderte Meldungen auf nur 7 eingrenzen und übernehmen auch direkt die Analyse von Zusammenhängen mit, sodass man sich auf das Wesentliche, die eigentliche Fehlersuche konzentrieren kann.

Mit dem Clustering in einer weiteren AWS-Lambda sieht die dampf-Anwendung mittlerweile folgendermaßen aus:

Diagramm des Aufbaus der bisherigen dampf-Anwendung

Wie genau die Benachrichtigungen aussehen und was an weiterer visueller Hilfe bei der Analyse gegeben ist, werden wir euch im nächsten Beitrag der dampf-Reihe zum Thema Chatbot, Grafana & Co. zeigen.