View a markdown version of this page

Einschränkungen - Amazon CloudWatch
Allgemeine CloudWatch KontingenteGrenzwerte, die für Alarme gelten, die auf metrischen mathematischen Ausdrücken basierenGrenzwerte, die für Alarme gelten, die auf Metrics Insights-Abfragen basierenGrenzwerte, die für Log-Alarme geltenGrenzwerte, die für Alarme gelten, die auf PromQL-Abfragen basierenGrenzwerte, die für Alarme gelten, die auf verbundenen Datenquellen basieren

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.

Einschränkungen

Allgemeine CloudWatch Kontingente

Informationen zu allgemeinen CloudWatch Servicekontingenten, die für Alarme gelten, finden Sie unterCloudWatch Servicekontingente.

Grenzwerte, die für Alarme gelten, die auf metrischen mathematischen Ausdrücken basieren

Alarme, die auf metrischen mathematischen Ausdrücken basieren, können auf maximal 10 Metriken verweisen. Dies ist eine feste Grenze, die nicht erhöht werden kann. Wenn Sie mehr als 10 Metriken in einem einzigen Alarm überwachen müssen, ziehen Sie einen der folgenden Ansätze in Betracht:

  • Wenn sich die Metriken im selben Namespace befinden, verwenden Sie in Ihrem Alarm eine Metrics Insights-Abfrage anstelle eines metrischen mathematischen Ausdrucks. Metrics Insights kann viele Metriken mit einer einzigen Abfrage aggregieren.

  • Pre-aggregate Metriken mithilfe einer Lambda-Funktion in benutzerdefinierte Metriken umwandeln und dann in Ihrem Alarmausdruck auf die aggregierten Metriken verweisen.

  • Teilen Sie Ihre Logik auf mehrere Alarme auf und kombinieren Sie sie mithilfe eines zusammengesetzten Alarms.

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:

  • Standardmäßig 200 Alarme, die die Metrics Insights-Abfrage pro Konto und Region verwenden

  • 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 (z. B. 95), StateReason wird „95 von 150 Zeitreihen als ALARM ausgewertet“

      • Wenn ALARM mehr als 100 Mitwirkende enthält (z. B. 105), StateReason wird „über 100 Zeitreihen, die als ALARM ausgewertet wurden“ angezeigt

    • Wenn die Anzahl der Attribute zu groß ist, kann außerdem die Anzahl der Mitwirkenden in ALARM 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 des Alarms EvaluationState wird der Wert PARTIAL_DATA für die folgenden Grenzwerte auf festgelegt:

    • Wenn die Metrics Insights-Abfrage mehr als 500 Zeitreihen zurückgibt.

    • Wenn die Metrics Insights-Abfrage mehr als 10.000 Metriken entspricht.

Weitere Informationen zu CloudWatch Servicekontingenten und -beschränkungen finden Sie unter Servicekontingente von CloudWatch Metrics Insights.

Grenzwerte, die für Log-Alarme gelten

Beachten CloudWatch Sie bei der Arbeit mit Alarmen die folgenden Grenzwerte:

Ressource Limit Einstellbar
PutLogAlarm Anfragen pro Sekunde 3 (Burst: 5) Nein
Maximale Anzahl an Log-Alarmen pro Konto ~1000 (begrenzt durch das von CloudWatch Logs AWS verwaltete Kontingent für geplante Abfragen) Nein
Maximale Anzahl an Mitwirkenden pro Abfrageausführung 500 Nein
Die maximale Anzahl der in ALARM erfassten Mitwirkenden 100 Nein
Maximale Anzahl an Feldern in der BY-Klausel 5 Nein
Maximale Anzahl an Protokollzeilen in der SNS-E-Mail-Benachrichtigung 50 (auch begrenzt durch das Nutzlastlimit für SNS-Benachrichtigungen von 256 KB) Nein

  • Bei Alarmen, bei denen mehrere Mitwirkende ausgewertet werden, wird die Anzahl der Mitwirkenden in ALARM auf 100 begrenzt.

    • Wenn es in ALARM weniger als 100 Mitwirkende gibt (z. B. 95), StateReason lautet der Wert „95 von 100 Mitwirkenden, die als ALARM bewertet wurden“.

    • Gibt es mehr als 100 Mitwirkende in ALARM (z. B. 105), StateReason lautet der Wert „Mehr als 100 Mitwirkende, die als ALARM bewertet wurden“.

    • Wenn die Anzahl der Attribute zu groß ist, kann die Anzahl der Mitwirkenden in ALARM auf weniger als 100 begrenzt werden.

  • Bei der Auswertung von Alarmen EvaluationState wird der auf gesetzt, PARTIAL_DATA wenn die Abfrage mehr als 500 Teilnehmergruppen zurückgibt.

  • Die Gesamtzahl der in einer Benachrichtigung enthaltenen Protokollzeilen wird durch die angeforderte Anzahl, die verfügbaren Gesamtergebnisse und die Größenbeschränkung der SNS-Nutzlast begrenzt. Wenn die Protokollzeilen das Nutzlastlimit überschreiten, werden weniger Zeilen aufgenommen.

Grenzwerte, die für Alarme gelten, die auf PromQL-Abfragen basieren

Beachten Sie bei der Arbeit mit CloudWatch Alarmen, die Prometheus Query Language (PromQL) -Abfragen verwenden, die folgenden Funktionseinschränkungen:

  • Ihr Konto kann standardmäßig bis zu 500 PromQL-Alarme in jeder Region enthalten.

  • Bei Alarmen, die mehrere Zeitreihen auswerten, wird die Anzahl der Mitwirkenden in ALARM auf 100 begrenzt.

    • Wenn ALARM weniger als 100 Mitwirkende enthält (z. B. 95), StateReason wird der Wert „95 Zeitreihen wurden zu ALARM ausgewertet“

    • Wenn ALARM mehr als 100 Mitwirkende enthält (z. B. 105), StateReason wird der Wert „Mehr als 100 Zeitreihen, die als ALARM ausgewertet wurden“ angezeigt

    • Wenn die Anzahl der Attribute zu groß ist, kann außerdem die Anzahl der Mitwirkenden in ALARM auf weniger als 100 begrenzt werden.

  • Die PromQL-Abfragegrenzwerte gelten für die maximale Anzahl von Zeitreihen, die analysiert oder zurückgegeben werden.

  • Bei der Auswertung des Alarms EvaluationState wird der auf den Wert gesetzt, PARTIAL_DATA wenn die PromQL-Abfrage mehr als 500 Zeitreihen zurückgibt.

Grenzwerte, die für Alarme gelten, die auf verbundenen Datenquellen basieren

  • Bei der CloudWatch Auswertung eines Alarms 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.

    • CloudWatch Erwartet bei der Auswertung des Alarms um 12:15:00 Uhr Datenpunkte mit den Zeitstempeln, und. 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 Zeitstempeln12:00:00,, und empfängt 12:05:0012: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.

  • 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.