Mithilfe neuronaler Netze suchen wir nach Anomalien und prognostizieren Ausfälle

Die industrielle Entwicklung von Softwaresystemen erfordert große Aufmerksamkeit für die Fehlertoleranz des Endprodukts sowie eine schnelle Reaktion auf Ausfälle und Ausfälle, falls diese auftreten. Die Überwachung hilft natürlich, effizienter und schneller auf Ausfälle und Ausfälle zu reagieren, reicht aber nicht aus. Erstens ist es sehr schwierig, den Überblick über eine große Anzahl von Servern zu behalten – es werden viele Leute benötigt. Zweitens müssen Sie die Funktionsweise der Anwendung gut verstehen, um ihren Zustand vorhersagen zu können. Deshalb brauchen wir viele Leute, die ein gutes Verständnis für die von uns entwickelten Systeme, ihre Leistung und Funktionen haben. Nehmen wir an, selbst wenn Sie genügend Leute finden, die dazu bereit sind, dauert es immer noch viel Zeit, sie zu schulen.

Was zu tun? Hier kommt uns künstliche Intelligenz zu Hilfe. Der Artikel wird darüber sprechen vorausschauende Wartung (vorausschauende Wartung). Dieser Ansatz erfreut sich immer größerer Beliebtheit. Es wurde eine große Anzahl von Artikeln geschrieben, auch über Habré. Große Unternehmen nutzen diesen Ansatz in vollem Umfang, um die Leistung ihrer Server aufrechtzuerhalten. Nachdem wir eine große Anzahl von Artikeln studiert hatten, entschieden wir uns, diesen Ansatz auszuprobieren. Was ist dabei herausgekommen?

Einführung

Das entwickelte Softwaresystem geht früher oder später in Betrieb. Für den Anwender ist es wichtig, dass das System störungsfrei arbeitet. Wenn ein Notfall eintritt, sollte dieser mit minimaler Verzögerung behoben werden.

Um den technischen Support eines Softwaresystems zu vereinfachen, insbesondere wenn viele Server vorhanden sind, werden in der Regel Überwachungsprogramme eingesetzt, die Metriken aus einem laufenden Softwaresystem übernehmen, eine Diagnose seines Zustands ermöglichen und dabei helfen, die genaue Ursache des Fehlers zu ermitteln. Dieser Vorgang wird als Softwaresystemüberwachung bezeichnet.

Abbildung 1. Grafana-Überwachungsschnittstelle

Metriken sind verschiedene Indikatoren eines Softwaresystems, seiner Ausführungsumgebung oder des physischen Computers, auf dem das System läuft, mit einem Zeitstempel des Zeitpunkts, zu dem die Metriken empfangen wurden. In der statischen Analyse werden diese Metriken als Zeitreihen bezeichnet. Um den Zustand des Softwaresystems zu überwachen, werden Metriken in Form von Diagrammen angezeigt: Die Zeit ist auf der X-Achse und die Werte sind auf der Y-Achse (Abbildung 1). Aus einem laufenden Softwaresystem (von jedem Knoten) können mehrere tausend Metriken entnommen werden. Sie bilden einen Raum von Metriken (mehrdimensionale Zeitreihen).

Da für komplexe Softwaresysteme eine Vielzahl von Metriken erfasst werden, wird die manuelle Überwachung zu einer schwierigen Aufgabe. Um die vom Administrator analysierte Datenmenge zu reduzieren, enthalten Überwachungstools Tools zur automatischen Erkennung möglicher Probleme. Sie können beispielsweise einen Auslöser konfigurieren, der ausgelöst wird, wenn der freie Speicherplatz unter einen bestimmten Schwellenwert fällt. Sie können auch automatisch eine Serverabschaltung oder eine kritische Verlangsamung der Servicegeschwindigkeit diagnostizieren. In der Praxis leisten Überwachungstools gute Dienste bei der Erkennung bereits aufgetretener Ausfälle oder bei der Identifizierung einfacher Symptome künftiger Ausfälle, doch im Allgemeinen bleibt die Vorhersage eines möglichen Ausfalls für sie eine schwierige Aufgabe. Vorhersagen durch manuelle Analyse von Metriken erfordern die Einbeziehung qualifizierter Spezialisten. Es handelt sich um eine geringe Produktivität. Die meisten potenziellen Fehler bleiben möglicherweise unbemerkt.

In letzter Zeit erfreut sich die sogenannte vorausschauende Wartung von Softwaresystemen bei großen IT-Softwareentwicklungsunternehmen immer größerer Beliebtheit. Der Kern dieses Ansatzes besteht darin, mithilfe künstlicher Intelligenz Probleme zu finden, die zu einer Systemverschlechterung im Frühstadium führen, bevor es zu einem Ausfall kommt. Dieser Ansatz schließt eine manuelle Überwachung des Systems nicht vollständig aus. Es unterstützt den gesamten Überwachungsprozess.

Das Hauptinstrument zur Umsetzung von Predictive Maintenance ist seitdem die Suche nach Anomalien in Zeitreihen wenn eine Anomalie auftritt In den Daten besteht eine hohe Wahrscheinlichkeit, dass nach einiger Zeit Es wird einen Fehler oder Misserfolg geben. Eine Anomalie ist eine bestimmte Abweichung in der Leistung eines Softwaresystems, z. B. die Feststellung einer Verschlechterung der Ausführungsgeschwindigkeit eines Anforderungstyps oder einer Verringerung der durchschnittlichen Anzahl bearbeiteter Anforderungen bei einem konstanten Niveau von Clientsitzungen.

Die Aufgabe der Suche nach Anomalien für Softwaresysteme hat ihre eigenen Besonderheiten. Theoretisch ist es für jedes Softwaresystem notwendig, bestehende Methoden zu entwickeln oder zu verfeinern, da die Suche nach Anomalien stark von den Daten abhängt, in denen sie durchgeführt wird, und die Daten von Softwaresystemen je nach den Tools zur Implementierung des Systems stark variieren , bis hin zu dem Computer, auf dem es ausgeführt wird.

Methoden zur Suche nach Anomalien bei der Vorhersage von Ausfällen von Softwaresystemen

Zunächst ist anzumerken, dass die Idee, Fehler vorherzusagen, durch den Artikel inspiriert wurde „Maschinelles Lernen im IT-Monitoring“. Um die Wirksamkeit des Ansatzes mit automatischer Suche nach Anomalien zu testen, wurde das Softwaresystem Web-Consolidation ausgewählt, eines der Projekte der Firma NPO Krista. Bisher wurde hierfür eine manuelle Überwachung auf Basis der empfangenen Metriken durchgeführt. Da das System recht komplex ist, werden dafür zahlreiche Metriken herangezogen: JVM-Indikatoren (Garbage Collector-Auslastung), Indikatoren des Betriebssystems, unter dem der Code ausgeführt wird (virtueller Speicher, prozentuale CPU-Auslastung des Betriebssystems), Netzwerkindikatoren (Netzwerkauslastung). ), der Server selbst (CPU-Auslastung, Speicher), Wildfly-Metriken und die anwendungseigenen Metriken für alle kritischen Subsysteme.

Alle Messwerte werden mithilfe von Graphit aus dem System entnommen. Ursprünglich wurde die Whisper-Datenbank als Standardlösung für Grafana verwendet, aber als der Kundenstamm wuchs, konnte Graphite nicht mehr damit umgehen, da die Kapazität des DC-Disk-Subsystems erschöpft war. Danach wurde beschlossen, eine effektivere Lösung zu finden. Die Wahl fiel positiv aus Graphit+Clickhouse, was es ermöglichte, die Belastung des Festplattensubsystems um eine Größenordnung zu reduzieren und den belegten Speicherplatz um das Fünf- bis Sechsfache zu reduzieren. Unten finden Sie ein Diagramm des Mechanismus zum Sammeln von Metriken mithilfe von Graphite+Clickhouse (Abbildung 2).

Abbildung 2. Schema zum Sammeln von Metriken

Das Diagramm ist einer internen Dokumentation entnommen. Es zeigt die Kommunikation zwischen Grafana (der von uns verwendeten Überwachungsoberfläche) und Graphite. Das Entfernen von Metriken aus einer Anwendung erfolgt durch separate Software – jmxtrans. Er setzt sie in Graphit ein.
Das Web Consolidation-System verfügt über eine Reihe von Funktionen, die Probleme bei der Vorhersage von Fehlern verursachen:

1. Der Trend ändert sich oft. Für dieses Softwaresystem stehen verschiedene Versionen zur Verfügung. Jeder von ihnen bringt Änderungen am Softwareteil des Systems mit sich. Dementsprechend haben Entwickler auf diese Weise direkten Einfluss auf die Metriken eines bestimmten Systems und können eine Trendwende herbeiführen;
2. Die Implementierungsfunktion sowie die Zwecke, für die Kunden dieses System verwenden, verursachen häufig Anomalien ohne vorherige Verschlechterung.
3. der Prozentsatz der Anomalien im Verhältnis zum gesamten Datensatz ist gering (< 5 %);
4. Es kann zu Lücken beim Empfang von Indikatoren aus dem System kommen. In einigen kurzen Zeiträumen kann das Überwachungssystem keine Messwerte erhalten. Zum Beispiel, wenn der Server überlastet ist. Dies ist entscheidend für das Training eines neuronalen Netzwerks. Es besteht die Notwendigkeit, die Lücken synthetisch zu schließen;
5. Fälle mit Anomalien sind häufig nur für ein bestimmtes Datum/einen bestimmten Monat/eine bestimmte Uhrzeit relevant (Saisonalität). Für die Nutzung dieses Systems durch die Nutzer gelten klare Regelungen. Dementsprechend sind die Kennzahlen nur für einen bestimmten Zeitpunkt relevant. Das System kann nicht dauerhaft, sondern nur in einigen Monaten genutzt werden: punktuell je nach Jahr. Es gibt Situationen, in denen das gleiche Verhalten von Metriken in einem Fall zu einem Ausfall des Softwaresystems führen kann, in einem anderen jedoch nicht.
   Zunächst wurden Methoden zur Erkennung von Anomalien in Überwachungsdaten von Softwaresystemen analysiert. In Artikeln zu diesem Thema wird am häufigsten die Verwendung neuronaler Netze vorgeschlagen, wenn der Prozentsatz der Anomalien im Vergleich zum Rest des Datensatzes gering ist.

Die grundlegende Logik für die Suche nach Anomalien mithilfe neuronaler Netzwerkdaten ist in Abbildung 3 dargestellt:

Abbildung 3. Suche nach Anomalien mithilfe eines neuronalen Netzwerks

Basierend auf dem Ergebnis der Prognose oder Wiederherstellung des Fensters des aktuellen Metrikflusses wird die Abweichung von der vom laufenden Softwaresystem erhaltenen Abweichung berechnet. Wenn es einen großen Unterschied zwischen den vom Softwaresystem und dem neuronalen Netzwerk erhaltenen Metriken gibt, können wir daraus schließen, dass das aktuelle Datensegment anomal ist. Für den Einsatz neuronaler Netze ergeben sich folgende Problemreihen:

1. Um im Streaming-Modus ordnungsgemäß zu funktionieren, dürfen die Daten zum Training neuronaler Netzwerkmodelle nur „normale“ Daten enthalten.
2. Für eine korrekte Erkennung ist ein aktuelles Modell erforderlich. Sich ändernde Trends und Saisonalität der Metriken können zu einer großen Anzahl falsch positiver Ergebnisse im Modell führen. Um es zu aktualisieren, ist es notwendig, den Zeitpunkt, zu dem das Modell veraltet ist, eindeutig zu bestimmen. Wenn Sie das Modell später oder früher aktualisieren, wird es höchstwahrscheinlich zu einer großen Anzahl falsch positiver Ergebnisse kommen.
   Wir dürfen auch nicht vergessen, nach Fehlalarmen zu suchen und deren häufiges Auftreten zu verhindern. Es wird davon ausgegangen, dass sie am häufigsten in Notsituationen auftreten. Sie können jedoch auch eine Folge eines neuronalen Netzwerkfehlers aufgrund unzureichenden Trainings sein. Es ist notwendig, die Anzahl falsch positiver Ergebnisse des Modells zu minimieren. Andernfalls wird durch falsche Vorhersagen viel Zeit des Administrators verschwendet, der für die Überprüfung des Systems vorgesehen ist. Früher oder später wird der Administrator einfach nicht mehr auf das „paranoide“ Überwachungssystem reagieren.

Wiederkehrendes neuronales Netzwerk

Um Anomalien in Zeitreihen zu erkennen, können Sie verwenden wiederkehrendes neuronales Netzwerk mit LSTM-Speicher. Das einzige Problem besteht darin, dass es nur für prognostizierte Zeitreihen verwendet werden kann. In unserem Fall sind nicht alle Kennzahlen vorhersehbar. Ein Versuch, RNN LSTM auf eine Zeitreihe anzuwenden, ist in Abbildung 4 dargestellt.

Abbildung 4. Beispiel eines rekurrenten neuronalen Netzwerks mit LSTM-Speicherzellen

Wie aus Abbildung 4 ersichtlich ist, konnte RNN LSTM die Suche nach Anomalien in diesem Zeitraum bewältigen. Weist das Ergebnis einen hohen Vorhersagefehler (mittlerer Fehler) auf, liegt tatsächlich eine Anomalie bei den Indikatoren vor. Die Verwendung eines einzelnen RNN LSTM wird eindeutig nicht ausreichen, da es auf eine kleine Anzahl von Metriken anwendbar ist. Kann als Hilfsmethode zur Suche nach Anomalien verwendet werden.

Autoencoder zur Fehlervorhersage

Autoencoder – im Wesentlichen ein künstliches neuronales Netzwerk. Die Eingabeschicht ist der Encoder, die Ausgabeschicht ist der Decoder. Der Nachteil aller neuronalen Netze dieser Art besteht darin, dass sie Anomalien nicht gut lokalisieren können. Es wurde eine synchrone Autoencoder-Architektur gewählt.

Abbildung 5. Beispiel für den Autoencoder-Betrieb

Autoencoder werden mit normalen Daten trainiert und finden dann etwas Anomales in den dem Modell zugeführten Daten. Genau das, was Sie für diese Aufgabe brauchen. Jetzt muss nur noch ausgewählt werden, welcher Autoencoder für diese Aufgabe geeignet ist. Die architektonisch einfachste Form eines Autoencoders ist ein vorwärts gerichtetes, nicht rückkehrendes neuronales Netzwerk, das sehr ähnlich ist mehrschichtiges Perzeptron (Multilayer Perceptron, MLP), mit einer Eingabeschicht, einer Ausgabeschicht und einer oder mehreren verborgenen Schichten, die diese verbinden.
Die Unterschiede zwischen Autoencodern und MLPs bestehen jedoch darin, dass bei einem Autoencoder die Ausgabeschicht die gleiche Anzahl von Knoten wie die Eingabeschicht hat und dass der Autoencoder nicht darauf trainiert wird, einen durch eine Eingabe X gegebenen Zielwert Y vorherzusagen um seine eigenen Xs zu rekonstruieren. Daher sind Autoencoder unbeaufsichtigte Lernmodelle.

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

Abbildung 6. Synchroner Autoencoder

Dafür wurde der Autoencoder ausgewählt Synchrone Architektur. Seine Vorteile: die Möglichkeit, den Streaming-Verarbeitungsmodus zu verwenden und eine relativ geringere Anzahl neuronaler Netzwerkparameter im Vergleich zu anderen Architekturen.

Mechanismus zur Minimierung falsch positiver Ergebnisse

Aufgrund der Tatsache, dass für das zu entwickelnde Anomalieerkennungsmodell verschiedene abnormale Situationen sowie möglicherweise eine unzureichende Ausbildung des neuronalen Netzwerks auftreten, wurde entschieden, dass es notwendig ist, einen Mechanismus zur Minimierung falsch positiver Ergebnisse zu entwickeln. Dieser Mechanismus basiert auf einer Vorlagenbasis, die vom Administrator klassifiziert wird.

Algorithmus zur dynamischen Timeline-Transformation (DTW-Algorithmus, aus dem Englischen „Dynamic Time Warping“) ermöglicht es Ihnen, die optimale Übereinstimmung zwischen Zeitsequenzen zu finden. Wird erstmals bei der Spracherkennung verwendet: Wird verwendet, um zu bestimmen, wie zwei Sprachsignale dieselbe ursprünglich gesprochene Phrase darstellen. Später fand es auch in anderen Bereichen Anwendung.

Das Hauptprinzip zur Minimierung falsch positiver Ergebnisse besteht darin, eine Datenbank mit Standards mithilfe eines Operators zu erstellen, der mithilfe neuronaler Netze erkannte verdächtige Fälle klassifiziert. Anschließend wird der klassifizierte Standard mit dem vom System erkannten Fall verglichen und eine Schlussfolgerung darüber gezogen, ob der Fall falsch ist oder zu einem Fehler führt. Der DTW-Algorithmus wird genau zum Vergleich zweier Zeitreihen verwendet. Das wichtigste Minimierungsinstrument ist nach wie vor die Klassifizierung. Es wird erwartet, dass das System nach dem Sammeln einer großen Anzahl von Referenzfällen aufgrund der Ähnlichkeit der meisten Fälle und des Auftretens ähnlicher Fälle beginnt, den Bediener weniger zu fragen.

Als Ergebnis wurde basierend auf den oben beschriebenen neuronalen Netzwerkmethoden ein experimentelles Programm erstellt, um Ausfälle des „Web-Consolidation“-Systems vorherzusagen. Ziel dieses Programms war es, anhand des vorhandenen Archivs an Überwachungsdaten und Informationen über frühere Ausfälle die Kompetenz dieses Ansatzes für unsere Softwaresysteme zu bewerten. Das Schema des Programms ist unten in Abbildung 7 dargestellt.

Abbildung 7. Fehlervorhersageschema basierend auf der metrischen Raumanalyse

Im Diagramm lassen sich zwei Hauptblöcke unterscheiden: die Suche nach anomalen Zeiträumen im Überwachungsdatenstrom (Metriken) und der Mechanismus zur Minimierung von Fehlalarmen. Hinweis: Zu Versuchszwecken werden die Daten über eine JDBC-Verbindung aus der Datenbank abgerufen, in der Graphite sie speichert.
Das Folgende ist die Schnittstelle des Überwachungssystems, die als Ergebnis der Entwicklung erhalten wurde (Abbildung 8).

Abbildung 8. Schnittstelle des experimentellen Überwachungssystems

Die Schnittstelle zeigt den Prozentsatz der Anomalie basierend auf den empfangenen Metriken an. In unserem Fall wird der Empfang simuliert. Wir verfügen bereits über mehrere Wochen über alle Daten und laden sie nach und nach, um den Fall einer Anomalie zu überprüfen, die zu einem Ausfall führt. Die untere Statusleiste zeigt den Gesamtprozentsatz der Datenanomalie zu einem bestimmten Zeitpunkt an, der mithilfe eines Autoencoders ermittelt wird. Außerdem wird für die vorhergesagten Metriken ein separater Prozentsatz angezeigt, der vom RNN LSTM berechnet wird.

Ein Beispiel für die Erkennung von Anomalien basierend auf der CPU-Leistung mithilfe des neuronalen Netzwerks RNN LSTM (Abbildung 9).

Abbildung 9. RNN LSTM-Erkennung

Ein relativ einfacher Fall, im Wesentlichen ein gewöhnlicher Ausreißer, der jedoch zu einem Systemausfall führte, wurde mit RNN LSTM erfolgreich berechnet. Der Anomalieindikator liegt in diesem Zeitraum bei 85–95 %, alles über 80 % (der Schwellenwert wurde experimentell ermittelt) gilt als Anomalie.
Ein Beispiel für eine Anomalieerkennung, wenn das System nach einem Update nicht booten konnte. Diese Situation wird vom Autoencoder erkannt (Abbildung 10).

Abbildung 10. Beispiel für die Autoencoder-Erkennung

Wie Sie der Abbildung entnehmen können, bleibt PermGen auf einer Ebene hängen. Der Autoencoder fand das seltsam, weil er so etwas noch nie zuvor gesehen hatte. Hier bleibt die Anomalie 100 % bestehen, bis das System wieder in einen betriebsbereiten Zustand zurückkehrt. Für alle Metriken wird eine Anomalie angezeigt. Wie bereits erwähnt, kann der Autoencoder keine Anomalien lokalisieren. In diesen Situationen ist der Bediener aufgefordert, diese Funktion auszuführen.

Abschluss

PC „Web-Consolidation“ befindet sich seit mehreren Jahren in der Entwicklung. Das System befindet sich in einem recht stabilen Zustand und die Anzahl der registrierten Vorfälle ist gering. Allerdings konnten bereits 5 – 10 Minuten vor dem Ausfall Anomalien festgestellt werden, die zum Ausfall führten. In manchen Fällen kann eine vorherige Benachrichtigung über einen Fehler dazu beitragen, die geplante Zeit einzusparen, die für die Durchführung von „Reparatur“-Arbeiten vorgesehen ist.

Basierend auf den durchgeführten Experimenten ist es noch zu früh, um endgültige Schlussfolgerungen zu ziehen. Bisher sind die Ergebnisse widersprüchlich. Einerseits ist klar, dass Algorithmen auf Basis neuronaler Netze in der Lage sind, „nützliche“ Anomalien zu finden. Andererseits gibt es nach wie vor einen hohen Prozentsatz falsch positiver Ergebnisse, und nicht alle von einem qualifizierten Spezialisten in einem neuronalen Netzwerk erkannten Anomalien können erkannt werden. Zu den Nachteilen gehört die Tatsache, dass das neuronale Netzwerk jetzt für den normalen Betrieb eine Schulung durch einen Lehrer erfordert.

Um das Fehlervorhersagesystem weiterzuentwickeln und in einen zufriedenstellenden Zustand zu bringen, können mehrere Wege in Betracht gezogen werden. Dies ist eine detailliertere Analyse von Fällen mit Anomalien, die zum Ausfall führen, da die Liste wichtiger Metriken, die den Zustand des Systems stark beeinflussen, ergänzt und unnötige Metriken, die keinen Einfluss darauf haben, verworfen werden. Wenn wir uns in diese Richtung bewegen, können wir außerdem versuchen, Algorithmen speziell für unsere Fälle mit Anomalien zu spezialisieren, die zu Fehlern führen. Es geht auch anders. Dies stellt eine Verbesserung neuronaler Netzwerkarchitekturen dar und erhöht dadurch die Erkennungsgenauigkeit bei gleichzeitiger Reduzierung der Trainingszeit.

Ich bedanke mich bei meinen Kollegen, die mir geholfen haben, diesen Artikel zu schreiben und die Relevanz aufrechtzuerhalten: Victor Verbitsky und Sergej Finogenow.

Source: habr.com