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 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/ScheduledQueries.html) 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.
1. CloudWatch erstellt automatisch eine AWS verwaltete geplante Abfrage, die Ihre Abfrage nach dem angegebenen Zeitplan ausführt.
1. Jede Abfrageausführung erzeugt aggregierte Ergebnisse (ein einzelner Wert oder mehrere Mitwirkende).
1. CloudWatch wertet die aggregierten Ergebnisse anhand Ihres Schwellenwerts aus, wobei die zuletzt ausgeführten Abfragen M-out-of-N ausgewertet werden.
1. 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 unter[Erstellen Sie einen Log-Alarm](Alarm-On-Logs.md#Create_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:
+ **QueryString**ist die CloudWatch Logs Insights-Abfrage, die ausgeführt werden soll.
+ **LogGroupIdentifiers**sind die abzufragenden Protokollgruppen. Geben Sie entweder Protokollgruppennamen oder Protokollgruppen-ARNs an.
+ **ScheduledQueryRoleARN**ist der ARN der IAM-Rolle, die es CloudWatch Logs ermöglicht, die geplante Abfrage in Ihrem Namen auszuführen.
+ **AggregationExpression**definiert, wie Abfrageergebnisse zu einem numerischen Wert für die Schwellenwertbewertung zusammengefasst werden.
+ **ScheduleExpression**definiert, wie oft die Abfrage ausgeführt wird (z. B.`rate(5 minutes)`).
+ **StartTimeOffset**definiert das Lookback-Fenster in Sekunden für jede Abfrageausführung.
+ **EndTimeOffset**definiert das Ende des Abfragezeitbereichs als Offset in Sekunden gegenüber der aktuellen Uhrzeit.
+ **ComparisonOperator**ist 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.
+ **QueryResultsToEvaluate**ist die Anzahl der zuletzt auszuwertenden Abfrageausführungen (N in M-out-of-N).
+ **QueryResultsToAlarm**ist die Anzahl der Sicherheitsergebnisse, die zum Auslösen von Sicherheitsverletzungen erforderlich sind `ALARM` (M in M-out-of-N).
+ **TreatMissingData**definiert, wie fehlende Abfrageergebnisse bei der Auswertung behandelt werden.
Eine vollständige Liste der Parameter und Anweisungen zur Erstellung finden Sie unter[Erstellen Sie einen Log-Alarm](Alarm-On-Logs.md#Create_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ührt`EndTimeOffset`.
Die Abfrage verwendet die [ CloudWatch Logs Insights-Abfragesyntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html). Richtlinien zum Schreiben effizienter Abfragen für Log Alarms finden Sie unter[Bewährte Methoden und Problembehebung](#log-alarm-best-practices).
## 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 unter[Alarmaktionen](alarm-actions.md).
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. `StartTimeOffset`und `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 verwendet`EndTimeOffset`, 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 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/scheduled-queries-best-practices.html) im * Amazon CloudWatch Logs-Benutzerhandbuch*.