Korrelation zwischen Einträgen
Die erste Empfehlung besteht darin, sicherzustellen, dass geeignete Warn- und Informationseinträge in der Protokolldatei zusammen mit Fehlern in den maschinellen Lernkomponenten der Lösung angezeigt werden. Alle Protokolleinträge sind potenziell nützliche Eingabedaten, wenn es möglich ist, dass Korrelationen zwischen Informationsmeldungen, Warnungen und Fehlern bestehen. Manchmal ist die Korrelation stark und daher entscheidend für die Maximierung der Lernrate.
Systemadministratoren erleben dies häufig als eine Reihe von Warnungen, gefolgt von einem Fehler, der durch den in den Warnungen angegebenen Zustand verursacht wird. Die Informationen in den Warnungen weisen eher auf die Grundursache des Fehlers hin als auf den Fehlereintrag, der erstellt wird, wenn das System oder ein Subsystem kritisch ausfällt.
Wenn ein Systemintegritäts-Dashboard für ein Gerät oder eine Reihe von Maschinen erstellt wird, die zusammenarbeiten, was in dieser Frage der Fall zu sein scheint, sind die Hauptursache für Probleme und einige Frühwarnfunktionen wichtige Informationen, die angezeigt werden müssen.
Darüber hinaus führen nicht alle schlechten Systemzustände zu einem Ausfall.
Die einzigen Protokolleinträge, die vor der Präsentation vor dem Lernmechanismus durch Filtration entfernt werden sollten, sind solche, die sicherlich irrelevant und nicht korreliert sind. Dies kann der Fall sein, wenn die Protokolldatei eine Aggregation der Protokollierung von mehreren Systemen ist. In einem solchen Fall sollten Einträge für das zu analysierende unabhängige System als Isolat aus Einträgen extrahiert werden, die möglicherweise nicht mit den zu analysierenden Phänomenen korrelieren könnten.
Es ist wichtig zu beachten, dass die Beschränkung der Analyse auf jeweils einen Eintrag die Nützlichkeit des Dashboards erheblich einschränkt. Der Zustand eines Systems entspricht nicht den Integritätsangaben des letzten Protokolleintrags. Es ist nicht einmal die lineare Summe der Gesundheitsindikationen der letzten N Einträge.
Der Systemzustand hat eine sehr nichtlineare und sehr zeitabhängige Beziehung zu vielen Einträgen. Auf vielen Systemtypen können im Laufe der Tage allmählich Muster auftreten. Das neuronale Basisnetz (oder ein Basisnetz) im System muss trainiert werden, um diese nichtlinearen Anzeichen von Gesundheit, drohenden Gefahren und Risikobedingungen zu identifizieren, wenn ein äußerst nützliches Dashboard gewünscht wird. Um die Wahrscheinlichkeit eines bevorstehenden Fehlers oder eines Qualitätskontrollproblems anzuzeigen, muss ein ganzes Zeitfenster von Protokolleinträgen von beträchtlicher Länge in dieses neuronale Netz eingegeben werden.
Unterscheidung zwischen bekannten und unbekannten Mustern
Beachten Sie, dass sich die Identifizierung bekannter Muster in einer wichtigen Hinsicht von der Identifizierung neuer Muster unterscheidet. Die Besonderheiten der Eintragssyntax bekannter Fehler wurden bereits identifiziert, wodurch der Lernaufwand in den Verarbeitungsstufen der Eingangsnormalisierung für diese Einträge erheblich verringert wurde. Die syntaktischen Besonderheiten neuer Fehlertypen müssen zuerst entdeckt werden.
Die Einträge eines bekannten Typs können auch von den unbekannten getrennt werden, wodurch die Verwendung bekannter Eintragstypen als Trainingsdaten ermöglicht wird, um das Erlernen neuer syntaktischer Muster zu erleichtern. Ziel ist es, syntaktisch normalisierte Informationen der semantischen Analyse zu präsentieren.
Erste Stufe der Normalisierung spezifisch für Protokolldateien
Wenn sich der Zeitstempel in Einträgen immer an derselben Stelle befindet, können Sie ihn als ersten Schritt in der Normalisierung vor allem anderen konvertieren, indem Sie ihn in relative Millisekunden konvertieren und möglicherweise 0x0d-Zeichen vor 0x0a-Zeichen entfernen. Stapelspuren können auch in tabulatorgetrennte Arrays von Traceebenen zusammengefasst werden, sodass eine Eins-zu-Eins-Entsprechung zwischen Protokolleinträgen und Protokollzeilen besteht.
Die syntaktisch normalisierten Informationen, die sich sowohl aus bekannten als auch aus unbekannten Einträgen von Fehlern und Einträgen vom Fehlertyp ergeben, können dann unbeaufsichtigten Netzen zur naiven Identifizierung von Kategorien einer semantischen Struktur präsentiert werden. Wir möchten keine Nummern oder Textvariablen wie Benutzernamen oder Seriennummern kategorisieren.
Wenn die syntaktisch normalisierten Informationen entsprechend gekennzeichnet sind, um stark variable Symbole wie Anzahl, Kapazität, Metrik und Zeitstempel anzuzeigen, kann die Merkmalsextraktion angewendet werden, um die Ausdrucksmuster so zu lernen, dass die Unterscheidung zwischen semantischer Struktur und Variablen erhalten bleibt. Die Beibehaltung dieser Unterscheidung ermöglicht die Verfolgung kontinuierlicherer (weniger diskreter) Trends in Systemmetriken. Jeder Eintrag kann null oder mehr solcher Variablen enthalten, unabhängig davon, ob sie a priori bekannt sind oder kürzlich durch Merkmalsextraktion erfasst wurden.
Trends können gegen die Zeit oder gegen die Anzahl der Instanzen einer bestimmten Art grafisch dargestellt werden. Solche Grafiken können bei der Identifizierung mechanischer Ermüdung, der Annäherung an Überkapazitätsbedingungen oder anderer Risiken, die zu einem Fehlerpunkt eskalieren, hilfreich sein. Weitere neuronale Netze können trainiert werden, um Warnindikatoren zu erzeugen, wenn die Trends darauf hinweisen, dass solche Bedingungen bevorstehen.
Lazy Logging
All diese Protokollanalysen wären umstritten, wenn Software-Architekten und Technologie-Beauftragte aufhören würden, das Speicherformat wichtiger Systeminformationen den unterschiedlichen Launen der Software-Entwickler zu überlassen. Protokolldateien sind im Allgemeinen ein Chaos, und das Extrahieren statistischer Informationen über Muster in ihnen ist eine der häufigsten Herausforderungen bei der Qualitätskontrolle von Software. Die Wahrscheinlichkeit, dass die Genauigkeit jemals allgemein auf die Protokollierung angewendet wird, ist gering, da keines der gängigen Protokollierungs-Frameworks die Genauigkeit fördert. Dies ist höchstwahrscheinlich der Grund, warum diese Frage häufig gestellt wurde.
Anforderungsabschnitt dieser spezifischen Frage
In dem in dieser Frage dargestellten speziellen Fall gibt Anforderung 1 an, dass die Analyse im Browser ausgeführt werden soll, was möglich, aber nicht empfohlen ist. Obwohl ECMA eine wunderbare Skriptsprache ist und die Maschinerie für reguläre Ausdrücke, die beim Lernen von Parsern hilfreich sein kann, in ECMA integriert ist (was dem anderen Teil der Anforderung Nr. 1 entspricht und keine zusätzlichen Installationen erfordert), sind nicht kompilierte Sprachen bei weitem nicht so effizient wie Java. Und selbst Java ist aufgrund der Speicherbereinigung und Ineffizienzen, die durch die Delegierung der Zuordnung von Bytecode zu Maschinencode zur Laufzeit auftreten, nicht so effizient wie C.
Viele Experimente im maschinellen Lernen verwenden Python, eine andere wunderbare Sprache, aber die meiste Arbeit, die ich in Python geleistet habe, wurde dann in vielen Fällen auf rechnerisch effizientes C ++ portiert, um die Geschwindigkeit um fast 1.000 bis eins zu steigern. Sogar die Suche nach C ++ - Methoden war ein Engpass, sodass die Ports im ECMA-Stil nur sehr wenig Vererbung verwenden, aber viel schneller. Im typischen traditionellen Kernel-Code eliminiert die Verwendung von C-Strukturen und Funktionszeigern den Overhead von vtable.
Die zweite Anforderung an modulare Handler ist vernünftig und impliziert eine ausgelöste Regelumgebung, von der viele möglicherweise glauben, dass sie mit NN-Architekturen nicht kompatibel ist, dies ist jedoch nicht der Fall. Sobald Musterkategorien identifiziert wurden, ist die Suche nach den häufigsten zuerst in weiteren Eingabedaten bereits in der bekannten / unbekannten Unterscheidung enthalten, die bereits in den obigen Prozess eingebettet ist. Dieser modulare Ansatz ist jedoch eine Herausforderung.
Da der Systemzustand häufig durch Trends und nicht durch einzelne Einträge angezeigt wird (wie oben erläutert) und der Systemzustand keine lineare Summe des Integritätswerts einzelner Einträge ist, sollte der modulare Ansatz für die Behandlung von Einträgen nicht einfach ohne weiteres an die Anzeige weitergeleitet werden Analyse. Dies ist in der Tat, wo neuronale Netze die größten funktionellen Vorteile bei der Gesundheitsüberwachung bieten. Die Ausgänge der Module müssen in ein neuronales Netz eingegeben werden, das trainiert werden kann, um diese nichtlinearen Anzeichen von Gesundheit, drohenden Gefahren und Risikobedingungen zu identifizieren.
Darüber hinaus impliziert der zeitliche Aspekt des Verhaltens vor dem Ausfall, dass ein ganzes Zeitfenster von Protokolleinträgen von beträchtlicher Länge in dieses Netz eintreten muss. Dies impliziert ferner die Unangemessenheit von ECMA oder Python als Wahl für den rechenintensiven Teil der Lösung. (Beachten Sie, dass der Trend in Python darin besteht, das zu tun, was ich mit C ++ mache: Verwenden Sie objektorientiertes Design, Kapselung und einfach zu verfolgende Entwurfsmuster für Überwachungscode und sehr rechnerisch effizienten kernelähnlichen Code für tatsächliches Lernen und anderen rechenintensiven oder datenintensiven Funktionen.)
Auswahlalgorithmen
Es ist nicht empfehlenswert, Algorithmen in den Anfangsstadien der Architektur auszuwählen (wie am Ende der Frage impliziert). Architekt zuerst den Prozess. Bestimmen Sie die Lernkomponenten, die Art der benötigten Komponenten, ihren Zielzustand nach dem Training, wo Verstärkung verwendet werden kann und wie das Wellness- / Fehlersignal generiert wird, um das gewünschte Netzwerkverhalten zu verstärken / zu korrigieren. Basieren Sie diese Bestimmungen nicht nur auf dem gewünschten Anzeigeinhalt, sondern auch auf dem erwarteten Durchsatz, den Anforderungen an die Rechenressourcen und der minimalen effektiven Lernrate. Algorithmen, Sprache und Kapazitätsplanung für das System können nur dann sinnvoll ausgewählt werden, wenn all diese Dinge zumindest grob definiert sind.
Ähnliche Arbeit in der Produktion
Das einfache adaptive Parsen wird hier im Labor als Teil der Automatisierung sozialer Netzwerke ausgeführt, jedoch nur für begrenzte Sätze von Symbolen und sequentiellen Mustern. Es lässt sich ohne Neukonfiguration auf beliebig große sprachliche Basiseinheiten, Präfixe, Endungen und Suffixe skalieren, die nur durch unsere Hardwarekapazitäten und unseren Durchsatz begrenzt sind. Das Vorhandensein von Bibliotheken für reguläre Ausdrücke war hilfreich, um das Design einfach zu halten. Wir verwenden die Bibliothek der PCRE Version 8-Serie, die von einer ansiotropen Form von DCNN gespeist wird, zur Merkmalsextraktion aus einem Fenster, das sich mit einer konfigurierbaren Fenstergröße und Verschiebungsinkrementgröße durch den Eingabetext bewegt. Heuristiken, die auf in einem ersten Durchgang gesammelte Eingabetextstatistiken angewendet werden, erzeugen einen Satz hypothetischer PCREs, die in zwei Schichten angeordnet sind.
Die Optimierung erfolgt, um bei einer chaotisch gestörten Textsuche höhere Wahrscheinlichkeitsgewichte auf die besten PCREs anzuwenden. Es verwendet die gleichen Konvergenzstrategien für den Gradientenabstieg, die bei der NN-Rückausbreitung im Training verwendet werden. Es ist ein naiver Ansatz, der keine Annahmen wie das Vorhandensein von Rückspuren, Dateien oder Fehlern trifft. Es würde sich gleichermaßen an arabische und spanische Botschaften anpassen.
Die Ausgabe ist ein beliebig gerichteter Graph im Speicher, der einem Speicherauszug einer objektorientierten Datenbank ähnelt.
قنبلة -> dangereux -> 4anlyss
bomba -> dangereux
ambiguïté -> 4anlyss -> préemption -> قنبلة
Obwohl ein Wiedereintrittsalgorithmus für eine Verstärkungsversion abgestumpft ist und das Wellness-Signal bereits verfügbar ist, haben andere Arbeiten die Weiterentwicklung des adaptiven Parsers oder die Arbeit am nächsten Schritt zur Verwendung der Arbeit für die natürliche Sprache verhindert: Anpassen der gerichteten Graphen an persistente gerichtete Graphen Filter, die Ideen darstellen, die den Aspekt der Ideenerinnerung des Sprachverständnisses nachahmen würden.
Letzte Kommentare
Das System verfügt über Komponenten und Prozessarchitekturen, die dem Protokollanalyseproblem ähneln, und beweist die oben aufgeführten Konzepte. Je unorganisierter die Protokollierung zwischen den Entwicklern des Systems ist, das die Protokollierung durchführt, desto schwieriger ist es für einen Menschen oder künstlichen Agenten natürlich, die Einträge zu eindeutig zu machen. Einige Systemprotokolle waren so lange so schlecht in der Qualitätskontrolle, dass das Protokoll nahezu unbrauchbar ist.