1. Anomalieerkennung

Was verstehen wir unter "Anomalieerkennung"?

Anomalien sind Ereignisse, die anderen Ereignissen nicht gleichen (griech. an-homalos). Wir ermitteln anomale Ereignisse mit Methoden des Maschinellen Lernens (Machine Learning - ML) und trainieren Neuronale Netze mit den gesammelten Systemdaten.

Dabei lernen die Modelle das System kennen: Sie lernen die häufig auftretenden, sich wiederholenden Muster. Anomalien stellen folglich für die Modelle seltene oder auch unbekannte Ereignisse dar. Hier liegt ein entscheidender Vorteil ML-gestützter Anomalieerkennung: das Modell kann auch Ereignisse identifizieren, die es noch nie gab bzw. solche, nach denen niemand suchen würde, weil man nicht weiß, dass sie auftreten könnten.

Im Rahmen unserer Analyse werden sowohl ungewöhnliche Log-Einträge als auch ungewöhnliche Sequenzen von Log-Einträgen berücksichtigt.

Fachliche Herausforderung: Dynamisches Systemverhalten und Monitoring in IT-Betrieben

Betreut der IT-Betrieb verschiedene Systemlandschaften, auf denen unterschiedliche Applikationen mit einem abweichenden oder sich gar dynamisch entwickelnden Nutzungsverhalten laufen, kommt es schnell zu einer Überforderung des IT-Betriebs, was dessen Bewertung anbelangt. Klassische Monitoring-Systeme bieten hier kaum Abhilfe: Über graphische Darstellungen, wie sich verschiedene vordefinierte Parameter im Zeitverlauf entwickeln, kann der Betrieb zwar eine Vorstellung von der "Baseline" des Systems entwickeln - dieses Vorgehen stößt allerdings schnell an seine Grenzen, sobald sich das Systemverhalten dynamisch entwickelt. Eine permanente Anpassung von Schwellwerten und Checks bei klassischen Monitoring-Systemen scheint kaum praktikabel. 

Das Monitoring-System und die überwachten Parameter und Schwellwerte sollen ja gerade meist den bisherigen "Normalzustand" widerspiegeln. Verändert sich dieser – und sei es auch nur zu bestimmten Zeiten – kann das klassische Monitoring nahezu unbrauchbar werden. Nicht selten werden dann Meldungen wie CPU-Warnungen mit dem Hinweis durch den IT-Betrieb bestätigt, dass z.B.  eine kurzfristig erhöhte CPU-Auslastung aufgrund von Rechnungsabschlüssen am Monatsanfang normal und in diesem Fall nicht als kritisch einzustufen sei und keine Aktion erfolgen müsse. Hinweise in dieser Art sind kondensiertes Erfahrungswissen des IT-Betriebs. Weicht das zukünftige Systemverhalten jedoch von den "erwarteten Mustern" ab, muss allerdings auch der IT-Betrieb mühsam neue Erfahrungswerte "aufbauen". Dies wird umso schwieriger, je weniger transparent die Zusammenhänge sind. 

Eine maschinelle Anomalieerkennung kann in solchen Fällen schnell eine wichtige Entscheidungsgrundlage liefern, um das Systemverhalten “live” zu bewerten und entsprechende Aktionen abzuleiten. Für die maschinelle Anomalieerkennung kann das "neue" Systemverhalten dann wiederum den neuen Trainings-Input darstellen, um schnell eine angepasste "Baseline" zu erhalten.

Die größte Schwäche des klassischen Monitorings ist aber der Umstand, dass nur erkannt werden kann, was vorab definiert wurde. In dem im Folgenden beschriebenen Fallbeispiel zur Detektion inhaltlich seltener bzw. ungewöhnlicher Ereignisse sehen wir, dass es trotz eines engmaschigen Monitorings durchaus Fälle gibt, die genauer durch den Betrieb untersucht werden sollten, die aber nicht zuvor über einen Monitoring-Check abgebildet waren.

Technische Herausforderung: Ähnlichkeitserkennung in Logtexten durch NLP-Technologien

Logtexte weisen, obwohl sie maschinengeneriert sind, eine hohe Varianz auf. Usernamen, Dateinamen, Maschinennamen, Prozessnamen, Resultstatements variieren praktisch in jedem Eintrag. Es stellt sich also die Frage nach Definition und Detektion ähnlicher und nicht-ähnlicher Logs. Zwei Log-Einträge wie
"User Franz is logged in." und "User Lisa is logged in." sollen als ähnlich erkannt werden.

Mögliche Ansätze zur Erkennung von Ähnlichkeiten wären traditionelle Methoden des NLP (Natural Language Processing) wie Bag of Words, N-Grams, oder Sparse Vectors. Wir setzen auf dem aktuellen Stand der NLP-Technologie auf und arbeiten mit Dense Vector Embeddings. Als Modell verwenden wir einen transformerbasierten Variational Autoencoder. Das Modell wird auf einer Menge gesammelter Logdaten trainiert. Dies kann für jeden Applikationstyp oder sogar für jedes einzelne Logfile geschehen. So ist das Modell schnell auf neue Domänen übertragbar. Durch regelmäßiges Nachtrainieren auf aktuellen Daten lernt das Modell immer wieder den gegenwärtigen Systemstand, die “Baseline” wird angepasst.

Mit dem trainierten Modell wird eine Menge historischer Log-Einträge vektorisiert und in einer Vektordatenbank gespeichert. Aktuelle Daten werden dann ebenfalls vektorisiert und mit den Vektoren in der Datenbank per Nearest Neighbor Search (NNS) abgeglichen. Diese Vektoren (Embeddings bzw. Encodings) repräsentieren in quantifizierter Form die Eigenschaften der Log-Einträge (Representational Learning). Ähnliche Log-Einträge haben ähnliche Vektoren, d.h. Vektoren mit geringer Distanz. Wenn ein Vektor keine nahen Nachbarvektoren hat, gibt es in der betrachteten Datenmenge keine ähnlichen Log-Einträge. Dies ist dann eine Anomalie.

Fallbeispiel: Erkennung inhaltlich seltener Log-Texte als Anomalie

Auf Basis des Trainingsdatensatzes wurde ermittelt, welche Log-Ereignisse auf der untersuchten Instanz inhaltlich selten sind - inhaltlich selten oder "ungewöhnlich" kann auch bedeuten, dass das jeweilige Ereignis bisher noch gar nicht aufgetreten war.  

Nicht jedes inhaltlich seltene Ereignis ist auch fachlich relevant. Es könnte sich allerdings auch um durchaus systemkritische Ereignisse wie beispielsweise neuartige Sicherheitsangriffe handeln, für die es noch gar kein gesichertes Erkennungsverfahren geben kann. Auch Intrusion Detection Systeme nutzen daher beispielsweise neben der Erkennung bestimmter Angriffssignaturen häufig anomaliebasierte Erkennungsmethoden.

2. Root Cause Analysis

Was verstehen wir unter "Korrelationsanalyse"? 

Korrelationsanalyse ist ein statistisches Verfahren, das verwendet wird, um die Stärke und Richtung der Beziehung zwischen zwei oder mehr Variablen zu ermitteln. Im Kontext von Zeitreihenanalysen kann sie dazu eingesetzt werden, um Muster oder Abhängigkeiten zwischen verschiedenen Log-Ereignissen über die Zeit zu identifizieren. Diese Methode hilft dabei, Ursache-Wirkungs-Beziehungen aufzudecken, was für die Vorhersage zukünftiger Ereignisse oder für die Fehleranalyse essentiell sein kann.

Um für die Fehlersuche ein umfassendes Bild zu generieren und eine passende Toolbox bereit zu stellen, verwenden wir in der Regel mehrere Verfahren, die jeweils verschiedene fachliche Aspekte und Fragestellungen bei der Fehlersuche adressieren. So kommen zum Beispiel klassische statistische wie auch ML-basierte Verfahren zum Einsatz.

Die zugrunde liegenden fachlichen Fragestellungen und Herangehensweisen entsprechen dabei dem, was uns im Alltag beim “Troubleshooting” im IT-Betrieb immer wieder begegnet.

Fallbeispiel:Korrelationsanalyse 

Fachliche Herausforderung im IT-Betrieb: Effiziente Fehleranalyse trotz Datensilos und Verantwortungsgrenzen

Im Rahmen der vorliegenden Case Study war der IT-Betrieb – alarmiert über ein klassisches Monitoring-System für vordefinierte Ereignisse – beim Auftreten von Fehlern damit betraut, je nach vermuteter Ursache (auf Basis des eigenen Erfahrungswissens) verschiedene Log-Quellen zu prüfen und so der vermuteten Ursache Schritt für Schritt durch visuelle Sichtung näher zu kommen. Dabei kommt der IT-Betrieb nicht selten auch zeitlich an seine Grenzen. In großen Unternehmen stellt sich zudem häufig die Herausforderung, dass es Datensilos und getrennte Verantwortlichkeiten für bestimmte Fachbereiche gibt, so dass bei dem Versuch, die Ursachenkette nachzuverfolgen, eine andere "Domäne" betreten werden muss, die ggf. den eigenen Erfahrungshorizont übersteigt.

In solchen Fällen wird dann häufig ein Ticket an einen weiteren Fachbereich erstellt mit Indizien oder allgemeine Vermutungen zur Ursache ("könnt ihr mal bitte prüfen, ob es in diesem Zeitraum Auffälligkeiten im Netzwerk gab"), oftmals mit einer Sammlung verschiedener Ereignisse und deren Zeitstempel, um für die weitere Analyse etwas mehr Kontext zu liefern. Hier scheitert es in der Praxis allerdings nicht selten aufgrund des nur domänenspezifischen Wissens an einem Verständnis, welche Arten von Informationen für die weitere Untersuchung überhaupt relevant sein könnten, so dass bei der Ursachenanalyse wertvolle Zeit verloren gehen kann. Nicht selten endet die Ursachenanalyse auch in einer Sackgasse ("in Log xy konnten wir in dem Zeitraum nichts Auffälliges feststellen"), weil beispielsweise nicht das richtige Log geprüft wurde. 

Technische Herausforderung: Korrekte Korrelationsanalyse in der IT-Fehlerdiagnose

Eine zentrale Herausforderung liegt bereits in der korrekten Identifizierung und Interpretation von Korrelationen: Nicht jede statistische Korrelation deutet auf eine tatsächliche kausale Beziehung hin. Vor allem bei zeitreihenbasierten Daten mit Versatz zwischen Timestamps aus verschiedenen Logquellen kann es schwierig sein, zwischen "Ursache" und "Wirkung" zu unterscheiden. Berücksichtigt man die speziellen Herausforderungen, die sich bei der Korrelation von Ereignissen aus verschiedenen Datenquellen ergeben, lassen sich aber nützliche Erkenntnisse gewinnen, die das bereits meist schon vorhandene Erfahrungswissen des IT-Betriebs ggf. bestätigen und auch erweitern. Der Nutzen von systematischen Korrelationsanalysen ist natürlich wesentlich höher, je mehr verschiedene (domänenübergreifende) Logquellen betrachtet werden können. Zudem lassen sich – je nach fachlicher Fragestellung – beliebig komplexe multivariate Zusammenhänge modellieren.

In diesem Fall wurde das Vorkommen zweier verschiedener Ereignistypen für mindestens zwei aufeinanderfolgende Zeitfenster betrachtet (wann tauchen zwei Ereignistypen mindestens einmal gemeinsam in diesem Zeitfenster auf?). Da unterschiedliche Ereignistypen in variierender Häufigkeit gemeinsam vorkommen können, ist es sinnvoll, für die visuelle Inspektion einen relativen Wert zu bilden, der sich an dem zu inspizierenden Zeitfenster orientiert, um eine aussagekräftige und skalierbare Analyse der Korrelationen zu ermöglichen.

Fallbeispiel: Ermittlung häufiger Sequenzen

Was verstehen wir unter „häufige Sequenzen“?

Eine Log-Sequenz ist die Abfolge einzelner Log-Einträge, z. B.:

• Process XYZ started.
• Opened file abc.txt. Process-ID XYZ
• Protocol written. Process-ID XYZ
• Error in in class DoTheStuff. Process-ID DFG
• Closed file abc.txt. Process-ID XYZ
• User Franz logged out.
• Process XYZ finished.

Inhaltlich gehören in diesem Beispiel alle Einträge mit “XYZ” zusammen. Die Einträge mit “DFG” und “logged out” gehören zu anderen Prozessen. 

Log-Texte sind nicht thematisch nach zusammenhängenden Ereignissen strukturiert, sondern nach der Reihenfolge ihres Auftretens. Die fachliche Herausforderung besteht darin, tatsächliche Zusammenhänge zu erkennen.

Wenn wir dieses Bsp. als Referenz nehmen, können wir weitere Abfolgen von Log-Einträgen als "ähnliche Sequenz" erkennen, die ebenfalls den Prozess "XYZ" enthalten - auch wenn andere Prozesse zwischen die Log-Einträge von „XYZ“ ihre eigenen Einträge schreiben.

Fachliche Herausforderung: Effektive Root Cause Analysis in IT-Betriebseinheiten

Für die "root cause analysis" ist aus fachlicher Sicht nicht nur interessant, welche Ereignisse im Zusammenhang mit anderen Ereignissen auftreten, sondern auch, in welcher Reihenfolge bestimmte Ereignisse normalerweise auftreten.

Auch wenn die IT-Betriebseinheit über entsprechende Experten mit einem Verständnis für technische Zusammenhänge verfügt, so ist beispielsweise bei der Einarbeitung neuer Kollegen auch immer ein gewisser Zeitaufwand darauf verbucht, das "jeweilige System" und seine "Eigenheiten" besser kennen zu lernen. Einarbeitung besteht somit zu einem großen Teil in der Weitergabe von Erfahrungswissen – z.B. kodifiziert anhand bestehender Dokumentationen. Im Praxisalltag sind das häufig Dokumente wie gesammelte Monitoring-Meldungen, entsprechende Hinweise zum Fehler-Handling und zum Kontext des Fehlers: Nicht jede Fehlermeldung ist auch in jedem Kontext relevant.

Manche Fehler werden erst relevant, wenn zusätzlich ein oder mehrere weitere Fehler auftreten – oder nur in einem bestimmten Zeitrahmen. Solche Dokumentationen können nicht nur beliebig komplex werden (schließlich lässt sich nur schwerlich jeder Kontext eines Fehlers und dessen Relevanz beschreiben) – das eigentliche Problem besteht vielmehr darin, dass hierüber nur ein bestimmter Status Quo abgebildet ist. Was auf den Systemen in welcher Reihenfolge normalerweise passiert, kann sich im Zeitverlauf ändern – und sei es nur, weil neue Infrastruktur-Komponenten oder Features hinzugekommen sind. Hier stößt auch das „Erfahrungswissen“ wiederum schnell an seine Grenzen. 

Die Ermittlung häufiger Sequenzen ist hier nur ein Beispiel, wie wertvolle Kontext-Informationen zu einem Fehler in die Analyse mit einbezogen werden können.

Technische Herausforderung: Einsatz von Embeddings und NNS zur Analyse von Log-Daten

Analog zu den einzelnen Log-Einträgen werden die Log-Sequenzen vektorisiert und in der Vektordatenbank gespeichert. Dort wird dann per NNS nach Clustern gesucht. 

Log-Einträge sind Sequenzen von Wörtern. Rein technisch macht es keinen Unterschied, eine Sequenz von Wörtern oder eine Sequenz von mehreren Log-Einträgen zu vektorisieren. Die größten Cluster (viele ähnliche Vektoren an einem Ort im Vektorraum) sind dann die häufigsten Sequenzen – auch wenn unter Umständen keine Sequenz exakt einer anderen gleicht.  

3. Mustererkennung

Was verstehen wir unter "Mustererkennung" bzw. “Saisonalität”?

Mustererkennung (Pattern Recognition) als Oberbegriff bezieht sich auf die Identifizierung von regelmäßigen Strukturen oder Trends in Daten. Saisonalität bezeichnet im Speziellen wiederkehrende Muster, die typischerweise mit jahreszeitlichen oder kalendarischen Ereignissen verbunden sind – darunter fallen zum Beispiel Ereignisse wie Abrechnungen zum Monatsabschluss.

Fallbeispiel: Erkennung von Saisonalitäten

Fachliche Herausforderung: Mustererkennung in IT-Betriebslogs zur Vorhersage von Systemausfällen

Für den IT-Betrieb, der Logdaten wie bspw. Datenbank- und Serverlogs untersucht, stellt sich immer wieder die Frage, ob bestimmte Ereignisse regelbasiert auftreten. Dabei gibt es bekannte, geplante Ereignisse wie beispielsweise Wartungsfenster, allerdings auch ungeplante Systemausfälle. Insbesondere in Bezug auf geschäftskritische oder kostenintensive Systemausfälle soll untersucht werden, ob diese irgendeinem bisher unbekannten Muster folgen, also beispielsweise jeden X. Tag im Monat (gehäuft) auftreten.

Auch wenn sich die unmittelbare "Ursache" nicht in der jeweils untersuchten Logquelle finden lässt (z.B. weil der Ausfall des Systems mit einer Netzwerkstörung zusammenhängt und die vorliegenden Logs nur die Datenbank-Systeme betreffen), so können die Erkenntnisse dennoch helfen, die Ursache genauer einzugrenzen. Die Kenntnisse des IT-Betriebs über saisonal wiederkehrende Ereignisse auf den Systemen speisten sich in diesem Fall vor allem aus bekannten Wartungsfenstern oder zu bestimmten Zeiten laufenden Jobs.

Technische Herausforderung: Einsatz von Fourier-Analyse zur Detektion saisonaler Muster in Log-Daten

Neben verschiedenen Dashboards zur Darstellung von "Mustern" z.B. in Heatmaps zum Aufkommen verschiedener Log-Ereignisse im Zeitverlauf, die der ersten visuellen Inspektion dienen, haben wir saisonal wiederkehrende Ereignisse auch mittels unten beschriebener Verfahren detektiert: Hiermit konnten wir Ereignisse herausstellen, für die ein saisonales Auftreten auf Basis des Modells festgestellt wurde und solche, für die das nicht der Fall war.

Um Saisonalität in den Logs zu ermitteln, wird für einzelne Log-Typen bzw. für einzelne Ereignisse die Häufigkeit über die Zeit aufgezeichnet. Für jede dieser Häufigkeitsverteilungen wird eine Fourier-Analyse ausgeführt. Mit der Fourier-Analyse werden die Frequenzen eines in der Zeit gemessenen Signals ermittelt. Nur dann, wenn im Frequenzspektrum ein signifikantes, über das Rauschen hinausgehendes Signal zu finden ist, wird dem Ereignistyp eine Saisonalität zugeschrieben. Diese kann nun über die Zeit verfolgt werden. Wenn z.B. wegen einer Störung ein (erwartetes) Ereignis ausfällt, kann das als Frequenzstörung beobachtet werden. So kann ein Monitoring erwarteter regelmäßiger Ereignisse implementiert werden. Umgekehrt kann eine nicht erwartete Saisonalität von Ereignissen detektiert werden.

Zukunftssichere AIOps-Lösungen für den Finanzsektor: Maßgeschneiderte Effizienz und Sicherheit mit 7P Mobility

In der Dynamik der Finanzdienstleistungsbranche, in der Effizienz und Sicherheit nicht nur wünschenswert, sondern unabdingbar sind, zeichnet sich 7P Mobility durch maßgeschneiderte AIOps-Lösungen aus, die speziell auf die einzigartigen Bedürfnisse und Herausforderungen dieser Branche zugeschnitten sind. Unsere langjährige Erfahrung im Betrieb und Monitoring komplexer IT-Landschaften ermöglicht es uns, nicht nur präzise auf Ihre spezifischen Anforderungen einzugehen, sondern auch proaktiv Lösungen zu entwickeln, die den Kern Ihrer Herausforderungen adressieren.

Unser Ansatz unterscheidet sich deutlich von dem anderer Anbieter, da wir eine AIOps-Lösung anbieten, die selbst in den sicherheitssensibelsten Umgebungen ohne Internetzugang nahtlos funktioniert. Dies unterstreicht unser Engagement für Ihre Sicherheitsbedürfnisse und betrieblichen Anforderungen. Darüber hinaus setzen wir für die Datenstromverarbeitung auf bewährte und stabile Open-Source-Komponenten wie Apache Kafka. Dieser strategische Einsatz spart nicht nur erhebliche Lizenzkosten, sondern befreit Sie auch von den Einschränkungen proprietärer Software und stellt Flexibilität und Transparenz in den Vordergrund. Die Unterstützung durch eine große Open-Source-Community stellt zudem sicher, dass Sie auch unabhängig von unserem direkten Betrieb auf einen zuverlässigen Support zurückgreifen können.