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.
# Konzepte
CloudWatch Alarme überwachen Messwerte und lösen Aktionen aus, wenn Schwellenwerte überschritten werden. Für eine effektive Überwachung ist es wichtig zu verstehen, wie Alarme Daten auswerten und auf Bedingungen reagieren.
**Topics**
+ [Abfragen von Alarmdaten](alarm-data-queries.md)
+ [Auswertung von Alarmen](alarm-evaluation.md)
+ [PromQL-Alarme](alarm-promql.md)
+ [Zusammengesetzte Alarme](alarm-combining.md)
+ [Alarmaktionen](alarm-actions.md)
+ [Regeln für die Stummschaltung](alarm-mute-rules.md)
+ [Einschränkungen](alarm-limits.md)
# Abfragen von Alarmdaten
CloudWatch Alarme können verschiedene Datenquellen überwachen. Wählen Sie je nach Ihren Überwachungsanforderungen den geeigneten Abfragetyp aus.
## Kennzahlen
Überwachen Sie eine einzelne CloudWatch Metrik. Dies ist der häufigste Alarmtyp zur Überwachung der Ressourcenleistung. Weitere Informationen zu Metriken finden Sie unter [Konzepte von CloudWatch Metriken](cloudwatch_concepts.md).
Weitere Informationen finden Sie unter [Erstellen Sie einen CloudWatch Alarm auf der Grundlage eines statischen Schwellenwerts](ConsoleAlarms.md).
## Metrikberechnungen
Sie können einen Alarm für das Ergebnis eines mathematischen Ausdrucks setzen, der auf einer oder mehreren CloudWatch-Metriken basiert. Ein mathematischer Ausdruck, der für einen Alarm verwendet wird, kann bis zu 10 Metriken umfassen. Jede Metrik muss den gleichen Zeitraum verwenden.
Bei einem Alarm, der auf einem mathematischen Ausdruck basiert, können Sie angeben, wie fehlende Datenpunkte behandelt werden CloudWatch sollen. In diesem Fall wird der Datenpunkt als fehlend betrachtet, wenn der mathematische Ausdruck keinen Wert für diesen Datenpunkt liefert.
Alarme, die auf mathematischen Ausdrücken basieren, können keine Amazon-EC2-Aktionen ausführen.
Weitere Informationen über metrische mathematische Ausdrücke und Syntax finden Sie unter [Verwenden von mathematischen Ausdrücken mit CloudWatch Metriken](using-metric-math.md).
Weitere Informationen finden Sie unter [Erstellen Sie einen CloudWatch Alarm auf der Grundlage eines metrischen mathematischen Ausdrucks](Create-alarm-on-metric-math-expression.md).
## Metrik-Einblicke
Eine CloudWatch Metrics Insights-Abfrage hilft Ihnen dabei, Metriken mithilfe einer SQL-ähnlichen Syntax maßstabsgetreu abzufragen. Sie können für jede Metrics Insights-Abfrage einen Alarm erstellen, einschließlich Abfragen, die mehrere Zeitreihen liefern. Diese Funktion erweitert Ihre Überwachungsmöglichkeiten erheblich. Wenn Sie einen Alarm auf der Grundlage einer Metrics Insights-Abfrage erstellen, passt sich der Alarm automatisch an, wenn Ressourcen zu Ihrer überwachten Gruppe hinzugefügt oder aus ihr entfernt werden. Wenn Sie den Alarm einmal erstellt haben, wird jede Ressource, die Ihrer Abfragedefinition und Ihren Filtern entspricht, in den Bereich der Alarmüberwachung aufgenommen, sobald die entsprechende Metrik verfügbar ist. Bei Abfragen mit mehreren Zeitreihen fließt jede zurückgegebene Zeitreihe in den Alarm ein, was eine detailliertere und dynamischere Überwachung ermöglicht.
Hier sind zwei Hauptanwendungsfälle für CloudWatch Metrics Insights-Alarme:
+ Erkennung von Anomalien und Gesamtüberwachung
Sie können einen Alarm für eine Metrics-Insights-Abfrage einrichten, die eine einzelne aggregierte Zeitreihe zurückgibt. Dieser Ansatz eignet sich gut für dynamische Alarme, die aggregierte Metriken in Ihrer gesamten Infrastruktur oder Ihren Anwendungen überwachen. Sie können beispielsweise die maximale CPU-Auslastung all Ihrer Instances überwachen, wobei sich der Alarm automatisch an die Größe Ihrer Flotte anpasst.
Verwenden Sie diese Abfragestruktur, um einen aggregierten Überwachungsalarm zu erstellen:
```
SELECT FUNCTION(metricName)
FROM SCHEMA(...)
WHERE condition;
```
+ Flottenüberwachung pro Ressource
Erstellen Sie einen Alarm, der mehrere Zeitreihen überwacht, wobei jede Zeitreihe einen Beitrag mit einem eigenen Status leistet. Der Alarm wird aktiviert, wenn eine beteiligte Zeitreihe in den ALARM-Status wechselt, wodurch ressourcenspezifische Aktionen ausgelöst werden. Überwachen Sie beispielsweise Datenbankverbindungen für mehrere RDS-Instances, um Verbindungsablehnungen zu verhindern.
Verwenden Sie diese Abfragestruktur, um mehrere Zeitreihen zu überwachen:
```
SELECT AVG(DatabaseConnections)
FROM AWS/RDS
WHERE condition
GROUP BY DBInstanceIdentifier
ORDER BY AVG() DESC;
```
Wenn Sie Alarme mit mehreren Zeitreihen erstellen, müssen Sie zwei wichtige Klauseln in Ihre Abfrage aufnehmen:
+ Eine `GROUP BY`-Klausel, die definiert, wie die Zeitreihen strukturiert werden sollen. Sie bestimmt, wie viele Zeitreihen die Abfrage erzeugen wird
+ Eine `ORDER BY`-Klausel, die eine deterministische Sortierung der Messwerte festlegt, sodass der Alarm die wichtigsten Signale zuerst auswerten kann
Diese Klauseln sind für eine korrekte Alarmauswertung unerlässlich. Die `GROUP BY`-Klausel teilt Ihre Daten in separate Zeitreihen auf (z. B. nach Instance-ID), und die `ORDER BY`-Klausel gewährleistet eine konsistente und priorisierte Verarbeitung dieser Zeitreihen bei der Alarmauswertung.
Weitere Informationen zum Erstellen eines Alarms mit mehreren Zeitreihen finden Sie unter[Erstellen Sie einen Alarm auf der Grundlage einer Multi Time Series Metrics Insights-Abfrage](multi-time-series-alarm.md).
## Metrische Gruppenfilter protokollieren
Sie können einen Alarm auf der Grundlage eines Metrikfilters für Protokollgruppen erstellen. Mit metrischen Filtern können Sie in Protokolldaten, an die die Daten gesendet werden, nach Begriffen und Mustern suchen. CloudWatch Weitere Informationen finden Sie unter [Metriken aus Protokollereignissen mithilfe von Filtern erstellen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
Weitere Informationen zum Erstellen eines Alarms auf der Grundlage eines Metrikfilters für Protokollgruppen finden Sie unter. [Alarmieren in Protokollen](Alarm-On-Logs.md)
## PromQL
Sie können einen Alarm erstellen, der eine Sofortabfrage der Prometheus Query Language (PromQL) verwendet, um die über den OTLP-Endpunkt aufgenommenen Metriken zu überwachen. CloudWatch
Weitere Informationen zur Funktionsweise von PromQL-Alarmen finden Sie unter. [PromQL-Alarme](alarm-promql.md)
Weitere Informationen zur Erstellung eines PromQL-Alarms finden Sie unter. [Erstellen Sie einen Alarm mit einer PromQL-Abfrage](Create_PromQL_Alarm.md)
## Externe Datenquelle
Sie können Alarme erstellen, die Messwerte aus Datenquellen überwachen, die nicht vorhanden sind CloudWatch. Weitere Informationen zum Erstellen von Verbindungen zu diesen anderen Datenquellen finden Sie unter [Metriken aus anderen Datenquellen abfragen](MultiDataSourceQuerying.md).
Weitere Informationen zum Erstellen eines Alarms auf der Grundlage einer verbundenen Datenquelle finden Sie unter[Einen Alarm basierend auf einer verbundenen Datenquelle erstellen](Create_MultiSource_Alarm.md).
# Auswertung von Alarmen
## Metrikalarm-Status
Ein Metrikalarm kann die folgenden Status aufweisen:
+ `OK` – Die Metrik oder der Ausdruck liegt innerhalb des festgelegten Schwellenwerts.
+ `ALARM` – Die Metrik oder der Ausdruck liegt außerhalb des festgelegten Schwellenwerts.
+ `INSUFFICIENT_DATA` – Der Alarm wurde soeben gestartet; die Metrik ist nicht verfügbar oder es sind nicht genügend Daten verfügbar, damit die Metrik den Alarmstatus bestimmen kann.
## Status der Alarmauswertung
Zusätzlich zum Alarmstatus hat jeder Alarm einen Bewertungsstatus, der Informationen über den Prozess der Alarmauswertung liefert. Die folgenden Zustände können auftreten:
+ `PARTIAL_DATA`— Weist darauf hin, dass aufgrund von Kontingentbeschränkungen nicht alle verfügbaren Daten abgerufen werden konnten. Weitere Informationen finden Sie unter [Wie mit Teildaten umgegangen wird](cloudwatch-metrics-insights-alarms-partial-data.md).
+ `EVALUATION_ERROR`— Weist auf Konfigurationsfehler bei der Alarmeinrichtung hin, die überprüft und korrigiert werden müssen. Weitere Informationen finden Sie im StateReason Feld des Alarms.
+ `EVALUATION_FAILURE`— Weist auf vorübergehende CloudWatch Probleme hin. Wir empfehlen eine manuelle Überwachung, bis das Problem behoben ist
Sie können den Evaluierungsstatus in den Alarmdetails in der Konsole oder mithilfe des `describe-alarms` CLI-Befehls oder der `DescribeAlarms` API anzeigen.
## Einstellungen für die Alarm-Auswertung
Wenn Sie einen Alarm erstellen, geben Sie drei Einstellungen an, anhand derer Sie CloudWatch auswerten können, wann der Alarmstatus geändert werden muss:
+ **Zeitraum** ist die Zeitspanne, die für die Auswertung der Metrik oder des Ausdrucks verwendet wird, um jeden einzelnen Datenpunkt für einen Alarm zu erstellen. Sie wird in Sekunden angegeben.
+ **Evaluation Periods (Auswertungszeiträume)** ist die Anzahl der neuesten Zeiträume, oder Datenpunkte, die beim Ermitteln des Alarmzustands zu bewerten sind.
+ **Datapoints to Alarm (Datenpunkte zum Alarm)** ist die Anzahl der Datenpunkte innerhalb des Auswertungszeitraums, die überschritten werden müssen, um zu bewirken, dass der Alarm in den `ALARM`-Status versetzt wird. Die überschrittenen Datenpunkte müssen nicht aufeinanderfolgend sein, aber sie müssen alle innerhalb der letzten Datenpunkte liegen (dem **Auswertungszeitraum** entsprechend).
Für einen Zeitraum von einer Minute oder länger wird jede Minute ein Alarm ausgewertet, und die Auswertung basiert auf dem durch den **Zeitraum** und die **Bewertungszeiträume** definierten Zeitfenster. Wenn der **Zeitraum** beispielsweise 5 Minuten (300 Sekunden) und der **Bewertungszeiträume** 1 ist, wird der Alarm am Ende von Minute 5 auf der Grundlage von Daten zwischen Minuten 1 und 5 ausgewertet. Am Ende von Minute 6 wird der Alarm dann auf der Grundlage der Daten aus den Minuten 2 bis 6 ausgewertet.
Wenn der Alarmzeitraum 10 Sekunden, 20 Sekunden oder 30 Sekunden beträgt, wird der Alarm alle 10 Sekunden ausgewertet. Weitere Informationen finden Sie unter [Hochauflösende Alarme](#high-resolution-alarms).
Wenn die Anzahl der Auswertungszeiträume für einen Alarm multipliziert mit der Länge der einzelnen Auswertungszeiträume einen Tag überschreitet, wird der Alarm einmal stündlich ausgewertet. Weitere Informationen darüber, wie diese mehrtägigen Alarme ausgewertet werden, finden Sie unter[Beispiel für die Auswertung eines mehrtägigen Alarms](#evaluate-multiday-alarm).
In der folgenden Abbildung ist die Alarmschwelle für einen Metrikalarm auf drei Einheiten festgelegt. Sowohl der **Auswertungszeitraum** als auch die **Datenpunkte zum Alarm** sind 3. Das heißt, wenn alle vorhandenen Datenpunkte in den letzten drei aufeinanderfolgenden Perioden über dem Schwellenwert liegen, wechselt der Alarm in den Status `ALARM`. In der Abbildung geschieht dies im dritten bis zum fünften Zeitraum. Bei Zeitraum 6 fällt der Wert unter den Schwellenwert, sodass einer der auszuwertenden Zeiträume keinen Schwellenwert verletzt, und der Alarmstatus ändert sich wieder in `OK`. Im neunten Zeitraum wird der Schwellenwert erneut verletzt, jedoch nur für einen Zeitraum. Daher bleibt der Alarmstatus `OK`.
![\[Alarm zum Auslösen des Schwellenwertalarms\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/alarm_graph.png)
Wenn Sie **Evaluation Periods (Auswertungszeiträume)** und **Datapoints to Alarm (Datenpunkte zum Alarm)** als unterschiedliche Werte konfigurieren, legen Sie einen „M von N“-Alarm fest. **Datenpunkte auf Alarm** ist („M“) und **Bewertungszeiträume** sind („N“). Das Bewertungsintervall ist die Anzahl der Evaluierungsperioden multipliziert mit der Periodenlänge. Wenn Sie beispielsweise 4 von 5 Datenpunkten mit einem Zeitraum von 1 Minute konfigurieren, beträgt das Auswertungsintervall 5 Minuten. Wenn Sie 3 von 3 Datenpunkten mit einem Zeitraum von 10 Minuten konfigurieren, beträgt das Auswertungsintervall 30 Minuten.
**Anmerkung**
Wenn kurz nach der Erstellung eines Alarms Datenpunkte fehlen und die Metrik CloudWatch vor der Erstellung des Alarms gemeldet wurde, CloudWatch ruft es bei der Auswertung des Alarms die neuesten Datenpunkte ab, die vor der Erstellung des Alarms entstanden sind.
## Hochauflösende Alarme
Wenn Sie einen Alarm für eine Metrik mit hoher Auflösung einrichten, können Sie einen Alarm mit hoher Auflösung mit einem Zeitraum von 10 Sekunden, 20 Sekunden oder 30 Sekunden angeben. Für hochauflösende Alarme ist eine höhere Gebühr zu zahlen. Weitere Informationen zu hochauflösenden Metriken finden Sie unter [Veröffentlichen von benutzerdefinierten Metriken](publishingMetrics.md).
## Beispiel für die Auswertung eines mehrtägigen Alarms
Ein Alarm ist ein mehrtägiger Alarm, wenn die Anzahl der Auswertungszeiträume multipliziert mit der Länge jedes Auswertungszeitraums einen Tag überschreitet. Mehrtägige Alarme werden einmal pro Stunde ausgewertet. Wenn mehrtägige Alarme ausgewertet werden, werden bei der Auswertung nur die Messwerte bis zur aktuellen Stunde in der Minute CloudWatch berücksichtigt.
Stellen Sie sich zum Beispiel einen Alarm vor, der einen Job überwacht, der alle 3 Tage um 10:00 Uhr ausgeführt wird.
1. Um 10:02 Uhr schlägt der Job fehl
1. Um 10:03 Uhr wird der Alarm ausgewertet und behält seinen Status `OK` bei, da bei der Auswertung nur Daten bis 10:00 Uhr berücksichtigt werden.
1. Um 11:03 Uhr berücksichtigt der Alarm Daten bis 11:00 Uhr und wechselt in den Status `ALARM`.
1. Um 11:43 Uhr korrigieren Sie den Fehler und der Job wird wieder erfolgreich ausgeführt.
1. Um 12:03 Uhr wird der Alarm erneut ausgewertet, erkennt den erfolgreichen Job und kehrt zum Status `OK` zurück.
# Konfiguration der Behandlung fehlender Daten durch CloudWatch Alarme
Manchmal wird nicht jeder erwartete Datenpunkt für eine Metrik gemeldet CloudWatch. Dies kann z. B. der Fall sein, wenn eine Verbindung unterbrochen wird, ein Server ausfällt oder wenn eine Metrik Daten grundsätzlich nur intermittierend meldet.
CloudWatch ermöglicht es Ihnen, festzulegen, wie fehlende Datenpunkte bei der Auswertung eines Alarms behandelt werden sollen. Dies hilft Ihnen, Ihren Alarm so zu konfigurieren, dass er nur dann in den `ALARM`-Zustand wechselt, wenn dies für den überwachten Datentyp angemessen ist. Sie können Fehlalarme vermeiden, wenn fehlende Daten nicht auf ein Problem hinweisen.
Ähnlich wie sich jeder Alarm immer in einem von drei Zuständen befindet, CloudWatch fällt jeder spezifische Datenpunkt, an den gemeldet wird, in eine von drei Kategorien:
+ Keine Verletzung (innerhalb des Schwellenwerts)
+ Verletzung (verletzt den Schwellenwert)
+ Fehlen
Für jeden Alarm können Sie angeben CloudWatch , dass fehlende Datenpunkte wie folgt behandelt werden sollen:
+ `notBreaching` – Fehlende Datenpunkte werden als „gut“ und innerhalb der Schwelle liegend behandelt
+ `breaching` – Fehlende Datenpunkte werden als „ungültig“ und außerhalb der Schwelle liegend behandelt
+ `ignore` – Der aktuelle Alarmstatus wird beibehalten
+ `missing` – Wenn alle Datenpunkte im Alarmauswertungsbereich fehlen, wechselt der Alarm zu INSUPFIZIENT\$1DATA.
Die beste Wahl ist abhängig von der Art der Metrik und dem Zweck des Alarms. Wenn Sie beispielsweise einen Anwendungs-Rollback-Alarm mithilfe einer Metrik erstellen, die kontinuierlich Daten meldet, sollten Sie fehlende Datenpunkte möglicherweise als Sicherheitsverletzung behandeln, da dies darauf hindeuten könnte, dass etwas nicht stimmt. Aber für eine Metrik, die nur Datenpunkte generiert, wenn ein Fehler auftritt, z. B. `ThrottledRequests` in Amazon DynamoDB, sollten Sie fehlende Daten als `notBreaching` behandeln. Das Standardverhalten ist `missing`.
**Wichtig**
Alarme, die für Amazon-EC2-Metriken konfiguriert sind, können vorübergehend in den INSUFFICIENT\$1DATA-Status wechseln, wenn metrische Datenpunkte fehlen. Dies ist selten, kann jedoch auftreten, wenn die metrische Berichterstattung unterbrochen wird, selbst wenn die Amazon-EC2-Instance fehlerfrei funktioniert. Für Alarme zu Amazon-EC2-Metriken, die so konfiguriert sind, dass sie Stopp-, Beenden-, Neustart- oder Wiederherstellungsaktionen ausführen, empfehlen wir, diese Alarme so zu konfigurieren, dass fehlende Daten als `missing` behandelt werden und dass diese Alarme nur ausgelöst werden, wenn sie sich im ALARM-Status befinden.
Wenn Sie die beste Option für Ihren Alarm wählen, werden unnötige und irreführende Änderungen an Alarmbedingungen verhindert und der Zustand Ihres Systems wird genauer angeben.
**Wichtig**
Alarme, die Metriken im `AWS/DynamoDB` Namespace auswerten, ignorieren standardmäßig fehlende Daten. Sie können dies überschreiben, wenn Sie eine andere Option dafür wählen, wie der Alarm fehlende Daten behandeln soll. Wenn für eine `AWS/DynamoDB`-Metrik Daten fehlen, verbleiben Alarme, die diese Metrik auswerten, in ihrem aktuellen Zustand.
## Wie der Alarmstatus bei fehlenden Daten ausgewertet wird
Immer wenn ein Alarm auswertet, ob der Status geändert werden soll, CloudWatch versucht er, eine höhere Anzahl von Datenpunkten abzurufen als die als **Bewertungszeiträume** angegebene Zahl. Die genaue Anzahl der Datenpunkte, die er abzurufen versucht, hängt von der Länge des Alarmzeitraums und davon ab, ob er auf einer Metrik mit Standardauflösung oder hoher Auflösung basiert. Der Zeitrahmen der Datenpunkte, die sie abzurufen versucht, ist der *Auswertungsbereich*.
Sobald diese Datenpunkte CloudWatch abgerufen wurden, passiert Folgendes:
+ Wenn keine Datenpunkte im Bewertungsbereich fehlen, wird der Alarm auf der Grundlage der zuletzt erfassten Datenpunkte CloudWatch ausgewertet. Die Anzahl der ausgewerteten Datenpunkte entspricht den **Auswertungszeiträumen** für den Alarm. Die zusätzlichen Datenpunkte von weiter hinten im Auswertungsbereich werden nicht benötigt und ignoriert.
+ Wenn einige Datenpunkte im Bewertungsbereich fehlen, aber die Gesamtzahl der vorhandenen Datenpunkte, die erfolgreich aus dem Bewertungsbereich abgerufen wurden, gleich oder größer als die **Bewertungszeiträume** des Alarms ist, CloudWatch bewertet der Alarmstatus auf der Grundlage der letzten erfolgreich abgerufenen realen Datenpunkte, einschließlich der erforderlichen zusätzlichen Datenpunkte, die weiter hinten im Bewertungsbereich liegen. In diesem Fall wird der von Ihnen eingestellte Wert für die Behandlung fehlender Daten nicht benötigt und ignoriert.
+ Wenn einige Datenpunkte im Bewertungsbereich fehlen und die Anzahl der tatsächlich abgerufenen Datenpunkte niedriger ist als die Anzahl der **Evaluierungsperioden** des Alarms, CloudWatch füllt die fehlenden Datenpunkte mit dem Ergebnis auf, das Sie für die Behandlung fehlender Daten angegeben haben, und wertet dann den Alarm aus. Es werden jedoch alle realen Datenpunkte im Bewertungsbereich in die Auswertung einbezogen. CloudWatch verwendet fehlende Datenpunkte nur so wenige Male wie möglich.
**Anmerkung**
Ein besonderer Fall dieses Verhaltens besteht darin, dass CloudWatch Alarme den letzten Satz von Datenpunkten für einen bestimmten Zeitraum wiederholt neu auswerten, nachdem die Metrik aufgehört hat zu fließen. Diese Neuauswertung kann dazu führen, dass der Alarm den Status ändert und Aktionen erneut ausführt, wenn er den Status unmittelbar vor dem Stoppen des Messdatenstroms geändert hatte. Um dieses Verhalten zu verhindern, verwenden Sie kürzere Zeiträume.
Die folgenden Tabellen zeigen Beispiele für das Verhalten der Alarmauswertung. In der ersten Tabelle haben die **Datenpunkte für Alarm** - und **Bewertungszeiträume jeweils den Wert** 3. CloudWatch ruft bei der Auswertung des Alarms die 5 neuesten Datenpunkte ab, falls einige der letzten 3 Datenpunkte fehlen. 5 ist der Bewertungsbereich für den Alarm.
In Spalte 1 werden die fünf letzten Datenpunkte angezeigt, da der Auswertungsbereich 5 beträgt. Diese Datenpunkte werden mit dem letzten Datenpunkt auf der rechten Seite angezeigt. 0 ist ein nicht überschreitender Datenpunkt, X ein überschreitender Datenpunkt und - ein fehlender Datenpunkt.
In Spalte 2 ist angegeben, wie viele der 3 erforderlichen Datenpunkte fehlen. Obwohl die 5 zuletzt hinzugekommenen Datenpunkte ausgewertet werden, sind zur Bewertung des Alarmstatus nur 3 davon nötig (gemäß der Einstellung für **Evaluation Periods (Auswertungszeiträume)**). Die Anzahl der Datenpunkte in Spalte 2 ist die Anzahl der Datenpunkte, die ausgefüllt sein muss. Dabei wird die Einstellung zur Behandlung fehlender Daten verwendet.
In den Spalten 3-6 sind die Spaltenüberschriften die möglichen Werte für die Behandlung fehlender Daten. Die Zeilen in diesen Spalten zeigen den Alarmstatus an, der für jede dieser möglichen Methoden zur Behandlung fehlender Daten festgelegt ist.
| Datenpunkte | Anzahl der Datenpunkte, die ausgefüllt werden müssen | MISSING | IGNORE | ÜBERSCHREITEND | NICHT ÜBERSCHREITEND |
| --- | --- | --- | --- | --- | --- |
| 0 - X - X | 0 | `OK` | `OK` | `OK` | `OK` |
| - - - - 0 | 2 | `OK` | `OK` | `OK` | `OK` |
| - - - - - | 3 | `INSUFFICIENT_DATA` | Aktuellen Status beibehalten | `ALARM` | `OK` |
| 0 X X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| - - X - - | 2 | `ALARM` | Aktuellen Status beibehalten | `ALARM` | `OK` |
In der zweiten Zeile der vorhergehenden Tabelle bleibt der Alarm `OK`, auch wenn fehlende Daten als Überschreitung behandelt werden, weil der eine vorhandene Datenpunkt nicht überschreitend ist. Dies wird zusammen mit zwei fehlenden Datenpunkten ausgewertet, die als Überschreitung behandelt werden. Wenn dieser Alarm das nächste Mal ausgewertet wird, werden die Daten, die noch fehlen, auf `ALARM` gesetzt, da dieser nicht verletzende Datenpunkt nicht mehr im Auswertebereich liegt.
Die dritte Zeile, in der alle fünf letzten Datenpunkte fehlen, veranschaulicht, wie sich die verschiedenen Einstellungen für die Behandlung fehlender Daten auf den Alarmzustand auswirken. Wenn fehlende Datenpunkte als Verletzung betrachtet werden, geht der Alarm in den ALARM-Status, während, wenn sie als nicht verletzt betrachtet werden, dann geht der Alarm in den OK-Zustand über. Wenn fehlende Datenpunkte ignoriert werden, behält der Alarm den aktuellen Zustand vor den fehlenden Datenpunkten bei. Und wenn fehlende Datenpunkte nur als fehlend angesehen werden, dann hat der Alarm nicht genügend aktuelle reale Daten, um eine Auswertung durchzuführen und geht in den Zustand INSUFFIZIENT\$1DATA.
In der vierten Zeile geht der Alarm in allen Fällen in den Zustand `ALARM` über, da die drei jüngsten Datenpunkte verletzt werden und die **Auswertungszeiträume** und **Datenpunkte zum Alarm** des Alarms beide auf 3 gesetzt sind. In diesem Fall wird der fehlende Datenpunkt ignoriert und die Einstellung für die Auswertung fehlender Daten ist nicht erforderlich, da drei reale Datenpunkte ausgewertet werden müssen.
Zeile 5 stellt einen Sonderfall der Alarmauswertung dar, der als *vorzeitiger Alarmzustand* bezeichnet wird. Weitere Informationen finden Sie unter [Vermeidung vorzeitiger Übergänge in den Alarmzustand](#CloudWatch-alarms-avoiding-premature-transition).
In der nächsten Tabelle ist **Period (Zeitraum)** erneut auf 5 Minuten gesetzt, und **Datapoints to Alarm (Datenpunkte zum Alarm)** ist nur 2, während **Evaluation Periods (Auswertungszeiträume)** 3 ist. Die ist ein 2-aus-3, M-aus-N-Alarm.
Der Auswertungsbereich beträgt 5. Dies ist die maximale Anzahl der zuletzt abgerufenen Datenpunkte und kann verwendet werden, falls einige Datenpunkte fehlen.
| Datenpunkte | Anzahl fehlender Datenpunkte | FEHLEND | IGNORE | ÜBERSCHREITEND | NICHT ÜBERSCHREITEND |
| --- | --- | --- | --- | --- | --- |
| 0 - X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| 0 0 X 0 X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| 0 - X - - | 1 | `OK` | `OK` | `ALARM` | `OK` |
| - - - - 0 | 2 | `OK` | `OK` | `ALARM` | `OK` |
| - - - - X | 2 | `ALARM` | Aktuellen Status beibehalten | `ALARM` | `OK` |
In den Zeilen 1 und 2 geht der Alarm immer in den ALARM-Zustand, da 2 der 3 letzten Datenpunkte verletzt werden. In Zeile 2 werden die beiden ältesten Datenpunkte im Auswertebereich nicht benötigt, da keiner der 3 jüngsten Datenpunkte fehlt, daher werden diese beiden älteren Datenpunkte ignoriert.
In den Zeilen 3 und 4 geht der Alarm nur dann in den ALARM-Zustand, wenn fehlende Daten als Verletzung behandelt werden. In diesem Fall werden die beiden letzten fehlenden Datenpunkte beide als Verletzung behandelt. In Zeile 4 stellen diese beiden fehlenden Datenpunkte, die als Verletzung behandelt werden, die zwei notwendigen Datenpunkte bereit, um den ALARM-Zustand auszulösen.
Zeile 5 stellt einen Sonderfall der Alarmauswertung dar, der als *vorzeitiger Alarmzustand* bezeichnet wird. Weitere Informationen finden Sie im folgenden Abschnitt.
### Vermeidung vorzeitiger Übergänge in den Alarmzustand
CloudWatch Die Auswertung von Alarmen beinhaltet Logik zur Vermeidung von Fehlalarmen, bei denen der Alarm vorzeitig in den ALARM-Zustand übergeht, wenn die Daten unterbrochen werden. Das Beispiel, das in Zeile 5 in den Tabellen im vorherigen Abschnitt gezeigt wird, veranschaulicht diese Logik. In diesen Zeilen und in den folgenden Beispielen beträgt der **Auswertungszeitraum** 3 und der Auswertungsbereich 5 Datenpunkte. **Datenpunkte zum Alarm** sind 3, mit Ausnahme des Beispiels M von N, wo **Datenpunkte zum Alarm** 2 sind.
Angenommen, die neuesten Daten eines Alarms sind `- - - - X`, mit vier fehlenden Datenpunkten und dann einem Datenpunkt, der verletzt wird, als neuestem Datenpunkt. Da der nächste Datenpunkt möglicherweise nicht verletzt wird, geht der Alarm nicht sofort in den ALARM-Zustand, wenn die Daten entweder `- - - - X` oder `- - - X -` sind und **Datenpunkte zum Alarm** 3 sind. Auf diese Weise werden Fehlalarme vermieden, wenn der nächste Datenpunkt nicht verletzt wird und dazu führt, dass die Daten `- - - X O` oder `- - X - O` sind.
Wenn jedoch die letzten paar Datenpunkte `- - X - -` sind, geht der Alarm in den ALARM-Zustand, auch wenn fehlende Datenpunkte als fehlend behandelt werden. Dies liegt daran, dass Alarme immer in den ALARM-Zustand gehen, wenn der älteste verfügbare verletzende Datenpunkt in der Anzahl der Datenpunkte während der **Auswertungszeiträume** mindestens so alt ist wie der Wert von **Mit Alarm zu versehende Datenpunkte** und alle anderen neueren Datenpunkte eine Verletzung darstellen oder fehlen. In diesem Fall geht der Alarm auch dann in den ALARM-Zustand, wenn die Gesamtzahl der verfügbaren Datenpunkte kleiner als M (**Datenpunkte zum Alarm**) ist.
Diese Alarmlogik gilt auch für „M von N“ Alarme. Wenn der älteste verletzte Datenpunkt während des Auswertungsbereichs mindestens so alt ist wie der Wert von **Datenpunkte zum Alarm** und alle neueren Datenpunkte entweder verletzt oder fehlen, geht der Alarm unabhängig vom Wert von M (**Datenpunkte zum Alarm**).
## Fehlende Daten in CloudWatch Metrics Insights-Alarmen
**Alarme basieren auf Metrics Insights-Abfragen, die zu einer einzigen Zeitreihe zusammengefasst werden**
Die Szenarien mit fehlenden Daten und ihre Auswirkungen auf die Auswertung von Alarmen entsprechen in Bezug auf die konfigurierte Behandlung fehlender Daten denen eines standardmäßigen metrischen Alarms. Siehe [Konfiguration der Behandlung fehlender Daten durch CloudWatch Alarme](#alarms-and-missing-data).
**Alarme basieren auf Abfragen von Metrics Insights, die mehrere Zeitreihen erzeugen**
Szenarien mit fehlenden Daten für Alarme von Metrics Insights treten auf, wenn:
+ Einzelne Datenpunkte innerhalb einer Zeitreihe sind nicht vorhanden.
+ Eine oder mehrere Zeitreihen verschwinden, wenn mehrere Zeitreihen ausgewertet werden.
+ Durch die Abfrage werden keine Zeitreihen abgerufen.
Szenarien mit fehlenden Daten wirken sich wie folgt auf die Alarmauswertung aus:
+ Bei der Auswertung einer Zeitreihe wird die Behandlung fehlender Daten auf einzelne Datenpunkte innerhalb der Zeitreihe angewendet. Wenn beispielsweise 3 Datenpunkte für die Zeitreihe abgefragt wurden, aber nur 1 empfangen wurde, würden 2 Datenpunkte auf die konfigurierte Konfiguration fehlender Daten folgen.
+ Wenn eine Zeitreihe von der Abfrage nicht mehr abgerufen wird, wird sie `OK` unabhängig von der Behandlung fehlender Daten in die Datenbank übergehen. Alarmaktionen im Zusammenhang mit dem `OK` Übergang auf der Ebene der Mitwirkenden werden ausgeführt und `StateReason` geben an, dass der oben genannte Mitwirkende nicht gefunden wurde. Es wird die Meldung „Für diesen Mitwirkenden wurden keine Daten zurückgegeben“ angezeigt. Der Status des Alarms hängt vom Status der anderen Mitwirkenden ab, die durch die Abfrage abgerufen wurden.
+ Wenn die Abfrage auf Alarmebene ein leeres Ergebnis zurückgibt (überhaupt keine Zeitreihe), geht der Alarm unabhängig von der eingestellten fehlenden Datenbehandlung in den Alarm über. `INSUFFICIENT_DATA`
# Wie mit Teildaten umgegangen wird
## Auswerten von Teildaten aus einer Metrics-Insights-Abfrage
Wenn die für den Alarm verwendete Metrics-Insights-Abfrage mehr als 10 000 Metriken entspricht, wird der Alarm anhand der ersten 10 000 Metriken ausgewertet, die die Abfrage findet. Das bedeutet, dass der Alarm anhand von Teildaten ausgewertet wird.
Sie können die folgenden Methoden verwenden, um herauszufinden, ob ein Metrics-Insights-Alarm seinen Alarmstatus derzeit anhand von Teildaten auswertet:
+ Wenn Sie in der Konsole einen Alarm auswählen, um die Seite **Details** aufzurufen, erscheint auf dieser Seite die Meldung **Evaluation warning: Not evaluating all data** (Bewertungswarnung: Es werden nicht alle Daten bewertet).
+ Sie sehen den Wert `PARTIAL_DATA` in dem `EvaluationState` Feld, wenn Sie den AWS CLI Befehl [describe-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/describe-alarms.html?highlight=describe%20alarms) oder die API verwenden. [ DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html)
Alarme veröffentlichen auch Ereignisse an Amazon, EventBridge wenn es in den Status „Teildaten“ übergeht, sodass Sie eine EventBridge Regel erstellen können, um auf diese Ereignisse zu achten. In diesen Ereignissen hat das `evaluationState`-Feld den Wert `PARTIAL_DATA`. Im Folgenden wird ein -Beispiel gezeigt.
```
{
"version": "0",
"id": "12345678-3bf9-6a09-dc46-12345EXAMPLE",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-11-08T11:26:05Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:my-alarm-name"
],
"detail": {
"alarmName": "my-alarm-name",
"state": {
"value": "ALARM",
"reason": "Threshold Crossed: 3 out of the last 3 datapoints [20000.0 (08/11/22 11:25:00), 20000.0 (08/11/22 11:24:00), 20000.0 (08/11/22 11:23:00)] were greater than the threshold (0.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2022-11-08T11:26:05.399+0000\",\"startDate\":\"2022-11-08T11:23:00.000+0000\",\"period\":60,\"recentDatapoints\":[20000.0,20000.0,20000.0],\"threshold\":0.0,\"evaluatedDatapoints\":[{\"timestamp\":\"2022-11-08T11:25:00.000+0000\",\"value\":20000.0}]}",
"timestamp": "2022-11-08T11:26:05.401+0000",
"evaluationState": "PARTIAL_DATA"
},
"previousState": {
"value": "INSUFFICIENT_DATA",
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2022-11-08T11:25:51.227+0000"
},
"configuration": {
"metrics": [
{
"id": "m2",
"expression": "SELECT SUM(PartialDataTestMetric) FROM partial_data_test",
"returnData": true,
"period": 60
}
]
}
}
}
```
Wenn die Abfrage für den Alarm eine GROUP-BY-Anweisung enthält, die anfänglich mehr als 500 Zeitreihen zurückgibt, wird der Alarm anhand der ersten 500 Zeitreihen ausgewertet, die die Abfrage findet. Wenn Sie jedoch eine ORDER-BY-Klausel verwenden, werden alle von der Abfrage zu verarbeitenden Zeitreihen sortiert, und die 500, die nach der ORDER-BY-Klausel den höchsten oder niedrigsten Wert haben, werden verwendet, um den Alarm zu bewerten.
## Wie Teildaten aus einem Alarm mit mehreren Datenquellen ausgewertet werden
Wenn die Lambda-Funktion unvollständige Daten zurückgibt:
+ Der Alarm wird weiterhin anhand der zurückgegebenen Datenpunkte ausgewertet.
+ Mit den folgenden Methoden können Sie feststellen, ob ein Alarm für eine Lambda-Funktion derzeit seinen Alarmstatus auf der Grundlage von Teildaten auswertet:
+ Wählen Sie in der Konsole einen Alarm und dann die Seite **Details** aus. Wenn auf dieser Seite die Meldung **Auswertungswarnung: Es werden nicht alle Daten ausgewertet** angezeigt wird, erfolgt die Auswertung auf der Grundlage unvollständiger Daten.
+ Wenn Sie den Wert `PARTIAL_DATA` in dem `EvaluationState` Feld sehen, wenn Sie den `describe-alarms` AWS CLI Befehl oder die DescribeAlarms API verwenden, werden Teildaten ausgewertet.
+ Ein Alarm veröffentlicht auch Ereignisse an Amazon, EventBridge wenn er in den Status „Teildaten“ übergeht.
# Perzentilbasierte Alarme und Stichproben mit wenigen Daten
Wenn Sie ein Perzentil als Statistik für einen Alarm festlegen, können Sie angeben, was zu tun ist, wenn nicht genügend Daten für eine gute statistische Bewertung vorliegen. Sie können festlegen, dass der Alarm trotzdem statistisch bewertet wird und der Alarmstatus möglicherweise geändert wird. Alternativ können Sie festlegen, dass der Alarm die Metrik bei einer kleinen Stichprobe ignoriert und mit der Bewertung wartet, bis ausreichend Daten vorliegen, um statistische Signifikanz zu erzielen.
Für Perzentile zwischen0,5 (inklusive) und 1,00 (exklusive) wird diese Einstellung verwendet, wenn weniger als 10/(1-Perzentil) Datenpunkte im Bewertungszeitraum vorhanden sind. Diese Einstellung würde beispielsweise verwendet werden, wenn weniger als 1 000 Beispiele für einen Alarm auf einem p99 Perzentil vorhanden sind. Für Perzentile zwischen 0 und 0,5 (exklusive) wird die Einstellung verwendet, wenn weniger als 10/Perzentil Datenpunkte vorhanden sind.
# PromQL-Alarme
Ein PromQL-Alarm überwacht Metriken mithilfe einer Sofortabfrage der Prometheus Query Language (PromQL). Die Abfrage wählt Metriken aus, die über den CloudWatch OTLP-Endpunkt aufgenommen wurden, und alle übereinstimmenden Zeitreihen, die von der Abfrage zurückgegeben werden, gelten als fehlerhaft. *Der Alarm wertet die Abfrage in regelmäßigen Intervallen aus und verfolgt jede Zeitreihe, bei der ein Verstoß vorliegt, unabhängig voneinander als Mitverursacher.*
Hinweise zur Erfassung von Metriken mithilfe von OpenTelemetry [OpenTelemetry](CloudWatch-OpenTelemetry-Sections.md)
## Wie funktionieren PromQL-Alarme
Ein PromQL-Alarm wertet eine PromQL-Sofortabfrage nach einem wiederkehrenden Zeitplan aus, der von der definiert wird. `EvaluationInterval` Die Abfrage gibt nur die Zeitreihen zurück, die die Bedingung erfüllen. Jede zurückgegebene Zeitreihe ist ein *Mitwirkender*, der durch ihren eindeutigen Satz von Attributen identifiziert wird.
Der Alarm verwendet Zustandsübergänge, die auf der Dauer basieren:
+ *Wenn bei der Abfrage ein Mitwirkender zurückgegeben wird, gilt dies als Verstoß.* Wenn der Mitwirkende den Verstoß für die von angegebene Dauer fortsetzt`PendingPeriod`, wechselt der Mitwirkende in den Status. `ALARM`
+ *Wenn ein Mitwirkender nicht mehr von der Abfrage zurückgegeben wird, wird davon ausgegangen, dass er wiederhergestellt wurde.* Bleibt der Mitwirkende für die von angegebene Dauer abwesend`RecoveryPeriod`, wechselt der Mitwirkende in den Status zurück. `OK`
Der `ALARM` Alarmzustand ist aktiviert, wenn mindestens ein Mitwirkender länger als die Wartezeit gegen die Vorschriften verstößt. Der Alarm kehrt in den `OK` Zustand zurück, wenn sich alle Mitwirkenden erholt haben.
## PromQL-Alarm-Konfiguration
Ein PromQL-Alarm wird mit den folgenden Parametern konfiguriert:
+ **PendingPeriod**ist die Dauer in Sekunden, die ein Mitwirkender kontinuierlich überschreiten muss, bevor der Mitwirkende in den Status wechselt. `ALARM` Dies entspricht der Dauer der Prometheus-Warnregel. `for`
+ **RecoveryPeriod**ist die Dauer in Sekunden, die ein Mitwirkender beenden muss, bevor der Mitwirkende wieder in den Status wechselt. `OK` Dies entspricht der Dauer der Prometheus-Warnregel. `keep_firing_for`
+ **EvaluationInterval**gibt an, wie oft, in Sekunden, der Alarm die PromQL-Abfrage auswertet.
Informationen zum Erstellen eines PromQL-Alarms finden Sie unter. [Erstellen Sie einen Alarm mit einer PromQL-Abfrage](Create_PromQL_Alarm.md)
# Zusammengesetzte Alarme
Mit CloudWatch können Sie mehrere Alarme zu einem *zusammengesetzten Alarm* kombinieren, um einen zusammengefassten, aggregierten Statusindikator für eine ganze Anwendung oder Gruppe von Ressourcen zu erstellen. Verbundalarme sind Alarme, die ihren Zustand durch die Überwachung der Zustände anderer Alarme bestimmen. Sie definieren Regeln, um den Status dieser überwachten Alarme mithilfe einer booleschen Logik zu kombinieren.
Sie können Verbundalarme verwenden, um Alarmrauschen zu reduzieren, indem Sie Aktionen nur auf aggregierter Ebene durchführen. Sie können beispielsweise einen Verbundalarm erstellen, um eine Benachrichtigung an Ihr Webserver-Team zu senden, wenn ein Alarm im Zusammenhang mit Ihrem Webserver ausgelöst wird. Wenn einer dieser Alarme in den ALARM-Status übergeht, wechselt der Verbundalarm selbst in den ALARM-Status und sendet eine Benachrichtigung an Ihr Team. Wenn andere Alarme, die sich auf Ihren Webserver beziehen, ebenfalls in den ALARM-Status wechseln, wird Ihr Team nicht mit neuen Benachrichtigungen überlastet, da der Verbundalarm sie bereits über die aktuelle Situation informiert hat.
Sie können auch Verbundalarme verwenden, um komplexe Alarmbedingungen zu erstellen und nur dann Maßnahmen zu ergreifen, wenn viele verschiedene Bedingungen erfüllt sind. Sie können beispielsweise einen Verbundalarm erstellen, der einen CPU-Alarm und einen Speicheralarm kombiniert und Ihr Team nur benachrichtigt, wenn sowohl der CPU- als auch der Speicheralarm ausgelöst wurden.
**Using composite alarms**
Bei der Verwendung von Verbundalarmen haben Sie zwei Möglichkeiten:
+ Konfigurieren Sie die gewünschten Aktionen nur auf der Ebene des Verbundalarms, und erstellen Sie die zugrunde liegenden überwachten Alarme ohne Aktionen
+ Konfigurieren Sie einen anderen Satz von Aktionen auf der Ebene des Verbundalarms. Bei den Aktionen für Verbundalarme könnte beispielsweise ein anderes Team involviert werden, falls ein weit verbreitetes Problem auftritt.
Verbundalarme können nur folgende Aktionen ausführen:
+ Benachrichtigen von Amazon-SNS-Themen
+ Aufrufen von Lambda-Funktionen
+ OpsItems Im Systems Manager Ops Center erstellen
+ Erstellen von Vorfällen in Systems Manager Incident Manager
**Anmerkung**
Alle zugrunde liegenden Alarme Ihres Verbundalarms müssen sich unter dem gleichen Konto und in der gleichen Region befinden wie Ihr Verbundalarm befinden. Wenn Sie jedoch einen zusammengesetzten Alarm in einem CloudWatch Konto für die kontenübergreifende Überwachung der Beobachtbarkeit einrichten, können die zugrunde liegenden Alarme Metriken in verschiedenen Quellkonten und im Überwachungskonto selbst überwachen. Weitere Informationen finden Sie unter [CloudWatch kontenübergreifende Beobachtbarkeit](CloudWatch-Unified-Cross-Account.md).
Ein einzelner zusammengesetzter Alarm kann 100 zugrunde liegende Alarme überwachen und 150 zusammengesetzte Alarme können einen einzelnen zugrunde liegenden Alarm überwachen.
**Regelausdrücke**
Alle zusammengesetzten Alarme enthalten Regelausdrücke. Über Regelausdrücke wird zusammengesetzten Alarmen mitgeteilt, welche anderen Alarme überwacht werden sollen, um ihre Zustände zu bestimmen. Regelausdrücke können sich auf Metrikalarme und auf zusammengesetzte Alarme beziehen. Wenn Sie in einem Regelausdruck auf einen Alarm verweisen, weisen Sie dem Alarm eine Funktion zu, die bestimmt, in welchem der folgenden drei Zustände sich der Alarm befindet:
+ ALARM
ALARM („Alarmname oder Alarm-ARN“) ist TRUE, wenn sich der Alarm im ALARM-Status befindet.
+ OK
OK („Alarmname oder Alarm-ARN“) ist TRUE, wenn sich der Alarm im OK-Status befindet.
+ INSUFFICIENT\$1DATA
INSUFFICIENT\$1DATA („Alarmname oder Alarm-ARN“) ist TRUE, wenn sich der Alarm im INSUFFICIENT\$1DATA-Status befindet.
**Anmerkung**
TRUE wird immer als TRUE und FALSE immer als FALSE ausgewertet.
**Alarm-Referenzen**
Wenn auf einen Alarm verwiesen wird, entweder mithilfe des Alarmnamens oder des ARN, kann die Regelsyntax die Referenzierung des Alarms mit oder ohne Anführungszeichen („) um den Alarmnamen oder den ARN unterstützen.
+ Falls ohne Anführungszeichen angegeben, ARNs dürfen Alarmnamen keine Leerzeichen, runden Klammern oder Kommas enthalten.
+ Wenn sie in Anführungszeichen angegeben sind, müssen Alarmnamen oder Alarmnamen ARNs , die doppelte Anführungszeichen („) *enthalten*, das" einschließen und dabei umgekehrte Escape-Zeichen (\$1) verwenden, um eine korrekte Interpretation des Verweises zu gewährleisten.
**Syntax**
Die Syntax des Ausdrucks, den Sie verwenden, um mehrere Alarme zu einem zusammengesetzten Alarm zusammenzufassen, verwendet boolesche Logik und Funktionen. In der folgenden Tabelle werden die in Regelausdrücken verfügbaren Operatoren und Funktionen beschrieben:
| Operator/Funktion | Description |
| --- | --- |
| AND | Logischer UND-Operator. Gibt TRUE zurück, wenn alle angegebenen Bedingungen WAHR sind. |
| OR | Logischer OR-Operator. Gibt TRUE zurück, wenn mindestens eine der angegebenen Bedingungen WAHR ist. |
| NOT | Logischer NOT-Operator. Gibt TRUE zurück, wenn die angegebene Bedingung FALSCH ist. |
| AT\$1LEAST | Funktion, die TRUE zurückgibt, wenn sich eine Mindestanzahl oder ein Mindestprozentsatz der angegebenen Alarme im erforderlichen Zustand befinden. Format: AT\$1LEAST(M, STATE\$1CONDITION, (alarm1, alarm2, ...alarmN)) wobei M eine absolute Zahl oder ein Prozentsatz (z. B. 50%) sein kann und STATE\$1CONDITION den Wert ALARM, OK, INSUFFICIENT\$1DATA, NOT ALARM, NOT OK oder NOT INSUFFICIENT\$1DATA haben kann. |
Sie können Klammern verwenden, um Bedingungen zu gruppieren und die Reihenfolge der Auswertung in komplexen Ausdrücken zu steuern.
**Beispielausdrücke**
Der Anforderungsparameter `AlarmRule` unterstützt die Verwendung der logischen Operatoren `AND` `OR``NOT`, und sowie der `AT_LEAST` Funktion, sodass Sie mehrere Funktionen zu einem einzigen Ausdruck kombinieren können. Die folgenden Beispielausdrücke zeigen, wie Sie die zugrunde liegenden Alarme in Ihrem zusammengesetzten Alarm konfigurieren können:
+ `ALARM(CPUUtilizationTooHigh) AND ALARM(DiskReadOpsTooHigh)`
Der Ausdruck gibt an, dass der zusammengesetzte Alarm nur in den Zustand `ALARM` wechselt, wenn sich `CPUUtilizationTooHigh` und `DiskReadOpsTooHigh` im Zustand `ALARM` befinden.
+ `AT_LEAST(2, ALARM, (WebServer1CPU, WebServer2CPU, WebServer3CPU, WebServer4CPU))`
Der Ausdruck gibt an, dass der zusammengesetzte Alarm ausgelöst wird, `ALARM` wenn mindestens 2 der 4 CPU-Alarme des Webservers aktiviert `ALARM` sind. Auf diese Weise können Sie Warnmeldungen auf der Grundlage eines Schwellenwerts der betroffenen Ressourcen auslösen, anstatt zu verlangen, dass sich alle oder nur eine Ressource im Alarmzustand befindet.
+ `AT_LEAST(50%, OK, (DatabaseConnection1, DatabaseConnection2, DatabaseConnection3, DatabaseConnection4))`
Der Ausdruck gibt an, dass der zusammengesetzte Alarm ausgelöst wird`ALARM`, wenn sich mindestens 50% der Datenbankverbindungsalarme im `OK` Status befinden. Durch die Verwendung von Prozentwerten kann sich die Regel dynamisch anpassen, wenn Sie überwachte Alarme hinzufügen oder entfernen.
+ `ALARM(CPUUtilizationTooHigh) AND NOT ALARM(DeploymentInProgress)`
Der Ausdruck gibt an, dass der zusammengesetzte Alarm in den Zustand `ALARM` wechselt, wenn `CPUUtilizationTooHigh` sich im Zustand `ALARM` und `DeploymentInProgress` sich nicht im Zustand `ALARM` befindet. Dies ist ein Beispiel für einen zusammengesetzten Alarm, der Alarmrauschen während eines Bereitstellungsfensters reduziert.
+ `AT_LEAST(2, ALARM, (AZ1Health, AZ2Health, AZ3Health)) AND NOT ALARM(MaintenanceWindow)`
Der Ausdruck gibt an, dass der zusammengesetzte Alarm ausgelöst wird, `ALARM` wenn mindestens 2 von 3 Integritätsalarmen in der Verfügbarkeitszone aktiviert `ALARM` sind und der Alarm im `ALARM` Wartungsfenster nicht aktiviert ist. Dies kombiniert die AT\$1LEAST-Funktion mit anderen logischen Operatoren für komplexere Überwachungsszenarien.
# Unterdrückung von Alarmen
Die kombinierte Unterdrückung von Alarmaktionen ermöglicht es Ihnen, Alarmaktionen vorübergehend zu deaktivieren, ohne die Alarmkonfiguration zu löschen oder zu ändern. Dies ist nützlich bei geplanten Wartungsarbeiten, Bereitstellungen oder bei der Untersuchung bekannter Probleme.
Mit der Aktionsunterdrückung für zusammengesetzte Alarme können Sie Alarme als Unterdrückungsalarme definieren. Unterdrückungsalarme verhindern, dass zusammengesetzte Alarme Aktionen ausführen. Sie können beispielsweise einen Unterdrückungsalarm angeben, der den Status einer unterstützenden Ressource darstellt. Wenn die unterstützende Ressource ausgefallen ist, verhindert der Unterdrückungsalarm, dass der zusammengesetzte Alarm Benachrichtigungen sendet.
## Wann sollte die Alarmunterdrückung eingesetzt werden
Häufige Situationen, in denen die Alarmunterdrückung nützlich ist:
+ Wartungsfenster Ihrer Anwendung
+ Bereitstellungen von Anwendungen
+ Laufende Untersuchung von Vorfällen
+ Test- und Entwicklungsaktivitäten
## Wie funktionieren Suppressor-Alarme
Unterdrückungsalarme werden bei der Konfiguration zusammengesetzter Alarme angegeben. Jeder Alarm kann als Unterdrückungsalarm fungieren. Wenn sich der Zustand eines Unterdrückungsalarms von `OK` in `ALARM` ändert, werden von dem zugehörigen zusammengesetzten Alarm keine Aktionen mehr ausgeführt. Wenn sich der Zustand eines Unterdrückungsalarms von `ALARM` in `OK` ändert, führt der zugehörige zusammengesetzte Alarm wieder Aktionen aus.
Da Verbundalarme es Ihnen ermöglichen, einen aggregierten Überblick über Ihren Zustand bei mehreren Alarmen zu erhalten, gibt es gängige Situationen, in denen erwartet wird, dass diese Alarme ausgelöst werden. Zum Beispiel während eines Wartungsfensters Ihrer Anwendung oder wenn Sie einen laufenden Vorfall untersuchen. In solchen Situationen möchten Sie möglicherweise die Aktionen Ihrer Verbundalarme unterdrücken, um unerwünschte Benachrichtigungen oder die Erstellung neuer Vorfall-Tickets zu verhindern
Mit der Aktionsunterdrückung für zusammengesetzte Alarme können Sie Alarme als Unterdrückungsalarme definieren. Unterdrückungsalarme verhindern, dass zusammengesetzte Alarme Aktionen ausführen. Sie können beispielsweise einen Unterdrückungsalarm angeben, der den Status einer unterstützenden Ressource darstellt. Wenn die unterstützende Ressource ausgefallen ist, verhindert der Unterdrückungsalarm, dass der zusammengesetzte Alarm Benachrichtigungen sendet. Die Aktionsunterdrückung für zusammengesetzte Alarme trägt zur Reduzierung von Alarmrauschen bei, sodass Sie weniger Zeit mit der Verwaltung Ihrer Alarme verbringen müssen und sich besser auf Ihre Abläufe konzentrieren können.
Unterdrückungsalarme werden bei der Konfiguration zusammengesetzter Alarme angegeben. Jeder Alarm kann als Unterdrückungsalarm fungieren. Wenn sich der Zustand eines Unterdrückungsalarms von `OK` in `ALARM` ändert, werden von dem zugehörigen zusammengesetzten Alarm keine Aktionen mehr ausgeführt. Wenn sich der Zustand eines Unterdrückungsalarms von `ALARM` in `OK` ändert, führt der zugehörige zusammengesetzte Alarm wieder Aktionen aus.
### `WaitPeriod` und `ExtensionPeriod`
Wenn Sie einen Unterdrückungsalarm angeben, legen Sie die Parameter `WaitPeriod` und `ExtensionPeriod` fest. Diese Parameter verhindern, dass zusammengesetzte Alarme während der Zustandsänderung von Unterdrückungsalarmen unerwartet Aktionen ausführen. Verwenden Sie `WaitPeriod`, um Verzögerungen auszugleichen, die auftreten können, wenn sich der Zustand eines Unterdrückungsalarms von `OK` in `ALARM` ändert. Wenn sich also beispielsweise der Zustand eines Unterdrückungsalarms innerhalb von 60 Sekunden von `OK` in `ALARM` ändert, legen Sie `WaitPeriod` auf 60 Sekunden fest.
![\[Unterdrückung von Aktionen innerhalb WaitPeriod\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example1border.png)
Im Image ändert sich der Zustand des zusammengesetzten Alarms bei t2 von `OK` in `ALARM`. Eine Wartezeit (`WaitPeriod`) beginnt bei t2 und endet bei t8. Dadurch hat der Unterdrückungsalarm Zeit, den Zustand bei t4 von `OK` in `ALARM` zu ändern, bevor die Aktionen des zusammengesetzten Alarms unterdrückt werden, wenn die Wartezeit (`WaitPeriod`) bei t8 abläuft.
Verwenden Sie `ExtensionPeriod`, um Verzögerungen auszugleichen, die auftreten können, wenn sich der Zustand eines zusammengesetzten Alarms in `OK` ändert, nachdem sich der Zustand eines Unterdrückungsalarms in `OK` geändert hat. Wenn sich also beispielsweise der Zustand eines Unterdrückungsalarms in `OK` geändert hat und sich der Zustand eines zusammengesetzten Alarms danach innerhalb von 60 Sekunden in `OK` ändert, legen Sie `ExtensionPeriod` auf 60 Sekunden fest.
![\[Unterdrückung innerer Aktionen ExtensionPeriod\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example2border.png)
Im Image ändert sich der Zustand des Unterdrückungsalarms bei t2 von `ALARM` in `OK`. Ein Verlängerungszeitraum (`ExtensionPeriod`) beginnt bei t2 und endet bei t8. Dadurch hat der zusammengesetzte Alarm Zeit, seinen Zustand von `ALARM` in `OK` zu ändern, bevor der Verlängerungszeitraum (`ExtensionPeriod`) bei t8 abläuft.
Von zusammengesetzten Alarmen werden keine Aktionen ausgeführt, wenn `WaitPeriod` und `ExtensionPeriod` aktiv werden. Zusammengesetzte Alarme führen Aktionen aus, die auf ihrem aktuellen Zustand basieren, wenn`ExtensionPeriod` und `WaitPeriod` inaktiv werden. Es wird empfohlen, den Wert für jeden Parameter auf 60 Sekunden festzulegen, da metrische Alarme jede Minute ausgewertet werden. Die Parameter können auf einen beliebigen ganzzahligen Sekundenwert festgelegt werden.
In den folgenden Beispielen wird detaillierter beschrieben, wie `WaitPeriod` und `ExtensionPeriod` verhindern, dass zusammengesetzte Alarme unerwartet Aktionen ausführen.
**Anmerkung**
In den folgenden Beispielen wird `WaitPeriod` als 2 Zeiteinheiten und `ExtensionPeriod` als 3 Zeiteinheiten konfiguriert.
#### Beispiele
** Beispiel 1: Aktionen werden nach `WaitPeriod` nicht unterdrückt **
![\[Erstes Beispiel für die Unterdrückung von Aktionen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example3border.png)
In der Abbildung ändert sich der Zustand des zusammengesetzten Alarms bei t2 von `OK` in `ALARM`. Eine Wartezeit (`WaitPeriod`) beginnt bei t2 und endet bei t4, um zu verhindern, dass der zusammengesetzte Alarm Aktionen ausführt. Nach Ablauf der Wartezeit (`WaitPeriod`) bei t4 führt der zusammengesetzte Alarm seine Aktionen aus, da sich der Unterdrückungsalarm noch im Zustand `OK` befindet.
** Beispiel 2: Aktionen werden durch den Alarm unterdrückt, bevor `WaitPeriod` abläuft **
![\[Zweites Beispiel für die Unterdrückung von Aktionen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example4border.png)
Im Image ändert sich der Zustand des zusammengesetzten Alarms bei t2 von `OK` in `ALARM`. Eine Wartezeit (`WaitPeriod`) beginnt bei t2 und endet bei t4. Dies gibt dem Unterdrückungsalarm Zeit, den Zustand bei t3 von `OK` in `ALARM` zu ändern. Da der Unterdrückungsalarm bei t3 den Zustand von `OK` in `ALARM` ändert, wird die bei t2 begonnene Wartezeit (`WaitPeriod`) verworfen, und der Unterdrückungsalarm verhindert nun, dass der zusammengesetzte Alarm Aktionen ausführt.
** Beispiel 3: Zustandsübergang, wenn Aktionen durch `WaitPeriod` unterdrückt werden **
![\[Drittes Beispiel für die Unterdrückung von Aktionen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example5border.png)
Im Image ändert sich der Zustand des zusammengesetzten Alarms bei t2 von `OK` in `ALARM`. Eine Wartezeit (`WaitPeriod`) beginnt bei t2 und endet bei t4. Dies gibt dem Unterdrückungsalarm Zeit, den Zustand zu ändern. Der Zustand des zusammengesetzten Alarms ändert sich bei t3 wieder in `OK`, wodurch die bei t2 begonnene Wartezeit (`WaitPeriod`) verworfen wird. Eine neue Wartezeit (`WaitPeriod`) beginnt bei t3 und endet bei t5. Nach Ablauf der neuen Wartezeit (`WaitPeriod`) bei t5 führt der zusammengesetzte Alarm seine Aktionen aus.
** Beispiel 4: Zustandsübergang, wenn Aktionen durch einen Alarm unterdrückt werden **
![\[Viertes Beispiel für die Unterdrückung von Aktionen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/cwasexamplefourborder.png)
Im Image ändert sich der Zustand des zusammengesetzten Alarms bei t2 von `OK` in `ALARM`. Der Unterdrückungsalarm befindet sich bereits im Zustand `ALARM`. Der Unterdrückungsalarm verhindert, dass der zusammengesetzte Alarm Aktionen ausführt.
** Beispiel 5: Aktionen werden nach `ExtensionPeriod` nicht unterdrückt **
![\[Fünftes Beispiel für die Unterdrückung von Aktionen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example7border.png)
Im Image ändert sich der Zustand des zusammengesetzten Alarms bei t2 von `OK` in `ALARM`. Eine Wartezeit (`WaitPeriod`) beginnt bei t2 und endet bei t4. Dadurch hat der Unterdrückungsalarm Zeit, den Zustand bei t3 von `OK` in `ALARM` zu ändern, bevor die Aktionen des zusammengesetzten Alarms bis t6 unterdrückt werden. Da der Unterdrückungsalarm bei t3 den Zustand von `OK` in `ALARM` ändert, wird die bei t2 begonnene Wartezeit (`WaitPeriod`) verworfen. Bei t6 ändert sich der Zustand des Unterdrückungsalarms in `OK`. Ein Verlängerungszeitraum (`ExtensionPeriod`) beginnt bei t6 und endet bei t9. Nach Ablauf von `ExtensionPeriod` führt der zusammengesetzte Alarm seine Aktionen aus.
** Beispiel 6: Zustandsübergang, wenn Aktionen durch `ExtensionPeriod` unterdrückt werden **
![\[Sechstes Beispiel für die Unterdrückung von Aktionen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/cwasexamplesixrborder.png)
Im Image ändert sich der Zustand des zusammengesetzten Alarms bei t2 von `OK` in `ALARM`. Eine Wartezeit (`WaitPeriod`) beginnt bei t2 und endet bei t4. Dadurch hat der Unterdrückungsalarm Zeit, den Zustand bei t3 von `OK` in `ALARM` zu ändern, bevor die Aktionen des zusammengesetzten Alarms bis t6 unterdrückt werden. Da der Unterdrückungsalarm bei t3 den Zustand von `OK` in `ALARM` ändert, wird die bei t2 begonnene Wartezeit (`WaitPeriod`) verworfen. Bei t6 ändert sich der Zustand des Unterdrückungsalarms wieder in `OK`. Ein Verlängerungszeitraum (`ExtensionPeriod`) beginnt bei t6 und endet bei t9. Wenn sich der Zustand des zusammengesetzten Alarm bei t7 wieder in `OK` ändert, wird der Verlängerungszeitraum (`ExtensionPeriod`) verworfen und eine neue Wartezeit (`WaitPeriod`) gestartet, die bei t7 beginnt und bei t9 endet.
**Tipp**
Wenn Sie den Aktionsunterdrückungsalarm ersetzen, wird jegliche aktive Wartezeit (`WaitPeriod`) bzw. jeglicher aktiver Verlängerungszeitraum (`ExtensionPeriod`) verworfen.
## Regeln zum Unterdrücken und Stummschalten von Aktionen
Wenn für einen zusammengesetzten Alarm sowohl die Regeln zur Unterdrückung von Aktionen als auch zum Stummschalten von Alarmen aktiv sind, haben die Regeln für die Stummschaltung Vorrang und unterdrücken alle Alarmaktionen. Nach Ablauf des Mute-Fensters bestimmt die Konfiguration des zusammengesetzten Alarms, ob Aktionen auf der Grundlage des Alarmstatus des Suppressor-Alarms und der konfigurierten Warte- oder Verlängerungszeiträume ausgeführt werden. Weitere Informationen zu den Regeln für die Stummschaltung von Alarmen finden Sie unter[Regeln für die Stummschaltung](alarm-mute-rules.md).
# Alarmaktionen
Sie können angeben, welche Aktionen ein Alarm ausführt, wenn er den Zustand zwischen den Zuständen OK, ALARM und INSUPFIZIENT\$1DATA ändert.
Die meisten Aktionen können für den Übergang in jeden der drei Zustände festgelegt werden. Mit Ausnahme der Auto-Scaling-Aktionen finden die Aktionen nur bei Zustandsübergängen statt und werden nicht erneut ausgeführt, wenn der Zustand über Stunden oder Tage anhält.
Folgendes wird als Alarmaktionen unterstützt:
+ Benachrichtigen Sie einen oder mehrere Subscriber mithilfe eines Themas von Amazon Simple Notification Service. Subscriber können sowohl Anwendungen als auch Personen sein.
+ Rufen Sie eine Lambda-Funktion auf. Dies ist die einfachste Methode für Sie, benutzerdefinierte Aktionen bei Änderungen des Alarmstatus zu automatisieren.
+ Auf EC2-Metriken basierende Alarme können auch EC2-Aktionen ausführen, wie etwa das Anhalten, Beenden, Neustarten oder Wiederherstellen einer EC2-Instance.
+ Alarme können auch Aktionen ausführen, um eine Auto-Scaling-Gruppe zu skalieren.
+ Alarme können OpsItems im Systems Manager Ops Center oder Vorfälle im AWS Systems Manager Incident Manager erstellt werden. Diese Aktionen werden nur ausgeführt, wenn der Alarm in den Zustand ALARM wechselt.
+ Ein Alarm kann eine Untersuchung einleiten, wenn er in den Status ALARM wechselt.
Alarme geben auch Ereignisse aus, Amazon EventBridge wenn sie ihren Status ändern, und Sie können festlegen, Amazon EventBridge dass bei diesen Zustandsänderungen andere Aktionen ausgelöst werden.
## Alarmaktionen und -benachrichtigungen
Die folgende Tabelle zeigt die Aktionen, die für Alarme ausgeführt wurden, sowie ihr Verhalten bei mehreren Zeitreihenalarmen (oder Mitwirkenden) Alarmen:
| Aktionstyp | Metrics Insights: Unterstützung für Alarme mit mehreren Zeitreihen | Unterstützung für PromQL Alarm | Weitere Informationen |
| --- | --- | --- | --- |
| SNS-Benachrichtigungen | Mitwirkenden-Stufe | Mitwirkenden-Stufe | [Amazon SNS SNS-Veranstaltungsziele](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html) |
| EC2-Aktionen (Stoppen, Beenden, Neustarten, Wiederherstellen) | Nicht unterstützt | Nicht unterstützt | [Beenden, Beenden, Neustarten oder Wiederherstellen einer EC2-Instance](UsingAlarmActions.md) |
| Auto Scaling-Aktionen | Nicht unterstützt | Nicht unterstützt | [Schrittweise und einfache Skalierungsrichtlinien für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html) |
| OpsItem Erstellung eines Systems Manager | Alarm-Stufe | Nicht unterstützt | [Konfigurieren Sie die zu erstellenden CloudWatch Alarme OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) |
| Vorfälle in Systems Manager Incident Manager | Alarm-Stufe | Nicht unterstützt | [Automatisches Erstellen von Vorfällen mit CloudWatch Alarmen](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html#incident-tracking-auto-alarms) |
| Aufruf einer Lambda-Funktion | Mitwirkenden-Stufe | Mitwirkenden-Stufe | [Aufrufen einer Lambda-Funktion von einem Alarm](alarms-and-actions-Lambda.md) |
| CloudWatch Ermittlungen, Ermittlungen | Alarm-Stufe | Nicht unterstützt | [Starten Sie eine CloudWatch Untersuchung von einem Alarm aus](Start-Investigation-Alarm.md) |
Der Inhalt der Alarmmeldungen unterscheidet sich je nach Alarmtyp:
+ Einzelmetrik-Alarme enthalten sowohl einen Statusgrund als auch detaillierte Daten mit den spezifischen Datenpunkten, die die Statusänderung verursacht haben.
+ Die in mehreren Zeitreihen hinterlegten Metrics Insights-Alarme bieten für jeden Mitwirkenden einen vereinfachten Grund für den Status, ohne dass der detaillierte Datenblock für den Grund des Zustands angegeben wird.
+ PromQL-Alarme enthalten in ihren Benachrichtigungen weder einen Grund für den Bundesstaat noch Daten zur Begründung des Bundesstaates.
**Example Beispiele für Inhalte in Benachrichtigungen**
Die Benachrichtigung für Einzelmetrik-Alarme enthält detaillierte Daten:
```
{
"stateReason": "Threshold Crossed: 3 out of the last 3 datapoints [32.6 (03/07/25 08:29:00), 33.8 (03/07/25 08:24:00), 41.0 (03/07/25 08:19:00)] were greater than the threshold (31.0)...",
"stateReasonData": {
"version": "1.0",
"queryDate": "2025-07-03T08:34:06.300+0000",
"startDate": "2025-07-03T08:19:00.000+0000",
"statistic": "Average",
"period": 300,
"recentDatapoints": [41, 33.8, 32.6],
"threshold": 31,
"evaluatedDatapoints": [
{
"timestamp": "2025-07-03T08:29:00.000+0000",
"sampleCount": 5,
"value": 32.6
}
// Additional datapoints...
]
}
}
```
Beispiel für mehrere Zeitreihen, Metrics Insights Alarm, SNS-Benachrichtigung für Mitwirkende:
```
{
"AlarmName": "DynamoDBInsightsAlarm",
"NewStateValue": "ALARM",
"NewStateReason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].",
"StateChangeTime": "2025-12-01T13:42:04.919+0000",
"OldStateValue": "OK",
"AlarmContributorId": "6d442278dba546f6",
"AlarmContributorAttributes": {
"TableName": "example-dynamodb-table-name"
}
// Additional information...
}
```
Beispiel für eine PromQL Alarm SNS-Benachrichtigung für Mitwirkende:
```
{
"AlarmName": "HighCPUUsageAlarm",
"NewStateValue": "ALARM",
"StateChangeTime": "2025-12-01T13:42:04.919+0000",
"OldStateValue": "OK",
"AlarmContributorId": "1d502278dcd546a1",
"AlarmContributorAttributes": {
"team": "example-team-name"
}
// Additional information...
}
```
## Alarmaktionen stummschalten
Mit Regeln zum Stummschalten von Alarmen können Sie Alarmaktionen während vordefinierter Zeitfenster, wie z. B. Wartungsperioden oder Betriebsereignissen, automatisch stummschalten. CloudWatch überwacht weiterhin den Alarmstatus und verhindert gleichzeitig unerwünschte Benachrichtigungen. Weitere Informationen finden Sie unter [Regeln für die Stummschaltung](alarm-mute-rules.md).
**Regeln stummschalten oder Alarmaktionen deaktivieren**
Regeln zum Stummschalten von Alarmen schalten Aktionen vorübergehend während festgelegter Zeitfenster stumm und heben die Stummschaltung automatisch auf, wenn das Fenster endet. Im Gegensatz dazu deaktiviert die `DisableAlarmActions` API Alarmaktionen dauerhaft, bis Sie sie manuell aufrufen. `EnableAlarmActions` Die `EnableAlarmActions` API hebt die Stummschaltung von Alarmen, die durch aktive Stummschaltungsregeln stummgeschaltet wurden, nicht auf.
**Anmerkung**
Das Stummschalten eines Alarms CloudWatch verhindert nicht, dass Alarmereignisse zur Erstellung, Aktualisierung, Löschung und Statusänderung von Alarmen an Amazon EventBridge gesendet werden.
# Regeln für die Stummschaltung
Bei den Regeln für die Stummschaltung von Alarmen handelt es sich um eine CloudWatch Funktion, mit der Sie Alarmaktionen in vordefinierten Zeitfenstern automatisch stummschalten können. Wenn Sie eine Stummschaltungsregel erstellen, definieren Sie bestimmte Zeiträume und Zielalarme, deren Aktionen stummgeschaltet werden. CloudWatch überwacht und bewertet weiterhin Alarmzustände und verhindert gleichzeitig unerwünschte Benachrichtigungen oder automatische Alarmaktionen bei erwarteten Betriebsereignissen.
Regeln zur Stummschaltung von Alarmen helfen Ihnen bei der Bewältigung kritischer Betriebsszenarien, in denen Alarmaktionen unnötig oder störend wären. So können Sie beispielsweise während der geplanten Wartungsfenster automatische Alarmaktionen verhindern, während Ihre Systeme absichtlich offline sind oder zu erwartende Probleme auftreten, sodass Sie Wartungsarbeiten ohne Unterbrechungen durchführen können. Für den Betrieb außerhalb der Geschäftszeiten, wie z. B. an Wochenenden oder Feiertagen, können Sie unkritische Alarmaktionen stummschalten, wenn keine sofortige Reaktion erforderlich ist. Dadurch werden Alarmgeräusche und unnötige Benachrichtigungen an Ihr Betriebsteam reduziert. In Testumgebungen ermöglichen Stummschaltungsregeln das vorübergehende Stummschalten von Alarmaktionen in Szenarien wie Auslastungstests, in denen ein hoher Ressourcenverbrauch oder hohe Fehlerraten zu erwarten sind und keine sofortige Bearbeitung erforderlich ist. Wenn Ihr Team aktiv Probleme behebt, können Sie mithilfe von Stummschaltungsregeln verhindern, dass doppelte Alarmaktionen ausgelöst werden, sodass Sie sich auf die Lösung konzentrieren können, ohne sich von redundanten Alarmmeldungen ablenken zu lassen.
## Regeln zum Stummschalten von Alarmen
Regeln für die Stummschaltung von Alarmen können wie folgt definiert werden: **Regeln** und **Ziele**.
+ **Regeln** — definieren Sie die Zeitfenster, in denen Alarmaktionen stummgeschaltet werden sollen. Regeln bestehen aus drei Attributen:
+ **Ausdruck** — Definiert, wann die Stummschaltungsperiode beginnt und wie sie sich wiederholt. Sie können zwei Arten von Ausdrücken verwenden:
+ **Cron-Ausdrücke** — Verwenden Sie die Standard-Cron-Syntax, um wiederkehrende Mute-Fenster zu erstellen. Dieser Ansatz ist ideal für regelmäßige Wartungspläne, z. B. wöchentliche Systemupdates oder tägliche Backup-Operationen. Mithilfe von Cron-Ausdrücken können Sie komplexe wiederkehrende Muster angeben, einschließlich bestimmter Wochentage, Monate oder Uhrzeiten.
*Syntax für den Cron-Ausdruck*
```
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12) (or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6) (0 or 7 is Sunday, or MON-SUN)
│ │ │ │ │
│ │ │ │ │
* * * * *
```
+ Die Zeichen`*`,`,`, `-` werden in allen Feldern unterstützt.
+ Englische Namen können für die Felder `month` (JAN-DEC) und `day of week` (SUN-SAT) verwendet werden
+ **AT-Ausdrücke** — Verwenden Sie AT-Ausdrücke für einmaliges Stummschalten von Fenstern. Dieser Ansatz eignet sich gut für geplante betriebliche Ereignisse, die einmal zu einem bekannten Zeitpunkt auftreten.
```
Syntax: `at(yyyy-MM-ddThh:mm)`
```
+ **Dauer** — Gibt an, wie lange die Stummschaltungsregel nach ihrer Aktivierung gültig ist. Die Dauer muss im ISO-8601-Format mit mindestens 1 Minute (PT1M) und maximal 15 Tagen (P15D) angegeben werden.
+ **Zeitzone — Gibt die Zeitzone** an, in der das Stummschaltfenster gemäß den Ausdrücken angewendet wird, wobei Standardzeitzonenbezeichner wie "“ verwendet werden. America/Los\$1Angeles" or "Europe/London
+ **Ziele** — geben Sie die Liste der Alarmnamen an, deren Aktionen während der definierten Zeitfenster stummgeschaltet werden. Sie können sowohl metrische Alarme als auch zusammengesetzte Alarme in Ihre Zielliste aufnehmen.
Sie können optional Start- und Endzeitstempel hinzufügen, um zusätzliche Grenzen für Ihre Mute-Fenster festzulegen. Startzeitstempel stellen sicher, dass Stummschaltungsregeln nicht vor einem bestimmten Datum und einer bestimmten Uhrzeit aktiviert werden, während Endzeitstempel verhindern, dass Regeln nach dem angegebenen Datum und der angegebenen Uhrzeit angewendet werden.
Weitere Informationen zum programmgesteuerten Erstellen von Regeln für die Stummschaltung von Alarmen finden Sie unter. [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)
**Anmerkung**
Die gezielten Alarme müssen in derselben Datei AWS-Konto und in derselben Datei vorhanden sein, AWS-Region in der die Stummschaltungsregel erstellt wurde.
Eine einzelne Regel zum Stummschalten von Alarmen kann bis zu 100 Alarme anhand der Alarmnamen als Ziel festlegen.
Die CloudWatch Konsole enthält eine spezielle Registerkarte „Regeln für die Stummschaltung von Alarmen“, über die Sie alle Stummschaltungsregeln in Ihrem System zentral verwalten können AWS-Konto. Sie können mithilfe der Attribute für die Stummschaltung, wie z. B. den Regelnamen, nach bestimmten Regeln für die Stummschaltung suchen.
## Status der Regel stummschalten
Nach der Erstellung kann sich eine Regel zum Stummschalten von Alarmen in einem der folgenden drei Status befinden:
+ **GEPLANT** — Die Stummschaltungsregel wird zu einem future Zeitpunkt gemäß dem konfigurierten Zeitfensterausdruck aktiv.
+ **AKTIV** — Die Stummschaltungsregel ist derzeit gemäß dem konfigurierten Zeitfensterausdruck aktiv und schaltet gezielte Alarmaktionen aktiv stumm.
+ **ABGELAUFEN** — Die Stummschaltungsregel wird in future nicht SCHEDULED/ACTIVE mehr gelten. Dies tritt bei einmaligen Stummschaltungsregeln auf, nachdem das Stummschaltungsfenster abgelaufen ist, oder bei wiederkehrenden Stummschaltungsregeln, wenn ein Endzeitstempel konfiguriert ist und diese Zeit abgelaufen ist.
## Auswirkungen von Stummschaltungsregeln auf Alarme
Wenn während eines aktiven Mute-Fensters der Status eines gezielten Alarms geändert wird und Aktionen konfiguriert sind, wird die Ausführung dieser Aktionen CloudWatch stummgeschaltet. Stummschaltungen werden nur auf Alarmaktionen angewendet, was bedeutet, dass Alarme weiterhin ausgewertet werden und Statusänderungen in der CloudWatch Konsole sichtbar sind, konfigurierte Aktionen wie Amazon Simple Notification Service-Benachrichtigungen, Amazon Elastic Compute Cloud Auto Scaling Scaling-Aktionen oder Amazon EC2 EC2-Aktionen jedoch nicht ausgeführt werden können. CloudWatch wertet Alarmzustände während der gesamten Stummschaltungsperiode weiterhin normal aus, und Sie können diese Informationen im Alarmverlauf einsehen.
Wenn ein Stummschaltfenster endet und der oder die gezielten Alarme sich in einem Alarmzustand (OK/ALARM/INSUFFICIENT\$1DATA) befinden, werden die Alarmaktionen, die während des Fensters stummgeschaltet waren, CloudWatch automatisch erneut ausgelöst. Dadurch wird sichergestellt, dass Ihre Alarmaktionen bei laufenden Problemen nach Ablauf der geplanten Stummschaltungsperiode ausgeführt werden, wodurch die Integrität Ihres Überwachungssystems gewahrt bleibt.
**Anmerkung**
Wenn Sie einen Alarm stummschalten:
Alle Aktionen, die mit den gezielten Alarmen verknüpft sind, sind stummgeschaltet
Aktionen, die allen Alarmzuständen (OK, ALARM und INSUFFICIENT\$1DATA) zugeordnet sind, sind stummgeschaltet
## Stummgeschaltete Alarme anzeigen und verwalten
Informationen zum Anzeigen und Verwalten von stummgeschalteten Alarmen finden Sie unter. [Stummgeschaltete Alarme anzeigen und verwalten](viewing-managing-muted-alarms.md)
# So funktionieren Regeln zum Stummschalten von Alarmen
Die folgenden Szenarien veranschaulichen, wie sich Regeln für die Stummschaltung von Alarmen auf die gezielten Alarme auswirken und wie die Alarmaktionen stummgeschaltet oder ausgeführt werden.
**Anmerkung**
Durch das Stummschalten eines Alarms werden Aktionen stummgeschaltet, die mit allen Alarmzuständen verknüpft sind, einschließlich OK, ALARM und INSUFFICIENT\$1DATA. Das unten dargestellte Verhalten gilt für Aktionen, die mit allen Alarmzuständen verknüpft sind.
Wenn Sie einen Metrics Insights-Alarm stummschalten, werden auch alle mitwirkenden Metrikreihen für diesen Alarm automatisch stummgeschaltet.
## Szenario: Alarmaktionen werden stummgeschaltet, wenn eine Stummschaltungsregel aktiv ist
Bedenken Sie,
+ Bei einem Alarm sind Aktionen für seinen ALARM-Status konfiguriert
+ Es ist geplant, dass eine Regel zum Stummschalten eines Alarms von t1 bis t5 aktiv ist und auf den Alarm abzielt
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-1.png)
+ Bei **t0** befindet sich der Alarm im Status OK, der Status der Stummschaltungsregel ist GEPLANT
+ Bei **t1** — Der Status der Stummschaltungsregel wird zu AKTIV
+ Bei **t2** — Der Alarm geht in den ALARM-Status über, wird die Aktion stummgeschaltet, da der Alarm durch die Stummschaltungsregel effektiv stummgeschaltet wird.
+ Bei **t4** kehrt der Alarm in den Status OK zurück, während die Stummschaltungsregel noch aktiv ist
+ Bei **t5** — Die Stummschaltungsregel wird inaktiv, aber es wird keine ALARM-Aktion ausgeführt, da sich der Alarm jetzt im Status OK befindet
## Szenario: Die Alarmaktion wird stummgeschaltet, wenn die Stummschaltungsregel aktiv ist, und wird nach dem Stummschalten erneut ausgelöst
Bedenken Sie,
+ Bei einem Alarm sind Aktionen für seinen ALARM-Status konfiguriert
+ Es ist geplant, dass eine Regel zum Stummschalten eines Alarms von t1 bis t5 aktiv ist und auf den Alarm abzielt
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-2.png)
+ Bei **t0** befindet sich der Alarm im Status OK, der Status der Stummschaltungsregel ist GEPLANT
+ Bei **t1** — Der Status der Stummschaltungsregel wird zu AKTIV
+ Bei **t2** — Der Alarm geht in den ALARM-Status über, wird die Aktion stummgeschaltet, da der Alarm durch die Stummschaltungsregel effektiv stummgeschaltet wird.
+ Bei **t4** — Das Mute-Fenster wird inaktiv, der Alarm befindet sich immer noch im ALARM-Status
+ Bei **t5** — Die Alarmaktion wird ausgeführt, weil das Mute-Fenster beendet ist und der Alarm in demselben Zustand (ALARM) verbleibt, in dem er ursprünglich stummgeschaltet war
## Szenario: Mehrere sich überschneidende Regeln für die Stummschaltung von Alarmen
Bedenken Sie,
+ Bei einem Alarm sind Aktionen für seinen ALARM-Status konfiguriert
Bedenken Sie, dass es zwei Stummschaltungsregeln gibt:
+ Alarm-Stummschaltungsregel 1 — schaltet den Alarm von t1 auf t5 stumm
+ Alarm-Stummschaltung Regel 2 — schaltet den Alarm von t3 auf t9 stumm
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-3.png)
+ Bei **t0** — Der Alarm befindet sich im Status OK, beide Stummschaltungsregeln sind GEPLANT
+ Bei **t1** — Die erste Stummschaltungsregel wird AKTIV
+ Bei **t2** geht der Alarm in den ALARM-Status über, die Aktion wird stummgeschaltet
+ Bei **t3** — Die zweite Stummschaltungsregel wird AKTIV
+ Bei **t5** — Die erste Stummschaltungsregel wird inaktiv, aber die Alarmaktion bleibt stumm geschaltet, da die zweite Stummschaltungsregel immer noch aktiv ist
+ Bei **t8** — Die Alarmaktion wird ausgeführt, weil das zweite Mute-Fenster beendet ist und der Alarm in demselben Zustand (ALARM) verbleibt, in dem er ursprünglich stummgeschaltet war
## Szenario: Stummgeschaltete Alarmaktionen werden ausgeführt, wenn die Aktualisierung der Stummschaltungsregeln das Mute-Fenster beendet
Bedenken Sie,
+ Bei einem Alarm sind Aktionen für seinen ALARM-Status konfiguriert
+ Es ist geplant, dass eine Regel zum Stummschalten eines Alarms von t1 bis t8 aktiv ist und auf den Alarm abzielt
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-4.png)
+ Bei **t0** befindet sich der Alarm im Status OK, die Stummschaltungsregel ist GEPLANT
+ Bei **t1** — Die Stummschaltungsregel wird AKTIV
+ Bei **t2** geht der Alarm in den ALARM-Status über, die Aktionen werden stummgeschaltet
+ Bei **t6** — Die Konfiguration der Stummschaltungsregeln wird so aktualisiert, dass das Zeitfenster bei t6 endet. Alarmaktionen werden bei t6 sofort ausgeführt, da die Stummschaltungsregel nicht mehr aktiv ist.
**Anmerkung**
Das gleiche Verhalten gilt,
Wenn die Stummschaltungsregel bei t6 gelöscht wird. Durch Löschen der Stummschaltungsregel wird die Stummschaltung des Alarms sofort aufgehoben.
Wenn der Alarm aus den Zielen für die Stummschaltungsregel entfernt wird (bei t6), wird die Stummschaltung des Alarms sofort aufgehoben.
## Szenario: Neue Aktionen werden ausgeführt, wenn Alarmaktionen während des Mute-Fensters aktualisiert werden
Bedenken Sie,
+ Bei einem Alarm sind Aktionen für seinen ALARM-Status konfiguriert
+ Es ist geplant, dass eine Regel zum Stummschalten eines Alarms von t1 bis t8 aktiv ist und auf den Alarm abzielt
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-5.png)
+ Bei **t0** befindet sich der Alarm im Status OK, die Stummschaltungsregel ist GEPLANT. Eine SNS-Aktion ist mit dem Alarmstatus ALARM konfiguriert.
+ Bei **t1** — Die Stummschaltungsregel wird AKTIV
+ Bei **t2** — Der Alarm geht in den ALARM-Status über, die konfigurierte SNS-Aktion ist stummgeschaltet
+ Bei **t6** — Die Alarmkonfiguration wurde aktualisiert, um die SNS-Aktion zu entfernen und eine Lambda-Aktion hinzuzufügen
+ Bei **t8** — Die für den Alarm konfigurierte Lambda-Aktion wird ausgeführt, weil das Mute-Fenster beendet ist und der Alarm in demselben Zustand (ALARM) verbleibt, in dem er ursprünglich stummgeschaltet war
**Anmerkung**
Wenn alle Alarmaktionen während des Mute-Fensters entfernt werden (bei t6 im obigen Beispiel), werden am Ende des Mute-Fensters (bei t8 oben) keine Aktionen ausgeführt
## Beispielpläne für allgemeine Anwendungsfälle
Die folgenden Beispiele zeigen, wie Zeitfensterausdrücke für allgemeine Anwendungsfälle konfiguriert werden.
**Szenario 1: Stummschalten von Alarmaktionen während geplanter Wartungsfenster** — Regelmäßige Wartungsaktivitäten, die nach einem vorhersehbaren Zeitplan ausgeführt werden, z. B. System- oder Datenbankaktualisierungen, wenn Dienste absichtlich nicht verfügbar sind oder im eingeschränkten Modus betrieben werden.
+ Cron-Ausdruck `0 2 * * SUN` mit Dauer `PT4H` — Schaltet Alarme jeden Sonntag von 2:00 Uhr bis 6:00 Uhr für wöchentliche Systemwartungen stumm.
+ Cron-Ausdruck `0 1 1 * *` mit Dauer `PT6H` — Schaltet Alarme am ersten Tag eines jeden Monats von 1:00 Uhr bis 7:00 Uhr für die monatliche Datenbankwartung stumm.
**Szenario 2: Stummschalten unkritischer Alarme außerhalb der Geschäftszeiten — Verringerung der Alarmmüdigkeit an Wochenenden oder Feiertagen, wenn keine** unmittelbare Aufmerksamkeit erforderlich ist.
+ Cron-Ausdruck `0 18 * * FRI` mit Dauer `P2DT12H` — Schaltet Alarme an jedem Wochenende von Freitag 18:00 Uhr bis Montag 6:00 Uhr stumm.
**Szenario 3: Stummschalten von Leistungsalarmen bei täglichen Backup-Vorgängen** — Tägliche automatisierte Backup-Prozesse, die vorübergehend die Ressourcenauslastung erhöhen und in vorhersehbaren Zeitfenstern leistungsbezogene Alarme auslösen können.
+ Cron-Ausdruck `0 23 * * *` mit Dauer `PT2H` — Schaltet bei nächtlichen Backup-Vorgängen, die vorübergehend die Festplatten- und CPU-Auslastung erhöhen, täglich von 23:00 Uhr bis 1:00 Uhr Alarme stumm. I/O
**Szenario 4: Stummschalten doppelter Alarme während aktiver Fehlerbehebungssitzungen** — Vorübergehendes Stummschalten von Alarmaktionen, während die Teams aktiv Probleme untersuchen und lösen, wodurch Störgeräusche vermieden und Probleme gezielt gelöst werden können.
+ Bei Ausdruck `at(2024-05-10T14:00)` mit Dauer `PT4H` — Schaltet Alarme am 10. Mai 2024 von 14:00 Uhr bis 18:00 Uhr während einer aktiven Incident-Response-Sitzung stumm.
**Szenario 5: Stummschalten von Alarmaktionen bei geplanten Unternehmensstillständen** — Einmalige verlängerte Wartungsperioden oder unternehmensweite Abschaltungen, bei denen alle Systeme absichtlich für längere Zeiträume offline sind.
+ Bei Auslösung `at(2024-12-23T00:00)` mit Dauer `P7D` — Schaltet während der jährlichen Betriebsunterbrechung Alarme für die gesamte Woche vom 23. bis 29. Dezember 2024 stumm.
# Einschränkungen
## Allgemeine CloudWatch Kontingente
Informationen zu allgemeinen CloudWatch Servicekontingenten, die für Alarme gelten, finden Sie unter[CloudWatch Dienstkontingente](cloudwatch_limits.md).
## Grenzwerte, die für Alarme gelten, die auf Metrics Insights-Abfragen basieren
Beachten Sie bei der Arbeit mit CloudWatch Metrics Insights-Alarmen die folgenden Funktionseinschränkungen:
+ Ein Standardwert von 200 Alarmen mit der Metrics Insights-Abfrage pro Konto und Region
+ Nur die Daten der letzten 3 Stunden können für die Auswertung des Alarmzustands verwendet werden. Sie können jedoch Daten von bis zu zwei Wochen auf der Detailseite des Alarms grafisch darstellen
+ Bei Alarmen, die mehrere Zeitreihen auswerten, wird die Anzahl der Mitwirkenden in ALARM auf 100 begrenzt
+ Angenommen, die Abfrage ruft 150 Zeitreihen ab:
+ Wenn ALARM weniger als 100 Mitwirkende enthält (zum Beispiel 95), `StateReason` wird „95 von 150 Zeitreihen, die zu ALARM ausgewertet wurden“ verwendet
+ Wenn mehr als 100 Mitwirkende an ALARM beteiligt sind (zum Beispiel 105), `StateReason` wird es sich um „mehr als 100 Zeitreihen, die für ALARM ausgewertet wurden“ handeln
+ Wenn das Volumen der Attribute zu groß ist, kann die Anzahl der Mitwirkenden in ALARM außerdem auf weniger als 100 begrenzt werden.
+ Es gelten die Grenzwerte von Metrics Insights für die maximale Anzahl analysierter oder zurückgegebener Zeitreihen
+ Bei der Auswertung von Alarmen `EvaluationState` wird der Wert `PARTIAL_DATA` für die folgenden Grenzwerte festgelegt:
+ Wenn die Metrics Insights-Abfrage mehr als 500 Zeitreihen zurückgibt.
+ Wenn die Metrics Insights-Abfrage mit mehr als 10.000 Metriken übereinstimmt.
Weitere Informationen zu CloudWatch Servicekontingenten und -beschränkungen finden Sie unter [Servicekontingente von CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html).
## Grenzwerte, die für Alarme gelten, die auf PromQL-Abfragen basieren
Beachten Sie bei der Arbeit mit CloudWatch PromQL-Alarmen die folgenden Funktionsgrenzen:
+ Alarme, die mehrere Zeitreihen auswerten, begrenzen die Anzahl der Mitwirkenden in ALARM auf 100
+ Wenn es weniger als 100 Mitwirkende in ALARM gibt (zum Beispiel 95), gilt „95 Zeitreihen, die `StateReason` für ALARM ausgewertet wurden“
+ Wenn mehr als 100 Mitwirkende an ALARM beteiligt sind (zum Beispiel 105), `StateReason` wird es sich um „mehr als 100 Zeitreihen, die für ALARM bewertet wurden“ handeln
+ Wenn das Volumen der Attribute zu groß ist, kann die Anzahl der Mitwirkenden in ALARM außerdem auf weniger als 100 begrenzt werden.
+ Es gelten PromQL-Abfragebeschränkungen für die maximale Anzahl analysierter oder zurückgegebener Zeitreihen
+ Bei der Auswertung von Alarmen `EvaluationState` wird das auf gesetzt, `PARTIAL_DATA` wenn die PromQL-Abfrage mehr als 500 Zeitreihen zurückgibt.
## Grenzwerte, die für Alarme gelten, die auf verbundenen Datenquellen basieren
+ Wenn ein Alarm CloudWatch ausgewertet wird, erfolgt dies jede Minute, auch wenn der Zeitraum für den Alarm länger als eine Minute ist. Damit der Alarm funktioniert, muss die Lambda-Funktion in der Lage sein, eine Liste von Zeitstempeln zurückzugeben, die mit einer beliebigen Minute beginnen, nicht nur mit einem Vielfachen der Zeitraumlänge. Diese Zeitstempel müssen einen Abstand von einer Zeitraumlänge haben.
Wenn die vom Lambda abgefragte Datenquelle daher nur Zeitstempel zurückgeben kann, die ein Vielfaches der Zeitraumlänge sind, sollte die Funktion die abgerufenen Daten „erneut abtasten“, damit sie den von der `GetMetricData`-Anforderung erwarteten Zeitstempeln entsprechen.
Beispielsweise wird ein Alarm mit einem Zeitraum von fünf Minuten jede Minute anhand von Fünf-Minuten-Fenstern ausgewertet, die sich jedes Mal um eine Minute verschieben. In diesem Fall.
+ Für die Alarmauswertung um 12:15:00 Uhr werden Datenpunkte mit den Zeitstempeln, und CloudWatch erwartet. `12:00:00` `12:05:00` `12:10:00`
+ CloudWatch Erwartet dann für die Alarmauswertung um 12:16:00 Uhr Datenpunkte mit den Zeitstempeln, und. `12:01:00` `12:06:00` `12:11:00`
+ Bei der CloudWatch Auswertung eines Alarms werden alle von der Lambda-Funktion zurückgegebenen Datenpunkte, die nicht mit den erwarteten Zeitstempeln übereinstimmen, gelöscht, und der Alarm wird anhand der verbleibenden erwarteten Datenpunkte ausgewertet. Wenn der Alarm beispielsweise bei der Auswertung ausgewertet wird, werden Daten mit den Zeitstempeln `12:15:00`, `12:00:00`, `12:05:00` und `12:10:00` erwartet. Wenn sie Daten mit den Zeitstempeln`12:00:00`,, und empfängt `12:05:00``12:06:00`, werden die Daten von gelöscht und `12:10:00` der Alarm `12:06:00` wird anhand der anderen Zeitstempel CloudWatch ausgewertet.
Für die nächste Auswertung um `12:16:00` werden dann Daten mit den Zeitstempeln `12:01:00`, `12:06:00` und `12:11:00` erwartet. Wenn nur die Daten mit den Zeitstempeln `12:00:00`, `12:05:00` und `12:10:00` vorliegen, werden all diese Datenpunkte um 12:16:00 Uhr ignoriert und der Alarm geht in den Zustand über, den Sie dem Alarm für die Behandlung fehlender Daten angegeben haben. Weitere Informationen finden Sie unter [Auswertung von Alarmen](alarm-evaluation.md).
+ Es wird empfohlen, diese Alarme zu erstellen, um Maßnahmen zu ergreifen, wenn sie in den `INSUFFICIENT_DATA`-Zustand wechseln, da bei mehreren Anwendungsfällen mit Lambda-Funktionsausfällen der Alarm auf `INSUFFICIENT_DATA` wechselt, unabhängig davon, wie Sie den Alarm zur Behandlung fehlender Daten einstellen.
+ Wenn die Lambda-Funktion einen Fehler zurückgibt:
+ Wenn beim Aufrufen der Lambda-Funktion ein Berechtigungsproblem auftritt, beginnt der Alarm mit fehlenden Datenübergängen, je nachdem, wie Sie den Alarm bei der Erstellung für die Behandlung fehlender Daten angegeben haben.
+ Jeder andere Fehler, der von der Lambda-Funktion kommt, führt dazu, dass der Alarm zu `INSUFFICIENT_DATA` wechselt.
+ Wenn die von der Lambda-Funktion angeforderte Metrik eine gewisse Verzögerung aufweist, sodass der letzte Datenpunkt immer fehlt, sollten Sie eine Problemumgehung verwenden. Sie können einen M-aus-N-Alarm erstellen oder den Bewertungszeitraum des Alarms verlängern. Weitere Informationen über M-aus-N-Alarmen finden Sie unter [Auswertung von Alarmen](alarm-evaluation.md).