KI im IT-Service-Geschäft – Technische Vorgehensweise

Datenanalyse & -operationalisierung

Bei der ersten Betrachtung von Daten steht man wie Moses in der Wüste und fragt sich: „Wo soll es hingehen?“ und „Wie erreiche ich mein Ziel?“. Und selbst wenn das geklärt ist, steht man vor der Herausforderung, seine prototypische Analyse zuverlässig und kostengünstig in den Produktivbetrieb zu überführen.  

Die Exploration der Loginformationen zeigte uns einige interessante Ansatzpunkte auf. Der unserer Meinung nach interessanteste Use Case: eine KI-gestützte Mustererkennung, um die große Menge an täglichen Logeinträgen intelligent zu clustern und zu klassifizieren. Damit wäre es möglich, wiederkehrende Fehlercluster zu identifizieren und die Ursachen für mögliche Systemausfälle zu beheben. Darum geht es im ersten Abschnitt über die Analyse der Logfiles.  

Im zweiten Abschnitt dieses Artikels geht es darum, das Verfahren in einen regelmäßig laufenden Prozess in der Cloud zu überführen und die Ergebnisse dem Nutzer zur Verfügung zu stellen.

Analyse der Logfiles

Wir haben die Logfiles des Applikationsservers aus einem Monat betrachtet. Pro Tag fallen dabei durchschnittlich etwa 180.000 Einträge an, die in einem standardisierten Format vorliegen. Dadurch lassen sich alle Einträge aus den täglichen Logfiles leicht in einem gemeinsamen, tabellenförmigen Datensatz sammeln, um sie systematisch zu analysieren. Neben dem Zeitstempel liegen je Logeintrag diverse Informationen vor, z. B. die Art der Meldung, die meldende Komponente oder die ID des ausführenden Threads. Aufgrund der guten Datenqualität war eine weitere Vorverarbeitung nicht notwendig. Es folgte eine explorative Analyse, um ein besseres Verständnis der Daten zu erlangen. Dabei wurden insbesondere Häufigkeitsverteilungen und Zusammenhänge zwischen den Merkmalen untersucht. 

Interessant waren für uns Logeinträge, die aus Fehlermeldungen resultieren, weil hier ggf. ein Eingreifen erforderlich ist, um den Betrieb der Applikation sicher zu stellen. Diese Meldungen machen etwa 24% aller Logeinträge aus. Bei der Analyse dieser Daten fiel uns auf, dass es initiale Fehlermeldungen gibt, die meistens eine Kaskade weiterer Fehlermeldungen nach sich ziehen. Abbildung 1 zeigt das abgeleitete Clustermodell für die Fehlermeldungen, das durch statische Untersuchungen unterstützt wird.

Mit Hilfe des DBSCAN Cluster-Algorithmus konnten wir diese Kaskaden isolieren und so aus über einer Million Fehlereignissen etwa 50.000 Fehlercluster bilden, d. h. eine Vereinfachung der zu betrachtenden Datenmenge um den Faktor 20!  

Ein wichtiger Schritt in der Vorverarbeitung ist die geeignete Selektion der Ereignisse: wendet man den Cluster-Algorithmus auf alle Fehlermeldungen an, müssen über 900 Milliarden Kombinationen aus je zwei Fehlermeldungen betrachtet werden, um zusammengehörige Ereignisse zu identifizieren – zu viele für die Speicher- und Rechenkapazität verfügbarer Computer.  

Eine weitergehende Analyse zeigte, dass das Clustering gut funktioniert hat und die 50.000 Fehler-Cluster sich in nur 9 unterschiedliche Fehlerkategorien aufteilen lassen.  

Zusammenfassend konnten wir durch die Analyse von über einer Million Fehlerereignissen ein geeignetes Clustering anwenden und so eine Handvoll wiederkehrende Fehlerkategorien identifizieren, die beurteilt und ggf. behandelt werden können.

Operationalisierung der Analyse

Nachdem wir eine prototypische Analyse entwickelt hatten, war unser nächster Schritt, einen Analytics-Service zu implementieren, dem man Logdateien zusendet und der wenig später die Ergebnisse bereitstellt.  

Wir haben uns für eine Cloud-Lösung mit Microsoft Azure entschieden. Die Vorteile liegen auf der Hand: hohe Verfügbarkeit, geringe Betriebskosten, schnelle Implementation der erarbeiteten Lösung und flexible Anpassungsmöglichkeiten. Über “Azure Machine Learning” wurden Recheninstanzen bereitgestellt und eine Pipeline aus Arbeitsschritten für die Datenextraktion und das Clustering aufgebaut. Der bereits entwickelte Code aus der Logfileanalyse konnte dabei fast 1:1 übernommen werden. Die Aufwände, um die Pipeline zu konfigurieren und zu testen hielten sich somit im überschaubaren Rahmen.  

Um den Analytics-Service zu nutzen, reicht es, die gezippten Logfiles via SFTP oder REST-Schnittstelle an eine vorgegebene URL zu schicken. Die Daten werden dabei in einem Azure Storage Verzeichnis gespeichert, der von der Pipeline beobachtet wird. Das Hochladen neuer Daten löst die Datenverarbeitung aus, welche die gewünschten Ergebnisse berechnet und in einer Zip-Datei zusammenfasst. Diese kann einige Minuten später von einer anderen URL wieder via SFTP oder REST-Schnittstelle abgeholt werden. Die Nutzung geheimer Tokens als Parameter der URL erlaubt die individuelle Zugriffssteuerung auf den Analytics-Service, der in Abbildung 2 schematisch dargestellt ist.

Ausblick: Nutzen für den DevOps-Engineer – die Ergebnisanzeige

Wie im Anwendungsfall oben beschrieben, soll der erhebliche manuelle Aufwand für Datenanalyse und Bewertung reduziert werden. Das heißt, die Ergebnisse aus dem dargestellten technischen Vorgehen müssen für den Anwender nutzbringend zusammengefasst und dargestellt werden. Dabei interessieren unseres Erachtens vor allem zwei Aspekte:  

1. Sind die KI-Ergebnisse brauchbar und  
2. Welche Maßnahmen zur Problembehebung müssen initiiert werden?