Für eine digitale Zukunft

Diese Fallstudie untersucht anhand verschiedener Anwendungsszenarien, wie eine AIOps-Lösung dazu beitragen kann, branchenspezifische Herausforderungen im Umfeld von Banken und Versicherungen zu bewältigen und die Schwächen bestehender klassischer Monitoring-Systeme zu kompensieren.

Besondere Herausforderungen

  • Hochreguliertes Umfeld: Strenge Vorschriften und Richtlinien, wie beispielsweise durch MaRisk, BAIT und BaFin vorgegeben, müssen befolgt werden: AIOps kann durch Predictive Analytics dazu beitragen, Risiken und compliance-relevante Probleme und meldepflichtige Ereignisse frühzeitig zu erkennen.
  • Zero-Trust-Umgebung: Nicht zuletzt durch das umfassende Logging sicherheitsrelevanter Aktivitäten werden große Datenvolumina generiert, die nur unter Einbezug von ML-Verfahren sinnvoll ausgewertet werden können.
  • Offline On-Premise: Kritische Systeme und Daten werden häufig im eigenen Rechenzentrum vorgehalten, AIOps-Lösungen müssen oftmals ohne Konnektivität zu externen Ressourcen auskommen.
  • Transparenz von Assets, Zugriffen und Datenflüssen: AIOps-Tools können Echtzeit-Einblicke in die IT-Infrastruktur bieten, indem sie Datenflüsse, Asset-Nutzung und Zugriffsmuster transparent machen und auswerten.
  • Einbindung ins IT Service Continuity Management (ITSCM): AIOps kann durch die Analyse von Ausfallmustern dazu beitragen, Ausfallzeiten zu reduzieren und die Betriebskontinuität zu verbessern.
  • Hochkomplexe, häufig mehrfach redundant ausgelegte IT-Infrastruktur: AIOps kann dabei helfen, Abhängigkeiten innerhalb der Infrastruktur zu verstehen und Störfaktoren schneller zu diagnostizieren und zu beheben.

IT-Betrieb in Banken und Versicherungen:
Einblick in eine typische Kundenumgebung 

Das folgende Ausgangsszenario beschreibt exemplarisch einen Teilbereich einer IT-Kundenumgebung, wie wir sie immer wieder im Umfeld von Banken und Versicherungen vorfinden und eine IT-Betriebseinheit, die für die Betreuung des spezifischen Bereichs zuständig ist:

  • Es sind verschiedene Datenbank-Management-Systeme (DBMS) im Einsatz, auf denen geschäftskritische Anwendungen laufen
  • Die DBMS werden auf einer redundant ausgelegten, virtualisierten Serverlandschaft betrieben, wobei für die Datenbank-Systeme wiederum ein Hochverfügbarkeits-Setting etabliert ist  
  • Die Datenbank-Systeme sind in ein zentral verwaltetes Backup-System eingebunden, über welches regelmäßig verschiedene Arten von Sicherungen gesteuert werden
  • Die Fachbereiche, deren Applikationen auf den Datenbanksystemen laufen, stellen bei Störungen des Applikationsbetriebs oder Performanz-Problemen über ein Ticketsystem entsprechende Anfragen an den IT-Betrieb
  • Der IT-Betrieb, der die DBMS betreut, stellt wiederum Tickets an weitere Betriebseinheiten, sofern eine diagnostizierte Störung außerhalb des eigenen Scopes liegt
  • Es gibt mindestens ein klassisches Monitoring-System, das auf Basis fest definierter Schwellwerte verschiedene Signale der Hosts (CPU-Auslastung, Memory etc.), der Datenbanken sowie des zugrunde liegenden Filesystems überwacht. Der IT-Betrieb prüft den Status der Systeme über das Monitoring-Tool, erhält aber auch entsprechende Benachrichtigungen aus dem Monitoring-System, sofern Schwellwerte überschritten wurden. Des Weiteren können bestimmte Fehlerkategorien oder vorab definierte Text-Messages aus den textbasierten Fehler-Logs der Datenbanken überwacht werden
  • Auf Basis der Monitoring-Meldungen oder der Anfragen aus dem Applikationsbereich prüft der IT-Betrieb u.a. verschiedene zeitreihenbasierte Log-Texte und versucht, entsprechende Ursachen für Probleme oder Störungen zu ermitteln und diese anschließend zu beseitigen

Die folgenden Fallbeispiele illustrieren nur eine Teilmenge der durch uns für einen Kunden implementierten AIOps-Lösung, spiegeln aber wider, was aus unserer eigenen Praxiserfahrung beim Betrieb von IT-Systemen bei verschiedenen Kunden immer wieder als relevant erachtet wird. Dabei werden sowohl fachliche Herausforderungen aus Sicht des IT-Betriebs beschrieben als auch ein Einblick in die technischen Herausforderungen bei der Umsetzung der AIOps-Lösung gegeben.

Wie könnte eine AIOps-Architektur aussehen?


Hier sind beispielhaft einige (etablierte) Open-Source-Komponenten beschrieben, die zur Konzeption einer Datenpipeline verwendet werden können:

 

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.

Welche Erkenntnisse konnten wir daraus ableiten?

 

Die folgenden Darstellungen aus unserem Rare Logs Detection Dashboard zeigen, dass nicht nur regulär stattfindende, aber relativ seltene Ereignisse wie Patches oder Wartungsfenster in den Logdaten als Anomalie erkannt werden, sondern auch selten auftretende Systemfehler – hier in Form eines Stack Dumps, bei dem vermeintlich "kryptische Zeichenfolgen" geloggt werden.

 

Die Intensität des Ausschlags ist hierbei ein (individuell definiertes) Maß für die "Seltenheit" der jeweiligen Ereignisse für das Zeitfenster. Dieses Ereignis wurde über das klassische Monitoring-System nicht erfasst, so dass sich nun erst über einen Anomalieerkennungs-Alert für den IT-Betrieb die Gelegenheit bot, die Ursache für den Systemfehler genauer zu untersuchen.

 

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.

Welche Erkenntnisse konnten wir daraus ableiten?

Im Rahmen unserer Auswertung war für den Kunden u.a. relevant, ob das verwendete Datenbank-Backupverfahren Auswirkungen auf die Systemstabilität hat. Bisher wurde ein Zusammenhang nur vermutet, da gemäß Erfahrungswissen der Experten das Monitoringsystem in der Vergangenheit häufig zeitgleich entsprechende Fehlermeldungen lieferte.

Wir konnten feststellen, dass eine sehr hohe Korrelation zwischen den täglich stattfindenden Datenbank Full Backups und I/O-Fehlern auf den betroffenen Datenbanken besteht – dies galt jedoch nicht für die stündlich laufenden Log Backups. Es konnten allerdings keine weiteren, damit zusammenhängenden Performance-Probleme oder gar Systemausfälle nachgewiesen werden.

 

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.  

Welche Erkenntnisse konnten wir daraus ableiten?

Aus Sicht des IT-Betriebs war u.a. die Frage relevant, welche anderen Ereignisse normalerweise im Zusammenhang mit einem bestimmten Ereignis-Typ (z.B. I/O-Fehler) auftreten bzw. in welcher Reihenfolge das der Fall ist.

Bei der Untersuchung von häufigen Sequenzen bestätigte sich noch mal das Bild, das wir auch bei der Untersuchung von Korrelationen erhalten haben. In Bezug auf I/O-Meldungen beispielsweise sehen wir eine spezifische Signatur von Fehlerabfolgen, die für das Kundensystem typisch sind. Die Erkenntnisse wurden an das Backup-Team weiter geleitet zur Prüfung, ob eine Umstellung auf ein anderes Verfahren oder eine Umplanung der Backups möglich wäre, um eine Häufung von I/O-Fehlern mit potenziellem Einfluss auf die Performanz zu vermeiden. 

 

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.

Welche Erkenntnisse konnten wir daraus ableiten?

Anhand der Übersicht zu saisonal und zu irregulär auftretenden Ereignissen konnte zumindest für systemkritische Fehler kein saisonales Auftreten festgestellt werden. Auch wenn keine weiteren Logs als Quelle für zusätzliche Erkenntnisse vorliegen, wäre ein saisonales Auftreten ein Indikator für einen Zusammenhang mit ebenfalls saisonal wiederkehrenden "externen” Ereignissen wie beispielsweise ressourcenintensiven Applikationsjobs zum Monatsabschluss.

Wir sehen, wann das Ereignis erstmalig auftrat und können uns einen Überblick über die „Wiederholungsrate“ (alle X Tage) eines bestimmten Ereignisses verschaffen. Wir erkennen darüber hinaus, wann und wie häufig es Abweichungen von dem Zeitintervall gab, in dem das Ereignis „normalerweise“ auftrat. Jede Abweichung wird separat erfasst und es kann ein Alerting aktiviert werden. 

Vorteile der AIOps-Lösung von 7P

  • Transparenz über häufige Fehlerquellen: Mögliche Schwachstellen erkennen
  • Noise Reduction: schnell gewöhnliches von ungewöhnlichem Systemverhalten unterscheiden
  • Systemverhalten via Mustererkennung besser verstehen: Transparenz über (regelbasierte) Ereignisse
  • Hinweise auf (domänenübergreifende) Ursachenketten erhalten (z.B. multivariate Zusammenhänge zwischen verschiedenen Ereignissen aus unterschiedlichen Datenquellen)
  • Anomalie- und Mustererkennung ermöglichen eine bedarfsgerechte und effektive Planung von Kapazitäten
  • Zeitersparnis beim Monitoring und der Fehlersuche: Root Causes (schneller) entdecken
  • Reaktion auf reales Systemverhalten statt auf fixe Monitoring-Schwellwerte
  • Basis für landschaftsübergreifendes Frühwarnsystem
  • Erleichterte Bewertung und Priorisierung von Fehlern
  • Ergänzung von "Expertenwissen": Technisch hochversierte Experten sind zum einen teuer und zum anderen angesichts des zunehmenden Fachkräftemangels schwer zu finden. Mit Hilfe der AIOps-Lösung können auch weniger versierte "Einsteiger" in die Lage versetzt werden, schnell Zusammenhänge zu erfassen.

 

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.

7P – Ihr zuverlässiger IT-Dienstleister

Wir von 7P Mobility wissen, dass Ihre IT-Infrastruktur das Rückgrat Ihres Unternehmens ist. Deshalb sind unsere Lösungen so konzipiert, dass sie nicht nur Ihre aktuellen Anforderungen erfüllen, sondern auch zukunftssichere Systeme schaffen, die mit den sich wandelnden Anforderungen des Finanzsektors Schritt halten können. Lassen Sie uns gemeinsam dafür sorgen, dass Ihr IT-Betrieb nicht nur reibungslos läuft, sondern auch strategisch so positioniert ist, dass er den langfristigen Erfolg Ihres Unternehmens unterstützt.

Mit diesen Kunden arbeiten wir: 

Haben Sie Fragen zum Einsatz von AIOps-Lösungen?
Sprechen Sie uns an.

MEHR ERFAHREN

Weitere Themen für Sie