Wir suchen Anomalien und sagen Ausfälle mit Hilfe von Neuronalen Netzen voraus

Die industrielle Entwicklung von Softwaresystemen erfordert große Aufmerksamkeit für die Ausfallsicherheit des Endprodukts sowie eine schnelle Reaktion auf Ausfälle und Störungen, wenn diese auftreten. Monitoring hilft natürlich, auf Ausfälle und Störungen effizienter und schneller zu reagieren, reicht jedoch nicht aus. Erstens ist es sehr schwierig, eine große Anzahl von Servern im Auge zu behalten – es bedarf vieler Menschen. Zweitens muss man gut verstehen, wie die Anwendung aufgebaut ist, um ihren Zustand vorherzusagen. Folglich braucht man viele Personen, die die von uns entwickelten Systeme, ihre Kennzahlen und Besonderheiten gut verstehen. Angenommen, selbst wenn genügend Personen gefunden werden, die bereit sind, sich damit zu beschäftigen, benötigt es dennoch viel Zeit, um sie auszubilden.

Was sollen wir tun? Hier kommt uns die künstliche Intelligenz zur Hilfe. Der folgende Artikel handelt von prädiktiver Wartung (predictive maintenance). Dieser Ansatz wird zunehmend populär. Es wurden viele Artikel darüber geschrieben, auch auf Habré. Große Unternehmen nutzen diesen Ansatz umfassend, um die Funktionsfähigkeit ihrer Server zu gewährleisten. Nach Durchsicht zahlreicher Artikel beschlossen wir, diesen Ansatz auszuprobieren. Was kam dabei heraus?

Einführung

Das entwickelte Softwaresystem wird früher oder später in Betrieb genommen. Es ist dem Benutzer wichtig, dass das System ohne Ausfälle funktioniert. Wenn es doch zu einer außergewöhnlichen Situation kommt, sollte sie mit minimalen Verzögerungen behoben werden.

Um die technische Unterstützung des Softwaresystems zu vereinfachen, insbesondere wenn es viele Server gibt, werden in der Regel Überwachungsprogramme eingesetzt, die Metriken des laufenden Softwaresystems erfassen, die Diagnose seines Zustands ermöglichen und helfen zu bestimmen, was genau den Ausfall verursacht hat. Dieser Prozess wird als Monitoring des Softwaresystems bezeichnet.

Abbildung 1. Schnittstelle zur Überwachung grafana

Metriken sind verschiedene Kennzahlen eines Softwaresystems, seiner Ausführungsumgebung oder der physischen Rechenmaschine, auf der das System läuft, mit einem Zeitstempel, zu dem die Metriken erfasst wurden. In der statischen Analyse werden die Metrikdaten als Zeitreihen bezeichnet. Um den Zustand des Softwaresystems zu überwachen, werden Metriken in Form von Diagrammen dargestellt: auf der X-Achse die Zeit und auf der Y-Achse die Werte (Abbildung 1). Aus einem funktionierenden Softwaresystem können mehrere Tausend Metriken (von jedem Knoten) erfasst werden. Sie bilden den Raum der Metriken (mehrdimensionale Zeitreihen).

Da bei komplexen Softwaresystemen eine große Anzahl an Metriken erfasst wird, wird die manuelle Überwachung zu einer schwierigen Aufgabe. Um das Volumen der vom Administrator zu analysierenden Daten zu reduzieren, enthalten Überwachungstools Instrumente zur automatischen Identifizierung möglicher Probleme. Beispielsweise kann ein Trigger eingerichtet werden, der bei einer Verringerung des verfügbaren Speicherplatzes auf einen angegebenen Schwellenwert ausgelöst wird. Außerdem können Serverausfälle oder kritische Geschwindigkeitsverlangsamungen automatisch diagnostiziert werden. In der Praxis sind Überwachungstools ziemlich gut darin, bereits aufgetretene Ausfälle zu erkennen oder einfache Symptome zukünftiger Ausfälle zu identifizieren, aber insgesamt bleibt die Vorhersage möglicher Fehler für sie eine harte Nuss. Die Vorhersage durch manuelle Analyse von Metriken erfordert das Hinzuziehen qualifizierter Spezialisten. Sie ist ineffizient. Die meisten potenziellen Ausfälle könnten unbemerkt bleiben.

In letzter Zeit erfreut sich unter großen IT-Unternehmen, die Software entwickeln, das sogenannte predictive Maintenance für Softwaresysteme zunehmender Beliebtheit. Das Wesen dieses Ansatzes besteht darin, Fehler, die zur Degradierung des Systems führen, in frühen Phasen vor ihrem Ausfall mithilfe von künstlicher Intelligenz zu erkennen. Dieser Ansatz schließt eine vollständige manuelle Überwachung des Systems nicht aus. Er ist eine unterstützende Maßnahme für den Überwachungsprozess insgesamt.

Das Hauptinstrument zur Umsetzung von predictive Maintenance ist die Anomalieerkennung in Zeitreihen, da bei Auftreten einer Anomalie in den Daten die Wahrscheinlichkeit hoch ist, dass nach einer gewissen Zeit Es wird ein Fehler oder Ausfall auftreten. Eine Anomalie ist eine Abweichung der Kennzahlen eines Softwaresystems, wie z.B. die Feststellung einer Verschlechterung der Ausführungszeit einer bestimmten Anfrage oder der Rückgang der durchschnittlichen Anzahl bearbeiteter Anfragen bei konstantem Niveau der Kundensitzungen.

Die Aufgabe der Anomalieerkennung für Softwaresysteme hat ihre eigene Spezifik. Grundsätzlich benötigt jede Software ein eigenes Design oder eine Anpassung vorhandener Methoden, da die Anomalieerkennung stark von den Daten abhängt, in denen sie durchgeführt wird, und die Daten von Softwaresystemen stark variieren, je nach den Implementierungswerkzeugen bis hin zu der Computerarchitektur, unter der sie betrieben wird.

Methoden zur Anomalieerkennung bei der Ausfallvorhersage von Softwaresystemen

Zunächst sei gesagt, dass die Idee der Ausfallvorhersage inspiriert wurde durch den Artikel „Maschinelles Lernen im IT-Monitoring“. Für die Überprüfung der Wirksamkeit des Ansatzes zur automatischen Anomalieerkennung wurde das Softwaresystem „Web-Konsolidierung“ ausgewählt, das eines der Projekte der NPO „Krista“ ist. Zuvor wurde für dieses System eine manuelle Überwachung anhand der erhobenen Metriken durchgeführt. Da das System recht komplex ist, werden eine große Anzahl von Metriken erfasst: JVM-Kennzahlen (Belastung des Garbage Collectors), Kenngrößen des Betriebssystems, unter dem der Code ausgeführt wird (virtueller Speicher, % CPU-Auslastung des OS), Netzwerkkennzahlen (Netzwerkbelastung), des Servers selbst (CPU-Auslastung, Speicher), Wildfly-Metriken und eigene Metriken der Anwendung in allen kritischen Teilsystemen.

Alle Kennzahlen werden mit Hilfe von Graphite aus dem System abgerufen. Anfänglich wurde die Whisper-Datenbank als Standardlösung für Grafana verwendet, aber mit dem Wachstum der Kundenbasis konnte Graphite nicht mehr mithalten und ließ die Durchsatzkapazität des Speichersystems des Rechenzentrums erschöpfen. Daraufhin wurde beschlossen, eine effizientere Lösung zu suchen. Die Wahl fiel auf Graphite+Clickhouse, was es ermöglichte, die Belastung des Speichersystems erheblich zu reduzieren und das benötigte Speichervolumen um das Fünf- bis Sechsfache zu verringern. Im Folgenden ist das Schema des Mechanismus zur Erfassung von Metriken unter Verwendung von Graphite+Clickhouse dargestellt (Abbildung 2).

Abbildung 2. Schema zur Erhebung von Metriken

Das Schema stammt aus interner Dokumentation. Es zeigt den Datenaustausch zwischen grafana (der Benutzeroberfläche für das Monitoring, die wir nutzen) und graphite. Die Metriken von der Anwendung werden von separater Software erfasst – jmxtrans. Diese speichert sie auch in graphite.
Das System „Web-Konsolidierung“ weist eine Reihe von Besonderheiten auf, die Prognosen über Ausfälle erschweren:

1. häufig kommt es zu einem Trendwechsel. Für dieses Softwaresystem erscheinen unterschiedliche Versionen. Jede von ihnen bringt Änderungen im Softwareteil des Systems mit sich. Folglich beeinflussen die Entwickler direkt die Metriken dieses Systems und können einen Trendwechsel verursachen;
2. die Besonderheit der Implementierung sowie die Ziele, die die Kunden mit diesem System verfolgen, verursachen oft Anomalien ohne vorhergehende Degeneration;
3. der Anteil der Anomalien im Verhältnis zur Gesamtheit der Daten ist gering (< 5%);
4. es kann zu Unterbrechungen bei der Erfassung von Kennzahlen vom System kommen. In bestimmten kurzen Zeitintervallen schafft es das Überwachungssystem nicht, Metriken zu erfassen. Zum Beispiel, wenn der Server überlastet ist. Für das Training des neuronalen Netzwerks ist dies entscheidend. Es besteht die Notwendigkeit, diese Lücken synthetisch zu füllen;
5. Fälle mit Anomalien sind häufig nur für bestimmte Zahlen/Monate/Zeitpunkte relevant (Saisonalität). Dieses System hat klare Nutzungsvorgaben für seine Nutzer. Folglich sind die Metriken nur zu bestimmten Zeiten von Bedeutung. Das System kann nicht konstant genutzt werden, sondern nur in bestimmten Monaten: selektiv je nach Jahr. Es entstehen Situationen, in denen das gleiche Verhalten der Metriken in einem Fall zu einem Ausfall des Softwaresystems führen kann, in einem anderen jedoch nicht.
   Zunächst wurden die Methoden zur Erkennung von Anomalien in den Überwachungsdaten von Softwaresystemen analysiert. In Artikeln zu diesem Thema wird bei niedrigen Anteilen an Anomalien im Verhältnis zum restlichen Datensatz häufig empfohlen, neuronale Netze zu verwenden.

Die grundlegende Logik zur Auffindung von Anomalien mit Hilfe von neuronalen Netzen ist in Abbildung 3 dargestellt:

Abbildung 3. Auffindung von Anomalien mithilfe eines neuronalen Netzwerks

Das Ergebnis der Prognose oder der Wiederherstellung des aktuellen Datenstroms wird durch die Abweichung von dem berechnet, was durch das funktionierende Softwaresystem erhalten wurde. Bei einer großen Diskrepanz zwischen den erhaltenen Kennzahlen vom Softwaresystem und dem neuronalen Netzwerk lässt sich auf die Anomalie des aktuellen Datenabschnitts schließen. Es entstehen folgende Probleme bei der Verwendung neuronaler Netze:

1. Für die korrekte Arbeit im Streaming-Modus müssen die Daten zum Trainieren der neuronalen Netzwerkmodelle ausschließlich "normale" Daten enthalten;
2. Es ist erforderlich, ein aktuelles Modell zur korrekten Erkennung zu haben. Die Änderung von Trends und Saisonalitäten in den Kennzahlen kann eine große Anzahl von Fehlalarmen des Modells verursachen. Um das Modell zu aktualisieren, muss der Zeitpunkt klar definiert werden, an dem das Modell veraltet ist. Wenn das Modell zu spät oder zu früh aktualisiert wird, wird höchstwahrscheinlich eine große Anzahl von Fehlalarmen folgen.
   Auch darf die Suche nach und die Vermeidung von häufigen Fehlalarmen nicht vergessen werden. Es wird angenommen, dass diese hauptsächlich in außergewöhnlichen Situationen auftreten. Sie können jedoch auch eine Folge des Fehlers des neuronalen Netzwerks aufgrund unzureichender Ausbildung sein. Es ist notwendig, die Anzahl der Fehlalarme des Modells zu minimieren. Andernfalls werden falsche Vorhersagen viel Zeit des Administrators in Anspruch nehmen, die für die Systemüberprüfung vorgesehen ist. So wird es früher oder später dazu führen, dass der Administrator einfach auf das "paranoide" Überwachungssystem nicht mehr reagiert.

Recurrent Neural Network

Zur Erkennung von Anomalien in Zeitreihen kann man ein rekurrentes neuronales Netzwerk mit LSTM-Speicher verwenden. Das Problem ist nur, dass es nur für vorhersagbare Zeitreihen verwendet werden kann. In unserem Fall sind nicht alle Kennzahlen vorhersagbar. Der Versuch, RNN LSTM für die Zeitreihe anzuwenden, ist in Abbildung 4 dargestellt.

Abbildung 4. Beispiel der Arbeit eines rekurrenten neuronalen Netzwerks mit LSTM-Speichereinheiten

Wie aus Abbildung 4 ersichtlich, konnte RNN LSTM die Anomaliesuche in diesem Zeitabschnitt erfolgreich durchführen. Dort, wo das Ergebnis einen hohen Vorhersagefehler (mean error) aufweist, trat tatsächlich eine Anomalie in den Kennzahlen auf. Die Verwendung eines einzelnen RNN LSTM wird offensichtlich nicht ausreichen, da es nur für eine begrenzte Anzahl von Metriken anwendbar ist. Man kann dies als unterstützende Methode zur Anomaliesuche verwenden.

Autoencoder zur Vorhersage von Ausfällen

Autoencoder – im Wesentlichen ein künstliches neuronales Netzwerk. Die Eingabeschicht ist der Encoder, die Ausgabeschicht der Decoder. Der Nachteil aller neuronalen Netze dieses Typs ist, dass sie Anomalien schlecht lokalisieren. Es wurde die Architektur eines synchronen Autoencoders gewählt.

Abbildung 5. Beispiel für die Funktionsweise eines Autoencoders

Autoencoder werden auf normalen Daten trainiert und finden dann etwas Anomalisches in den in das Modell eingegebenen Daten. Genau das, was für diese Aufgabe benötigt wird. Es bleibt nur zu wählen, welcher der Autoencoder für diese spezielle Aufgabe geeignet ist. Die architektonisch einfachste Form eines Autoencoders besteht aus einem einfachen, nicht rekursiven neuronalen Netzwerk, das sehr ähnlich ist wie ein mehrschichtiger Perzeptron (multilayer perceptron, MLP), mit einer Eingabeschicht, einer Ausgabeschicht und einer oder mehreren versteckten Schichten, die diese verbinden.
Jedoch unterscheiden sich Autoencoder von MLP darin, dass der Ausgangslevel die gleiche Anzahl von Knoten hat wie der Eingang, und dass der Autoencoder nicht auf die Vorhersage eines Zielwerts Y trainiert wird, der durch den Eingang X vorgegeben ist, sondern darauf, seine eigenen X zu rekonstruieren. Daher sind Autoencoder unüberwachte Lernmodelle.

Die Aufgabe des Autoencoders besteht darin, die zeitlichen Indizes r0 … rn zu finden, die den anomalen Elementen im Eingangsvektor X entsprechen. Dieser Effekt wird durch die Suche nach dem quadratischen Fehler erreicht.

Abbildung 6. Synchroner Autoencoder

Für den Autoencoder wurde eine synchrone Architekturausgewählt. Ihre Vorteile: die Möglichkeit, den Streaming-Modus zu verwenden, und eine vergleichsweise geringere Anzahl an Parametern des neuronalen Netzwerks im Vergleich zu anderen Architekturen.

Der Mechanismus zur Minimierung von Fehlalarmen

Angesichts der verschiedenen unerwarteten Situationen und der Möglichkeit einer unzureichenden Ausbildung des neuronalen Netzwerks wurde beschlossen, einen Mechanismus zur Minimierung von Fehlalarmen für das entwickelte Anomalieerkennungsmodell zu entwickeln. Dieser Mechanismus basiert auf einer Sammlung von Mustern, die vom Administrator klassifiziert wird.

Algorithmus zur dynamischen Transformation der Zeitachse (DTW-Algorithmus, von engl. dynamic time warping) ermöglicht es, die optimale Übereinstimmung zwischen Zeitreihen zu finden. Er wurde erstmals in der Spracherkennung eingesetzt: Dabei wurde festgestellt, wie zwei Sprachsignale dasselbe gesprochene Wort darstellen. Später fand er auch in anderen Bereichen Anwendung.

Das Hauptprinzip zur Minimierung von Fehlalarmen besteht darin, eine Sammlung von Referenzen durch einen Operator zu erstellen, der verdächtige Fälle klassifiziert, die durch neuronale Netze entdeckt wurden. Anschließend erfolgt der Vergleich der klassifizierten Referenz mit dem Fall, den das System erkannt hat, und es wird eine Schlussfolgerung über die Zugehörigkeit des Falls zu einem Fehlalarm oder einem Problem getroffen. Der DTW-Algorithmus wird genau für den Vergleich zweier Zeitreihen verwendet. Das Hauptinstrument zur Minimierung bleibt jedoch die Klassifizierung. Es wird davon ausgegangen, dass das System nach der Sammlung einer großen Anzahl von Referenzfällen seltener den Operator befragen wird, da die meisten Fälle Ähnlichkeiten aufweisen.

Infolgedessen wurde auf der Grundlage der oben beschriebenen Methoden der neuronalen Netze ein experimentelles Programm zur Vorhersage von Systemausfällen der „Web-Konsolidierung“ erstellt. Ziel dieses Programms war es, basierend auf dem vorhandenen Archiv von Überwachungsdaten und Informationen über bereits aufgetretene Ausfälle die Eignung dieses Ansatzes für unsere Softwaresysteme zu bewerten. Das Schema der Programmfunktion ist unten in Abbildung 7 dargestellt.

Abbildung 7. Schema zur Vorhersage von Ausfällen basierend auf der Analyse des Metrikraums

Im Schema lassen sich zwei Hauptblöcke erkennen: die Suche nach anomal auftretenden Zeitabschnitten im Datenstrom der Überwachung (Metriken) und der Mechanismus zur Minimierung von Fehlalarmen. Hinweis: Zu experimentellen Zwecken werden die Daten über eine JDBC-Verbindung aus einer Datenbank abgerufen, in der sie in Graphite gespeichert werden.
Im Folgenden ist die Benutzeroberfläche des aus der Entwicklung des Überwachungssystems erhaltenen Ergebnisses dargestellt (Abbildung 8).

Abbildung 8. Benutzeroberfläche des experimentellen Überwachungssystems

Auf der Benutzeroberfläche wird der Anomalie-Prozentsatz der erhaltenen Metriken angezeigt. In unserem Fall wird der Empfang simuliert. Wir haben bereits alle Daten der letzten Wochen und laden sie schrittweise zur Überprüfung des Falls mit der Anomalie, die zum Ausfall führt, hoch. In der unteren Statusleiste wird der aktuelle Gesamtprozentsatz der Anomalie-Daten angezeigt, der mithilfe eines Autoencoders bestimmt wird. Für die prognostizierten Metriken wird ebenfalls ein separater Prozentsatz angezeigt, der von einem RNN LSTM berechnet wird.

Beispiel für die Erkennung einer Anomalie an den CPU-Messwerten mithilfe des RNN LSTM (Abbildung 9).

Abbildung 9. RNN LSTM-Erkennung

Ein ziemlich einfacher Fall, im Grunde ein normaler Ausreißer, der jedoch zum Ausfall des Systems führt, wurde erfolgreich mit RNN LSTM berechnet. Der Anomaliewert in diesem Zeitraum liegt zwischen 85 und 95 %, alles über 80 % (Schwelle experimentell festgelegt) wird als Anomalie angesehen.
Beispiel für die Erkennung einer Anomalie, als das System nach einem Update nicht starten konnte. Diese Situation erkennt der Autoencoder (Abbildung 10).

Abbildung 10. Beispiel für die Erkennung durch den Autoencoder

Wie aus der Abbildung zu sehen ist, blieb PermGen auf einem Niveau hängen. Der Autoencoder hielt das für merkwürdig, da er zuvor so etwas nicht gesehen hatte. Hier beträgt der Anomaliewert konstant 100 %, bis das System wieder in einen funktionsfähigen Zustand zurückkehrt. Die Anomalie wird für alle Metriken angezeigt. Wie bereits erwähnt, kann der Autoencoder Anomalien nicht lokalisieren. Der Operator ist in solchen Situationen beauftragt, diese Funktion zu erfüllen.

Fazit

Das PC-System "Web-Konsolidierung" wird nicht seit dem letzten Jahr entwickelt. Das System befindet sich in einem recht stabilen Zustand, und die Anzahl der registrierten Vorfälle ist gering. Dennoch ist es gelungen, Anomalien zu finden, die zu Ausfällen 5 bis 10 Minuten vor dem Auftreten eines Ausfalls führen. In mehreren Fällen hätte eine frühzeitige Benachrichtigung über den Ausfall helfen können, die für die Durchführung von "Reparatur"-Arbeiten festgelegte Zeit zu sparen.

Bei den Experimenten, die durchgeführt werden konnten, ist es noch zu früh für endgültige Schlussfolgerungen. Momentan sind die Ergebnisse widersprüchlich. Einerseits ist zu erkennen, dass Algorithmen auf Basis neuronaler Netze in der Lage sind, "nützliche" Anomalien zu erkennen. Andererseits gibt es einen hohen Prozentsatz an falschen Positiven, und nicht alle Anomalien, die von einem qualifizierten Spezialisten erkannt werden, lassen sich von der Neuronalen Netz erkennen. Zu den Nachteilen gehört auch, dass das neuronale Netz derzeit für ein optimales Funktionieren ein supervised Learning erfordert.

Für die weitere Entwicklung des Ausfallvorhersagesystems und die Verbesserung seines Zustands könnten mehrere Wege in Betracht gezogen werden. Dazu gehört eine detaillierte Analyse der Fälle mit Anomalien, die zu Ausfällen führen, was durch die Ergänzung einer Liste kritischer Metriken, die den Zustand des Systems stark beeinflussen, und das Weglassen unnötiger, nicht einflussreicher Metriken erreicht werden kann. Wenn wir in diese Richtung weiterarbeiten, könnten auch Versuche unternommen werden, Algorithmen speziell für unsere Fälle von Anomalien, die zu Ausfällen führen, zu spezialisieren. Es gibt auch einen anderen Weg: die Verbesserung der Architektur neuronaler Netze und damit eine Erhöhung der Erkennungsgenauigkeit bei gleichzeitig verkürzter Lernzeit.

Ich danke meinen Kollegen, die mir bei der Erstellung und Aktualisierung dieses Artikels geholfen haben: Wiktor Werbiczkij und Sergej Finoginow.

Quelle: habr.com