© sebastien decoret, 123RF

Künstliche Intelligenz und maschinelles Lernen sind in der IT besonders im Bereich der Systemüberwachung auf dem Vormarsch. Teilautonome Monitoring-Systeme oder zumindest intelligente Alarme haben das Potenzial, die Administratoren und den Service Desk deutlich zu entlasten.

Künstliche Intelligenz (KI), Machine Learning (ML) und Deep Learning (DL) sind heute als Schlagwörter in aller Munde, häufig – zu Unrecht – als Synonyme. Als künstliche Intelligenz bezeichnet man die Fähigkeit einer Maschine, Entscheidungen zu treffen, die denen ähneln, die Menschen fällen. Zum Beispiel könnte eine Software entscheiden, einen Alarm auszulösen, den auch ein Mensch ausgelöst hätte. Hier handelt es sich um das Simulieren intelligenten Verhaltens durch mehr oder weniger komplexe Algorithmen.

Als Machine Learning klassifiziert man hingegen Methoden, Vorgehensweisen und Algorithmen, die der Maschine bei der Entscheidungsfindung helfen. Machine Learning fungiert damit quasi als die Mathematik, die der KI erst die Fähigkeit gibt, aus Erfahrung zu lernen. Aus dieser Perspektive liefert Machine Learning lediglich die Grundlage für eine Entscheidung.

Anschaulich wird das an einem Beispiel: Das Lernergebnis sei ein prozentualer Wert, der die aktuellen Daten zu 90 Prozent einem bestimmten Typ zuordnet. Ob die Maschine dann diesen Wert zusammen mit anderen als Auslöser für einen Alarm betrachtet, hat aus mathematischer Sicht nichts mehr mit dem Teil des Algorithmus zu tun, der den Wert errechnet.

Das maschinelle Lernen funktioniert im Allgemeinen umso verlässlicher, je mehr Daten zur Verfügung stehen. Diese Methode lässt sich auch als Filter verstehen. Daten liegen den meisten Unternehmen heute reichlich vor – meist sogar so viele, dass eine manuelle Auswertung undenkbar ist. Als Abhilfe ließen sich Machine-Learning-Algorithmen und weitere Methoden vorschalten, um die vorhandenen Daten zu filtern und so auf ein Niveau zu bringen, dass sich wieder interpretieren lässt. Der entsprechend aufbereitete Datenbestand erlaubt dann die Definition von Regeln für ein intelligentes Verhalten einer Software.

Beim traditionellen Machine Learning entscheidet der Anwender bereits während der Implementierung, mit welchem Algorithmus es welche Information auf welche Weise zu verarbeiten beziehungsweise zu filtern gilt. Beim Deep Learning hingegen bestimmt ein sogenanntes neuronales Netz, welche Information es in welcher Gewichtung weitergibt. Deep-Learning-Methoden erfordern einen hohen Rechenaufwand. Zwar existiert die zugrunde liegende Mathematik schon lange, doch erst die gesteigerte Rechenleistung hat Deep Learning im vergangenen Jahrzehnt wirklich universell einsetzbar gemacht.

Unterschiedliche Methoden und Ergebnisse

Für den Umgang mit den Daten gilt: Egal, ob eine rein statistische Analysemethode – insbesondere explorative Datenanalyse (EDA) – zum Einsatz kommt oder ein Machine-Learning-Algorithmus, es lässt sich immer zwischen univariaten und multivariaten Methoden unterscheiden. Univariate Methoden arbeiten schneller, da sie meist weniger Rechenleistung erfordern. Multivariate Methoden hingegen können Zusammenhänge aufdecken, die sonst unerkannt geblieben wären. Allerdings hat die Anwendung komplexer Methoden nicht immer ein besseres Ergebnis zur Folge.

Generell kann man sich eine Machine-Learning-Methode als zweiteiligen Prozess vorstellen (Abbildung 1): Der erste Teil – das Training des Algorithmus – besteht aus einer ausführlichen Analyse der zur Verfügung stehenden Daten. Sie soll Muster aufdecken und eine mathematische Regel oder Funktion finden, die diese Art Muster erklärt. Dazu gibt es die unterschiedlichsten Methoden, wie etwa lineare, nicht lineare, logistische und dergleichen mehr. Ziel ist es, einen möglichst geringen Fehler zu erhalten, wenn man die zu analysierenden Daten mit der entsprechenden mathematischen Funktion erklärt. Die in Schritt eins erhaltene Funktion dient dann der Vorhersage weiterer Daten.

Abbildung 1: Das Zusammenspiel der Trainings- und Testmethoden beim Machine Learning.

Die folgenden Abschnitte veranschaulichen die verschiedenen Analyseformen anhand der Bewertung der Lastkurve eines Server-Prozessors (Abbildung 2). Die Auslastung bleibt dabei über den gesamten Zeitraum unter 50 Prozent, sieht man von ein paar punktuellen Lastspitzen ab.

Abbildung 2: Die Kurve der Prozessorauslastung mit regelmäßigen Spitzen.

Univariate Analyse

Die univariate Analyse untersucht immer nur eine Metrik gleichzeitig. Auf die Prozessorkurve angewandt bedeutet das: Ein traditionelles mittel- oder grenzwertbasierendes Monitoring richtet das Augenmerk insbesondere auf die höheren punktuellen Ausschläge und stuft sie je nach Konfiguration der Schwellwerte und Anzahl an Schwellwertüberschreitungen als potenziell gefährlich ein.

Des Weiteren könnte eine univariate Analyse auch herausfinden, dass die Überschreitungen in immer nahezu gleichen Zeitabständen erfolgen: Das entsprechende Event scheint also zyklisch aufzutreten. Ein Großteil der Überschreitungen lässt sich im Beispiel diesem zyklischen Typ zuschreiben, andere jedoch nicht. Es handelt sich also nicht mehr um einzelne Events, sondern um zwei Gruppen von Events. Außerdem kann man beobachten, dass der Mittelwert der Auslastung in der ersten Datenhälfte konstant bleibt, in der zweiten Hälfte jedoch linear zunimmt (Abbildung 3).

Abbildung 3: Der Mittelwert der Auslastung steigt in der zweiten Hälfte der Kurve an.

Dieser Effekt sticht zwar viel weniger ins Auge, vernachlässigen darf man ihn aber nicht: Hält der Trend an, kann er in der Zukunft zu einer immer höheren Auslastung des Servers führen. Hier kann man also einen Teilbereich der Daten dazu heranziehen, einen anderen Teilbereich vorherzusagen. Je nachdem, wie gut das gelingt, lässt sich daraus schließen, dass die Prozesse, die die Daten erzeugen, nach wie vor dieselben sind.

Anhand einer einzigen Kurve sind somit bereits mehrere Aussagen möglich, aber es ist schwierig, auf dieser Basis Entscheidungen zu treffen. Ohne weitere Daten, etwa von anderen messbaren Größen oder anderen vergleichbaren Servern, kann der Administrator die Situation höchstens auf seiner Erfahrung basierend interpretieren und dementsprechend reagieren.

Bivariate Analyse

Bei der bivariaten Analyse untersucht man stets zwei Kurven gleichzeitig. Es wäre somit möglich, mithilfe einer weiteren Kurve eine Erklärung für Effekte in den Daten zu finden. So könnte man dank der orangefarbenen Kurve aus Abbildung 4 die zyklischen Lastspitzen erklären. Denkbar wären etwa Batch-Tasks, die in konstanten Zeitintervallen anstehen und zu einer höheren Prozessorlast führen. Kombiniert mit den entsprechenden Logs, lässt sich die Aktivität als geplant und ungefährlich einstufen. Lediglich eine einzelne der verbleibenden Überschreitungen aus dem Beispiel entzieht sich dieser Erklärung und muss näher untersucht werden.

Abbildung 4: Eine bivariate Analyse der Prozessordaten: Die meisten Spitzen scheinen auf zyklische Ereignisse zurückzuführen sein.

Multivariate Analyse

Die multivariate Analyse weitet das Prinzip der bivariaten Analyse auf die gleichzeitige Interpretation beliebig vieler Kurven aus. Beginnt beispielsweise die Auslastung des Prozessors nicht nur auf einem Server zu wachsen, sondern auf mehreren gleichzeitig, ist der Effekt noch relevanter: Im Zeitalter von Cryptojacking-Attacken wollen sich die Angreifer nach Möglichkeit überhaupt nicht bemerkbar machen. Hier geht es um den Missbrauch von Ressourcen zu illegitimen Zwecken. Ein minimaler Prozentsatz an missbräuchlich genutzter Rechenleistung fällt bei einzelnen Maschinen nicht weiter auf. Erst bei einer Analyse, die auffällige Veränderungen auf mehreren Servern verknüpft beziehungsweise mehrere Metriken gemeinsam studiert, gelangen derartige Attacken schnell ans Tageslicht und lassen sich zeitnah unterbinden.

Des Weiteren lassen sich Machine-Learning-Algorithmen danach unterscheiden, wie viele Etikettierungen (Label) sie benötigen. Dies ist von besonderem Interesse, weil sich solche Etikettierungen nicht immer automatisch erzeugen lassen und sie somit einen potenziell zeitaufwendigen Teil der Analyse darstellen. Beim überwachten Lernen sind die Etikettierungen essenziell: Hier lernt der Algorithmus in der Trainingsphase, zwischen unterschiedlichen Gruppen zu unterscheiden, indem er sich auf die Label verlässt. Beim halbüberwachten Lernen liegt zumindest für einen Teil der Daten eine Etikettierung vor, beim unüberwachten Lernen hingegen sind keine Label nötig.

Insbesondere die Anomaly Detection setzt immer mehr auf Methoden ohne Überwachung, besonders, um bisher noch nie aufgetretene kritische Situationen möglichst früh zu erkennen. Die möglichen Verfahren reichen von traditionellen Algorithmen wie DBSCAN bis hin zu modernen Verfahren wie Isolation Forest. Ein Kritikpunkt an den unüberwachten Methoden: Ohne den sogenannten Ground Truth kann man Anomalien zwar sehr wohl ausfindig machen, es lässt sich aber unmöglich abschätzen, wie viele der vorhandenen Ereignisse tatsächlich gefunden wurden.

Einsatz in der Praxis

Abbildung 5 zeigt einen Fall aus der Praxis, der dem bereits vorgestellten Beispiel ähnelt: Die Prozessorauslastung (links oben) nimmt linear zu. Der jeweils unterhalb der vier Kurven als Balkendiagramm dargestellte Differenzenplot verdeutlicht und quantifiziert den Effekt, indem er den aktuellen Zustand mit dem der Vorwoche vergleicht. Mit Batch-Requests (rechts oben) lässt sich der Zuwachs hier nicht erklären. Erst die gemeinsame Analyse mit den Latenzen der Festplatten, der Version Store Size (links unten) und der Longest Running Transaction ergeben ein genaueres Bild und erklären die Prozessorauslastung.

Abbildung 5: Anstieg der Prozessorauslastung, die nicht von Batchjobs herrührt. Zusätzliche Messwerte liefern eine Erklärung.

KI lässt sich verwenden, um derartige Konstellationen aufzuspüren, ohne manuell in Dashboards danach suchen zu müssen. Ein sachkundiger Experte, der sonst viel Zeit mit der Ursachenanalyse verbringen müsste, kann dadurch unmittelbar tätig werden. Das erlaubt ihm, kritische Settings oder Zustände zu beseitigen, bevor sich gravierende Probleme entwickeln und weiträumige Auswirkungen nach sich ziehen. Darüber hinaus kann KI die Gegenmaßnahmen des Experten untersuchen, dort Muster erkennen und bei zukünftigen vergleichbaren Situationen entsprechende Gegenmaßnahmen bereits vorschlagen – oder in einigen Fällen sogar automatisch treffen.

Im Gegensatz zum traditionellen reaktiven Monitoring können KI-basierende Methoden ein Stück weit in die Zukunft sehen und den Administrator benachrichtigen, sobald die Wahrscheinlichkeit steigt, dass sich die momentane Situation in ein negatives Setting verwandelt.

Neben der traditionellen Frage – ist die aktuelle Situation kritisch (im Vergleich zu den historischen Daten)? – lassen sich somit auch Fragen mathematisch beantworten wie: Wann tritt eine kritische Situation ein, wenn alles so weiterläuft wie bisher? Was gilt es zu unternehmen, damit die Situation nicht kritisch wird? Wo früher hauptsächlich jahrelange Erfahrung von Vorteil war, kann nun eine KI errechnen, welche Metrik mit welcher Wahrscheinlichkeit zur jeweiligen Situation beiträgt.

Diese theoretischen Überlegungen lassen sich beispielsweise anhand der in Abbildung 6 gezeigten Pipeline auf das Performance-Monitoring in der Praxis übertragen (Abbildung 6). Eine Zeitreihendatenbank (etwa InfluxDB) speichert dabei Daten aus heterogenen Quellen. Der Anwender prüft jede eingehende Metrik auf Stufe I zunächst mittels univariater Analyse und vereinfacht sie mit statistischen Verfahren, um eine Navigation zu ermöglichen. Alarme optimiert er weitgehend.

Abbildung 6: Die fünf Stufen bei der Anwendung von KI im Performance-Monitoring.

Auf Stufe I gewonnene Erkenntnisse gelangen auf Stufe II, wo der Nutzer sie weiter auswertet und sowohl univariat als auch multivariat auf Server-Ebene weiter analysiert. Stufe III erkennt auf Server-Ebene Anomalien und wertet sie aus. Das hilft beim Erstellen intelligenter und dynamischer Baselines, um Störungen bestmöglich vorzubeugen.

Stufe IV wird von allen vorhergehenden Stufen direkt oder indirekt beeinflusst. Eine multivariate Analyse auf Systemebene und der gezielte Einsatz von Machine-Learning-Algorithmen zur Analyse und Prognose ermöglichen eine effiziente Ursachenanalyse. So lassen sich Ausfallzeiten minimieren. Stufe V führt schließlich alle vorher gewonnenen Erkenntnisse zusammen, um das Service-Management generell zu verbessern. Dank der aufbereiteten und statistisch zusammengefassten Daten sowie den bereits erzielten Ergebnissen lassen sich informierte Entscheidungen treffen und deren Auswirkungen nach der Implementierung zeitnah quantifizieren.

Will ein Unternehmen seine Möglichkeiten im Bereich Systemüberwachung erweitern und zum Beispiel überprüfen, ob eine bestimmte Applikation im eigenen System oder beim Kunden reibungslos läuft, kann es Standardlösungen verwenden wie bestehende vorimplementierte Algorithmen (etwa Random Forest, künstliche neuronale Netze oder Support Vector Machines). Sofern die Erfahrung im eigenen Team ausreicht, lassen sich damit bereits Ergebnisse erzielen, die ohne KI nicht denkbar wären.

Insbesondere komplexere, vielversprechende Ansätze, die sich aber noch in der aktiven Forschung befinden, lassen sich oft nicht ausreichend verallgemeinern, um sie in Standardlösungen zu implementieren. Welches zusätzliche Analysepotenzial sie für die jeweilige Anwendung bieten, können am besten Experten abschätzen. Für die Datenaufbereitung (zum Beispiel Normalisierung, Pruning, Splitting) stehen dagegen meist alle notwendigen Routinen bereit.

Bei diesem Schritt ist lediglich von Bedeutung, dass derjenige, der die Preprocessing-Pipeline erstellt, den später anzuwendenden Machine-Learning-Algorithmus so weit kennt, dass er die notwendigen Schritte in der richtigen Reihenfolge vorschalten kann. Automatisierte Verfahren erzielen hier zwar auch Ergebnisse, doch besteht das Risiko, dass Daten zeitaufwendig bearbeitet werden, ohne dass die späteren Ergebnisse aus mathematischer Sicht Sinn ergeben und einen wirklichen Mehrwert darstellen.

Fazit

Künstliche Intelligenz und maschinelles Lernen verändern fast alle Branchen, nicht zuletzt die IT. Entsprechende Ansätze und Methoden, mit denen die durch IT-Operationen produzierten Daten aufgezeichnet, analysiert und weiterverarbeitet werden, fasst man unter dem Begriff IT Operations Analytics (ITOA) zusammen. Moderne Monitoring-Systeme wie NetEye von Würth Phoenix bringen bereits heute einige Vereinfachungen und Erleichterungen für die Administratoren, teilautonome Lösungen dürften nicht mehr lange auf sich warten lassen.

Dabei muss jedoch klar sein, dass ITOA das tradierte Application Performance Management (APM) nicht ersetzen kann. Es handelt sich vielmehr um eine Ergänzung, die die Administratoren befähigt, schneller und zielgerichteter auf Probleme zu reagieren. Dabei bleibt die Erfahrung der IT-Mitarbeiter unverzichtbar. (jcb/jlu)