{"id":53531,"date":"2019-12-04T00:00:00","date_gmt":"2019-12-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej"},"modified":"2020-02-18T14:01:26","modified_gmt":"2020-02-18T11:01:26","slug":"ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","title":{"rendered":"Wir suchen nach Anomalien und prognostizieren Ausf\u00e4lle mithilfe von neuronalen Netzwerken.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wir<\/p>\n

<\/p>\n

Die industrielle Entwicklung von Softwaresystemen erfordert gro\u00dfe Aufmerksamkeit f\u00fcr die Ausfallsicherheit des Endprodukts sowie eine schnelle Reaktion auf Fehler und St\u00f6rungen, wenn sie auftreten. Monitoring hilft zwar, effektiver und schneller auf Ausf\u00e4lle zu reagieren, ist jedoch nicht ausreichend. Erstens ist es sehr schwierig, eine gro\u00dfe Anzahl von Servern im Auge zu behalten \u2013 daf\u00fcr wird eine Vielzahl von Personen ben\u00f6tigt. Zweitens muss man gut verstehen, wie die Anwendung funktioniert, um ihren Status prognostizieren zu k\u00f6nnen. Das bedeutet, dass viele Personen ben\u00f6tigt werden, die die von uns entwickelten Systeme sowie ihre Leistungskennzahlen und Besonderheiten gut verstehen. Angenommen, sogar wenn es gelingt, gen\u00fcgend Personen zu finden, die daran arbeiten m\u00f6chten, ben\u00f6tigt es zudem viel Zeit, um sie auszubilden.<\/p>\n

<\/p>\n

Was tun? Hier kommt uns die k\u00fcnstliche Intelligenz zu Hilfe. In diesem Artikel geht es um pr\u00e4diktive Wartung<\/a><\/noindex> (predictive maintenance). Dieser Ansatz gewinnt zunehmend an Beliebtheit. Zahlreiche Artikel wurden dar\u00fcber verfasst, auch auf Plattformen wie Habr. Gro\u00dfe Unternehmen setzen diesen Ansatz intensiv ein, um die Betriebsf\u00e4higkeit ihrer Server zu gew\u00e4hrleisten. Nach einer gr\u00fcndlichen Analyse vieler Artikel haben wir beschlossen, diesen Ansatz auszuprobieren. Was dabei herausgekommen ist? <\/p>\n

<\/a><\/noindex><\/p>\n

Einf\u00fchrung<\/h2>\n

<\/p>\n

Jedes entwickelte Softwaresystem wird fr\u00fcher oder sp\u00e4ter in Betrieb genommen. F\u00fcr den Benutzer ist es wichtig, dass das System reibungslos funktioniert. Sollte dennoch eine Fehlfunktion auftreten, muss diese mit minimalen Verz\u00f6gerungen behoben werden. <\/p>\n

<\/p>\n

Um den technischen Support des Softwaresystems zu erleichtern, insbesondere wenn viele Server im Einsatz sind, werden in der Regel \u00dcberwachungsprogramme eingesetzt. Diese erfassen die Metriken des laufenden Systems, erm\u00f6glichen die Diagnose seines Zustands und helfen dabei festzustellen, was genau den Fehler verursacht hat. Dieser Prozess wird als System\u00fcberwachung bezeichnet.<\/p>\n

\n\"Wir<\/p>\n

Abbildung 1. Schnittstelle zur \u00dcberwachung mit Grafana<\/em><\/p>\n

Metriken sind verschiedene Kennzahlen eines Softwaresystems, seiner Ausf\u00fchrungsumgebung oder der physikalischen Rechenmaschine, auf der das System l\u00e4uft, mit einem Zeitstempel, der den Moment angibt, in dem die Metriken erfasst wurden. In der statischen Analyse werden die Metrikdaten als Zeitreihen bezeichnet. Um den Zustand des Softwaresystems zu \u00fcberwachen, werden die Metriken in Form von Diagrammen dargestellt: auf der X-Achse die Zeit und auf der Y-Achse die Werte (Abbildung 1). Aus einem laufenden Softwaresystem k\u00f6nnen mehrere Tausend Metriken (von jedem Knoten) erfasst werden. Sie bilden den Raum der Metriken (mehrdimensionale Zeitreihen). <\/p>\n

<\/p>\n

Da komplexe Softwaresysteme eine Vielzahl von Metriken erfassen, wird die manuelle \u00dcberwachung zu einer anspruchsvollen Aufgabe. Um die von Administrators zu analysierenden Datenmengen zu reduzieren, bieten Monitoring-Tools Funktionen zur automatischen Erkennung m\u00f6glicher Probleme. Beispielsweise kann ein Trigger eingerichtet werden, der ausl\u00f6st, wenn der freie Speicherplatz die festgelegte Grenze erreicht. Auch das automatische Diagnostizieren eines Serverausfalls oder einer kritischen Verlangsamung der Dienstgeschwindigkeit ist m\u00f6glich. In der Praxis bew\u00e4ltigen Monitoring-Tools die Erkennung bereits eingetretener Ausf\u00e4lle oder das Aufsp\u00fcren einfacher Symptome zuk\u00fcnftiger Ausf\u00e4lle recht gut, jedoch bleibt die Vorhersage m\u00f6glicher St\u00f6rungen eine gro\u00dfe Herausforderung. Die Prognose mittels manueller Analyse der Metriken erfordert den Einsatz qualifizierter Fachkr\u00e4fte und ist ineffizient. Viele potenzielle Ausf\u00e4lle k\u00f6nnten unentdeckt bleiben.<\/p>\n

<\/p>\n

In letzter Zeit gewinnt das sogenannte pr\u00e4diktive Wartung von Softwaresystemen unter gro\u00dfen IT-Unternehmen zunehmend an Bedeutung. Bei diesem Ansatz geht es darum, St\u00f6rungen, die zur Degradation des Systems f\u00fchren, fr\u00fchzeitig zu identifizieren, bevor es zum Ausfall kommt, und zwar unter Verwendung von k\u00fcnstlicher Intelligenz. Dieser Ansatz schlie\u00dft manuelle System\u00fcberwachung nicht vollst\u00e4ndig aus, sondern dient als unterst\u00fctzende Ma\u00dfnahme f\u00fcr den \u00dcberwachungsprozess insgesamt. <\/p>\n

<\/p>\n

Das Hauptinstrument zur Umsetzung der pr\u00e4diktiven Wartung ist die Anomalieerkennung in Zeitreihen, da bei Auftreten einer Anomalie<\/strong> in den Daten eine hohe Wahrscheinlichkeit besteht, dass es nach einiger Zeit zu einem Fehler oder Ausfall kommt<\/strong>. Eine Anomalie ist eine Abweichung von den Kennzahlen eines Softwaresystems, wie die Feststellung einer Verschlechterung der Antwortgeschwindigkeit einer bestimmten Anfragetyp oder die Abnahme der durchschnittlichen Anzahl bearbeiteter Anfragen bei konstantem Client-Sitzungsniveau.<\/p>\n

<\/p>\n

Die Identifizierung von Anomalien in Softwaresystemen hat ihre eigenen Besonderheiten. Grunds\u00e4tzlich ist es notwendig, f\u00fcr jedes Softwaresystem bestehende Methoden zu entwickeln oder anzupassen, da die Anomalieerkennung stark von den Daten abh\u00e4ngt, in denen sie durchgef\u00fchrt wird, und diese Daten in Abh\u00e4ngigkeit von den eingesetzten Implementierungstools stark variieren \u2013 bis hin zu der Hardware, auf der das System l\u00e4uft.<\/p>\n

<\/p>\n

Methoden zur Anomalieerkennung bei der Vorhersage von Ausf\u00e4llen von Softwaresystemen<\/h2>\n

<\/p>\n

Zun\u00e4chst sei angemerkt, dass die Idee der Ausfallvorhersage von einem Artikel inspiriert wurde \u201eMaschinelles Lernen im IT-Monitoring\u201c<\/a><\/noindex>. Zur \u00dcberpr\u00fcfung der Effektivit\u00e4t des Ansatzes zur automatischen Anomalieerkennung wurde das Software-System \u201eWeb-Konsolidierung\u201c ausgew\u00e4hlt, das eines der Projekte der Firma NPO \u201eKrista\u201c ist. Zuvor wurden manuelle \u00dcberwachungen basierend auf den erhaltenen Metriken durchgef\u00fchrt. Da das System recht komplex ist, werden eine Vielzahl von Metriken erfasst: JVM-Werte (Last des Garbage Collectors), Kennzahlen des Betriebssystems, auf dem der Code ausgef\u00fchrt wird (virtueller Speicher, % der CPU-Auslastung), Netzwerkmetriken (Netzwerklast), Servermetriken (CPU-Last, Arbeitsspeicher), Wildfly-Metriken und eigene Metriken der Anwendung f\u00fcr alle kritischen Teilsysteme. <\/p>\n

<\/p>\n

Alle Metriken werden mithilfe von Graphite aus dem System abgerufen. Urspr\u00fcnglich wurde die Whisper-Datenbank als Standardl\u00f6sung f\u00fcr Grafana verwendet, aber mit dem Wachstum der Kundenbasis konnte Graphite die Anforderungen nicht mehr erf\u00fcllen und ersch\u00f6pfte die Speicherkapazit\u00e4t der Festplattensubsysteme im Rechenzentrum. Daraufhin wurde entschieden, nach einer effizienteren L\u00f6sung zu suchen. Die Wahl fiel auf Graphite+Clickhouse<\/a><\/noindex>, was die Belastung des Disk-Subsystems erheblich verringerte und den belegten Speicherplatz um das F\u00fcnf- bis Sechsfache reduzierte. Nachfolgend ist das Schema des Mechanismus zur Erfassung von Metriken mit Graphite+ClickHouse dargestellt (Abbildung 2).<\/p>\n

\n\"Wir
\n<\/p>\n

Abbildung 2. Schema zur Erfassung von Metriken<\/em><\/p>\n

Das Schema stammt aus der internen Dokumentation. Es zeigt den Datenaustausch zwischen Grafana (der Benutzeroberfl\u00e4che f\u00fcr das Monitoring, die wir verwenden) und Graphite. Die Erfassung der Metriken von der Anwendung erfolgt durch eine separate Software \u2013 jmxtrans<\/a><\/noindex>. Diese speichert sie in Graphite.
\nDas System \u201eWeb-Konsolidierung\u201c weist eine Reihe von Besonderheiten auf, die Probleme bei der Vorhersage von Ausf\u00e4llen verursachen:<\/p>\n

<\/p>\n

    \n
  1. Es kommt h\u00e4ufig zu einem Trendwechsel. F\u00fcr dieses Software-System werden verschiedene Versionen ver\u00f6ffentlicht. Jede von ihnen bringt \u00c4nderungen in der Software der Systemkomponenten mit sich. Somit beeinflussen die Entwickler direkt die Metriken dieses Systems und k\u00f6nnen einen Trendwechsel ausl\u00f6sen; <\/li>\n
  2. Die Art der Implementierung sowie die Ziele, die die Kunden mit diesem System verfolgen, f\u00fchren h\u00e4ufig zu Anomalien, ohne dass zuvor eine Degeneration stattfindet; <\/li>\n
  3. Der Anteil der Anomalien im Verh\u00e4ltnis zum gesamten Datensatz ist gering (< 5%); <\/li>\n
  4. Es k\u00f6nnen Unterbrechungen bei der Erfassung von Kennzahlen durch das System auftreten. In bestimmten kurzen Zeitspannen ist es dem \u00dcberwachungssystem nicht m\u00f6glich, Metriken zu erhalten, beispielsweise wenn der Server \u00fcberlastet ist. F\u00fcr das Training des neuronalen Netzwerks ist dies entscheidend. Daher besteht die Notwendigkeit, die L\u00fccken synthetisch zu f\u00fcllen;<\/li>\n
  5. F\u00e4lle mit Anomalien sind oft nur f\u00fcr eine bestimmte Anzahl\/Monat\/Zeit (Saisonabh\u00e4ngigkeit) relevant. Dieses System hat klare Richtlinien f\u00fcr die Nutzung durch seine Benutzer. Dementsprechend sind die Metriken nur f\u00fcr spezifische Zeitr\u00e4ume relevant. Das System kann nicht st\u00e4ndig genutzt werden, sondern nur in bestimmten Monaten, je nach Jahr. Es gibt Situationen, in denen das gleiche Verhalten der Metriken in einem Fall zum Ausfall des Programmsystems f\u00fchren kann, in einem anderen jedoch nicht.
    \nZun\u00e4chst wurden die Methoden zur Erkennung von Anomalien in den \u00dcberwachungsdaten von Softwaresystemen analysiert. In Artikeln zu diesem Thema wird bei niedrigen Prozents\u00e4tzen an Anomalien im Vergleich zum Rest der Daten h\u00e4ufig empfohlen, neuronale Netzwerke einzusetzen. <\/li>\n<\/ol>\n

    <\/p>\n

    Die grundlegende Logik zur Auffindung von Anomalien mithilfe von Daten neuronaler Netze ist in Abbildung 3 dargestellt:<\/p>\n

    \n\"Wir
    \n<\/p>\n

    Abbildung 3. Anomaliefindung mithilfe eines neuronalen Netzes<\/em><\/p>\n

    Das Abweichungsverh\u00e4ltnis zwischen den Prognosen oder Rekonstruktionen des aktuellen Metricsflusses wird im Vergleich zu den Werten aus dem laufenden Softwaresystem berechnet. Bei einer signifikanten Differenz zwischen den erhaltenen Metriken aus dem Softwaresystem und dem neuronalen Netz kann auf die Anomalit\u00e4t des aktuellen Datenausschnitts geschlossen werden. Hier ergeben sich verschiedene Herausforderungen bei der Verwendung neuronaler Netze:<\/p>\n

    <\/p>\n

      \n
    1. F\u00fcr einen korrekten Betrieb im Stream-Modus sollten die Daten zum Trainieren der neuronalen Modelle ausschlie\u00dflich 'normale' Daten enthalten; <\/li>\n
    2. Es ist notwendig, ein aktuelles Modell zur ordnungsgem\u00e4\u00dfen Erkennung zu haben. Ver\u00e4nderungen in Trends und Saisonalit\u00e4t der Metriken k\u00f6nnen eine Vielzahl von falsch-positiven Alarme ausl\u00f6sen. Um das Modell zu aktualisieren, muss genau festgelegt werden, wann das Modell veraltet ist. Wenn das Modell zu sp\u00e4t oder zu fr\u00fch aktualisiert wird, ist es wahrscheinlich, dass es zu einer hohen Anzahl von falsch-positiven Alarmen kommt.
      \nEs ist ebenso wichtig, die Suche nach und die Verhinderung h\u00e4ufiger Fehlalarme nicht zu vergessen. Diese treten meist in Ausnahmef\u00e4llen auf. Sie k\u00f6nnen jedoch auch auf einen Fehler im neuronalen Netzwerk zur\u00fcckzuf\u00fchren sein, der durch unzureichendes Training verursacht wird. Die Anzahl der Fehlalarme des Modells muss minimiert werden. Andernfalls werden falsche Vorhersagen viel Zeit des Administrators in Anspruch nehmen, die eigentlich f\u00fcr die System\u00fcberpr\u00fcfung eingeplant ist. Irgendwann wird der Administrator einfach aufh\u00f6ren, auf das \"paranoide\" \u00dcberwachungssystem zu reagieren.<\/li>\n<\/ol>\n

      <\/p>\n

      Recurrent Neural Network<\/h2>\n

      <\/p>\n

      Zur Erkennung von Anomalien in Zeitreihen kann man ein rekurrentes neuronales Netzwerk <\/a><\/noindex>mit LSTM-Speicher anwenden. Das Problem besteht jedoch darin, dass es nur f\u00fcr vorhersagbare Zeitreihen eingesetzt werden kann. In unserem Fall sind nicht alle Metriken vorhersagbar. Ein Versuch, RNN LSTM f\u00fcr die Zeitreihe anzuwenden, ist in Abbildung 4 dargestellt.<\/p>\n

      \n\"Wir
      \n<\/p>\n

      Abbildung 4. Beispiel f\u00fcr die Funktionsweise eines rekurrenten neuronalen Netzwerks mit LSTM-Speichereinheiten.<\/em><\/p>\n

      Wie aus Abbildung 4 ersichtlich, konnte das RNN LSTM Anomalien in diesem Zeitabschnitt identifizieren. Dort, wo das Ergebnis eine hohe Prognosefehlerquote (mittelm\u00e4\u00dfiger Fehler) aufweist, traten tats\u00e4chlich Anomalien auf. Die Verwendung eines einzigen RNN LSTM wird offensichtlich nicht ausreichen, da es auf eine begrenzte Anzahl von Metriken anwendbar ist. Es kann als unterst\u00fctzende Methode zur Anomalieerkennung genutzt werden. <\/p>\n

      <\/p>\n

      Autoencoder zur Vorhersage von Ausf\u00e4llen<\/h2>\n

      <\/p>\n

      Autoencoder<\/a><\/noindex> \u2013 im Grunde ein k\u00fcnstliches neuronales Netzwerk. Der Eingabeschicht fungiert als Encoder, die Ausgabeschicht als Decoder. Ein Nachteil aller neuronalen Netzwerke dieses Typs ist die schlechte Lokalisierung von Anomalien. Es wurde die Architektur eines synchronen Autoencoders ausgew\u00e4hlt.<\/p>\n

      \n\"Wir
      \n<\/p>\n

      Abbildung 5. Beispiel f\u00fcr die Funktionsweise eines Autoencoders<\/em><\/p>\n

      Autoencoder werden mit Normaldaten trainiert und finden anschlie\u00dfend Anomalien in den der Modellierung zugef\u00fchrten Daten. Genau das, was f\u00fcr diese Aufgabe ben\u00f6tigt wird. Es bleibt nur noch zu entscheiden, welcher der Autoencoder am besten f\u00fcr diese Aufgabe geeignet ist. Die architektonisch einfachste Form eines Autoencoders ist ein direktes, nicht r\u00fcckf\u00fchrbares neuronales Netzwerk, das sehr \u00e4hnlich ist wie ein mehrschichtiges Perzeptron<\/a><\/noindex> (Multilayer-Perzeptron, MLP), mit einer Eingabeschicht, einer Ausgabeschicht und einer oder mehreren verborgenen Schichten, die sie verbinden.
      \nDie Unterschiede zwischen Autoencodern und MLP liegen jedoch darin, dass der Ausgabeschicht die gleiche Anzahl von Neuronen wie der Eingabeschicht hat und dass der Autoencoder nicht darauf trainiert wird, einen Zielwert Y, der durch die Eingabe X bestimmt wird, vorherzusagen. Stattdessen lernt der Autoencoder, seine eigenen X zu rekonstruieren. Daher sind Autoencoder un\u00fcberwachte Lernmodelle. <\/p>\n

      <\/p>\n

      Die Aufgabe des Autoencoders besteht darin, die Zeitindizes r0 \u2026 rn zu finden, die den anomalien Elementen im Eingangsvektor X entsprechen. Dieser Effekt wird durch die Suche nach dem quadratischen Fehler erreicht.<\/p>\n

      \n\"Wir <\/p>\n

      Abbildung 6. Synchroner Autoencoder<\/em><\/p>\n

      F\u00fcr den Autoencoder wurde eine synchronen Architektur<\/a><\/noindex>ausgew\u00e4hlt. Ihre Vorteile liegen in der M\u00f6glichkeit der Verwendung eines Streaming-Verarbeitungsmodus und einer relativ geringen Anzahl von Parametern im Vergleich zu anderen Architekturen.<\/p>\n

      <\/p>\n

      Mechanismus zur Minimierung von Fehlalarmen<\/h2>\n

      <\/p>\n

      Da in verschiedenen Situationen unerwartete Ereignisse auftreten k\u00f6nnen und die Schulung des neuronalen Netzwerks m\u00f6glicherweise unzureichend sein kann, wurde f\u00fcr das zu entwickelnde Anomalieerkennungsmodell die Notwendigkeit eines Mechanismus zur Minimierung von Fehlalarmen beschlossen. Dieser Mechanismus basiert auf einer Vorlagenbasis, die vom Administrator klassifiziert wird. <\/p>\n

      <\/p>\n

      Algorithmus zur dynamischen Transformation der Zeitachse<\/a><\/noindex> (DTW-Algorithmus, abgeleitet von dynamic time warping) erm\u00f6glicht es, die optimale \u00dcbereinstimmung zwischen zeitlichen Sequenzen zu finden. Er wurde erstmals in der Spracherkennung eingesetzt: dabei wurde bestimmt, wie zwei Sprachsignale denselben urspr\u00fcnglich ausgesprochenen Satz repr\u00e4sentieren. Sp\u00e4ter fand er auch in anderen Bereichen Anwendung.<\/p>\n

      <\/p>\n

      Das Hauptprinzip zur Minimierung von Fehlalarmen besteht darin, eine Basis von Referenzen mit Hilfe eines Operators zu sammeln, der verd\u00e4chtige F\u00e4lle, die durch neuronale Netze entdeckt wurden, klassifiziert. Anschlie\u00dfend erfolgt der Vergleich des klassifizierten Referenzfalls mit dem Fall, den das System entdeckt hat, und es wird entschieden, ob der Fall zu einem Fehlalarm oder zu einem tats\u00e4chlichen Fehler geh\u00f6rt. Genau daf\u00fcr wird der DTW-Algorithmus verwendet, um zwei Zeitreihen zu vergleichen. Das Hauptinstrument zur Minimierung bleibt jedoch die Klassifikation. Es wird angenommen, dass das System, nach der Sammlung einer gro\u00dfen Anzahl von Referenzf\u00e4llen, weniger oft den Operator konsultieren wird, da die meisten F\u00e4lle \u00e4hnlich sind und \u00e4hnliche Muster aufweisen.<\/p>\n

      <\/p>\n

      Auf der Grundlage der oben beschriebenen Methoden der neuronalen Netze wurde ein experimentelles Programm zur Vorhersage von Systemausf\u00e4llen f\u00fcr die \"Web-Konsolidierung\" erstellt. Ziel dieses Programms war es, unter Verwendung des bestehenden Archivs von \u00dcberwachungsdaten und Informationen \u00fcber bereits aufgetretene Ausf\u00e4lle die Wirksamkeit dieses Ansatzes f\u00fcr unsere Softwaresysteme zu bewerten. Das Arbeitsdiagramm des Programms ist unten in Abbildung 7 dargestellt.<\/p>\n

      \n\"Wir <\/p>\n

      Abbildung 7. Schema zur Vorhersage von Ausf\u00e4llen basierend auf der Analyse des Metrikraums<\/em><\/p>\n

      Im Diagramm lassen sich zwei Hauptbl\u00f6cke unterscheiden: die Suche nach anomalen Zeitabschnitten im Datenstrom der \u00dcberwachung (Metriken) und den Mechanismus zur Minimierung von Fehlalarmen. Hinweis: Zu experimentellen Zwecken werden die Daten \u00fcber eine JDBC-Verbindung aus einer Datenbank abgerufen, in der sie in Graphite gespeichert werden.
      \nIm Folgenden wird die Benutzeroberfl\u00e4che des entwickelten \u00dcberwachungssystems dargestellt (Abbildung 8).<\/p>\n

      \n\"Wir<\/p>\n

      Abbildung 8. Benutzeroberfl\u00e4che des experimentellen \u00dcberwachungssystems<\/em><\/p>\n

      In der Benutzeroberfl\u00e4che wird der Anomalieprozentsatz der empfangenen Metriken angezeigt. In unserem Fall wird der Erhalt simuliert. Wir haben bereits alle Daten der letzten Wochen gesammelt und laden sie schrittweise hoch, um den Fall einer Anomalie zu \u00fcberpr\u00fcfen, die zu einem Ausfall f\u00fchrt. In der unteren Statusleiste wird der allgemeine Prozentsatz der Anomalie der Daten zu einem bestimmten Zeitpunkt angezeigt, der mithilfe des Autoencoders bestimmt wird. Zus\u00e4tzlich wird f\u00fcr die prognostizierten Metriken ein separater Prozentsatz angezeigt, der von einem RNN LSTM berechnet wird.<\/p>\n

      <\/p>\n

      Beispiel f\u00fcr die Erkennung von Anomalien anhand der CPU-Leistung mithilfe des RNN LSTM-Netzes (Abbildung 9).<\/p>\n

      \n\"Wir<\/p>\n

      Abbildung 9. Erkennung von RNN LSTM<\/em><\/p>\n

      Ein recht einfacher Fall, im Grunde ein gew\u00f6hnlicher Ausrei\u00dfer, der jedoch zu einem Systemausfall f\u00fchrte, wurde erfolgreich mit Hilfe von RNN LSTM erfasst. Der Anomaliewert in diesem Zeitabschnitt liegt zwischen 85 und 95 %, alles \u00fcber 80 % (der Schwellenwert wurde experimentell festgelegt) gilt als Anomalie.
      \nBeispiel einer Anomalieerkennung, als das System nach einem Update nicht mehr hochfahren konnte. Diese Situation wird durch den Autoencoder erkannt (Abbildung 10).<\/p>\n

      \n\"Wir<\/p>\n

      Abbildung 10. Beispiel der Erkennung durch den Autoencoder<\/em><\/p>\n

      Wie aus der Abbildung ersichtlich ist, hat PermGen auf einem Niveau festgehangen. Der Autoencoder hielt das f\u00fcr merkw\u00fcrdig, da er zuvor nichts Vergleichbares gesehen hatte. Hier liegt die Anomalie konstant bei 100 %, bis das System wieder einsatzbereit ist. Die Anomalie zeigt sich in allen Metriken. Wie bereits erw\u00e4hnt, kann der Autoencoder Anomalien nicht lokalisieren. Der Operator ist in solchen Situationen daf\u00fcr verantwortlich.<\/p>\n

      <\/p>\n

      Fazit<\/h2>\n

      <\/p>\n

      Das System \u201eWeb-Konsolidierung\u201c wird seit mehreren Jahren entwickelt. Es befindet sich in einem stabilen Zustand, und die Anzahl der registrierten Vorf\u00e4lle ist gering. Dennoch konnten Anomalien identifiziert werden, die zu einem Ausfall 5 bis 10 Minuten vor dessen Eintreten f\u00fchren. In einigen F\u00e4llen h\u00e4tte eine fr\u00fchzeitige Warnung vor dem Ausfall geholfen, die f\u00fcr Wartungsarbeiten festgelegte Zeit zu sparen.<\/p>\n

      <\/p>\n

      In Bezug auf die durchgef\u00fchrten Experimente ist es noch zu fr\u00fch, endg\u00fcltige Schlussfolgerungen zu ziehen. Die Ergebnisse sind momentan widerspr\u00fcchlich. Einerseits ist erkennbar, dass neuronale Netzalgorithmen in der Lage sind, \u201en\u00fctzliche\u201c Anomalien zu identifizieren. Andererseits gibt es eine hohe Rate an Fehlalarmen, und nicht alle Anomalien, die von qualifizierten Spezialisten entdeckt werden, sind f\u00fcr die neuronalen Netzwerke erkennbar. Ein Nachteil ist zudem, dass das neuronale Netzwerk derzeit eine Beaufsichtigung zum Lernen ben\u00f6tigt, um ordnungsgem\u00e4\u00df zu funktionieren.<\/p>\n

      <\/p>\n

      Um die Entwicklung des Ausfallvorhersagesystems voranzutreiben und es in einen zufriedenstellenden Zustand zu bringen, gibt es mehrere Ans\u00e4tze. Dazu geh\u00f6rt eine detailliertere Analyse der anomalies betreffenden F\u00e4lle, die zu Ausf\u00e4llen f\u00fchren, durch eine Erweiterung der Liste wichtiger Metriken, die einen erheblichen Einfluss auf den Systemzustand haben, w\u00e4hrend unwichtige Metriken ausgeschlossen werden. Wenn wir in diese Richtung weiterarbeiten, k\u00f6nnen wir auch versuchen, die Algorithmen speziell auf unsere F\u00e4lle von Anomalien, die zu Ausf\u00e4llen f\u00fchren, zuzuschneiden. Ein weiterer Ansatz w\u00e4re die Verbesserung der Architektur von neuronalen Netzen, wodurch die Genauigkeit der Erkennungen erh\u00f6ht und die Trainingszeit verk\u00fcrzt wird.<\/p>\n

      <\/p>\n

      Ich m\u00f6chte meinen Kollegen danken, die mir beim Verfassen und der Aktualisierung dieses Artikels geholfen haben: Wiktor Werbitski<\/a><\/noindex> und Sergej Finogenow.<\/p>\n

      Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044f \u043a \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u043a\u043e\u043d\u0435\u0447\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0431\u044b\u0441\u0442\u0440\u043e\u0433\u043e \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438, \u0435\u0441\u043b\u0438 \u043e\u043d\u0438 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0430\u044e\u0442\u0441\u044f. \u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433, \u043a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u0435\u0435 \u0438 \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043d\u043e \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e. \u0412\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u043e\u0447\u0435\u043d\u044c \u0441\u043b\u043e\u0436\u043d\u043e \u0443\u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u2013 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043b\u044e\u0434\u0435\u0439. \u0412\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u043d\u0443\u0436\u043d\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c, \u043a\u0430\u043a […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53531","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Wir suchen nach Anomalien und prognostizieren Ausf\u00e4lle mit Hilfe von neuronalen Netzen | ProHoster","description":"Die industrielle Softwareentwicklung erfordert gro\u00dfe Aufmerksamkeit f\u00fcr die Fehlertoleranz des Endprodukts sowie eine schnelle Reaktion auf Ausf\u00e4lle und St\u00f6rungen, falls diese dennoch auftreten. Monitoring hilft nat\u00fcrlich, effizienter und schneller auf Ausf\u00e4lle und St\u00f6rungen zu reagieren, ist jedoch nicht ausreichend. Erstens ist es sehr schwierig, eine gro\u00dfe Anzahl von Servern im Blick zu behalten \u2013 daf\u00fcr werden viele Fachkr\u00e4fte ben\u00f6tigt. Zweitens ist es wichtig, gut zu verstehen, wie","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0449\u0435\u043c \u0430\u043d\u043e\u043c\u0430\u043b\u0438\u0438 \u0438 \u043f\u0440\u0435\u0434\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0441\u0431\u043e\u0438 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u043d\u0435\u0439\u0440\u043e\u0441\u0435\u0442\u0435\u0439 | ProHoster","og:description":"\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044f \u043a \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u043a\u043e\u043d\u0435\u0447\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0431\u044b\u0441\u0442\u0440\u043e\u0433\u043e \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438, \u0435\u0441\u043b\u0438 \u043e\u043d\u0438 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0430\u044e\u0442\u0441\u044f. \u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433, \u043a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u0435\u0435 \u0438 \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043d\u043e \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e. \u0412\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u043e\u0447\u0435\u043d\u044c \u0441\u043b\u043e\u0436\u043d\u043e \u0443\u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u2013 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043b\u044e\u0434\u0435\u0439. \u0412\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u043d\u0443\u0436\u043d\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c, \u043a\u0430\u043a","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-12-03T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53531","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 07:46:24","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:23:55","updated":"2026-01-24 07:46:24"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=53531"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53531\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=53531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=53531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=53531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}