View a markdown version of this page

Alarme protokollieren - Amazon CloudWatch
Wie funktionieren Log AlarmsLebenszyklus für verwaltete geplante AbfragenAlarm-Konfiguration protokollierenLog-AbfrageAggregationsausdrückeMulti-contributor AlarmeFehlende DatenbehandlungDie Auswertung gibt anAlarm-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, wechselt der Alarm in den ALARM Status und führt konfigurierte Aktionen aus.

Im Gegensatz zu metrischen Alarmen, für die Metrikfilter als Zwischenschritt erforderlich sind, werten Log-Alarme die Protokolldaten direkt aus und verwenden dabei dieselbe Logs Insights-Abfragesprache, die Sie für Ad-hoc-Analysen verwenden.

Wie funktionieren Log Alarms

In den folgenden Schritten wird beschrieben, wie ein Log Alarm funktioniert:

  1. Sie erstellen einen Protokollalarm 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 anhand der M-out-of-N Auswertung der letzten Abfrageausführungen aus.

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

Anmerkung

Log Alarms werten die letzten N Abfrageausführungen aus. Der Alarm wird ausgelöst, ALARM wenn M dieser N Ausführungen den Schwellenwert überschreiten.

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

Lebenszyklus für verwaltete geplante Abfragen

Wenn Sie einen Protokollalarm 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 ist mit den folgenden Parametern konfiguriert:

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

  • LogGroupIdentifierssind die Protokollgruppen, die abgefragt werden sollen. Geben Sie entweder Protokollgruppennamen oder Protokollgruppen-ARNs an.

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

  • AggregationExpressiondefiniert, wie Abfrageergebnisse für die Schwellenwertauswertung zu einem numerischen Wert aggregiert 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 einen Abstand von der aktuellen Uhrzeit in Sekunden.

  • ComparisonOperatorgibt an, 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 letzten auszuwertenden Abfrageausführungen (N in M-out-of-N).

  • QueryResultsToAlarmist die Anzahl der Ergebnisse eines Sicherheitsverstoßes, die ausgelöst werden müssen ALARM (M in M-out-of-N).

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

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

Log-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 innerhalb des durch StartTimeOffset und definierten Zeitraums 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 Schwellenwertauswertung 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.

Unterstützte Aggregationsfunktionen
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) Minimaler Wert des angegebenen Feldes. min(latency)
max(field) Maximalwert des angegebenen Feldes. max(latency)

Die bin() Funktion wird in der by Klausel für den Aggregationsausdruck 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 aus. Der Alarm geht in den ALARM Status über, wenn ein Mitwirkender den Schwellenwert überschreitet.

Der folgende Ausdruck gruppiert beispielsweise die Anzahl der Fehler nach dem Dienstnamen:

count(*) by serviceName

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

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

  • Maximal 5 Felder in der by Klausel.

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

  • Maximal 100 Mitwirkende werden gleichzeitig im ALARM Status erfasst.

Standardmäßig sind die Mitwirkenden alphabetisch sortiert und nur die ersten 500 werden pro Abfrageausführung 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 Durch die Sortierung wird sichergestellt, 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 verstoßendem Mitwirkenden). Systems Manager OpsItem Manager-Aktionen werden auf der Alarmebene ausgeführt.

Anmerkung

Systems Manager Incident Manager und Ermittlungsaktionen werden für Protokollalarme nicht unterstützt.

Wenn ein Mitwirkender aus den Abfrageergebnissen verschwindet (z. B. wenn eine kurzlebige Ressource beendet wird), wechselt dieser Mitwirkende unabhängig von der Einstellung für die fehlende Datenbehandlung 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 keine Protokollereignisse im Abfragezeitraum.

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

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

  • Das Feld, auf das im Aggregationsausdruck verwiesen wurde, war in den Abfrageergebnissen nicht vorhanden. Beispiel: count(error-codes) error-codes Wo ist in den zurückgegebenen Protokollereignissen nicht vorhanden.

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

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.

Fehlende Daten, Behandlungsmöglichkeiten
Wert Behavior
missing Behandeln Sie den Datenpunkt als fehlend. Dies ist die Standardeinstellung.
notBreaching Behandeln Sie den fehlenden Datenpunkt so, als ob er den Schwellenwert nicht überschreitet.
breaching Behandeln Sie den fehlenden Datenpunkt als Überschreitung des Schwellenwerts.
ignore Ignorieren Sie den fehlenden Datenpunkt und werten Sie nur verfügbare Daten aus.

Die Auswertung gibt an

Zusätzlich zu den Status Standard OKALARM, und INSUFFICIENT_DATA kann Log Alarms die folgenden Bewertungsstatus vor EvaluationState Ort melden. Diese Status bieten zusätzlichen Kontext darüber, warum sich der Alarm in seinem aktuellen Status befindet.

Status der Alarmauswertung protokollieren
Status Description
EVALUATION_FAILURE Ein vorübergehendes CloudWatch Serviceproblem verhinderte die Auswertung. Dies kann auftreten, wenn der Dienst aufgrund von Dienstfehlern 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 auf Fehler bei allen Abfrageergebnissen zurückzuführen sein. Der Alarm wird auf „INSUFFICIENT_DATASofort“ umgestellt. Einzelheiten entnehmen Sie dem StateReason Feld.
PARTIAL_DATA Bei der Abfrage wurden die maximal 500 Teilnehmergruppen zurückgegeben, es wurden jedoch mehr 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, wird der Alarm solange aktiviert, INSUFFICIENT_DATA bis genügend neue Datenpunkte erfasst wurden. Änderungen am Schwellenwert oder an den M-out-of-N Werten lösen diesen Reset nicht aus.

Aktionen und Benachrichtigungen

Log Alarms unterstützen die folgenden Aktionen:

  • Amazon-SNS-Benachrichtigungen

  • Aufrufe von Lambda-Funktionen

  • OpsItem Erstellung eines Systems Manager

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

Wenn ein Protokollalarm den Status wechselt, enthält die Aktionsbenachrichtigung die folgenden Informationen:

  • Standardinformationen zur Änderung der Alarmkonfiguration (Alarmname, Beschreibung, Konfigurationsdetails).

  • Informationen zur Statusänderung (neuer Status, Grund für den Status, Zeitstempel).

  • 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 SNS-E-Mail-Benachrichtigung für einen Log Alarm mit einem einzigen Wert (ohne BY Klausel):

{
    "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 SNS-E-Mail-Benachrichtigung für einen Log Alarm mit mehreren Mitwirkenden (mit einer BY Klausel). Jeder Mitarbeiter, der gegen einen Verstoß 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...
}

Einschließlich 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 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 SNS-Nachrichten offengelegt werden. Überprüfen Sie Ihren Protokollinhalt, bevor Sie diese Funktion aktivieren.

Um Protokollzeilen einzubeziehen, muss die Rolle „Protokollzeilen“ über die logs:GetQueryResults entsprechende Berechtigung verfügen. Die Anzahl der in einer Benachrichtigung enthaltenen Protokollzeilen ist durch die angeforderte Anzahl, die verfügbaren Gesamtergebnisse und die Größenbeschränkung der Amazon SNS SNS-Nutzlast begrenzt.

Bewährte Methoden und Problembehebung

Bewährte Methoden

Optimierung der 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.

  • Begrenzen Sie die Abfragezeitbereiche (StartTimeOffset), um Timeouts bei Protokollgruppen mit hohem Volumen zu vermeiden.

  • Verwenden Sie Feldindizes, um die Abfrageleistung zu optimieren.

Planung planen

  • Wählen Sie eine Zeitplanhäufigkeit, 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, die Auswertung unvollständiger Daten zu vermeiden.

  • Verteilen Sie Log Alarm-Zeitpläne auf Ihr Konto, um zu vermeiden, dass die Grenzwerte für die Parallelität bei geplanten Abfragen überschritten werden. Die Anzahl der gleichzeitigen Abfrageausführungen in Ihrem Konto darf 100 nicht überschreiten. Berücksichtigen Sie dieses Kontingent, wenn Sie mehrere Protokollalarme mit sich überschneidenden Zeitplänen erstellen.

Einstellung der Schwellenwerte

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

  • Stellen Sie bei Ereignissen mit geringer Dichte (z. B. selten auftretende Fehler) die Einstellung TreatMissingData auf notBreaching ein, sodass der Alarm im Status OK bleibt, wenn keine Protokolle übereinstimmen.

  • Bei kontinuierlichen Signalen (z. B. Verkehrsprotokollen) sollten Sie die Einstellung TreatMissingData so einstellen, dass erkannt wird, wann die erwarteten Protokolldaten nicht mehr eintreffen. breaching

Multi-contributor Design

  • Wählen Sie aussagekräftige Felder für die BY-Klausel aus, die unterschiedliche Ressourcen oder Dimensionen darstellen, die Sie unabhängig ü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
Für die Rolle zur geplanten Abfrageausführung fehlen die erforderlichen Berechtigungen Stellen Sie sicherlogs:StartQuery, dass die Rollelogs:StopQuery,logs:GetQueryResults, und die logs:DescribeLogGroups Berechtigungen auf die richtigen Protokollgruppen beschränkt sind.
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 Bewertungsfenster 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 Protokollkonsole, 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 lautet, stellen Sie sicheravg(latency), dass die Abfrage ein latency Feld erzeugt. Wenn das Feld nicht vorhanden ist, wird das Ergebnis als fehlende Daten behandelt.
Verzögerung bei der Datenaufnahme protokollieren

Eine geplante Abfrage kann nur Protokollereignisse auswerten, die zum Zeitpunkt ihrer Ausführung erfasst 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 Ereignisse für das von Ihnen abgefragte Fenster immer noch aufgenommen werden, wird die Abfrage ausgeführt, bevor sie verfügbar sind, und überspringt sie.

Verwenden Sie diese OptionEndTimeOffset, 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 dem Eintreten der Ereignisse abfragbar sind.

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

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

Der Alarm zeigt EVALUATION_ERROR

Dies weist auf ein Problem mit der Client-Konfiguration hin. Überprüfen Sie das StateReason Feld auf Einzelheiten. Häufige Ursachen:

  • Ungültige oder falsch formatierte Abfragesyntax.

  • Unzureichende Berechtigungen für die Rolle zur geplanten Abfrageausführung.

  • Alle Abfrageausführungen schlugen fehl (z. B. entzogene Protokollgruppenberechtigungen).

Der Alarm zeigt EVALUATION_FAILURE

Dies deutet 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 anhält, überprüfen Sie das CloudWatch Service-Integritäts-Dashboard.

Der Alarm zeigt PARTIAL_DATA

Bei der Abfrage wurden die maximal 500 Teilnehmergruppen zurückgegeben, 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 logs:GetQueryResults Rechte der Rolle „Protokollzeilen“ auf die richtigen Protokollgruppen beschränkt sind.

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

  • Abfragen, die unmask() keine Protokollzeilen in Benachrichtigungen enthalten dürfen (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.