Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Erkennung von Protokollanomalien
Sie können für jede Protokollgruppe einen Detektor für Protokollanomalien erstellen. Der Anomaliedetektor scannt die in die Protokollgruppe aufgenommenen Protokollereignisse und findet Anomalien in den Protokolldaten. Die Anomalieerkennung nutzt maschinelles Lernen und Mustererkennung, um Basiswerte für typische Protokollinhalte zu erstellen.
Nachdem Sie einen Anomaliedetektor für eine Protokollgruppe erstellt haben, trainiert er anhand der Protokollereignisse der letzten zwei Wochen in der Protokollgruppe. Die Trainingszeit kann bis zu 15 Minuten dauern. Nach Abschluss der Schulung werden eingehende Protokolle analysiert, um Anomalien zu identifizieren. Die Anomalien werden dann in der CloudWatch Protokollkonsole angezeigt, sodass Sie sie untersuchen können.
CloudWatch Die Protokollmustererkennung extrahiert Protokollmuster, indem statische und dynamische Inhalte in Ihren Protokollen identifiziert werden. Muster sind nützlich für die Analyse großer Protokollsätze, da eine große Anzahl von Protokollereignissen oft in wenige Muster komprimiert werden kann.
Sehen Sie sich beispielsweise das folgende Beispiel mit drei Protokollereignissen an.
2023-01-01 19:00:01 [INFO] Calling DynamoDB to store for resource id 12342342k124-12345 2023-01-01 19:00:02 [INFO] Calling DynamoDB to store for resource id 324892398123-12345 2023-01-01 19:00:03 [INFO] Calling DynamoDB to store for resource id 3ff231242342-12345
Im vorherigen Beispiel folgen alle drei Protokollereignisse einem Muster:
<*> <*> [INFO] Calling DynamoDB to store for resource id <*>
Felder innerhalb eines Musters werden als Token bezeichnet. Felder, die innerhalb eines Musters variieren, z. B. eine Anforderungs-ID oder ein Zeitstempel, werden als dynamische Token bezeichnet. Dynamische Token werden dargestellt<*>, wenn CloudWatch Logs das Muster anzeigt. Jeder unterschiedliche Wert, der für ein dynamisches Token gefunden wird, wird als Tokenwert bezeichnet.
Zu den häufigsten Beispielen für dynamische Token gehören Fehlercodes, Zeitstempel und Anforderungs-IDs.
Die Erkennung von Protokollanomalien verwendet diese Muster, um Anomalien zu finden. Nach der Trainingszeit für das Modell des Anomaliedetektors werden die Protokolle anhand bekannter Trends bewertet. Der Anomaliedetektor kennzeichnet signifikante Schwankungen als Anomalien.
Für die Erstellung von Protokollanomaliedetektoren fallen keine Gebühren an.
Schweregrad und Priorität von Anomalien und Mustern
Jeder Anomalie, die von einem Log-Anomaliedetektor gefunden wird, wird eine Priorität zugewiesen. Jedem gefundenen Muster wird ein Schweregrad zugewiesen.
Die Priorität wird automatisch berechnet und basiert sowohl auf dem Schweregrad des Musters als auch auf dem Ausmaß der Abweichung von den erwarteten Werten. Wenn beispielsweise ein bestimmter Token-Wert plötzlich um 500% steigt, kann diese Anomalie als
HIGHPriorität eingestuft werden, auch wenn ihr SchweregradNONEDer Schweregrad basiert nur auf Schlüsselwörtern, die in den Mustern wie
FATALERROR, und vorkommen.WARNWenn keines dieser Schlüsselwörter gefunden wird, wird der Schweregrad eines Musters als gekennzeichnetNONE.
Sichtbarkeit und Zeit der Anomalie
Wenn Sie einen Anomaliedetektor erstellen, geben Sie die maximale Sichtbarkeitsdauer für Anomalien an. Dies ist die Anzahl der Tage, an denen die Anomalie in der Konsole angezeigt und durch den ListAnomaliesAPI-Vorgang zurückgegeben wird. Wenn diese Zeitspanne für eine Anomalie verstrichen ist und sie weiterhin auftritt, wird sie automatisch als normales Verhalten akzeptiert, und das Anomaliedetektormodell markiert sie nicht mehr als Anomalie.
Wenn Sie die Sichtbarkeitszeit bei der Erstellung eines Anomaliedetektors nicht anpassen, werden 21 Tage als Standard verwendet.
Unterdrückung einer Anomalie
Nachdem eine Anomalie gefunden wurde, können Sie wählen, ob sie vorübergehend oder dauerhaft unterdrückt werden soll. Das Unterdrücken einer Anomalie bewirkt, dass der Anomaliedetektor dieses Ereignis für den von Ihnen angegebenen Zeitraum nicht mehr als Anomalie kennzeichnet. Wenn Sie eine Anomalie unterdrücken, können Sie wählen, ob Sie nur diese spezifische Anomalie oder alle Anomalien unterdrücken möchten, die mit dem Muster zusammenhängen, in dem die Anomalie gefunden wurde.
Sie können unterdrückte Anomalien weiterhin in der Konsole anzeigen. Sie können sich auch dafür entscheiden, sie nicht mehr zu unterdrücken.
Häufig gestellte Fragen
AWS Verwendet es meine Daten, um Algorithmen für maschinelles Lernen für den AWS Gebrauch oder für andere Kunden zu trainieren?
Nein. Das durch das Training erstellte Modell zur Erkennung von Anomalien basiert auf den Protokollereignissen in einer Protokollgruppe und wird nur innerhalb dieser Protokollgruppe und dieses AWS Kontos verwendet.
Welche Arten von Protokollereignissen eignen sich gut für die Erkennung von Anomalien?
Die Erkennung von Protokollanomalien eignet sich gut für: Anwendungsprotokolle und andere Protokolltypen, bei denen die meisten Protokolleinträge typischen Mustern entsprechen. Protokollgruppen mit Ereignissen, die Schlüsselwörter für die Protokollebene oder den Schweregrad enthalten, wie INFO, ERROR und DEBUG, eignen sich besonders gut für die Erkennung von Protokollanomalien.
Die Erkennung von Protokollanomalien ist nicht geeignet für: Protokollereignisse mit extrem langen JSON-Strukturen, wie z. B. Logs. CloudTrail Die Musteranalyse analysiert nur die ersten 1500 Zeichen einer Protokollzeile, sodass alle Zeichen, die diese Grenze überschreiten, übersprungen werden.
Audit- oder Zugriffsprotokolle, wie z. B. VPC-Flow-Logs, werden bei der Erkennung von Anomalien ebenfalls weniger Erfolg haben. Die Anomalieerkennung dient der Erkennung von Anwendungsproblemen und ist daher möglicherweise nicht für Netzwerk- oder Zugriffsanomalien geeignet.
Um festzustellen, ob ein Anomaliedetektor für eine bestimmte Protokollgruppe geeignet ist, verwenden Sie die CloudWatch Protokollmusteranalyse, um die Anzahl der Muster in den Protokollereignissen in der Gruppe zu ermitteln. Wenn die Anzahl der Muster nicht mehr als etwa 300 beträgt, funktioniert die Erkennung von Anomalien möglicherweise gut. Weitere Informationen zur Musteranalyse finden Sie unterMusteranalyse.
Was wird als Anomalie gekennzeichnet?
Die folgenden Ereignisse können dazu führen, dass ein Protokollereignis als Anomalie gekennzeichnet wird:
Ein Protokollereignis mit einem Muster, das in der Protokollgruppe noch nie zuvor beobachtet wurde.
Eine signifikante Abweichung von einem bekannten Muster.
Ein neuer Wert für ein dynamisches Token mit einem diskreten Satz üblicher Werte.
Eine starke Änderung der Häufigkeit, mit der ein Wert für ein dynamisches Token vorkommt.
Obwohl alle oben genannten Punkte möglicherweise als Anomalien gekennzeichnet werden, bedeuten sie nicht alle, dass die Anwendung schlecht funktioniert. Beispielsweise könnten eine higher-than-usual Reihe von 200 Erfolgswerten als Anomalie gekennzeichnet werden. In Fällen wie diesem könnten Sie erwägen, diese Anomalien zu unterdrücken, die nicht auf Probleme hinweisen.
Was passiert mit sensiblen Daten, die maskiert werden?
Alle Teile von Protokollereignissen, die als sensible Daten maskiert sind, werden nicht auf Anomalien überprüft. Weitere Informationen zum Maskieren vertraulicher Daten finden Sie unter Hilfe zum Schutz vertraulicher Protokolldaten durch Maskierung.
