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, 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.
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 anhand der M-out-of-N Auswertung der letzten Abfrageausführungen aus.
1. 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 unter[Erstellen Sie einen Log-Alarm](Alarm-On-Logs.md#Create_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:
+ **QueryString**ist die CloudWatch Logs Insights-Abfrage, die ausgeführt werden soll.
+ **LogGroupIdentifiers**sind die Protokollgruppen, die abgefragt werden sollen. Geben Sie entweder Protokollgruppennamen oder Protokollgruppen-ARNs an.
+ **ScheduledQueryRoleARN**ist der ARN der IAM-Rolle, der es CloudWatch Logs ermöglicht, die geplante Abfrage in Ihrem Namen auszuführen.
+ **AggregationExpression**definiert, wie Abfrageergebnisse für die Schwellenwertauswertung zu einem numerischen Wert aggregiert 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 einen Abstand von der aktuellen Uhrzeit in Sekunden.
+ **ComparisonOperator**gibt 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.
+ **QueryResultsToEvaluate**ist die Anzahl der letzten auszuwertenden Abfrageausführungen (N in M-out-of-N).
+ **QueryResultsToAlarm**ist die Anzahl der Ergebnisse eines Sicherheitsverstoßes, die ausgelöst werden müssen `ALARM` (M in M-out-of-N).
+ **TreatMissingData**definiert, wie fehlende Abfrageergebnisse bei der Auswertung behandelt werden.
Die vollständige Liste der Parameter und Anweisungen zur Erstellung finden Sie unter[Erstellen Sie einen Log-Alarm](Alarm-On-Logs.md#Create_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ü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 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 `OK``ALARM`, 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 unter[Alarmaktionen](alarm-actions.md).
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. `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 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 Option`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 dem Eintreten der Ereignisse abfragbar sind.[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/alarm-log.html) |
**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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/scheduled-queries-best-practices.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.