View a markdown version of this page

Alarme protokollieren - Amazon CloudWatch
So funktionieren Log-AlarmeLebenszyklus verwalteter zeitgesteuerter AbfragenAlarm-Konfiguration protokollierenProtokolliert die AbfrageAggregationsausdrückeMulti-contributor AlarmeFehlende DatenbehandlungStatus der BewertungAlarm-UpdateAktionen und BenachrichtigungenBewährte Methoden und Problembehebung

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.

Alarme protokollieren

Ein Log Alarm überwacht die Ergebnisse einer CloudWatch Logs Insights-Abfrage, die nach einem Zeitplan mithilfe einer geplanten Abfrage ausgeführt wird. Der Alarm wendet einen Aggregationsausdruck auf die Abfrageergebnisse an, um einen numerischen Wert zu erzeugen. Wenn dieser aggregierte Wert einen konfigurierten Schwellenwert überschreitet, geht der Alarm in den ALARM Status über und führt konfigurierte Aktionen aus.

Im Gegensatz zu Metrikalarmen, für die als Zwischenschritt Metrikfilter erforderlich sind, werden Log-Alarme direkt anhand der Log-Daten ausgewertet. Dabei wird dieselbe Logs Insights-Abfragesprache verwendet, die Sie für Ad-hoc-Analysen verwenden.

So funktionieren Log-Alarme

Die folgenden Schritte beschreiben, wie ein Log Alarm funktioniert:

  1. Sie erstellen einen Log-Alarm mit einer Abfrage, einem Aggregationsausdruck, einem Zeitplan und einem Schwellenwert.

  2. CloudWatch erstellt automatisch eine AWS verwaltete geplante Abfrage, die Ihre Abfrage nach dem angegebenen Zeitplan ausführt.

  3. Jede Abfrageausführung erzeugt aggregierte Ergebnisse (ein einzelner Wert oder mehrere Mitwirkende).

  4. CloudWatch wertet die aggregierten Ergebnisse anhand Ihres Schwellenwerts aus, wobei die zuletzt ausgeführten Abfragen M-out-of-N ausgewertet werden.

  5. Wenn der Schwellenwert überschritten wird, geht der Alarm in den ALARM Status über und führt Ihre konfigurierten Aktionen aus (z. B. Amazon SNS-Benachrichtigungen).

Anmerkung

Log Alarms werten die letzten N Abfrageausführungen aus. Der Alarm geht über, ALARM wenn M dieser N Ausführungen den Schwellenwert überschreiten.

Informationen zum Erstellen eines Log-Alarms finden Sie unterErstellen Sie einen Log-Alarm.

Lebenszyklus verwalteter zeitgesteuerter Abfragen

Wenn Sie einen Log-Alarm erstellen, CloudWatch wird automatisch eine AWS verwaltete geplante Abfrage erstellt, die Ihre Abfrage nach dem angegebenen Zeitplan ausführt. Sie müssen die geplante Abfrage nicht separat erstellen.

Die AWS verwaltete geplante Abfrage weist die folgenden Merkmale auf:

  • Sie ist in der CloudWatch Logs-Konsole unter Geplante Abfragen sichtbar.

  • Sie können es nicht direkt ändern. Um die Abfrage oder ihre Konfiguration zu ändern, aktualisieren Sie den Log Alarm.

  • CloudWatch löscht die AWS verwaltete geplante Abfrage, wenn Sie den Alarm löschen.

Alarm-Konfiguration protokollieren

Ein Log-Alarm wird mit den folgenden Parametern konfiguriert:

  • QueryStringist die CloudWatch Logs Insights-Abfrage, die ausgeführt werden soll.

  • LogGroupIdentifierssind die abzufragenden Protokollgruppen. Geben Sie entweder Protokollgruppennamen oder Protokollgruppen-ARNs an.

  • ScheduledQueryRoleARNist der ARN der IAM-Rolle, die es CloudWatch Logs ermöglicht, die geplante Abfrage in Ihrem Namen auszuführen.

  • AggregationExpressiondefiniert, wie Abfrageergebnisse zu einem numerischen Wert für die Schwellenwertbewertung zusammengefasst werden.

  • ScheduleExpressiondefiniert, wie oft die Abfrage ausgeführt wird (z. B.rate(5 minutes)).

  • StartTimeOffsetdefiniert das Lookback-Fenster in Sekunden für jede Abfrageausführung.

  • EndTimeOffsetdefiniert das Ende des Abfragezeitbereichs als Offset in Sekunden gegenüber der aktuellen Uhrzeit.

  • ComparisonOperatorist die Art und Weise, wie aggregierte Ergebnisse mit dem Schwellenwert verglichen werden. Zulässige Werte: GreaterThanThreshold, GreaterThanOrEqualToThreshold, LessThanThreshold, LessThanOrEqualToThreshold.

  • Der Schwellenwert ist der numerische Wert, mit dem verglichen werden soll.

  • QueryResultsToEvaluateist die Anzahl der zuletzt auszuwertenden Abfrageausführungen (N in M-out-of-N).

  • QueryResultsToAlarmist die Anzahl der Sicherheitsergebnisse, die zum Auslösen von Sicherheitsverletzungen erforderlich sind ALARM (M in M-out-of-N).

  • TreatMissingDatadefiniert, wie fehlende Abfrageergebnisse bei der Auswertung behandelt werden.

Eine vollständige Liste der Parameter und Anweisungen zur Erstellung finden Sie unterErstellen Sie einen Log-Alarm.

Protokolliert die Abfrage

Die Log-Alarm-Abfrage ist eine CloudWatch Logs Insights-Abfrage, die die auszuwertenden Protokolldaten auswählt und filtert. Die Abfrage wird für die in angegebenen Protokollgruppen LogGroupIdentifiers über den durch StartTimeOffset und definierten Zeitraum ausgeführtEndTimeOffset.

Die Abfrage verwendet die CloudWatch Logs Insights-Abfragesyntax. Richtlinien zum Schreiben effizienter Abfragen für Log Alarms finden Sie unterBewährte Methoden und Problembehebung.

Aggregationsausdrücke

Der Aggregationsausdruck definiert, wie Abfrageergebnisse zu einem numerischen Wert für die Schwellenwertbewertung CloudWatch zusammengefasst werden. Der Ausdruck verwendet dieselbe Syntax wie der stats Befehl in CloudWatch Logs Insights.

Die Syntax für einen Aggregationsausdruck lautet wie folgt:

statistic_func_expression [by field1, field2, ...] [| sort asc|desc]

Sie können nur einen einzigen Aggregationsausdruck angeben. In der folgenden Tabelle sind die unterstützten Aggregationsfunktionen aufgeführt.

Funktion Description Beispiel
count(*) Anzahl aller übereinstimmenden Protokollzeilen. count(*)
avg(field) Durchschnittswert des angegebenen Feldes. avg(duration)
sum(field) Summe des angegebenen Feldes. sum(bytesSent)
min(field) Mindestwert des angegebenen Feldes. min(latency)
max(field) Maximalwert des angegebenen Feldes. max(latency)

Die bin() Funktion wird in der by Klausel für Aggregationsausdrücke nicht unterstützt. Sie können sie jedoch bin() in der Abfragezeichenfolge selbst verwenden.

Multi-contributor Alarme

Wenn Sie eine by Klausel in Ihren Aggregationsausdruck aufnehmen, wertet der Alarm jede eindeutige Kombination von Feldwerten (als Mitwirkender bezeichnet) unabhängig voneinander aus. Der Alarm geht in den ALARM Status über, wenn ein Mitwirkender den Schwellenwert überschreitet.

Beispielsweise gruppiert der folgende Ausdruck die Fehleranzahl nach Dienstnamen:

count(*) by serviceName

Jeder Einzelwert von serviceName wird unabhängig vom Schwellenwert bewertet. Wenn ein Dienst bei M von N Abfrageausführungen den Schwellenwert überschreitet, geht der Alarm in den ALARM Status über.

Die folgenden Grenzwerte gelten für Alarme mit mehreren Teilnehmern:

  • Maximal 5 Felder in der by Klausel.

  • Pro Abfrageausführung werden maximal 500 Ergebnisse für Mitwirkende zurückgegeben.

  • Maximal 100 Mitwirkende werden gleichzeitig im ALARM Status erfasst.

Standardmäßig werden die Mitwirkenden alphabetisch sortiert und pro Abfrageausführung werden nur die ersten 500 zurückgegeben. Um die Mitwirkenden stattdessen nach ihrem aggregierten Wert zu sortieren, geben Sie | sort asc oder | sort desc in Ihrem Aggregationsausdruck an (z. B.). avg(latency) by serviceName | sort desc Value-based Die Sortierung stellt sicher, dass die wichtigsten Mitwirkenden zuerst bewertet werden, wenn die Gesamtzahl 500 übersteigt.

Bei Alarmen mit mehreren Mitwirkenden werden Amazon SNS- und Lambda-Aktionen auf der Ebene der Mitwirkenden ausgeführt (einmal pro Verursacher des Verstoßes). Systems OpsItem Manager-Aktionen werden auf der Alarmebene ausgeführt.

Anmerkung

Incident Manager- und Ermittlungsaktionen von Systems Manager werden für Log-Alarme nicht unterstützt.

Wenn ein Mitwirkender aus den Abfrageergebnissen verschwindet (z. B. wenn eine temporäre Ressource beendet wird), wechselt dieser Mitwirkende unabhängig von der fehlenden Datenbehandlungseinstellung in den OK Status.

Fehlende Datenbehandlung

Fehlende Daten treten auf, wenn eine geplante Abfrageausführung keinen Wert ergibt, der anhand des Schwellenwerts ausgewertet werden kann. Dies ist in den folgenden Fällen möglich:

Keine Protokolle vorhanden — Die Protokollgruppe enthält im Abfragezeitraum keine Protokollereignisse.

Die Abfrage gibt keine zutreffenden Ergebnisse zurück — Es sind zwar Protokolle vorhanden, aber der Aggregationsausdruck kann keinen Wert ergeben. Das passiert, wenn:

  • Gemäß dem Abfragefilter waren keine passenden Abfrageergebnisse vorhanden.

  • Das Feld, auf das im Aggregationsausdruck verwiesen wird, war in den Abfrageergebnissen nicht vorhanden. Beispielsweise, count(error-codes) wo in den zurückgegebenen Protokollereignissen error-codes nicht vorhanden ist.

Beachten Sie, dass count(*) bei einer leeren Ergebnismenge 0 zurückgegeben wird. Dies ist ein gültiger Datenpunkt, der nicht als fehlend behandelt wird.

Mithilfe des Parameters können Sie konfigurieren, wie der Alarm mit fehlenden Daten umgeht. TreatMissingData In der folgenden Tabelle werden die verfügbaren Optionen beschrieben.

Wert Behavior
missing Behandeln Sie den Datenpunkt als fehlend. Das ist die Standardeinstellung.
notBreaching Behandeln Sie den fehlenden Datenpunkt so, als ob er den Schwellenwert nicht überschreitet.
breaching Behandeln Sie den fehlenden Datenpunkt so, als ob er den Schwellenwert überschreitet.
ignore Ignorieren Sie den fehlenden Datenpunkt und werten Sie nur verfügbare Daten aus.

Status der Bewertung

Zusätzlich zum Standard OK und den INSUFFICIENT_DATA Zuständen kann Log Alarms die folgenden Evaluierungszustände vor EvaluationState Ort melden. ALARM Diese Status bieten zusätzlichen Kontext darüber, warum sich der Alarm in seinem aktuellen Status befindet.

Status Description
EVALUATION_FAILURE Ein vorübergehendes CloudWatch Serviceproblem verhinderte die Bewertung. Dies kann auftreten, wenn der Dienst aufgrund von Servicefehlern Probleme bei der Auswertung von Abfrageergebnissen hat oder wenn einige (aber nicht alle) Abfrageergebnisse fehlgeschlagen sind. Der Alarm geht über zuINSUFFICIENT_DATA. Wir empfehlen eine manuelle Überwachung, bis das Problem behoben ist.
EVALUATION_ERROR Ein Fehler in der Client-Konfiguration verhinderte die Evaluierung. Dies kann auf unzureichende Berechtigungen, eine ungültige Abfrage oder darauf zurückzuführen sein, dass alle Abfrageergebnisse fehlgeschlagen sind. Der Alarm geht auf „INSUFFICIENT_DATASofort“ über. Einzelheiten finden Sie in dem StateReason Feld.
PARTIAL_DATA Die Abfrage gab die maximal 500 Teilnehmergruppen zurück, es wurden jedoch mehr Treffer gefunden. Der Alarm bewertet die verfügbaren Mitwirkenden, aber die Ergebnisse sind möglicherweise unvollständig.

Alarm-Update

Wenn Sie die Abfrage, den Aggregationsausdruck, den Zeitplan oder die Protokollgruppen eines Log-Alarms aktualisieren, geht der Alarm so lange über, INSUFFICIENT_DATA bis genügend neue Datenpunkte erfasst wurden. Änderungen des Schwellenwerts oder der M-out-of-N Werte lösen diesen Reset nicht aus.

Aktionen und Benachrichtigungen

Log Alarms unterstützt die folgenden Aktionen:

  • Amazon-SNS-Benachrichtigungen

  • Aufrufe von Lambda-Funktionen

  • Erstellung von Systems Manager OpsItem

Die vollständige Matrix zur Unterstützung von Aktionen finden Sie unterAlarmaktionen.

Wenn ein Log-Alarm den Status wechselt, enthält die Aktionsbenachrichtigung die folgenden Informationen:

  • Informationen zur Änderung der Standardkonfiguration des Alarms (Alarmname, Beschreibung, Konfigurationsdetails).

  • Informationen zur Statusänderung (neuer Status, Grund des Zustands, Zeitstempel).

  • Die E-Mail-Benachrichtigungen von Amazon SNS enthalten auch einen Deep-Link zur CloudWatch Logs Insights-Konsole, in der die vollständigen Abfrageergebnisse angezeigt werden.

Das folgende Beispiel zeigt eine Amazon SNS-E-Mail-Benachrichtigung für einen Log Alarm mit einem einzigen Wert (ohne Klausel): BY

{
    "AlarmName": "HighErrorCount",
    "NewStateValue": "ALARM",
    "NewStateReason": "Threshold Crossed: 3 out of the last 5 query results [142.0 (10/06/26 12:15:00), 135.0 (10/06/26 12:10:00), 120.0 (10/06/26 12:05:00)] were greater than the threshold (100.0) (minimum 3 datapoints for OK -> ALARM transition).",
    "NewStateReasonData": {
        "version": "1.0",
        "queryDate": "2026-06-10T12:15:30.000+0000",
        "threshold": 100.0,
        "queryResultsToEvaluate": 5,
        "queryResultsToAlarm": 3,
        "results": [
            {
                "queryResultId": "scheduled-query-execution-id-3",
                "status": "COMPLETE",
                "timestamp": "2026-06-10T12:15:00.000+0000",
                "value": 142.0
            }
            // Additional results...
        ]
    },
    "StateChangeTime": "2026-06-10T12:15:30.000+0000",
    "OldStateValue": "OK"
    // Additional fields...
}

Das folgende Beispiel zeigt eine Amazon SNS-E-Mail-Benachrichtigung für einen Log Alarm mit mehreren Mitwirkenden (mit einer Klausel). BY Jeder Mitwirkende, der gegen die Datenschutzverletzung verstößt, generiert eine separate Benachrichtigung:

{
    "AlarmName": "EndpointLatency",
    "NewStateValue": "ALARM",
    "NewStateReason": "5 out of 10 contributors evaluated to ALARM",
    "StateChangeTime": "2026-06-10T12:20:15.000+0000",
    "OldStateValue": "OK",
    "AlarmContributorId": "a1b2c3d4e5f6g7h8",
    "AlarmContributorAttributes": {
        "endpoint": "/api/orders"
    }
    // Additional fields...
}

Einbeziehen von Protokollzeilen in Benachrichtigungen

Sie können optional Protokollzeilen mit unformatierten Abfrageergebnissen in Alarmbenachrichtigungen einbeziehen, indem Sie den ActionLogLineCount Parameter auf einen Wert zwischen 1 und 50 setzen. Dies sind die zugrunde liegenden Protokollereignisse, anhand derer der Aggregationsausdruck ausgewertet wird, nicht die aggregierten Werte. Der Standardwert ist 0, was bedeutet, dass keine Protokollzeilen enthalten sind.

Anmerkung

Protokollzeilen sind nur in Amazon SNS-E-Mail-Benachrichtigungen enthalten. Lambda-Aktionen enthalten keine Protokollzeilen in ihren Payloads.

Wichtig

Wenn Sie Protokollzeilen in Benachrichtigungen aufnehmen, können vertrauliche Daten aus Ihren Protokollen in Amazon SNS-Nachrichten preisgegeben werden. Überprüfen Sie den Inhalt Ihres Protokolls, bevor Sie diese Funktion aktivieren.

Um Protokollzeilen einzubeziehen, muss die Loglines-Rolle über die logs:GetQueryResults entsprechende Berechtigung verfügen. Die Anzahl der Protokollzeilen, die in einer Benachrichtigung enthalten sind, wird durch die angeforderte Anzahl, die verfügbaren Gesamtergebnisse und die Amazon SNS-Nutzlastgrößenbeschränkung begrenzt.

Bewährte Methoden und Problembehebung

Bewährte Methoden

Optimierung von Abfragen

  • Testen Sie Abfragen manuell in CloudWatch Logs Insights, bevor Sie sie in einem Log Alarm verwenden, um die Leistung und die erwarteten Ergebnisse zu überprüfen.

  • Verwenden Sie zu Beginn Ihrer Abfrage Filterbefehle, um das Volumen der verarbeiteten Daten zu reduzieren.

  • Beschränken Sie Abfragezeitbereiche (StartTimeOffset), um Timeouts bei großen Protokollgruppen zu vermeiden.

  • Verwenden Sie Feldindizes, um die Abfrageleistung zu optimieren.

Planung planen

  • Wählen Sie eine Zeitplanfrequenz, mit der Abfragen vor der nächsten Ausführung abgeschlossen werden können. Verwenden Sie für Protokollgruppen mit hohem Volumen längere Intervalle (z. B. 10 Minuten statt 5).

  • Berücksichtigen Sie bei der Einstellung Verzögerungen bei der Protokollaufnahme. StartTimeOffset Eine kleine Lücke zwischen EndTimeOffset und der aktuellen Uhrzeit hilft dabei, die Auswertung unvollständiger Daten zu vermeiden.

  • Verteilen Sie die Zeitpläne für Log-Alarme auf Ihr Konto, um zu vermeiden, dass die Parallelitätsgrenzen für geplante Abfragen überschritten werden. Die Anzahl gleichzeitiger Abfrageausführungen in Ihrem Konto darf 100 nicht überschreiten. Berücksichtigen Sie dieses Kontingent, wenn Sie mehrere Log-Alarme mit sich überschneidenden Zeitplänen erstellen.

Anpassung des Schwellenwerts

  • Beginnen Sie mit höheren Werten QueryResultsToEvaluate (N), um das Alarmgeräusch aufgrund vorübergehender Spitzen zu reduzieren.

  • Stellen Sie bei seltenen Ereignissen (z. B. selten auftretenden Fehlern) den Wert auf ein, TreatMissingData notBreaching um den Alarm im Zustand OK zu belassen, wenn keine Protokolle übereinstimmen.

  • Bei kontinuierlichen Signalen (wie Verkehrsprotokollen) sollten Sie die Einstellung TreatMissingData auf in Betracht ziehen, um breaching zu erkennen, wann die erwarteten Protokolldaten nicht mehr eintreffen.

Multi-contributor entwerfen

  • Wählen Sie aussagekräftige Felder für die BY-Klausel aus, die unterschiedliche Ressourcen oder Dimensionen darstellen, die Sie unabhängig voneinander überwachen möchten.

  • Beachten Sie, dass pro Abfrageausführung nur die ersten 500 Mitwirkenden zurückgegeben werden. Wenn Sie mehr erwarten, schränken Sie Ihre Abfrage ein oder verwenden Sie weniger BY-Klauselfelder.

  • Verwenden Sie das | sort asc Suffix | sort desc oder in Ihrem Aggregationsausdruck, um die höchsten oder niedrigsten Werte auf der Grundlage Ihres Vergleichsoperators zu priorisieren, wenn das Limit von 500 Mitwirkenden erreicht ist.

Fehlerbehebung

Der Alarm bleibt in INSUFFICIENT_DATA

Mögliche Ursache Auflösung
Der Rolle zur Ausführung geplanter Abfragen fehlen die erforderlichen Berechtigungen Stellen Sie sicherlogs:StartQuery, dass die Rolle über logs:StopQuerylogs:GetQueryResults,, und die logs:DescribeLogGroups Berechtigungen für die richtigen Protokollgruppen verfügt.
Die Protokollgruppe ist nicht vorhanden oder wurde gelöscht Stellen Sie sicher, dass die ARNs der Protokollgruppe in der Alarmkonfiguration korrekt und zugänglich sind.
Kürzlich erstellter oder aktualisierter Alarm Nach der Erstellung oder Aktualisierung der Konfiguration verbleibt der Alarm in INSUFFICIENT_DATA, bis genügend Abfrageausführungen abgeschlossen sind, um das Evaluierungsfenster zu erfüllen. M-out-of-N
Die geplante Abfrage wird nicht ausgeführt Überprüfen Sie die AWS verwaltete geplante Abfrage in der CloudWatch Logs-Konsole, um sicherzustellen, dass sie planmäßig ausgeführt wird.
Das Aggregationsfeld ist in den Abfrageergebnissen nicht vorhanden Das Feld, auf das im Aggregationsausdruck verwiesen wird, muss in den Abfrageergebnissen vorhanden sein. Wenn Ihre Aggregation beispielsweise so istavg(latency), stellen Sie sicher, dass die Abfrage ein latency Feld erzeugt. Wenn das Feld nicht vorhanden ist, wird das Ergebnis als fehlende Daten behandelt.
Verzögerung bei der Aufnahme protokollieren

Eine geplante Abfrage kann nur Protokollereignisse auswerten, die zum Zeitpunkt ihrer Ausführung aufgenommen wurden. StartTimeOffsetund EndTimeOffset definieren das Abfragefenster relativ zur Ausführungszeit T — [T − StartTimeOffset, T − EndTimeOffset] —, aber sie berücksichtigen nicht die Verzögerung bei der Aufnahme. Wenn für das Fenster, das Sie abfragen, noch Ereignisse aufgenommen werden, wird die Abfrage ausgeführt, bevor sie verfügbar sind, und überspringt sie.

Wird verwendetEndTimeOffset, um das Fenster so weit nach hinten zu verschieben, dass die Erfassung für den gesamten Bereich abgeschlossen ist.

Beispiel: Angenommen, es dauert bis zu 2 Minuten, bis Protokolle nach Eintreten der Ereignisse abfragbar sind.

  • StartTimeOffset=60, EndTimeOffset=0— Fenster [T−60s, T]. Das Fenster endet zur Ausführungszeit, sodass aktuelle Ereignisse noch nicht aufgenommen wurden und übersehen werden.

  • StartTimeOffset=180, EndTimeOffset=120— Fenster [T−180s, T−120s]. Das Fenster endet 2 Minuten in der Vergangenheit. Zu diesem Zeitpunkt sind alle Ereignisse aufgenommen und auswertbar.

Der Alarm zeigt EVALUATION_ERROR

Dies weist auf ein Problem mit der Client-Konfiguration hin. Einzelheiten finden Sie in dem StateReason Feld. Häufige Ursachen:

  • Ungültige oder falsch formatierte Abfragesyntax.

  • Unzureichende Berechtigungen für die Rolle zur Ausführung geplanter Abfragen.

  • Alle Abfrageausführungen sind fehlgeschlagen (z. B. wurden die Protokollgruppenberechtigungen widerrufen).

Der Alarm zeigt EVALUATION_FAILURE

Dies weist auf ein vorübergehendes CloudWatch Serviceproblem hin. Der Alarm wird automatisch wiederhergestellt, wenn das Problem behoben ist. Wenn das Problem länger als ein paar Minuten andauert, überprüfen Sie das CloudWatch Service-Status-Dashboard.

Der Alarm zeigt PARTIAL_DATA

Die Abfrage gab die maximal 500 Teilnehmergruppen zurück, es wurden jedoch mehr Treffer gefunden. Der Alarm bewertet die verfügbaren Mitwirkenden, aber die Ergebnisse sind möglicherweise unvollständig. Erwägen Sie, Ihre Abfrage einzugrenzen oder die Anzahl der BY-Klauselfelder zu reduzieren.

Protokollzeilen erscheinen nicht in Benachrichtigungen

  • Verify ActionLogLineCount ist auf einen Wert zwischen 1 und 50 eingestellt.

  • Stellen Sie sicher, dass die Rolle „Loglines“ über logs:GetQueryResults Berechtigungen für die richtigen Protokollgruppen verfügt.

  • Protokollzeilen sind nur in Amazon SNS-E-Mail-Benachrichtigungen enthalten. Andere Aktionstypen enthalten keine Protokollzeilen.

  • Abfragen, die verwendet unmask() werden, können keine Protokollzeilen in Benachrichtigungen einbeziehen (bei der Erstellung abgelehnt).

Weitere bewährte Methoden zur Optimierung, Überwachung und Autorisierung von Abfragen finden Sie unter Bewährte Methoden für geplante Abfragen im Amazon CloudWatch Logs-Benutzerhandbuch.