

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.

# Auswertung von Alarmen
<a name="alarm-evaluation"></a>

## Metrikalarm-Status
<a name="alarm-states"></a>

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
<a name="alarm-evaluation-state"></a>

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
<a name="alarm-evaluation-settings"></a>

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
<a name="high-resolution-alarms"></a>

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
<a name="evaluate-multiday-alarm"></a>

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
<a name="alarms-and-missing-data"></a>

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
<a name="alarms-evaluating-missing-data"></a>

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
<a name="CloudWatch-alarms-avoiding-premature-transition"></a>

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
<a name="mi-missing-data-treatment"></a>

 **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
<a name="cloudwatch-metrics-insights-alarms-partial-data"></a>

## Auswerten von Teildaten aus einer Metrics-Insights-Abfrage
<a name="cloudwatch-metrics-insights-query-evaluation"></a>

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
<a name="multi-data-source-partial-data"></a>

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
<a name="percentiles-with-low-samples"></a>

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.