Empfohlene Alarme

4XXError

Abmessungen: ApiName Bühne

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Rate von clientseitigen Fehlern. Dies kann auf ein Problem mit den Autorisierungs- oder Client-Anfrageparametern hinweisen. Es könnte auch bedeuten, dass eine Ressource entfernt wurde oder dass ein Client eine Ressource anfordert, die nicht existiert. Erwägen Sie, CloudWatch Logs zu aktivieren und nach Fehlern zu suchen, die die 4XX-Fehler verursachen könnten. Erwägen Sie außerdem, detaillierte CloudWatch Metriken zu aktivieren, um diese Metrik pro Ressource und Methode anzuzeigen und die Fehlerquelle einzugrenzen. Fehler können auch durch eine Überschreitung des konfigurierten Drosselungslimits verursacht werden. Wenn in den Antworten und Protokollen eine hohe und unerwartete Anzahl von 429-Fehlern gemeldet wird, folgen Sie dieser Anleitung, um dieses Problem zu beheben.

Absicht: Dieser Alarm kann eine hohe Anzahl von clientseitigen Fehlern bei den API-Gateway-Anfragen erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Mit dem vorgeschlagenen Schwellenwert wird erkannt, wenn bei mehr als 5 % der gesamten Anfragen 4XX-Fehler auftreten. Sie können den Schwellenwert jedoch so einstellen, dass er dem Datenverkehr der Anfragen sowie den akzeptablen Fehlerraten entspricht. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu bestimmen, und den Schwellenwert dann entsprechend anpassen. Bei häufig auftretenden 4XX-Fehlern muss ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

5XXError

Abmessungen:ApiName, Stufe

Alarmbeschreibung: Dieser Alarm hilft dabei, eine hohe Rate serverseitiger Fehler zu erkennen. Dies kann darauf hindeuten, dass im API-Backend, im Netzwerk oder bei der Integration zwischen dem API-Gateway und der Backend-API etwas nicht stimmt. Diese Dokumentation kann Ihnen helfen, die Ursache von 5XX-Fehlern zu beheben.

Absicht: Dieser Alarm kann hohe Raten serverseitiger Fehler bei den API-Gateway-Anfragen erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Mit dem vorgeschlagenen Schwellenwert wird erkannt, wenn bei mehr als 5 % der gesamten Anfragen 5XX-Fehler auftreten. Sie können den Schwellenwert jedoch an den Datenverkehr der Anfragen sowie an die akzeptablen Fehlerraten anpassen. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu ermitteln, und den Schwellenwert dann entsprechend anpassen. Bei häufig auftretenden 5XX-Fehlern muss ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: GREATER_THAN_THRESHOLD

Count

Abmessungen: ApiName Bühne

Alarmbeschreibung: Dieser Alarm hilft dabei, ein geringes Datenverkehrsaufkommen für die REST-API-Phase zu erkennen. Dies kann ein Hinweis auf ein Problem mit der Anwendung sein, die die API aufruft, z. B. die Verwendung falscher Endpunkte. Es könnte auch ein Hinweis auf ein Problem mit der Konfiguration oder den Berechtigungen der API sein, so dass sie für Kunden nicht erreichbar ist.

Absicht: Dieser Alarm kann ein unerwartet geringes Verkehrsaufkommen in der REST-API-Phase erkennen. Wir empfehlen Ihnen, diesen Alarm zu erstellen, wenn Ihre API unter normalen Bedingungen eine vorhersehbare und konstante Anzahl von Anfragen erhält. Wenn Sie detaillierte CloudWatch Messwerte aktiviert haben und das normale Verkehrsaufkommen pro Methode und Ressource vorhersagen können, empfehlen wir Ihnen, alternative Alarme zu erstellen, um den Rückgang des Verkehrsaufkommens für jede Ressource und Methode genauer überwachen zu können. Dieser Alarm wird nicht für APIs empfohlen, die keinen konstanten und gleichmäßigen Datenverkehr erwarten.

Statistik: SampleCount

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf der Grundlage historischer Datenanalysen fest, um zu ermitteln, wie viele Anfragen für Ihre API zu erwarten sind. Wenn Sie den Schwellenwert auf einen sehr hohen Wert setzen, kann dies dazu führen, dass der Alarm in Zeiten mit normalem und erwartungsgemäß geringem Datenverkehr zu empfindlich reagiert. Umgekehrt könnte eine Einstellung auf einen sehr niedrigen Wert dazu führen, dass der Alarm ungewöhnliche kleinere Rückgänge des Verkehrsaufkommens übersieht.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: LESS_THAN_THRESHOLD

Count

Dimensionen: PhaseApiName, Ressource, Methode

Alarmbeschreibung: Dieser Alarm hilft dabei, ein geringes Datenverkehrsaufkommen für die REST-API-Ressource und -Methode in der Phase zu erkennen. Dies kann auf ein Problem mit dem Aufruf der API durch die Anwendung hinweisen, z. B. die Verwendung falscher Endpunkte. Es könnte auch ein Hinweis auf ein Problem mit der Konfiguration oder den Berechtigungen der API sein, so dass sie für Kunden nicht erreichbar ist.

Absicht: Dieser Alarm kann ein unerwartet geringes Datenverkehrsaufkommen für die REST-API-Ressource und -Methode in der Phase erkennen. Wir empfehlen Ihnen, diesen Alarm zu erstellen, wenn Ihre API unter normalen Bedingungen eine vorhersehbare und konstante Anzahl von Anfragen erhält. Dieser Alarm wird nicht für APIs empfohlen, die keinen konstanten und gleichmäßigen Datenverkehr erwarten.

Statistik: SampleCount

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf der Grundlage historischer Datenanalysen fest, um zu ermitteln, wie viele Anfragen für Ihre API zu erwarten sind. Wenn Sie den Schwellenwert auf einen sehr hohen Wert setzen, kann dies dazu führen, dass der Alarm in Zeiten mit normalem und erwartungsgemäß geringem Datenverkehr zu empfindlich reagiert. Umgekehrt könnte eine Einstellung auf einen sehr niedrigen Wert dazu führen, dass der Alarm ungewöhnliche kleinere Rückgänge des Verkehrsaufkommens übersieht.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: LESS_THAN_THRESHOLD

Count

Abmessungen:ApiId, Bühne

Alarmbeschreibung: Dieser Alarm hilft dabei, ein geringes Datenverkehrsaufkommen für die HTTP-API-Phase zu erkennen. Dies kann auf ein Problem mit dem Aufruf der API durch die Anwendung hinweisen, z. B. die Verwendung falscher Endpunkte. Es könnte auch ein Hinweis auf ein Problem mit der Konfiguration oder den Berechtigungen der API sein, so dass sie für Kunden nicht erreichbar ist.

Absicht: Dieser Alarm kann ein unerwartet geringes Datenverkehrsaufkommen in der HTTP-API-Phase erkennen. Wir empfehlen Ihnen, diesen Alarm zu erstellen, wenn Ihre API unter normalen Bedingungen eine vorhersehbare und konstante Anzahl von Anfragen erhält. Wenn Sie detaillierte CloudWatch Metriken aktiviert haben und das normale Verkehrsaufkommen pro Route vorhersagen können, empfehlen wir Ihnen, alternative Alarme zu erstellen, um den Rückgang des Verkehrsaufkommens für jede Route genauer überwachen zu können. Dieser Alarm wird nicht für APIs empfohlen, die keinen konstanten und gleichmäßigen Datenverkehr erwarten.

Statistik: SampleCount

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf der Grundlage historischer Datenanalysen fest, um zu ermitteln, wie viele Anfragen für Ihre API zu erwarten sind. Wenn Sie den Schwellenwert auf einen sehr hohen Wert setzen, kann dies dazu führen, dass der Alarm in Zeiten mit normalem und erwartungsgemäß geringem Datenverkehr zu empfindlich reagiert. Umgekehrt könnte eine Einstellung auf einen sehr niedrigen Wert dazu führen, dass der Alarm ungewöhnliche kleinere Rückgänge des Verkehrsaufkommens übersieht.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: LESS_THAN_THRESHOLD

Count

Dimensionen: PhaseApiId, Ressource, Methode

Alarmbeschreibung: Dieser Alarm hilft dabei, ein geringes Datenverkehrsaufkommen für die HTTP-API-Route in dieser Phase zu erkennen. Dies kann auf ein Problem mit dem Aufruf der API durch die Anwendung hinweisen, z. B. die Verwendung falscher Endpunkte. Dies könnte auch auf ein Problem mit der Konfiguration oder den Berechtigungen der API hinweisen, sodass sie für Clients nicht erreichbar ist.

Absicht: Dieser Alarm kann ein unerwartet geringes Datenverkehrsaufkommen in der HTTP-API-Route in dieser Phase erkennen. Wir empfehlen Ihnen, diesen Alarm zu erstellen, wenn Ihre API unter normalen Bedingungen eine vorhersehbare und konstante Anzahl von Anfragen erhält. Dieser Alarm wird nicht für APIs empfohlen, die keinen konstanten und gleichmäßigen Datenverkehr erwarten.

Statistik: SampleCount

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf der Grundlage historischer Datenanalysen fest, um zu ermitteln, wie viele Anfragen für Ihre API zu erwarten sind. Wenn Sie den Schwellenwert auf einen sehr hohen Wert setzen, kann dies dazu führen, dass der Alarm in Zeiten mit normalem und erwartungsgemäß geringem Datenverkehr zu empfindlich reagiert. Umgekehrt könnte eine Einstellung auf einen sehr niedrigen Wert dazu führen, dass der Alarm ungewöhnliche kleinere Rückgänge des Verkehrsaufkommens übersieht.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: LESS_THAN_THRESHOLD

IntegrationLatency

Abmessungen:ApiId, Bühne

Alarmbeschreibung: Dieser Alarm hilft zu erkennen, ob für die API-Anfragen in einer Phase eine hohe Integrationslatenz besteht. Sie können den IntegrationLatency-Metrikwert mit der entsprechenden Latenzmetrik Ihres Backends korrelieren, z. B. der Duration-Metrik für Lambda-Integrationen. Auf diese Weise können Sie feststellen, ob das API-Backend aufgrund von Leistungsproblemen mehr Zeit benötigt, um Anfragen von Clients zu verarbeiten, oder ob durch die Initialisierung oder den Kaltstart ein anderer Overhead entsteht. Erwägen Sie außerdem, CloudWatch Logs für Ihre API zu aktivieren und die Protokolle auf Fehler zu überprüfen, die zu den Problemen mit der hohen Latenz führen könnten. Erwägen Sie außerdem, detaillierte CloudWatch Metriken zu aktivieren, um einen Überblick über diese Metrik pro Route zu erhalten, damit Sie die Ursache der Integrationslatenz eingrenzen können.

Absicht: Dieser Alarm kann erkennen, wenn die API-Gateway-Anfragen in einer Phase eine hohe Integrationslatenz aufweisen. Wir empfehlen diesen Alarm für WebSocket APIs und halten ihn für HTTP-APIs für optional, da es dort bereits separate Alarmempfehlungen für die Latenzmetrik gibt. Wenn Sie detaillierte CloudWatch Metriken aktiviert haben und unterschiedliche Leistungsanforderungen für die Integrationslatenz pro Route haben, empfehlen wir Ihnen, alternative Alarme zu erstellen, um die Integrationslatenz für jede Route genauer überwachen zu können.

Statistik: p90

Empfohlener Schwellenwert: 2 000,0

Begründung des Schwellenwerts: Der vorgeschlagene Wert des Schwellenwerts funktioniert nicht für alle API-Workloads. Sie können ihn jedoch als Ausgangspunkt für den Schwellenwert verwenden. Anschließend können Sie je nach Workload und akzeptablen Latenz-, Leistungs- und SLA-Anforderungen für die API unterschiedliche Schwellenwerte auswählen. Wenn es für die API generell akzeptabel ist, eine höhere Latenz zu haben, legen Sie einen höheren Schwellenwert fest, um den Alarm weniger empfindlich zu machen. Wenn jedoch erwartet wird, dass die API Antworten nahezu in Echtzeit liefert, legen Sie einen niedrigeren Schwellenwert fest. Sie können auch historische Daten analysieren, um die erwartete Basislatenz für den Anwendungs-Workload zu ermitteln. Anhand dieser Daten können Sie dann den Schwellenwert entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

IntegrationLatency

Abmessungen:ApiId, Etappe, Route

Beschreibung des Alarms: Dieser Alarm hilft zu erkennen, ob bei WebSocket API-Anfragen für eine Route in einer Phase eine hohe Integrationslatenz besteht. Sie können den IntegrationLatency-Metrikwert mit der entsprechenden Latenzmetrik Ihres Backends korrelieren, z. B. der Duration-Metrik für Lambda-Integrationen. Auf diese Weise können Sie feststellen, ob das API-Backend aufgrund von Leistungsproblemen mehr Zeit benötigt, um Anfragen von Clients zu verarbeiten, oder ob durch die Initialisierung oder den Kaltstart ein anderer Overhead entsteht. Erwägen Sie außerdem, CloudWatch Logs für Ihre API zu aktivieren und die Protokolle auf Fehler zu überprüfen, die die Probleme mit der hohen Latenz verursachen könnten.

Absicht: Dieser Alarm kann erkennen, wenn die API-Gateway-Anfragen für eine Route in einer Phase eine hohe Integrationslatenz aufweisen.

Statistik: p90

Empfohlener Schwellenwert: 2 000,0

Begründung des Schwellenwerts: Der vorgeschlagene Wert des Schwellenwerts funktioniert nicht für alle API-Workloads. Sie können ihn jedoch als Ausgangspunkt für den Schwellenwert verwenden. Anschließend können Sie je nach Workload und akzeptablen Latenz-, Leistungs- und SLA-Anforderungen für die API unterschiedliche Schwellenwerte auswählen. Wenn es für die API generell akzeptabel ist, eine höhere Latenz zu haben, können Sie einen höheren Schwellenwert festlegen, um den Alarm weniger empfindlich zu machen. Wenn jedoch erwartet wird, dass die API Antworten nahezu in Echtzeit liefert, legen Sie einen niedrigeren Schwellenwert fest. Sie können auch historische Daten analysieren, um die erwartete Basislatenz für den Anwendungs-Workload zu ermitteln. Anhand dieser Daten können Sie dann den Schwellenwert entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latency

Abmessungen:ApiName, Bühne

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Latenz in einer Phase. Suchen Sie den IntegrationLatency-Metrikwert, um die Latenz des API-Backends zu überprüfen. Wenn die beiden Metriken größtenteils übereinstimmen, ist das API-Backend die Ursache für die höhere Latenz, und Sie sollten dort nach Problemen suchen. Erwägen Sie auch, CloudWatch Protokolle zu aktivieren und nach Fehlern zu suchen, die die hohe Latenz verursachen könnten. Erwägen Sie außerdem, detaillierte CloudWatch Metriken zu aktivieren, um diese Metrik pro Ressource und Methode anzuzeigen und die Ursache der Latenz einzugrenzen. Falls zutreffend, lesen Sie die Anleitungen zur Fehlerbehebung mit Lambda oder zur Fehlerbehebung für Edge-optimierte API-Endpunkte.

Absicht: Dieser Alarm kann erkennen, wenn die API-Gateway-Anfragen in einer Phase eine hohe Latenz aufweisen. Wenn Sie detaillierte CloudWatch Metriken aktiviert haben und für jede Methode und Ressource unterschiedliche Anforderungen an die Latenzleistung haben, empfehlen wir Ihnen, alternative Alarme zu erstellen, um die Latenz für jede Ressource und Methode genauer überwachen zu können.

Statistik: p90

Empfohlener Schwellenwert: 2 500,0

Begründung des Schwellenwerts: Der vorgeschlagene Schwellenwert funktioniert nicht für alle API-Workloads. Sie können ihn jedoch als Ausgangspunkt für den Schwellenwert verwenden. Anschließend können Sie je nach Workload und akzeptablen Latenz-, Leistungs- und SLA-Anforderungen für die API unterschiedliche Schwellenwerte auswählen. Wenn es für die API generell akzeptabel ist, eine höhere Latenz zu haben, können Sie einen höheren Schwellenwert festlegen, um den Alarm weniger empfindlich zu machen. Wenn jedoch erwartet wird, dass die API Antworten nahezu in Echtzeit liefert, legen Sie einen niedrigeren Schwellenwert fest. Sie können auch historische Daten analysieren, um die erwartete Basislatenz für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latency

Dimensionen: PhaseApiName, Ressource, Methode

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Latenz für eine Ressource und Methode in einer Phase. Suchen Sie den IntegrationLatency-Metrikwert, um die Latenz des API-Backends zu überprüfen. Wenn die beiden Metriken größtenteils übereinstimmen, ist das API-Backend die Ursache für die höhere Latenz, und Sie sollten dort nach Leistungsproblemen suchen. Erwägen Sie auch, CloudWatch Protokolle zu aktivieren und nach Fehlern zu suchen, die die hohe Latenz verursachen könnten. Falls zutreffend, finden Sie auch die Anleitungen zur Fehlerbehebung mit Lambda oder zur Fehlerbehebung für Edge-optimierte API-Endpunkte.

Absicht: Dieser Alarm kann erkennen, wenn die API-Gateway-Anfragen für eine Ressource und Methode in einer Phase eine hohe Latenz aufweisen.

Statistik: p90

Empfohlener Schwellenwert: 2 500,0

Begründung des Schwellenwerts: Der vorgeschlagene Wert des Schwellenwerts funktioniert nicht für alle API-Workloads. Sie können ihn jedoch als Ausgangspunkt für den Schwellenwert verwenden. Anschließend können Sie je nach Workload und akzeptablen Latenz-, Leistungs- und SLA-Anforderungen für die API unterschiedliche Schwellenwerte auswählen. Wenn es für die API generell akzeptabel ist, eine höhere Latenz zu haben, können Sie einen höheren Schwellenwert festlegen, um den Alarm weniger empfindlich zu machen. Wenn jedoch erwartet wird, dass die API Antworten nahezu in Echtzeit liefert, legen Sie einen niedrigeren Schwellenwert fest. Sie können auch historische Daten analysieren, um die erwartete Basislatenz für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latency

Abmessungen:ApiId, Bühne

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Latenz in einer Phase. Suchen Sie den IntegrationLatency-Metrikwert, um die Latenz des API-Backends zu überprüfen. Wenn die beiden Metriken größtenteils übereinstimmen, ist das API-Backend die Ursache für die höhere Latenz, und Sie sollten dort nach Leistungsproblemen suchen. Erwägen Sie auch, CloudWatch Logs zu aktivieren und nach Fehlern zu suchen, die die hohe Latenz verursachen könnten. Erwägen Sie außerdem, detaillierte CloudWatch Metriken zu aktivieren, um diese Metrik pro Route anzuzeigen und die Ursache der Latenz einzugrenzen. Falls zutreffend, können Sie auch den Leitfaden zur Fehlerbehebung mit Lambda-Integrationen lesen.

Absicht: Dieser Alarm kann erkennen, wenn die API-Gateway-Anfragen in einer Phase eine hohe Latenz aufweisen. Wenn Sie detaillierte CloudWatch Metriken aktiviert haben und unterschiedliche Anforderungen an die Latenzleistung pro Route haben, empfehlen wir Ihnen, alternative Alarme zu erstellen, um die Latenz für jede Route genauer überwachen zu können.

Statistik: p90

Empfohlener Schwellenwert: 2 500,0

Begründung des Schwellenwerts: Der vorgeschlagene Wert des Schwellenwerts funktioniert nicht für alle API-Workloads. Er kann jedoch als Ausgangspunkt für den Schwellenwert verwendet werden. Anschließend können Sie je nach Workload und akzeptablen Latenz-, Leistungs- und SLA-Anforderungen für die API unterschiedliche Schwellenwerte auswählen. Wenn es akzeptabel ist, dass die API generell eine höhere Latenz aufweist, können Sie einen höheren Schwellenwert festlegen, um sie weniger empfindlich zu machen. Wenn jedoch erwartet wird, dass die API Antworten nahezu in Echtzeit liefert, legen Sie einen niedrigeren Schwellenwert fest. Sie können auch historische Daten analysieren, um die erwartete Basislatenz für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latency

Dimensionen: PhaseApiId, Ressource, Methode

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Latenz für eine Route in einer Phase. Suchen Sie den IntegrationLatency-Metrikwert, um die Latenz des API-Backends zu überprüfen. Wenn die beiden Metriken größtenteils übereinstimmen, ist das API-Backend die Ursache für die höhere Latenz und sollte auf Leistungsprobleme untersucht werden. Erwägen Sie auch, CloudWatch Protokolle zu aktivieren und nach Fehlern zu suchen, die die hohe Latenz verursachen könnten. Falls zutreffend, können Sie auch den Leitfaden zur Fehlerbehebung mit Lambda-Integrationen lesen.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, wenn die API-Gateway-Anfragen für eine Route in einer Phase eine hohe Latenz aufweisen.

Statistik: p90

Empfohlener Schwellenwert: 2 500,0

Begründung des Schwellenwerts: Der vorgeschlagene Wert des Schwellenwerts funktioniert nicht für alle API-Workloads. Er kann jedoch als Ausgangspunkt für den Schwellenwert verwendet werden. Anschließend können Sie je nach Workload und akzeptablen Latenz-, Leistungs- und SLA-Anforderungen für die API unterschiedliche Schwellenwerte auswählen. Wenn es für die API generell akzeptabel ist, eine höhere Latenz zu haben, können Sie einen höheren Schwellenwert festlegen, um den Alarm weniger empfindlich zu machen. Wenn jedoch erwartet wird, dass die API Antworten nahezu in Echtzeit liefert, legen Sie einen niedrigeren Schwellenwert fest. Sie können auch historische Daten analysieren, um die erwartete Basislatenz für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

4xx

Abmessungen:ApiId, Bühne

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Rate von clientseitigen Fehlern. Dies kann auf ein Problem mit den Autorisierungs- oder Client-Anfrageparametern hinweisen. Es könnte auch bedeuten, dass eine Route entfernt wurde oder ein Client eine anfordert, die in der API nicht vorhanden ist. Erwägen Sie, CloudWatch Logs zu aktivieren und nach Fehlern zu suchen, die die 4xx-Fehler verursachen könnten. Erwägen Sie außerdem, detaillierte CloudWatch Metriken zu aktivieren, um diese Metrik pro Route anzuzeigen, damit Sie die Fehlerquelle eingrenzen können. Fehler können auch durch eine Überschreitung des konfigurierten Drosselungslimits verursacht werden. Wenn in den Antworten und Protokollen eine hohe und unerwartete Anzahl von 429-Fehlern gemeldet wird, folgen Sie dieser Anleitung, um dieses Problem zu beheben.

Absicht: Dieser Alarm kann eine hohe Anzahl von clientseitigen Fehlern bei den API-Gateway-Anfragen erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Mit dem vorgeschlagenen Schwellenwert wird erkannt, wenn bei mehr als 5 % der gesamten Anfragen 4XX-Fehler auftreten. Sie können den Schwellenwert jedoch so einstellen, dass er dem Datenverkehr der Anfragen sowie den akzeptablen Fehlerraten entspricht. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu bestimmen, und den Schwellenwert dann entsprechend anpassen. Bei häufig auftretenden 4XX-Fehlern muss ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

5xx

Abmessungen:ApiId, Stufe

Alarmbeschreibung: Dieser Alarm hilft dabei, eine hohe Rate serverseitiger Fehler zu erkennen. Dies kann darauf hindeuten, dass im API-Backend, im Netzwerk oder bei der Integration zwischen dem API-Gateway und der Backend-API etwas nicht stimmt. Diese Dokumentation kann Ihnen helfen, die Ursache für 5XX-Fehler zu beheben.

Absicht: Dieser Alarm kann hohe Raten serverseitiger Fehler bei den API-Gateway-Anfragen erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Mit dem vorgeschlagenen Schwellenwert wird erkannt, wenn bei mehr als 5 % der gesamten Anfragen 5XX-Fehler auftreten. Sie können den Schwellenwert jedoch so einstellen, dass er dem Datenverkehr der Anfragen sowie den akzeptablen Fehlerraten entspricht. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu ermitteln. Anschließend können Sie den Schwellenwert entsprechend anpassen. Bei häufig auftretenden 5XX-Fehlern muss ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: GREATER_THAN_THRESHOLD

MessageCount

Abmessungen: ApiId Bühne

Beschreibung des Alarms: Dieser Alarm hilft dabei, ein geringes Verkehrsaufkommen in der WebSocket API-Phase zu erkennen. Dies kann auf ein Problem beim Aufruf der API durch Clients hinweisen, z. B. die Verwendung falscher Endpunkte oder Probleme mit dem Backend, das Nachrichten an Clients sendet. Dies könnte auch auf ein Problem mit der Konfiguration oder den Berechtigungen der API hinweisen, sodass sie für Clients nicht erreichbar ist.

Absicht: Dieser Alarm kann ein unerwartet geringes Verkehrsaufkommen in der WebSocket API-Phase erkennen. Wir empfehlen Ihnen, diesen Alarm zu erstellen, wenn Ihre API unter normalen Bedingungen eine vorhersehbare und konsistente Anzahl von Nachrichten empfängt und sendet. Wenn Sie detaillierte CloudWatch Metriken aktiviert haben und das normale Verkehrsaufkommen pro Route vorhersagen können, ist es besser, alternative Alarme zu diesem zu erstellen, um den Rückgang des Verkehrsaufkommens für jede Route genauer überwachen zu können. Wir empfehlen diesen Alarm nicht für APIs, die keinen konstanten und konsistenten Datenverkehr erwarten.

Statistik: SampleCount

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf der Grundlage historischer Datenanalysen fest, um zu ermitteln, wie hoch die erwartete Anzahl an Nachrichten für Ihre API ist. Wenn Sie den Schwellenwert auf einen sehr hohen Wert setzen, kann dies dazu führen, dass der Alarm in Zeiten mit normalem und erwartungsgemäß geringem Datenverkehr zu empfindlich reagiert. Umgekehrt könnte eine Einstellung auf einen sehr niedrigen Wert dazu führen, dass der Alarm ungewöhnliche kleinere Rückgänge des Verkehrsaufkommens übersieht.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: LESS_THAN_THRESHOLD

MessageCount

Abmessungen:ApiId, Etappe, Route

Beschreibung des Alarms: Dieser Alarm hilft dabei, ein geringes Verkehrsaufkommen für die WebSocket API-Route in der Phase zu erkennen. Dies kann auf ein Problem beim Aufrufen der API durch die Clients hinweisen, z. B. auf die Verwendung falscher Endpunkte oder auf Probleme beim Senden von Nachrichten an Clients durch das Backend. Dies könnte auch auf ein Problem mit der Konfiguration oder den Berechtigungen der API hinweisen, sodass sie für Clients nicht erreichbar ist.

Absicht: Dieser Alarm kann ein unerwartet geringes Verkehrsaufkommen für die WebSocket API-Route in der Phase erkennen. Wir empfehlen Ihnen, diesen Alarm zu erstellen, wenn Ihre API unter normalen Bedingungen eine vorhersehbare und konsistente Anzahl von Nachrichten empfängt und sendet. Wir empfehlen diesen Alarm nicht für APIs, die keinen konstanten und konsistenten Datenverkehr erwarten.

Statistik: SampleCount

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf der Grundlage historischer Datenanalysen fest, um zu ermitteln, wie hoch die erwartete Anzahl an Nachrichten für Ihre API ist. Wenn Sie den Schwellenwert auf einen sehr hohen Wert setzen, kann dies dazu führen, dass der Alarm in Zeiten mit normalem und erwartungsgemäß geringem Datenverkehr zu empfindlich reagiert. Umgekehrt könnte eine Einstellung auf einen sehr niedrigen Wert dazu führen, dass der Alarm ungewöhnliche kleinere Rückgänge des Verkehrsaufkommens übersieht.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: LESS_THAN_THRESHOLD

ClientError

Abmessungen:ApiId, Bühne

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Rate von Client-Fehlern. Dies kann auf ein Problem mit den Autorisierungs- oder Nachrichtenparametern hinweisen. Es könnte auch bedeuten, dass eine Route entfernt wurde oder ein Client eine anfordert, die in der API nicht vorhanden ist. Erwägen Sie, CloudWatch Logs zu aktivieren und nach Fehlern zu suchen, die die 4xx-Fehler verursachen könnten. Erwägen Sie außerdem, detaillierte CloudWatch Metriken zu aktivieren, um diese Metrik pro Route anzuzeigen, damit Sie die Fehlerquelle eingrenzen können. Fehler können auch durch eine Überschreitung des konfigurierten Drosselungslimits verursacht werden. Wenn in den Antworten und Protokollen eine hohe und unerwartete Anzahl von 429-Fehlern gemeldet wird, folgen Sie dieser Anleitung, um dieses Problem zu beheben.

Absicht: Dieser Alarm kann eine hohe Anzahl von Client-Fehlern für die WebSocket API-Gateway-Nachrichten erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Mit dem vorgeschlagenen Schwellenwert wird erkannt, wenn bei mehr als 5 % der gesamten Anfragen 4XX-Fehler auftreten. Sie können den Schwellenwert sowohl an den Datenverkehr der Anfragen als auch an Ihre akzeptablen Fehlerraten anpassen. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen. Bei häufig auftretenden 4XX-Fehlern muss ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

ExecutionError

Abmessungen:ApiId, Bühne

Alarmbeschreibung: Dieser Alarm hilft dabei, eine hohe Anzahl von Ausführungsfehlern zu erkennen. Dies kann durch 5XX-Fehler aufgrund Ihrer Integration, durch Berechtigungsprobleme oder durch andere Faktoren verursacht werden, die einen erfolgreichen Aufruf der Integration verhindern, z. B. wenn die Integration gedrosselt oder gelöscht wird. Erwägen Sie, CloudWatch Logs für Ihre API zu aktivieren und die Logs auf Art und Ursache der Fehler zu überprüfen. Erwägen Sie außerdem, detaillierte CloudWatch Metriken zu aktivieren, um einen Überblick über diese Metrik pro Route zu erhalten und so die Fehlerquelle einzugrenzen. Diese Dokumentation kann Ihnen auch dabei helfen, die Ursache von Verbindungsfehlern zu beheben.

Absicht: Dieser Alarm kann eine hohe Anzahl von Ausführungsfehlern für die WebSocket API-Gateway-Nachrichten erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Der vorgeschlagene Schwellenwert erkennt, wenn bei mehr als 5 % der gesamten Anfragen Ausführungsfehler auftreten. Sie können den Schwellenwert sowohl an den Datenverkehr der Anfragen als auch an Ihre akzeptablen Fehlerraten anpassen. Sie können historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen. Bei häufig auftretenden Ausführungsfehlern muss ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: GREATER_THAN_THRESHOLD

GroupInServiceCapacity

Abmessungen: AutoScalingGroupName

Alarmbeschreibung: Dieser Alarm hilft zu erkennen, wenn die Kapazität in der Gruppe unter der gewünschten Kapazität liegt, die für Ihren Workload erforderlich ist. Um Fehler zu beheben, überprüfen Sie Ihre Skalierungsaktivitäten auf Startfehler und stellen Sie sicher, dass Ihre gewünschte Kapazitätskonfiguration korrekt ist.

Absicht: Dieser Alarm kann eine geringe Verfügbarkeit in Ihrer Auto-Scaling-Gruppe aufgrund von Startfehlern oder unterbrochenen Starts erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der Schwellenwert sollte der Mindestkapazität entsprechen, die zur Ausführung Ihres Workloads erforderlich ist. In den meisten Fällen können Sie dies so einstellen, dass es der GroupDesiredCapacity Metrik entspricht.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: LESS_THAN_THRESHOLD

5 xxErrorRate

Abmessungen:DistributionId, Region=Global

Beschreibung des Alarms: Dieser Alarm überwacht den Prozentsatz der 5xx-Fehlerantworten von Ihrem Ursprungsserver, damit Sie feststellen können, ob der CloudFront Dienst Probleme hat. Unter Fehlerbehebung bei Fehlerantworten von Ihrem Ursprungsserver finden Sie Informationen, die Ihnen helfen, die Probleme mit Ihrem Server zu verstehen. Außerdem können Sie zusätzliche Metriken aktivieren, um detaillierte Fehlermetriken zu erhalten.

Absicht: Dieser Alarm wird verwendet, um Probleme mit der Bearbeitung von Anfragen vom Ursprungsserver oder Probleme mit der Kommunikation zwischen CloudFront und Ihrem Ursprungsserver zu erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von der Toleranz für 5XX-Antworten ab. Sie können historische Daten und Trends analysieren und dann den Schwellenwert entsprechend festlegen. Da 5XX-Fehler durch vorübergehende Probleme verursacht werden können, empfehlen wir, den Schwellenwert auf einen Wert größer als 0 festzulegen, damit der Alarm nicht zu empfindlich reagiert.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

OriginLatency

Abmessungen:DistributionId, Region=Global

Alarmbeschreibung: Der Alarm hilft zu überwachen, ob der Ursprungsserver zu lange braucht, um zu antworten. Wenn der Server zu lange braucht, um zu antworten, kann dies zu einem Timeout führen. Lesen Sie, wie Sie verzögerte Antworten von Anwendungen auf Ihrem Ursprungsserver finden und beheben können, wenn Sie konstant hohe OriginLatency-Werte feststellen.

Absicht: Dieser Alarm wird verwendet, um Probleme zu erkennen, bei denen der Ursprungsserver zu lange braucht, um zu antworten.

Statistik: p90

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Sie sollten den Wert von etwa 80 % des ursprünglichen Antwort-Timeouts berechnen und das Ergebnis als Schwellenwert verwenden. Wenn diese Metrik durchweg in der Nähe des Timeout-Werts für die Ursprungsserver-Antwort liegt, treten möglicherweise 504-Fehler auf.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

FunctionValidationErrors

Dimensionen:DistributionId,, Region=Global FunctionName

Beschreibung des Alarms: Dieser Alarm hilft Ihnen dabei, Validierungsfehler von CloudFront Funktionen zu überwachen, sodass Sie Maßnahmen ergreifen können, um sie zu beheben. Analysieren Sie die CloudWatch Funktionsprotokolle und schauen Sie sich den Funktionscode an, um die Ursache des Problems zu finden und zu beheben. Informationen zu den häufigsten Fehlkonfigurationen von Funktionen finden Sie unter Einschränkungen für CloudFront Edge-Funktionen.

Absicht: Dieser Alarm wird verwendet, um Validierungsfehler von CloudFront Funktionen zu erkennen.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Ein Wert über 0 weist auf einen Validierungsfehler hin. Wir empfehlen, den Schwellenwert auf 0 zu setzen, da Validierungsfehler auf ein Problem hinweisen, wenn CloudFront Funktionen wieder an übergeben CloudFront werden. Benötigt beispielsweise CloudFront den HTTP-Host-Header, um eine Anfrage zu verarbeiten. Nichts hindert einen Benutzer daran, den Host-Header in seinem CloudFront Funktionscode zu löschen. Aber wenn die Antwort CloudFront zurückkommt und der Host-Header fehlt, CloudFront wird ein Validierungsfehler ausgegeben.

Zeitraum: 60

Datenpunkte bis Alarm: 2

Auswertungszeiträume: 2

Vergleichsoperator: GREATER_THAN_THRESHOLD

FunctionExecutionErrors

Abmessungen:DistributionId, FunctionName, Region=Global

Beschreibung des Alarms: Dieser Alarm hilft Ihnen dabei, Ausführungsfehler von CloudFront Funktionen zu überwachen, sodass Sie Maßnahmen ergreifen können, um sie zu beheben. Analysieren Sie die CloudWatch Funktionsprotokolle und schauen Sie sich den Funktionscode an, um die Ursache des Problems zu finden und zu beheben.

Absicht: Dieser Alarm wird verwendet, um Ausführungsfehler von CloudFront Funktionen zu erkennen.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Wir empfehlen, den Schwellenwert auf 0 zu setzen, da ein Ausführungsfehler auf ein Problem mit dem Code hinweist, das zur Laufzeit auftritt.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

FunctionThrottles

Dimensionen:DistributionId, FunctionName, Region=Global

Beschreibung des Alarms: Dieser Alarm hilft Ihnen zu überwachen, ob Ihre CloudFront Funktion gedrosselt ist. Wenn Ihre Funktion gedrosselt ist, bedeutet dies, dass die Ausführung zu lange dauert. Um Funktionsdrosselungen zu vermeiden, sollten Sie eine Optimierung des Funktionscodes in Betracht ziehen.

Absicht: Dieser Alarm kann erkennen, wenn Ihre CloudFront Funktion gedrosselt ist, sodass Sie reagieren und das Problem lösen können, um ein reibungsloses Kundenerlebnis zu gewährleisten.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Wir empfehlen, den Schwellenwert auf 0 zu setzen, um eine schnellere Auflösung der Funktionsdrosselung zu ermöglichen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

SignUpThrottles

Abmessungen:, UserPool UserPoolClient

Alarmbeschreibung: Dieser Alarm überwacht die Anzahl der gedrosselten Anfragen. Wenn Benutzer ständig gedrosselt werden, sollten Sie das Limit erhöhen, indem Sie eine Erhöhung der Service Quotas beantragen. In Kontingente in Amazon Cognito erfahren Sie, wie Sie eine Kontingenterhöhung beantragen können. Um proaktiv Maßnahmen zu ergreifen, sollten Sie die Nutzungsquote nachverfolgen.

Absicht: Dieser Alarm hilft dabei, das Auftreten gedrosselter Registrierungsanfragen zu überwachen. Auf diese Weise können Sie wissen, wann Sie Maßnahmen ergreifen müssen, um eine Verschlechterung des Anmeldeerlebnisses zu verhindern. Anhaltende Drosselung von Anfragen wirkt sich negativ auf die Anmeldeerfahrung der Benutzer aus.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Bei einem gut ausgestatteten Benutzerpool sollte es zu keiner Drosselung kommen, die sich über mehrere Datenpunkte erstreckt. Ein typischer Schwellenwert für einen erwarteten Workload sollte also Null sein. Bei einem unregelmäßigen Workload mit häufigen Spitzenwerten können Sie historische Daten analysieren, um die akzeptable Drosselung für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen. Eine gedrosselte Anfrage sollte erneut versucht werden, um die Auswirkungen auf die Anwendung so gering wie möglich zu halten.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

SignInThrottles

Abmessungen:UserPool, UserPoolClient

Alarmbeschreibung: Dieser Alarm überwacht die Anzahl der gedrosselten Benutzerauthentifizierungsanfragen. Wenn Benutzer ständig gedrosselt werden, müssen Sie das Limit möglicherweise erhöhen, indem Sie eine Erhöhung der Service Quotas beantragen. In Kontingente in Amazon Cognito erfahren Sie, wie Sie eine Kontingenterhöhung beantragen können. Um proaktiv Maßnahmen zu ergreifen, sollten Sie die Nutzungsquote nachverfolgen.

Absicht: Dieser Alarm hilft dabei, das Auftreten gedrosselter Anmeldeanfragen zu überwachen. Auf diese Weise können Sie wissen, wann Sie Maßnahmen ergreifen müssen, um eine Verschlechterung der Anmeldeerfahrung zu verhindern. Eine anhaltende Drosselung von Anfragen führt zu einer schlechten Benutzererfahrung bei der Authentifizierung.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Bei einem gut ausgestatteten Benutzerpool sollte es zu keiner Drosselung kommen, die sich über mehrere Datenpunkte erstreckt. Ein typischer Schwellenwert für einen erwarteten Workload sollte also Null sein. Bei einem unregelmäßigen Workload mit häufigen Spitzenwerten können Sie historische Daten analysieren, um die akzeptable Drosselung für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen. Eine gedrosselte Anfrage sollte erneut versucht werden, um die Auswirkungen auf die Anwendung so gering wie möglich zu halten.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

TokenRefreshThrottles

Abmessungen:UserPool, UserPoolClient

Alarmbeschreibung: Sie können den Schwellenwert so einstellen, dass er sowohl dem Datenverkehr der Anfrage als auch einer akzeptablen Drosselung für Token-Aktualisierungsanfragen entspricht. Die Drosselung wird verwendet, um Ihr System vor zu vielen Anfragen zu schützen. Es ist jedoch wichtig zu überwachen, ob Sie auch für Ihren normalen Datenverkehr nicht ausreichend ausgestattet sind. Sie können historische Daten analysieren, um die akzeptable Drosselung für den Anwendungs-Workloads zu ermitteln, und dann den Alarmschwellenwert so einstellen, dass er über dem akzeptablen Drosselungswert liegt. Gedrosselte Anfragen sollten von der Anwendung/dem Service erneut versucht werden, da sie kurzlebig sind. Daher kann ein sehr niedriger Wert für den Schwellenwert dazu führen, dass der Alarm empfindlich ist.

Absicht: Dieser Alarm hilft dabei, das Auftreten gedrosselter Token-Aktualisierungsanfragen zu überwachen. Auf diese Weise wissen Sie, wann Sie Maßnahmen ergreifen müssen, um potenzielle Probleme zu beheben, eine reibungslose Benutzererfahrung sowie die Integrität und Zuverlässigkeit Ihres Authentifizierungssystems zu gewährleisten. Eine anhaltende Drosselung von Anfragen führt zu einer schlechten Benutzererfahrung bei der Authentifizierung.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der Schwellenwert kann auch so eingestellt/angepasst werden, dass er dem Datenverkehr der Anfrage entspricht, sowie eine akzeptable Drosselung für Token-Aktualisierungsanfragen bietet. Drosselungen dienen dazu, Ihr System vor zu vielen Anfragen zu schützen. Es ist jedoch wichtig, zu überwachen, ob Sie auch für Ihren normalen Datenverkehr nicht ausreichend ausgestattet sind, und zu prüfen, ob dies die Auswirkungen verursacht. Historische Daten können auch analysiert werden, um festzustellen, welche Drosselung für den Anwendungs-Workload akzeptabel ist. Der Schwellenwert kann auch höher eingestellt werden als die übliche zulässige Drosselungsstufe. Gedrosselte Anfragen sollten von der Anwendung/dem Service erneut versucht werden, da sie kurzlebig sind. Daher kann ein sehr niedriger Wert für den Schwellenwert dazu führen, dass der Alarm empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

FederationThrottles

Abmessungen:UserPool, UserPoolClient, IdentityProvider

Alarmbeschreibung: Dieser Alarm überwacht die Anzahl der gedrosselten Identity Identitätsverbund-Anfragen. Wenn Sie ständig eine Drosselung feststellen, deutet dies möglicherweise darauf hin, dass Sie das Limit erhöhen müssen, indem Sie eine Erhöhung der Service Quotas beantragen. In Kontingente in Amazon Cognito erfahren Sie, wie Sie eine Kontingenterhöhung beantragen können.

Absicht: Dieser Alarm hilft dabei, das Auftreten gedrosselter Identitätsverbund-Anfragen zu überwachen. Dies kann Ihnen helfen, proaktiv auf Leistungsengpässe oder Fehlkonfigurationen zu reagieren und eine reibungslose Authentifizierung für Ihre Benutzer sicherzustellen. Eine anhaltende Drosselung von Anfragen führt zu einer schlechten Benutzererfahrung bei der Authentifizierung.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Sie können den Schwellenwert so festlegen, dass er sowohl dem Datenverkehr der Anfrage als auch der akzeptablen Drosselung für Identitätsverbund-Anfragen entspricht. Die Drosselung wird verwendet, um Ihr System vor zu vielen Anfragen zu schützen. Es ist jedoch wichtig zu überwachen, ob Sie auch für Ihren normalen Datenverkehr nicht ausreichend ausgestattet sind. Sie können historische Daten analysieren, um die akzeptable Drosselung für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert auf einen Wert festlegen, der über Ihrer akzeptablen Drosselungsstufe liegt. Gedrosselte Anfragen sollten von der Anwendung/dem Service erneut versucht werden, da sie kurzlebig sind. Daher kann ein sehr niedriger Wert für den Schwellenwert dazu führen, dass der Alarm empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

AccountProvisionedReadCapacityUtilization

Dimensionen: Keine

Alarmbeschreibung: Dieser Alarm erkennt, ob die Lesekapazität des Kontos das bereitgestellte Limit erreicht. In diesem Fall können Sie das Kontingent für die Nutzung der Lesekapazität erhöhen. Mithilfe von Service Quotas können Sie Ihre aktuellen Kontingente für Lesekapazitätseinheiten einsehen und Erhöhungen beantragen.

Absicht: Der Alarm kann erkennen, ob sich die Lesekapazitätsauslastung des Kontos der bereitgestellten Lesekapazitätsauslastung nähert. Wenn die Auslastung ihr maximales Limit erreicht, beginnt DynamoDB, Leseanfragen zu drosseln.

Statistik: Maximum

Empfohlener Schwellenwert: 80,0

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf 80 % fest, sodass Maßnahmen (z. B. die Erhöhung der Kontolimits) ergriffen werden können, bevor die volle Kapazität erreicht ist, um eine Drosselung zu vermeiden.

Zeitraum: 300

Datenpunkte bis Alarm: 2

Auswertungszeiträume: 2

Vergleichsoperator: GREATER_THAN_THRESHOLD

AccountProvisionedWriteCapacityUtilization

Dimensionen: Keine

Alarmbeschreibung: Dieser Alarm erkennt, ob die Schreibkapazität des Kontos das bereitgestellte Limit erreicht. In diesem Fall können Sie das Kontingent für die Schreibkapazitätsnutzung erhöhen. Mithilfe von Service Quotas können Sie Ihre aktuellen Kontingente für Schreibkapazitätseinheiten einsehen und Erhöhungen beantragen.

Absicht: Dieser Alarm kann erkennen, ob sich die Schreibkapazitätsauslastung des Kontos der bereitgestellten Schreibkapazitätsauslastung nähert. Wenn die Auslastung ihr maximales Limit erreicht, beginnt DynamoDB, Schreibanfragen zu drosseln.

Statistik: Maximum

Empfohlener Schwellenwert: 80,0

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf 80 % fest, sodass Maßnahmen (z. B. die Erhöhung der Kontolimits) ergriffen werden können, bevor die volle Kapazität erreicht ist, um eine Drosselung zu vermeiden.

Zeitraum: 300

Datenpunkte bis Alarm: 2

Auswertungszeiträume: 2

Vergleichsoperator: GREATER_THAN_THRESHOLD

AgeOfOldestUnreplicatedRecord

Abmessungen:TableName, DelegatedOperation

Alarmbeschreibung: Dieser Alarm erkennt die Verzögerung bei der Replikation in einen Kinesis-Datenstrom. Im normalen Betrieb sollte AgeOfOldestUnreplicatedRecord nur Millisekunden betragen. Diese Zahl erhöht sich durch erfolglose Replikationsversuche, die durch die vom Kunden gesteuerte Konfiguration verursacht werden. Beispiele für kundengesteuerte Konfigurationen, die zu erfolglosen Replikationsversuchen führen, sind eine zu geringe Kapazität des Kinesis-Datenstroms, die zu einer übermäßigen Drosselung führt, oder eine manuelle Aktualisierung der Zugriffsrichtlinien des Kinesis-Datenstroms, die DynamoDB daran hindert, Daten zum Datenstrom hinzuzufügen. Um diese Metrik so niedrig wie möglich zu halten, müssen Sie für die richtige Bereitstellung der Kinesis-Datenstromkapazität sorgen und sicherstellen, dass die Berechtigungen von DynamoDB unverändert bleiben.

Absicht: Dieser Alarm kann erfolglose Replikationsversuche und die daraus resultierende Verzögerung bei der Replikation im Kinesis-Datenstrom überwachen.

Statistik: Maximum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Stellen Sie den Schwellenwert entsprechend der gewünschten Replikationsverzögerung ein, gemessen in Millisekunden. Dieser Wert hängt von den Anforderungen Ihres Workloads und der erwarteten Leistung ab.

Zeitraum: 300

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: GREATER_THAN_THRESHOLD

FailedToReplicateRecordCount

Abmessungen:TableName, DelegatedOperation

Alarmbeschreibung: Dieser Alarm erkennt die Anzahl der Datensätze, die DynamoDB nicht in Ihren Kinesis-Datenstrom replizieren konnte. Bestimmte Elemente, die größer als 34 KB sind, können sich vergrößern, um Datensätze zu ändern, die größer als die Elementgrößengrenze von 1 MB von Kinesis Data Streams sind. Diese Größenerweiterung tritt auf, wenn diese Elemente, die größer als 34 KB sind, eine große Anzahl von booleschen oder leeren Attributwerten enthalten. Boolesche und leere Attributwerte werden in DynamoDB als 1 Byte gespeichert, erweitern sich jedoch auf bis zu 5 Byte, wenn sie mit Standard-JSON für die Kinesis-Data-Streams-Replikation serialisiert werden. DynamoDB kann solche Änderungsdatensätze nicht in Ihren Kinesis Dats Stream replizieren. DynamoDB überspringt diese Änderungsdatensätze und repliziert automatisch nachfolgende Datensätze.

Absicht: Dieser Alarm kann die Anzahl der Datensätze überwachen, die DynamoDB aufgrund der Elementgrößenbeschränkung für Kinesis-Datenströme nicht in Ihren Kinesis-Datenstrom repliziert hat.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Setzen Sie den Schwellenwert auf 0, um alle Datensätze zu erkennen, die DynamoDB nicht replizieren konnte.

Zeitraum: 60

Datenpunkte bis Alarm: 1

Auswertungszeiträume: 1

Vergleichsoperator: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Abmessungen: TableName

Alarmbeschreibung: Dieser Alarm erkennt, ob eine hohe Anzahl von Leseanfragen für die DynamoDB-Tabelle gedrosselt wird. Informationen zur Behebung des Problems finden Sie unter Behebung von Drosselungsproblemen in Amazon DynamoDB.

Absicht: Dieser Alarm kann eine anhaltende Drosselung von Leseanfragen an die DynamoDB-Tabelle erkennen. Eine anhaltende Drosselung von Leseanfragen kann sich negativ auf Ihre Workload-Lesevorgänge auswirken und die Gesamteffizienz des Systems verringern.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert entsprechend dem erwarteten Leseverkehr für die DynamoDB-Tabelle fest und berücksichtigen Sie dabei ein akzeptables Maß an Drosselung. Es ist wichtig, dass Sie überwachen, ob Sie zu wenig Ressourcen zur Verfügung haben und nicht durchgängig eine Drosselung verursachen. Sie können auch historische Daten analysieren, um die akzeptable Drosselungsstufe für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert so einstellen, dass er höher als die übliche Drosselungsstufe ist. Gedrosselte Anfragen sollten von der Anwendung oder dem Service erneut versucht werden, da sie vorübergehend sind. Daher kann ein sehr niedriger Schwellenwert dazu führen, dass der Alarm zu empfindlich ist, was zu unerwünschten Zustandsübergängen führen kann.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Abmessungen:TableName, GlobalSecondaryIndexName

Alarmbeschreibung: Dieser Alarm erkennt, ob eine hohe Anzahl von Leseanfragen für den Global Secondary Index der DynamoDB-Tabelle gedrosselt wird. Informationen zur Behebung des Problems finden Sie unter Behebung von Drosselungsproblemen in Amazon DynamoDB.

Absicht: Dieser Alarm kann eine anhaltende Drosselung von Leseanfragen für den Global Secondary Index der DynamoDB-Tabelle erkennen. Eine anhaltende Drosselung von Leseanfragen kann sich negativ auf Ihre Workload-Lesevorgänge auswirken und die Gesamteffizienz des Systems verringern.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert entsprechend dem erwarteten Leseverkehr für die DynamoDB-Tabelle fest und berücksichtigen Sie dabei ein akzeptables Maß an Drosselung. Es ist wichtig, dass Sie überwachen, ob Sie unterdurchschnittlich ausgelastet sind und nicht durchgehend eine Drosselung verursachen. Sie können auch historische Daten analysieren, um eine akzeptable Drosselungsstufe für den Anwendungs-Workload zu finden, und dann den Schwellenwert so einstellen, dass er über der üblichen akzeptablen Drosselungsstufe liegt. Gedrosselte Anfragen sollten von der Anwendung oder dem Service erneut versucht werden, da sie vorübergehend sind. Daher kann ein sehr niedriger Schwellenwert dazu führen, dass der Alarm zu empfindlich ist, was zu unerwünschten Zustandsübergängen führen kann.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

ReplicationLatency

Abmessungen:TableName, ReceivingRegion

Alarmbeschreibung: Der Alarm erkennt, wenn das Replikat in einer Region für die globale Tabelle hinter der Quellregion zurückbleibt. Die Latenz kann sich erhöhen, wenn eine AWS Region herabgesetzt wird und Sie in dieser Region über eine Replikattabelle verfügen. In diesem Fall können Sie die Lese- und Schreibaktivitäten Ihrer Anwendung vorübergehend in eine andere AWS Region umleiten. Wenn Sie globale Tabellen der Version 2017.11.29 (veraltet) verwenden, sollten Sie überprüfen, ob die Schreibkapazitätseinheiten (WCUs) für jede der Replikattabellen identisch sind. Sie können auch sicherstellen, dass Sie die Empfehlungen unter Bewährte Methoden und Anforderungen für das Kapazitätsmanagement befolgen.

Absicht: Dieser Alarm kann erkennen, wenn die Replikattabelle in einer Region bei der Replikation der Änderungen aus einer anderen Region in Verzug gerät. Dies könnte dazu führen, dass Ihr Replikat von den anderen Replikaten abweicht. Es ist nützlich, die Replikationslatenz jeder AWS Region zu kennen und eine Warnung zu erhalten, wenn diese Replikationslatenz kontinuierlich zunimmt. Die Replikation der Tabelle gilt nur für globale Tabellen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von Ihrem Anwendungsfall ab. Replikationslatenzen von mehr als 3 Minuten sind in der Regel ein Grund für Untersuchungen. Prüfen Sie die Wichtigkeit und die Anforderungen der Replikationsverzögerung, analysieren Sie historische Trends und wählen Sie dann den Schwellenwert entsprechend aus.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

SuccessfulRequestLatency

Abmessungen:TableName, Bedienung

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Latenz für den DynamoDB-Tabellenvorgang (angezeigt durch den Dimensionswert von Operation im Alarm). In diesem Dokument zur Fehlerbehebung finden Sie Informationen zur Behebung von Latenzproblemen in Amazon DynamoDB.

Absicht: Dieser Alarm kann eine hohe Latenz für den DynamoDB-Tabellenvorgang erkennen. Eine höhere Latenz für die Vorgänge kann sich negativ auf die Gesamteffizienz des Systems auswirken.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: DynamoDB bietet eine durchschnittliche Latenz im einstelligen Millisekundenbereich für Singleton-Operationen wie, usw. GetItem PutItem Sie können den Schwellenwert jedoch auf der Grundlage einer akzeptablen Latenztoleranz für die Art des Vorgangs und der Tabelle festlegen, die an dem Workload beteiligt sind. Sie können historische Daten dieser Metrik analysieren, um die übliche Latenz für den Tabellenvorgang zu ermitteln, und dann den Schwellenwert auf eine Zahl festlegen, die eine kritische Verzögerung für den Vorgang darstellt.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_THRESHOLD

SystemErrors

Abmessungen: TableName

Alarmbeschreibung: Dieser Alarm erkennt eine anhaltend hohe Anzahl von Systemfehlern für die DynamoDB-Tabellenanfragen. Wenn Sie weiterhin 5XX-Fehler erhalten, öffnen Sie das AWS Service Health Dashboard, um nach Betriebsproblemen mit dem Service zu suchen. Sie können diesen Alarm verwenden, um benachrichtigt zu werden, falls ein längeres internes Serviceproblem von DynamoDB auftritt, und er hilft Ihnen, das Problem, mit dem Ihre Client-Anwendung konfrontiert ist, zu korrelieren. Weitere Informationen finden Sie unter Fehlerbehandlung für DynamoDB.

Absicht: Dieser Alarm kann anhaltende Systemfehler für die DynamoDB-Tabellenanfragen erkennen. Systemfehler deuten auf interne Servicefehler von DynamoDB hin und helfen dabei, das Problem, das der Client hat, zu korrelieren.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert entsprechend dem zu erwartenden Datenverkehr fest und berücksichtigen Sie dabei ein akzeptables Maß an Systemfehlern. Sie können auch historische Daten analysieren, um die akzeptable Fehlerzahl für den Anwendungs-Workload zu ermitteln, und den Schwellenwert dann entsprechend anpassen. Systemfehler sollten von der Anwendung/dem Service erneut versucht werden, da sie vorübergehend sind. Daher kann ein sehr niedriger Schwellenwert dazu führen, dass der Alarm zu empfindlich ist, was zu unerwünschten Zustandsübergängen führen kann.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

ThrottledPutRecordCount

Abmessungen:TableName, DelegatedOperation

Alarmbeschreibung: Dieser Alarm erkennt, dass die Datensätze während der Replikation von Change Data Capture zu Kinesis durch Ihren Kinesis-Datenstrom gedrosselt werden. Diese Drosselung erfolgt aufgrund unzureichender Kinesis-Datenstrom-Kapazität. Wenn eine übermäßige und regelmäßige Drosselung auftritt, müssen Sie möglicherweise die Anzahl der Kinesis-Stream-Shards proportional zum beobachteten Schreibdurchsatz Ihrer Tabelle erhöhen. Weitere Informationen zur Bestimmung der Größe eines Kinesis Data Streams finden Sie unter Bestimmen der anfänglichen Größe eines Kinesis Data Streams.

Absicht: Dieser Alarm kann die Anzahl der Datensätze überwachen, die von Ihrem Kinesis-Datenstrom wegen unzureichender Kapazität des Kinesis-Datenstroms gedrosselt wurden.

Statistik: Maximum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Bei außergewöhnlichen Nutzungsspitzen kann es zu einer gewissen Drosselung kommen, gedrosselte Datensätze sollten jedoch so niedrig wie möglich gehalten werden, um eine höhere Replikationslatenz zu vermeiden (DynamoDB versucht erneut, gedrosselte Datensätze an den Kinesis-Datenstrom zu senden). Setzen Sie den Schwellenwert auf eine Zahl, mit der Sie regelmäßige übermäßige Drosselungen erkennen können. Sie können auch historische Daten dieser Metrik analysieren, um die akzeptablen Drosselungsraten für die Anwendungs-Workload zu ermitteln. Stellen Sie den Schwellenwert auf einen Wert ein, den die Anwendung in Abhängigkeit von Ihrem Anwendungsfall tolerieren kann.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_THRESHOLD

UserErrors

Dimensionen: Keine

Alarmbeschreibung: Dieser Alarm erkennt eine anhaltend hohe Anzahl von Benutzerfehlern bei DynamoDB-Tabellenanfragen. Sie können während des Problemzeitraums in den Protokollen der Client-Anwendungen nachsehen, warum die Anfragen ungültig sind. Sie können den HTTP-Statuscode 400 überprüfen, um zu sehen, welche Art von Fehler Sie erhalten, und entsprechende Maßnahmen ergreifen zu können. Möglicherweise müssen Sie die Anwendungslogik korrigieren, um gültige Anfragen zu erstellen.

Absicht: Dieser Alarm kann anhaltende Benutzerfehler bei den DynamoDB-Tabellenanfragen erkennen. Benutzerfehler bei angeforderten Vorgängen bedeuten, dass der Client ungültige Anfragen generiert und der Vorgang fehlschlägt.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Setzen Sie den Schwellenwert auf Null, um clientseitige Fehler zu erkennen. Oder Sie können ihn auf einen höheren Wert setzen, wenn Sie vermeiden möchten, dass der Alarm bei einer sehr geringen Anzahl von Fehlern ausgelöst wird. Entscheiden Sie auf der Grundlage Ihres Anwendungsfalls und des Datenverkehrs für die Anfragen.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Abmessungen: TableName

Alarmbeschreibung: Dieser Alarm erkennt, ob eine hohe Anzahl von Schreibanfragen für die DynamoDB-Tabelle gedrosselt wird. Informationen zur Behebung des Problems finden Sie unter Behebung von Drosselungsproblemen in Amazon DynamoDB.

Absicht: Dieser Alarm kann eine anhaltende Drosselung von Schreibanfragen an die DynamoDB-Tabelle erkennen. Eine anhaltende Drosselung von Schreibanfragen kann sich negativ auf Ihre Workload-Schreibvorgänge auswirken und die Gesamteffizienz des Systems verringern.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert entsprechend dem erwarteten Schreibverkehr für die DynamoDB-Tabelle fest und berücksichtigen Sie dabei ein akzeptables Maß an Drosselung. Es ist wichtig, dass Sie überwachen, ob Sie unterdurchschnittlich ausgelastet sind und nicht durchgehend eine Drosselung verursachen. Sie können auch historische Daten analysieren, um den akzeptablen Grad der Drosselung für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert auf einen Wert einstellen, der über der üblichen akzeptablen Drosselungsstufe liegt. Gedrosselte Anfragen sollten von der Anwendung/dem Service erneut versucht werden, da sie kurzlebig sind. Daher kann ein sehr niedriger Schwellenwert dazu führen, dass der Alarm zu empfindlich ist, was zu unerwünschten Zustandsübergängen führen kann.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Abmessungen:TableName, GlobalSecondaryIndexName

Alarmbeschreibung: Dieser Alarm erkennt, ob eine hohe Anzahl von Schreibanfragen für den Global Secondary Index der DynamoDB-Tabelle gedrosselt wird. Informationen zur Behebung des Problems finden Sie unter Behebung von Drosselungsproblemen in Amazon DynamoDB.

Absicht: Dieser Alarm kann eine anhaltende Drosselung von Schreibanfragen für den Global Secondary Index der DynamoDB-Tabelle erkennen. Eine anhaltende Drosselung von Schreibanfragen kann sich negativ auf Ihre Workload-Schreibvorgänge auswirken und die Gesamteffizienz des Systems verringern.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert entsprechend dem erwarteten Schreibverkehr für die DynamoDB-Tabelle fest und berücksichtigen Sie dabei ein akzeptables Maß an Drosselung. Es ist wichtig, dass Sie überwachen, ob Sie unterdurchschnittlich ausgelastet sind und nicht durchgehend eine Drosselung verursachen. Sie können auch historische Daten analysieren, um die akzeptable Drosselungsstufe für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert auf einen Wert einstellen, der über der üblichen akzeptablen Drosselungsstufe liegt. Gedrosselte Anfragen sollten von der Anwendung/dem Service erneut versucht werden, da sie kurzlebig sind. Daher kann ein sehr niedriger Wert dazu führen, dass der Alarm zu empfindlich ist, was zu unerwünschten Zustandsübergängen führen kann.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

VolumeStalledioCheck

Abmessungen:VolumeId, InstanceId

Beschreibung des Alarms: Dieser Alarm hilft Ihnen, die I/O-Leistung Ihrer Amazon EBS-Volumes zu überwachen. Diese Prüfung erkennt grundlegende Probleme mit der Amazon EBS-Infrastruktur, wie Hardware- oder Softwareprobleme in den Speichersubsystemen, die den Amazon EBS-Volumes zugrunde liegen, Hardwareprobleme auf dem physischen Host, die sich auf die Erreichbarkeit der Amazon EBS-Volumes von Ihrer Amazon EC2 EC2-Instance aus auswirken, und kann Verbindungsprobleme zwischen der Instance und den Amazon EBS-Volumes aufdecken. Wenn der Stalled IO Check fehlschlägt, können Sie entweder warten, AWS bis das Problem behoben ist, oder Sie können Maßnahmen ergreifen, z. B. das betroffene Volume austauschen oder die Instance, an die das Volume angehängt ist, beenden und neu starten. In den meisten Fällen, wenn diese Metrik fehlschlägt, diagnostiziert Amazon EBS Ihr Volume automatisch und stellt es innerhalb weniger Minuten wieder her.

Absicht: Dieser Alarm kann den Status Ihrer Amazon EBS-Volumes erkennen, um festzustellen, wann diese Volumes beeinträchtigt sind und I/O-Operationen nicht abgeschlossen werden können.

Statistik: Maximum

Empfohlener Schwellenwert: 1,0

Begründung des Schwellenwerts: Wird eine Statusprüfung nicht bestanden, ist der Wert dieser Metrik 1. Der Schwellenwert ist so eingestellt, dass sich der Alarm immer dann im ALARM-Status befindet, wenn die Statusüberprüfung fehlschlägt.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

CPUUtilization

Abmessungen: InstanceId

Alarmbeschreibung: Dieser Alarm hilft bei der Überwachung der CPU-Auslastung einer EC2-Instance. Je nach Anwendung kann eine gleichbleibend hohe Auslastung normal sein. Wenn jedoch die Leistung beeinträchtigt ist und die Anwendung nicht durch Festplatten-I/O, Arbeitsspeicher oder Netzwerkressourcen eingeschränkt ist, kann eine ausgelastete CPU auf einen Ressourcenengpass oder auf Probleme mit der Anwendungsleistung hinweisen. Eine hohe CPU-Auslastung kann darauf hindeuten, dass ein Upgrade auf eine CPU-intensivere Instance erforderlich ist. Wenn die detaillierte Überwachung aktiviert ist, können Sie den Zeitraum auf 60 Sekunden statt auf 300 Sekunden ändern. Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren der detaillierten Überwachung für Ihre Instances.

Absicht: Dieser Alarm wird verwendet, um eine hohe CPU-Auslastung zu erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 80,0

Begründung des Schwellenwerts: In der Regel können Sie den Schwellenwert für die CPU-Auslastung auf 70 bis 80 % festlegen. Sie können diesen Wert jedoch an Ihr akzeptables Leistungsniveau und Ihre Workload-Merkmale anpassen. Bei einigen Systemen kann eine konstant hohe CPU-Auslastung normal sein und ist kein Anzeichen für ein Problem, bei anderen kann sie jedoch Anlass zur Sorge geben. Analysieren Sie historische Daten zur CPU-Auslastung, um die Auslastung zu ermitteln, herauszufinden, welche CPU-Auslastung für Ihr System akzeptabel ist, und legen Sie den Schwellenwert entsprechend fest.

Zeitraum: 300

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: GREATER_THAN_THRESHOLD

StatusCheckFailed

Abmessungen: InstanceId

Alarmbeschreibung: Dieser Alarm hilft dabei, sowohl System-Statusprüfungen als auch den Instance-Status zu überwachen. Wenn eine der beiden Arten der Statusüberprüfung fehlschlägt, sollte sich dieser Alarm im ALARM-Status befinden.

Absicht: Dieser Alarm wird verwendet, um grundlegende Probleme mit Instances zu erkennen, einschließlich fehlgeschlagener System-Statusprüfungen und fehlgeschlagener Instance-Statusprüfungen.

Statistik: Maximum

Empfohlener Schwellenwert: 1,0

Begründung des Schwellenwerts: Wird eine Statusprüfung nicht bestanden, ist der Wert dieser Metrik 1. Der Schwellenwert ist so eingestellt, dass sich der Alarm immer dann im ALARM-Status befindet, wenn die Statusüberprüfung fehlschlägt.

Zeitraum: 300

Datenpunkte bis Alarm: 2

Auswertungszeiträume: 2

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

StatusCheckFailed_Angehängte Datenbanken

Abmessungen: InstanceId

Beschreibung des Alarms: Mit diesem Alarm können Sie überwachen, ob die an eine Instance angeschlossenen Amazon EBS-Volumes erreichbar sind und I/O-Operationen abschließen können. Bei dieser Statusüberprüfung werden grundlegende Probleme mit der Datenverarbeitungs- oder Amazon EBS-Infrastruktur erkannt, z. B. die folgenden:

Hardware- oder Softwareprobleme in den Speichersubsystemen, die den Amazon EBS-Volumes zugrunde liegen
Hardwareprobleme auf dem physischen Host, die sich auf die Erreichbarkeit der Amazon EBS-Volumes auswirken
Verbindungsprobleme zwischen der Instance und Amazon EBS-Volumes

Wenn die angehängte EBS-Statusprüfung fehlschlägt, können Sie entweder warten, bis Amazon das Problem behoben hat, oder Sie können Maßnahmen ergreifen, z. B. die betroffenen Volumes austauschen oder die Instance beenden und neu starten.

Absicht: Dieser Alarm wird verwendet, um unerreichbare Amazon EBS-Volumes zu erkennen, die an eine Instance angehängt sind. Diese können zu Fehlern bei I/O-Vorgängen führen.

Statistik: Maximum

Empfohlener Schwellenwert: 1,0

Begründung des Schwellenwerts: Wird eine Statusprüfung nicht bestanden, ist der Wert dieser Metrik 1. Der Schwellenwert ist so eingestellt, dass sich der Alarm immer dann im ALARM-Status befindet, wenn die Statusüberprüfung fehlschlägt.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

CPUUtilization

Abmessungen:CacheClusterId, CacheNodeId

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung der CPU-Auslastung für die gesamte ElastiCache Instance, einschließlich der Datenbank-Engine-Prozesse und anderer Prozesse, die auf der Instance ausgeführt werden. AWS Elasticache unterstützt zwei Engine-Typen: Memcached und Redis. Wenn Sie auf einem Memcached-Knoten eine hohe CPU-Auslastung erreichen, sollten Sie erwägen, Ihren Instance-Typ zu skalieren oder neue Cache-Knoten hinzuzufügen. Wenn Ihr Workload bei Redis hauptsächlich aus Leseanfragen besteht, sollten Sie in Erwägung ziehen, Ihrem Cache-Cluster mehr Lesereplikate hinzuzufügen. Wenn Ihr Workload hauptsächlich aus Schreibanfragen besteht, sollten Sie in Erwägung ziehen, weitere Shards hinzuzufügen, um den Workload auf mehr Primärknoten zu verteilen, wenn Sie im Cluster-Modus arbeiten, oder Ihren Instance-Typ hochzuskalieren, wenn Sie Redis im Nicht-Clustermodus betreiben.

Absicht: Dieser Alarm wird verwendet, um eine hohe CPU-Auslastung von Hosts zu erkennen. ElastiCache Es ist nützlich, einen umfassenden Überblick über die CPU-Auslastung in der gesamten Instance zu erhalten, einschließlich Prozessen, die nicht zur Engine gehören.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf den Prozentsatz fest, der einer kritischen CPU-Auslastung für Ihre Anwendung entspricht. Bei Memcached kann die Engine bis zu num_threads Kerne verwenden. Bei Redis ist die Engine größtenteils Single-Thread-fähig, kann aber zusätzliche Kerne verwenden, falls verfügbar, um I/O zu beschleunigen. In den meisten Fällen können Sie den Schwellenwert auf etwa 90 % Ihrer verfügbaren CPU setzen. Da Redis mit nur einem Thread arbeitet, sollte der tatsächliche Schwellenwert als ein Bruchteil der Gesamtkapazität des Knotens berechnet werden.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

CurrConnections

Abmessungen:CacheClusterId, CacheNodeId

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Verbindungsanzahl, was auf eine hohe Auslastung oder Leistungsprobleme hinweisen kann. Ein stetiger Anstieg von CurrConnections kann zur Erschöpfung der 65 000 verfügbaren Verbindungen führen. Dies kann darauf hinweisen, dass die Verbindungen auf der Anwendungsseite nicht ordnungsgemäß geschlossen und auf der Serverseite bestehen gelassen wurden. Sie sollten die Verwendung von Verbindungspooling oder Timeouts bei inaktiven Verbindungen in Betracht ziehen, um die Anzahl der Verbindungen zu dem Cluster zu begrenzen. Bei Redis sollten Sie in Betracht ziehen, tcp-keepalive auf Ihrem Cluster zu optimieren, um potenzielle tote Peers zu erkennen und zu beenden.

Absicht: Der Alarm hilft Ihnen dabei, hohe Verbindungszahlen zu erkennen, die sich auf die Leistung und Stabilität Ihres ElastiCache Clusters auswirken könnten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark vom akzeptablen Verbindungsbereich für Ihren Cluster ab. Überprüfen Sie die Kapazität und die erwartete Arbeitslast Ihres ElastiCache Clusters und analysieren Sie die historischen Verbindungszahlen während der regulären Nutzung, um einen Basiswert festzulegen, und wählen Sie dann einen entsprechenden Schwellenwert aus. Denken Sie daran, dass jeder Knoten bis zu 65 000 gleichzeitige Verbindungen unterstützen kann.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_THRESHOLD

DatabaseMemoryUsagePercentage

Abmessungen: CacheClusterId

Alarmbeschreibung: Dieser Alarm hilft Ihnen, die Speicherauslastung Ihres Clusters zu überwachen. Wenn Ihr DatabaseMemoryUsagePercentage 100 % erreicht, wird die Redis-Maxmemory-Richtlinie ausgelöst und es kann je nach der ausgewählten Richtlinie zu Bereinigungen kommen. Wenn kein Objekt im Cache der Bereinigungsrichtlinie entspricht, schlagen Schreibvorgänge fehl. Einige Workloads erwarten oder verlassen sich auf Bereinigungen. Andernfalls müssen Sie die Speicherkapazität Ihres Clusters erhöhen. Sie können Ihren Cluster skalieren, indem Sie weitere Primärknoten hinzufügen, oder ihn hochskalieren, indem Sie einen größeren Knotentyp verwenden. Einzelheiten finden Sie unter Skalierung ElastiCache für Redis-Cluster.

Absicht: Dieser Alarm wird verwendet, um eine hohe Speicherauslastung Ihres Clusters zu erkennen, sodass Sie Fehler beim Schreiben in Ihren Cluster vermeiden können. Es ist hilfreich zu wissen, wann Sie Ihren Cluster hochskalieren müssen, wenn bei Ihrer Anwendung nicht mit Bereinigungen zu rechnen ist.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung der Schwellenwerte: Abhängig von den Speicheranforderungen Ihrer Anwendung und der Speicherkapazität Ihres ElastiCache Clusters sollten Sie den Schwellenwert auf den Prozentsatz festlegen, der die kritische Speichernutzung des Clusters widerspiegelt. Sie können historische Speichernutzungsdaten als Referenz für einen akzeptablen Schwellenwert für die Speichernutzung verwenden.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

EngineCPUUtilization

Abmessungen: CacheClusterId

Beschreibung des Alarms: Dieser Alarm hilft dabei, die CPU-Auslastung eines Redis-Engine-Threads innerhalb der ElastiCache Instanz zu überwachen. Häufige Gründe für hohe CPU-Engines sind lang andauernde Befehle, die viel CPU verbrauchen, eine hohe Anzahl von Anfragen, eine Zunahme neuer Client-Verbindungsanfragen in kurzer Zeit und viele Bereinigungen, wenn der Cache nicht über genügend Speicher für neue Daten verfügt. Sie sollten die Skalierung ElastiCache für Redis-Cluster in Betracht ziehen, indem Sie weitere Knoten hinzufügen oder Ihren Instanztyp skalieren.

Absicht: Dieser Alarm wird verwendet, um eine hohe CPU-Auslastung des Redis-Engine-Threads zu erkennen. Dies ist nützlich, wenn Sie die CPU-Auslastung der Datenbank-Engine selbst überwachen möchten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 90,0

Begründung des Schwellenwerts: Stellen Sie den Schwellenwert auf einen Prozentsatz ein, der die kritische CPU-Auslastung der Engine für Ihre Anwendung widerspiegelt. Sie können Ihren Cluster anhand Ihrer Anwendung und des erwarteten Workloads vergleichen, um EngineCPUUtilization und Leistung als Referenz zu korrelieren, und dann den Schwellenwert entsprechend festlegen. In den meisten Fällen können Sie den Schwellenwert auf etwa 90 % Ihrer verfügbaren CPU festlegen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

ReplicationLag

Abmessungen: CacheClusterId

Beschreibung des Alarms: Dieser Alarm hilft dabei, den Replikationsstatus Ihres ElastiCache Clusters zu überwachen. Eine hohe Verzögerung bei der Replikation bedeutet, dass der Primärknoten oder das Replikat nicht mit dem Tempo der Replikation Schritt halten kann. Wenn Ihre Schreibaktivität zu hoch ist, sollten Sie erwägen, Ihren Cluster zu skalieren, indem Sie weitere Primärknoten hinzufügen, oder ihn mithilfe eines größeren Knotentyps hochskalieren. Einzelheiten finden Sie unter Skalierung ElastiCache für Redis-Cluster. Wenn Ihre Lesereplikate durch die Anzahl der Leseanfragen überlastet sind, sollten Sie erwägen, weitere Lesereplikate hinzuzufügen.

Absicht: Dieser Alarm wird verwendet, um eine Verzögerung zwischen Datenaktualisierungen auf dem Primärknoten und deren Synchronisation mit dem Replikatknoten zu erkennen. Er trägt dazu bei, die Datenkonsistenz eines Lesereplikats-Clusterknotens sicherzustellen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert entsprechend den Anforderungen Ihrer Anwendung und den potenziellen Auswirkungen einer Verzögerung bei der Replikation fest. Sie sollten die von Ihrer Anwendung zu erwartenden Schreibraten und Netzwerkbedingungen für die akzeptable Verzögerung bei der Replikation berücksichtigen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

GPU ConnectivityCheckFailed

Abmessungen: InstanceId GPUID

Alarmbeschreibung: Dieser Alarm hilft dabei, Verbindungsfehler zwischen der Instance und dem Elastic-Graphics-Beschleuniger zu erkennen. Elastic Graphics verwendet das Instance-Netzwerk zum Senden von OpenGL-Befehlen an eine remote verbundene Grafikkarte. Dazu wird auf ein Desktop mit einer OpenGL-Anwendung mit einem Elastic-Graphics-Beschleuniger typischerweise mithilfe von Remote-Zugrifftechnologie zugegriffen. Es ist wichtig, zwischen Leistungsproblemen aufgrund des OpenGL-Renderings und solchen aufgrund der Desktop-Fernzugriffstechnologie zu unterscheiden. Weitere Informationen zu diesem Problem finden Sie unter Untersuchen von Leistungsproblemen von Anwendungen.

Absicht: Dieser Alarm wird verwendet, um Verbindungsprobleme zwischen der Instance und dem Elastic-Graphics-Beschleuniger zu erkennen.

Statistik: Maximum

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Der Schwellenwert von 1 gibt an, dass die Konnektivität fehlgeschlagen ist.

Zeitraum: 300

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: GREATER_THAN_THRESHOLD

GPU HealthCheckFailed

Abmessungen: InstanceId GPUID

Alarmbeschreibung: Dieser Alarm informiert Sie darüber, wenn der Status des Elastic-Graphics-Beschleuniger fehlerhaft ist. Wenn der Beschleuniger fehlerhaft ist, lesen Sie die Schritte zur Fehlerbehebung unter Beheben von Problemen im Status Fehlerhaft.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, ob der Elastic-Graphics-Beschleuniger fehlerhaft ist.

Statistik: Maximum

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Der Schwellenwert 1 zeigt den Fehlschlag einer Statusprüfung an.

Zeitraum: 300

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: GREATER_THAN_THRESHOLD

CPUReservation

Abmessungen: ClusterName

Alarmbeschreibung: Dieser Alarm hilft Ihnen, eine hohe CPU-Reservierung des ECS-Clusters zu erkennen. Eine hohe CPU-Reservierung kann darauf hindeuten, dass dem Cluster die registrierten CPUs für die Aufgabe ausgehen. Zur Fehlerbehebung können Sie mehr Kapazität hinzufügen, den Cluster skalieren oder Auto Scaling einrichten.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob die Gesamtzahl der für Aufgaben im Cluster reservierten CPU-Einheiten die Gesamtzahl der für den Cluster registrierten CPU-Einheiten erreicht. Auf diese Weise wissen Sie, wann Sie den Cluster hochskalieren müssen. Wenn die Gesamtzahl der CPU-Einheiten für den Cluster erreicht wird, kann dies dazu führen, dass die CPU für Aufgaben knapp wird. Wenn Sie die verwaltete Skalierung von EC2-Kapazitätsanbietern aktiviert haben oder Fargate mit Kapazitätsanbietern verknüpft haben, wird dieser Alarm nicht empfohlen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 90,0

Begründung des Schwellenwerts: Legen Sie den Schwellenwert für die CPU-Reservierung auf 90 % fest. Alternativ können Sie einen niedrigeren Wert basierend auf Cluster-Eigenschaften auswählen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

CPUUtilization

Abmessungen:ClusterName, ServiceName

Alarmbeschreibung: Dieser Alarm hilft Ihnen, eine hohe CPU-Auslastung des ECS-Services zu erkennen. Wenn keine laufende ECS-Bereitstellung stattfindet, kann eine maximale CPU-Auslastung auf einen Ressourcenengpass oder auf Probleme mit der Anwendungsleistung hinweisen. Zur Fehlerbehebung können Sie das CPU-Limit erhöhen.

Absicht: Dieser Alarm wird verwendet, um eine hohe CPU-Auslastung für den ECS-Service zu erkennen. Eine konstant hohe CPU-Auslastung kann auf einen Ressourcenengpass oder auf Probleme mit der Anwendungsleistung hinweisen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 90,0

Begründung des Schwellenwerts: Die Servicemetriken für die CPU-Auslastung könnten die Auslastung von 100 % überschreiten. Wir empfehlen jedoch, die Metrik auf hohe CPU-Auslastung zu überwachen, um andere Services nicht zu beeinträchtigen. Legen Sie den Schwellenwert auf etwa 90-95 % fest. Wir empfehlen Ihnen, Ihre Aufgabendefinitionen so zu aktualisieren, dass sie die tatsächliche Nutzung widerspiegeln, um zukünftige Probleme mit anderen Services zu vermeiden.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

MemoryReservation

Abmessungen: ClusterName

Alarmbeschreibung: Dieser Alarm hilft Ihnen, eine hohe Speicherreservierung des ECS-Clusters zu erkennen. Eine hohe Speicherreservierung kann auf einen Ressourcenengpass für den Cluster hinweisen. Analysieren Sie zur Problembehandlung die Leistung der Serviceaufgabe, um festzustellen, ob die Speicherauslastung der Aufgabe optimiert werden kann. Sie können auch mehr Speicher registrieren oder Auto Scaling einrichten.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob die Gesamtzahl der für Aufgaben auf dem Cluster reservierten Speichereinheiten die Gesamtzahl der für den Cluster registrierten Speichereinheiten erreicht. Auf diese Weise können Sie wissen, wann Sie den Cluster hochskalieren müssen. Wenn die Gesamtzahl der Speichereinheiten für den Cluster erreicht ist, kann dies dazu führen, dass der Cluster keine neuen Aufgaben starten kann. Wenn Sie die verwaltete Skalierung von EC2-Kapazitätsanbietern aktiviert haben oder Fargate mit Kapazitätsanbietern verknüpft haben, wird dieser Alarm nicht empfohlen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 90,0

Begründung des Schwellenwerts: Legen Sie den Schwellenwert für die Speicherreservierung auf 90 % fest. Sie können diesen Wert auf der Grundlage der Cluster-Eigenschaften auf einen niedrigeren Wert anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

HTTPCode_Target_5XX_Count

Abmessungen:ClusterName, ServiceName

Alarmbeschreibung: Dieser Alarm hilft Ihnen dabei, eine hohe serverseitige Fehlerzahl für den ECS-Service zu erkennen. Dies kann darauf hindeuten, dass Fehler vorliegen, die dazu führen, dass der Server Anfragen nicht bearbeiten kann. Um Fehler zu beheben, überprüfen Sie Ihre Anwendungsprotokolle.

Absicht: Dieser Alarm wird verwendet, um eine hohe Anzahl serverseitiger Fehler für den ECS-Service zu erkennen.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Berechnen Sie den Wert von etwa 5 % Ihres durchschnittlichen Datenverkehrs und verwenden Sie diesen Wert als Ausgangspunkt für den Schwellenwert. Sie können den durchschnittlichen Datenverkehr anhand der RequestCount-Metrik ermitteln. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu ermitteln, und dann den Schwellenwert entsprechend anpassen. Bei häufig auftretenden 5XX-Fehlern muss ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

TargetResponseTime

Abmessungen:ClusterName, ServiceName

Alarmbeschreibung: Dieser Alarm hilft Ihnen dabei, eine hohe Zielantwortzeit für ECS-Serviceanfragen zu erkennen. Dies kann darauf hindeuten, dass Probleme vorliegen, die dazu führen, dass der Service Anfragen nicht rechtzeitig bearbeiten kann. Überprüfen Sie zur Fehlerbehebung anhand der Metrik CPUUtilization, ob dem Service die CPU-Auslastung ausgeht, oder überprüfen Sie die CPU-Auslastung anderer nachgeschalteter Services, von denen Ihr Service abhängt.

Absicht: Dieser Alarm wird verwendet, um eine hohe Zielantwortzeit für ECS-Serviceanfragen zu erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von Ihrem Anwendungsfall ab. Überprüfen Sie die Wichtigkeit und die Anforderungen der angestrebten Reaktionszeit des Services und analysieren Sie das historische Verhalten dieser Metrik, um sinnvolle Schwellenwerte zu ermitteln.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

EphemeralStorageUtilized

Abmessungen:ClusterName, ServiceName

Beschreibung des Alarms: Mit diesem Alarm können Sie erkennen, dass der Fargate-Cluster einen hohen Anteil an flüchtigem Speicher nutzt. Wenn der flüchtige Speicher konstant hoch ist, können Sie die Nutzung des flüchtigen Speichers überprüfen und den flüchtigen Speicher erhöhen.

Absicht: Dieser Alarm wird verwendet, um eine hohe Nutzung des flüchtigen Speichers für den Fargate-Cluster zu erkennen. Eine gleichbleibend hohe Auslastung von flüchtigem Speicher kann darauf hinweisen, dass die Festplatte voll ist, was zu einem Ausfall des Containers führen kann.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf etwa 90 % der Größe des flüchtigen Speichers fest. Sie können diesen Wert auf der Grundlage Ihrer akzeptablen Nutzung von flüchtigem Speicher des Fargate-Clusters anpassen. Bei einigen Systemen kann eine gleichbleibend hohe Auslastung von flüchtigem Speicher normal sein, während dies bei anderen zum Ausfall des Containers führen kann.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

RunningTaskCount

Abmessungen:ClusterName, ServiceName

Beschreibung des Alarms: Dieser Alarm hilft Ihnen dabei, eine geringe Anzahl laufender Aufgaben des ECS-Services zu erkennen. Wenn die Anzahl der laufenden Aufgaben zu niedrig ist, kann dies darauf hinweisen, dass die Anwendung die Auslastung des Services nicht bewältigen kann, was zu Leistungsproblemen führen kann. Wenn es keine laufende Aufgabe gibt, ist der Amazon-ECS-Service möglicherweise nicht verfügbar oder es liegen Bereitstellungsprobleme vor.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob die Anzahl der laufenden Aufgaben zu gering ist. Eine konstant niedrige Anzahl ausgeführter Aufgaben kann auf Probleme bei der Bereitstellung oder Leistung des ECS-Services hinweisen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Sie können den Schwellenwert auf der Grundlage der Mindestanzahl laufender Aufgaben des ECS-Services anpassen. Wenn die Anzahl der laufenden Aufgaben 0 ist, ist der Amazon-ECS-Service nicht verfügbar.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: LESS_THAN_OR_EQUAL_TO_THRESHOLD

instance_filesystem_utilization

Abmessungen:InstanceId, ContainerInstanceId, ClusterName

Alarmbeschreibung: Dieser Alarm hilft Ihnen, eine hohe Dateisystem-Auslastung des ECS-Clusters zu erkennen. Wenn die Auslastung des Dateisystems konstant hoch ist, überprüfen Sie die Festplattennutzung.

Absicht: Dieser Alarm wird verwendet, um eine hohe Dateisystemauslastung für den Amazon-ECS-Cluster zu erkennen. Eine konstant hohe Dateisystemauslastung kann auf einen Ressourcenengpass oder auf Probleme mit der Anwendungsleistung hinweisen und die Ausführung neuer Aufgaben verhindern.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 90,0

Begründung des Schwellenwerts: In der Regel können Sie den Schwellenwert für die Dateisystem-Auslastung auf 90–95 % festlegen. Sie können diesen Wert auf der Grundlage der akzeptablen Dateisystemkapazität des Amazon-ECS-Clusters anpassen. Bei einigen Systemen ist eine konstant hohe Dateisystemauslastung möglicherweise normal und deutet nicht auf ein Problem hin, während sie bei anderen Anlass zur Sorge geben und zu Leistungseinbußen führen und die Ausführung neuer Aufgaben verhindern kann.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

PercentIOLimit

Abmessungen: FileSystemId

Alarmbeschreibung: Dieser Alarm trägt dazu bei, dass der Workload innerhalb des für das Dateisystem verfügbaren I/O-Limits bleibt. Wenn die Metrik regelmäßig das I/O-Limit erreicht, sollten Sie in Erwägung ziehen, die Anwendung auf ein Dateisystem zu verschieben, das als Modus die maximale I/O-Leistung verwendet. Überprüfen Sie zur Fehlerbehebung die Clients, die mit dem Dateisystem verbunden sind, und die Anwendungen der Clients, die das Dateisystem drosseln.

Absicht: Dieser Alarm wird verwendet, um festzustellen, wie nah das Dateisystem an der I/O-Grenze des General-Purpose-Performance-Modus ist. Ein gleichbleibend hoher I/O-Prozentsatz kann ein Hinweis darauf sein, dass das Dateisystem in Bezug auf I/O-Anfragen nicht ausreichend skaliert werden kann und dass das Dateisystem zu einem Ressourcenengpass für die Anwendungen, die das Dateisystem verwenden, führen kann.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 100,0

Begründung des Schwellenwerts: Wenn das Dateisystem sein I/O-Limit erreicht, reagiert es möglicherweise langsamer auf Lese- und Schreibanfragen. Daher wird empfohlen, die Metrik zu überwachen, um zu vermeiden, dass sich dies auf Anwendungen auswirkt, die das Dateisystem verwenden. Der Schwellenwert kann auf etwa 100 % festgelegt werden. Dieser Wert kann jedoch auf der Grundlage der Dateisystemeigenschaften auf einen niedrigeren Wert angepasst werden.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

BurstCreditBalance

Abmessungen: FileSystemId

Alarmbeschreibung: Mit diesem Alarm kann sichergestellt werden, dass für die Nutzung des Dateisystems ein ausreichendes Guthaben verfügbar ist. Wenn kein Sptzenwert-Guthaben verfügbar ist, wird der Zugriff von Anwendungen auf das Dateisystem aufgrund niedrigen Durchsatzes eingeschränkt. Wenn die Metrik kontinuierlich auf 0 sinkt, sollten Sie erwägen, den Durchsatzmodus in den Durchsatzmodus Elastic oder Provisioned zu ändern.

Absicht: Dieser Alarm wird verwendet, um einen niedrigen Guthabenstand des Dateisystems zu erkennen. Ein gleichbleibend niedriger Spitzenwert-Guthabenstand kann ein Indikator für eine Verlangsamung des Durchsatzes und eine Zunahme der I/O-Latenz sein.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,0

Begründung der Schwellenwerte: Wenn das Dateisystem keine Burst-Credits mehr hat und auch wenn die Basisdurchsatzrate niedriger ist, stellt EFS weiterhin einen gemessenen Durchsatz von 1 für alle Dateisysteme MiBps bereit. Es wird jedoch empfohlen, die Metrik im Hinblick auf ein niedriges Spitzenwert-Guthaben zu überwachen, um zu verhindern, dass das Dateisystem zu einem Ressourcenengpass für die Anwendungen wird. Der Schwellenwert kann auf etwa 0 Byte festgelegt werden.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: LESS_THAN_OR_EQUAL_TO_THRESHOLD

node_cpu_utilization

Abmessungen: ClusterName

Alarmbeschreibung: Dieser Alarm hilft dabei, eine hohe CPU-Auslastung in Worker-Knoten des EKS-Clusters zu erkennen. Wenn die Auslastung konstant hoch ist, kann dies darauf hindeuten, dass Sie Ihre Worker-Knoten durch Instances mit mehr CPU ersetzen müssen oder dass das System horizontal skaliert werden muss.

Absicht: Dieser Alarm hilft dabei, die CPU-Auslastung der Worker-Knoten im EKS-Cluster zu überwachen, sodass die Systemleistung nicht beeinträchtigt wird.

Statistik: Maximum

Empfohlener Schwellenwert: 80,0

Begründung des Schwellenwerts: Es wird empfohlen, den Schwellenwert auf weniger als oder gleich 80 % festzulegen, um genügend Zeit für das Debuggen des Problems zu haben, bevor das System Auswirkungen bemerkt.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

node_filesystem_utilization

Abmessungen: ClusterName

Alarmbeschreibung: Dieser Alarm hilft dabei, eine hohe Dateisystemauslastung in den Worker-Knoten des EKS-Clusters zu erkennen. Wenn die Auslastung konstant hoch ist, müssen Sie möglicherweise Ihre Worker-Knoten aktualisieren, um über ein größeres Festplattenvolumen zu verfügen, oder Sie müssen möglicherweise horizontal skalieren.

Absicht: Dieser Alarm hilft bei der Überwachung der Dateisystemauslastung der Worker-Knoten im EKS-Cluster. Wenn die Auslastung 100 % erreicht, kann dies zu einem Ausfall der Anwendung, zu Engpässen bei der Festplatten-I/O, zur Pod-Bereinigung oder dazu führen, dass der Knoten nicht mehr reagiert.

Statistik: Maximum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Bei ausreichendem Festplattendruck (was bedeutet, dass die Festplatte voll wird), werden Knoten als nicht fehlerfrei markiert und die Pods werden aus dem Knoten entfernt. Pods auf einem Knoten mit hoher Festplattenauslastung werden entfernt, wenn das verfügbare Dateisystem unter den im Kubelet festgelegten Schwellenwerten für die Bereinigung liegt. Stellen Sie den Alarmschwellenwert so ein, dass Sie genügend Zeit haben, um zu reagieren, bevor der Knoten aus dem Cluster entfernt wird.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

node_memory_utilization

Abmessungen: ClusterName

Alarmbeschreibung: Dieser Alarm hilft bei der Erkennung einer hohen Speicherauslastung in Worker-Knoten des EKS-Clusters. Wenn die Auslastung konstant hoch ist, deutet dies möglicherweise darauf hin, dass Sie die Anzahl der Pod-Replikate skalieren oder Ihre Anwendung optimieren müssen.

Absicht: Dieser Alarm hilft dabei, die Speicherauslastung der Worker-Knoten im EKS-Cluster zu überwachen, sodass die Systemleistung nicht beeinträchtigt wird.

Statistik: Maximum

Empfohlener Schwellenwert: 80,0

Begründung des Schwellenwerts: Es wird empfohlen, den Schwellenwert auf weniger als oder gleich 80 % festzulegen, damit genügend Zeit für das Debuggen des Problems zur Verfügung steht, bevor das System Auswirkungen bemerkt.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

pod_cpu_utilization_over_pod_limit

Abmessungen:ClusterName, Namespace, Service

Alarmbeschreibung: Dieser Alarm hilft bei der Erkennung einer hohen CPU-Auslastung in Pods des EKS-Clusters. Wenn die Auslastung konstant hoch ist, deutet dies möglicherweise darauf hin, dass das CPU-Limit für den betroffenen Pod erhöht werden muss.

Absicht: Dieser Alarm hilft dabei, die CPU-Auslastung der Pods zu überwachen, die zu einem Kubernetes-Service im EKS-Cluster gehören, sodass Sie schnell erkennen können, ob der Pod eines Services mehr CPU verbraucht als erwartet.

Statistik: Maximum

Empfohlener Schwellenwert: 80,0

Begründung des Schwellenwerts: Es wird empfohlen, den Schwellenwert auf weniger als oder gleich 80 % festzulegen, damit genügend Zeit für das Debuggen des Problems zur Verfügung steht, bevor das System Auswirkungen bemerkt.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

pod_memory_utilization_over_pod_limit

Dimensionen:ClusterName, Namespace, Service

Alarmbeschreibung: Dieser Alarm hilft bei der Erkennung einer hohen Speicherauslastung in Pods des EKS-Clusters. Wenn die Auslastung konstant hoch ist, deutet dies möglicherweise darauf hin, dass das Speicherlimit für den betroffenen Pod erhöht werden muss.

Absicht: Dieser Alarm hilft dabei, die Speicherauslastung der Pods im EKS-Cluster zu überwachen, sodass die Systemleistung nicht beeinträchtigt wird.

Statistik: Maximum

Empfohlener Schwellenwert: 80,0

Begründung des Schwellenwerts: Es wird empfohlen, den Schwellenwert auf weniger als oder gleich 80 % festzulegen, damit genügend Zeit für das Debuggen des Problems zur Verfügung steht, bevor das System Auswirkungen bemerkt.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

GetRecords.IteratorAgeMilliseconds

Abmessungen: StreamName

Alarmbeschreibung: Dieser Alarm kann erkennen, ob das Höchstalter des Iterators zu hoch ist. Bei Datenverarbeitungsanwendungen in Echtzeit sollten Sie die Datenaufbewahrung entsprechend der Verzögerungstoleranz konfigurieren. Dies ist normalerweise innerhalb von Minuten der Fall. Verwenden Sie bei Anwendungen, die historische Daten verarbeiten, diese Metrik, um die Aufholgeschwindigkeit zu überwachen. Eine schnelle Lösung, um Datenverlust zu verhindern, besteht darin, die Aufbewahrungsdauer zu verlängern, während Sie das Problem beheben. Sie können auch die Anzahl der Worker erhöhen, die Datensätze in Ihrer Verbraucheranwendung verarbeiten. Die häufigsten Ursachen für einen allmählichen Anstieg des Iterator-Alters sind unzureichende physische Ressourcen oder eine Logik für die Datensatzverarbeitung, die nicht mit einem Anstieg des Stream-Durchsatzes skaliert. Weitere Einzelheiten finden Sie unter dem Link.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, ob die Daten in Ihrem Stream ablaufen, weil sie zu lange aufbewahrt werden oder weil die Verarbeitung der Datensätze zu langsam ist. Er hilft Ihnen, Datenverluste zu vermeiden, nachdem Sie 100 % der Stream-Aufbewahrungszeit erreicht haben.

Statistik: Maximum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von der Aufbewahrungsdauer des Streams und der Toleranz der Verarbeitungsverzögerungen für die Datensätze ab. Überprüfen Sie Ihre Anforderungen und analysieren Sie historische Trends. Legen Sie dann den Schwellenwert auf die Anzahl von Millisekunden fest, die einer kritischen Verarbeitungsverzögerung entspricht. Wenn das Alter eines Iterators 50 % des Aufbewahrungszeitraums (standardmäßig 24 Stunden, anpassbar auf bis zu 365 Tage) überschreitet, besteht die Gefahr des Datenverlusts durch Ablauf des Datensatzes. Sie können die Metrik überwachen, um sicherzustellen, dass keiner Ihrer Shards jemals dieses Limit erreicht.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

GetRecords. Erfolg

Abmessungen: StreamName

Alarmbeschreibung: Diese Metrik wird immer dann erhöht, wenn Ihre Verbraucher erfolgreich Daten aus Ihrem Stream lesen. GetRecords gibt keine Daten zurück, wenn eine Ausnahme auslöst wird. Die häufigste Ausnahme ist ProvisionedThroughputExceededException, weil die Anfragerate für den Stream zu hoch ist oder weil der verfügbare Durchsatz für die angegebene Sekunde bereits bereitgestellt wurde. Reduzieren Sie die Häufigkeit oder den Umfang Ihrer Anfragen. Weitere Informationen finden Sie unter Streams Limits im Entwicklerhandbuch von Amazon Kinesis Data Streams und unter Error Retries and Exponential Backoff in AWS.

Absicht: Dieser Alarm kann erkennen, ob das Abrufen von Datensätzen aus dem Stream durch Verbraucher fehlschlägt. Wenn Sie einen Alarm für diese Metrik einrichten, können Sie proaktiv alle Probleme mit dem Datenverbrauch erkennen, z. B. erhöhte Fehlerraten oder einen Rückgang erfolgreicher Abrufe. Auf diese Weise können Sie rechtzeitig Maßnahmen ergreifen, um potenzielle Probleme zu lösen und eine reibungslose Datenverarbeitungspipeline aufrechtzuerhalten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Je nachdem, wie wichtig es ist, Datensätze aus dem Stream abzurufen, legen Sie den Schwellenwert auf der Grundlage der Toleranz Ihrer Anwendung für fehlgeschlagene Datensätze fest. Der Schwellenwert sollte dem entsprechenden Prozentsatz erfolgreicher Vorgänge entsprechen. Sie können historische GetRecords Metrikdaten als Referenz für die akzeptable Ausfallrate verwenden. Sie sollten bei der Festlegung des Schwellenwerts auch Wiederholungsversuche in Betracht ziehen, da fehlgeschlagene Datensätze wiederholt werden können. Auf diese Weise wird verhindert, dass vorübergehende Spitzenwerte unnötige Warnmeldungen auslösen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: LESS_THAN_THRESHOLD

PutRecord. Erfolg

Abmessungen: StreamName

Alarmbeschreibung: Dieser Alarm erkennt, wenn die Anzahl der fehlgeschlagenen PutRecord-Vorgänge den Schwellenwert überschreitet. Untersuchen Sie die Datenproduzent-Protokolle, um die Hauptursachen der Fehler zu ermitteln. Der häufigste Grund ist ein unzureichender bereitgestellter Durchsatz auf dem Shard, der ProvisionedThroughputExceededException verursacht hat. Dies geschieht, weil die Anfragerate für den Stream zu hoch ist oder der Durchsatz, der in den Shard aufgenommen werden sollte, zu hoch ist. Reduzieren Sie die Häufigkeit oder den Umfang Ihrer Anfragen. Weitere Informationen finden Sie unter Streams Limits and Error Retries und Exponential Backoff in. AWS

Absicht: Dieser Alarm kann erkennen, ob die Erfassung von Datensätzen in den Stream fehlschlägt. Er hilft Ihnen dabei, Probleme beim Schreiben von Daten in den Stream zu identifizieren. Indem Sie bei dieser Metrik einen Alarm einrichten, können Sie proaktiv alle Probleme erkennen, die Produzenten bei der Veröffentlichung von Daten im Stream haben, z. B. erhöhte Fehlerquoten oder einen Rückgang erfolgreicher Veröffentlichungen von Datensätzen. Auf diese Weise können Sie rechtzeitig Maßnahmen ergreifen, um potenzielle Probleme zu beheben und einen zuverlässigen Datenerfassungsprozess aufrechtzuerhalten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Je nachdem, wie wichtig die Datenerfassung und -verarbeitung für Ihren Service ist, legen Sie den Schwellenwert auf der Grundlage der Toleranz Ihrer Anwendung für fehlerhafte Datensätze fest. Der Schwellenwert sollte dem entsprechenden Prozentsatz erfolgreicher Vorgänge entsprechen. Sie können historische PutRecord Metrikdaten als Referenz für die akzeptable Ausfallrate verwenden. Sie sollten bei der Festlegung des Schwellenwerts auch Wiederholungsversuche in Betracht ziehen, da fehlgeschlagene Datensätze wiederholt werden können.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: LESS_THAN_THRESHOLD

PutRecords.FailedRecords

Abmessungen: StreamName

Alarmbeschreibung: Dieser Alarm erkennt, wenn die Anzahl der fehlgeschlagenen PutRecords den Schwellenwert überschreitet. Kinesis Data Streams versucht, alle Datensätze in jeder PutRecords-Anfrage zu verarbeiten, aber der Ausfall eines einzelnen Datensatzes verhindert nicht die Verarbeitung nachfolgender Datensätze. Der Hauptgrund für diese Fehler ist die Überschreitung des Durchsatzes eines Streams oder eines einzelnen Shards. Häufige Ursachen sind Verkehrsspitzen und Netzwerklatenzen, die dazu führen, dass Datensätze ungleichmäßig im Stream ankommen. Sie sollten erfolglos verarbeitete Datensätze erkennen und sie in einem späteren Aufruf erneut versuchen. Weitere Informationen finden Sie unter Behandlung von Fehlern bei der Verwendung PutRecords.

Absicht: Dieser Alarm kann konsistente Fehler erkennen, wenn Datensätze mithilfe eines Batch-Vorgangs in Ihren Stream aufgenommen werden. Wenn Sie einen Alarm für diese Metrik einrichten, können Sie proaktiv eine Zunahme fehlgeschlagener Datensätze erkennen und so rechtzeitig Maßnahmen ergreifen, um die zugrunde liegenden Probleme zu beheben und einen reibungslosen und zuverlässigen Datenerfassungsprozess sicherzustellen.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf die Anzahl der fehlgeschlagenen Datensätze fest, was der Toleranz der Anwendung gegenüber fehlerhaften Datensätzen entspricht. Sie können historische Daten als Referenz für den akzeptablen Fehlerwert verwenden. Sie sollten bei der Festlegung des Schwellenwerts auch Wiederholungsversuche in Betracht ziehen, da fehlgeschlagene Datensätze bei nachfolgenden PutRecords Aufrufen erneut versucht werden können.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

ReadProvisionedThroughputExceeded

Abmessungen: StreamName

Alarmbeschreibung: Der Alarm verfolgt die Anzahl der Datensätze, die zu einer Drosselung der Lesedurchsatzkapazität führen. Wenn Sie feststellen, dass Sie ständig gedrosselt werden, sollten Sie erwägen, Ihrem Stream weitere Shards hinzuzufügen, um den bereitgestellten Lesedurchsatz zu erhöhen. Wenn mehr als eine Verbraucheranwendung auf dem Stream läuft und diese Anwendungen das GetRecords-Limit gemeinsam nutzen, empfehlen wir Ihnen, neue Verbraucheranwendungen über Enhanced Fan-Out zu registrieren. Wenn das Hinzufügen weiterer Shards die Anzahl der Drosselungen nicht verringert, haben Sie möglicherweise einen „heißen“ Shard, der von mehr Shards gelesen wird als andere Shards. Aktivieren Sie die erweiterte Überwachung, suchen Sie den „heißen“ Shard und teilen Sie ihn auf.

Absicht: Dieser Alarm kann erkennen, ob Verbraucher gedrosselt werden, wenn sie Ihren bereitgestellten Lesedurchsatz überschreiten (bestimmt durch die Anzahl Ihrer Shards). In diesem Fall können Sie nicht aus dem Stream lesen, und der Stream kann mit der Sicherung beginnen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Normalerweise können gedrosselte Anfragen erneut versucht werden. Wenn der Schwellenwert auf Null gesetzt wird, ist der Alarm daher zu empfindlich. Eine konsequente Drosselung kann sich jedoch auf das Lesen aus dem Stream auswirken und sollte den Alarm auslösen. Legen Sie den Schwellenwert auf einen Prozentsatz fest, der den gedrosselten Anfragen für die Anwendung entspricht, und versuchen Sie es erneut mit den Konfigurationen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

SubscribeToShardEvent.MillisBehindLatest

Abmessungen:StreamName, ConsumerName

Alarmbeschreibung: Dieser Alarm erkennt, wenn die Verzögerung der Datensatzverarbeitung in der Anwendung den Schwellenwert überschreitet. Vorübergehende Probleme wie API-Betriebsausfälle bei einer nachgelagerten Anwendung können zu einem plötzlichen Anstieg in der Metrik führen. Sie sollten untersuchen, ob sie regelmäßig auftreten. Eine häufige Ursache ist, dass der Verbraucher Datensätze nicht schnell genug verarbeitet, weil nicht genügend physische Ressourcen zur Verfügung stehen oder die Logik der Datensatzverarbeitung nicht mit einem Anstieg des Stream-Durchsatzes skaliert wurde. Das Blockieren von Aufrufen im kritischen Pfad ist häufig die Ursache für eine Verlangsamung der Datensatzverarbeitung. Sie können Ihre Parallelität erhöhen, indem Sie die Anzahl der Shards erhöhen. Sie sollten auch sicherstellen, dass die zugrunde liegenden Verarbeitungsknoten bei hoher Nachfrage über ausreichende physische Ressourcen verfügen.

Absicht: Dieser Alarm kann eine Verzögerung beim Ereignis „Abonnement des Shards“ für den Stream erkennen. Dies deutet auf eine Verarbeitungsverzögerung hin und kann dazu beitragen, potenzielle Probleme mit der Leistung der Verbraucheranwendung oder dem allgemeinen Zustand des Streams zu identifizieren. Wenn die Verarbeitungsverzögerung erheblich ansteigt, sollten Sie etwaige Engpässe oder Ineffizienzen bei Verbraucheranwendungen untersuchen und beheben, um die Datenverarbeitung in Echtzeit sicherzustellen und Datenrückstände zu minimieren.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von der Verzögerung ab, die Ihre Anwendung tolerieren kann. Prüfen Sie die Anforderungen Ihrer Anwendung, analysieren Sie historische Trends und wählen Sie dann einen entsprechenden Schwellenwert aus. Wenn der SubscribeToShard Anruf erfolgreich ist, empfängt Ihr Kunde bis zu 5 Minuten lang SubscribeToShardEvent Ereignisse über die persistente Verbindung. Danach müssen Sie SubscribeToShard erneut anrufen, um das Abonnement zu verlängern, wenn Sie weiterhin Aufzeichnungen erhalten möchten.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

WriteProvisionedThroughputExceeded

Abmessungen: StreamName

Alarmbeschreibung: Dieser Alarm erkennt, wenn die Anzahl der Datensätze, die zu einer Drosselung der Schreibdurchsatzkapazität geführt haben, den Schwellenwert erreicht hat. Wenn Ihre Produzenten Ihren bereitgestellten Schreibdurchsatz (bestimmt durch die Anzahl Ihrer Shards) überschreiten, werden sie gedrosselt und Sie können keine Datensätze in den Stream aufnehmen. Um einer ständigen Drosselung entgegenzuwirken, sollten Sie erwägen, Ihrem Stream Shards hinzuzufügen. Dies erhöht den bereitgestellten Schreibdurchsatz und verhindert zukünftige Drosselungen. Sie sollten bei der Aufnahme von Datensätzen auch die Wahl des Partitionsschlüssels berücksichtigen. Ein zufälliger Partitionsschlüssel wird bevorzugt, da er die Datensätze, wann immer möglich, gleichmäßig auf die Shards des Streams verteilt.

Absicht: Dieser Alarm kann erkennen, ob Ihre Produzenten aufgrund einer Drosselung des Streams oder Shards für das Schreiben von Datensätzen abgewiesen werden. Wenn sich Ihr Stream im Bereitstellungsmodus befindet, können Sie durch die Einstellung dieses Alarms proaktiv Maßnahmen ergreifen, wenn der Datenstrom seine Grenzen erreicht. So können Sie die bereitgestellte Kapazität optimieren oder geeignete Skalierungsmaßnahmen ergreifen, um Datenverlust zu vermeiden und eine reibungslose Datenverarbeitung aufrechtzuerhalten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Normalerweise können gedrosselte Anfragen erneut versucht werden. Wenn Sie den Schwellenwert also auf Null setzen, wird der Alarm zu empfindlich. Eine konsistente Drosselung kann sich jedoch auf das Schreiben in den Stream auswirken. Sie sollten den Alarmschwellenwert so einstellen, dass dies erkannt wird. Legen Sie den Schwellenwert auf einen Prozentsatz fest, der den gedrosselten Anfragen für die Anwendung entspricht, und versuchen Sie es erneut mit den Konfigurationen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

ClaimedAccountConcurrency

Dimensionen: Keine

Beschreibung des Alarms: Mit diesem Alarm können Sie überwachen, ob sich die Parallelität Ihrer Lambda-Funktionen dem Parallelitätslimit Ihres Kontos auf Regionsebene nähert. Eine Funktion wird gedrosselt, wenn sie das Gleichzeitigkeitslimit erreicht. Sie können folgende Aktionen durchführen, um Drosselung zu vermeiden.

Fordern Sie eine Erhöhung der Parallelität in dieser Region an.
Identifizieren und reduzieren Sie jegliche ungenutzte reservierte Parallelität oder bereitgestellte Parallelität.
Identifizieren Sie Leistungsprobleme bei den Funktionen, um die Verarbeitungsgeschwindigkeit und damit den Durchsatz zu verbessern.
Erhöhen Sie die Batchgröße der Funktionen, sodass bei jedem Funktionsaufruf mehr Nachrichten verarbeitet werden.

Absicht: Dieser Alarm kann proaktiv erkennen, ob sich die Parallelität Ihrer Lambda-Funktionen dem Parallelitätskontingent auf Regionsebene Ihres Kontos nähert, sodass Sie entsprechend handeln können. Funktionen werden gedrosselt, wenn das Kontingent für Parallelität auf Regionsebene für das Konto ClaimedAccountConcurrency erreicht wird. Wenn Sie Reserved Concurrency (RC) oder Provisioned Concurrency (PC) verwenden, erhalten Sie mit diesem Alarm einen besseren Überblick über die Parallelitätsnutzung als bei einem Alarm. ConcurrentExecutions

Statistik: Maximum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Sie sollten den Wert von etwa 90% der Quote für Parallelität berechnen, die für das Konto in der Region festgelegt wurde, und das Ergebnis als Schwellenwert verwenden. Standardmäßig verfügt Ihr Konto über ein Gleichzeitigkeitskontingent von 1 000 für alle Funktionen in einer Region. Sie sollten jedoch das Kontingent Ihres Kontos im Service-Kontingents-Dashboard überprüfen.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_THRESHOLD

Fehler

Abmessungen: FunctionName

Alarmbeschreibung: Dieser Alarm erkennt hohe Fehlerzahlen. Zu den Fehlern gehören die vom Code ausgelösten Ausnahmen sowie die von der Lambda-Laufzeit ausgelösten Ausnahmen. Sie können die mit der Funktion verbundenen Protokolle überprüfen, um das Problem zu diagnostizieren.

Absicht: Dieser Alarm hilft dabei, hohe Fehlerzahlen bei Funktionsaufrufen zu erkennen.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Setzen Sie den Schwellenwert auf eine Zahl größer als Null. Der genaue Wert kann von der Fehlertoleranz in Ihrer Anwendung abhängen. Machen Sie sich mit der Wichtigkeit der Aufrufe vertraut, die die Funktion verarbeitet. Bei einigen Anwendungen kann jeder Fehler inakzeptabel sein, während andere Anwendungen eine gewisse Fehlerquote zulassen können.

Zeitraum: 60

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: GREATER_THAN_THRESHOLD

Drosselungen

Abmessungen: FunctionName

Alarmbeschreibung: Dieser Alarm erkennt eine hohe Anzahl gedrosselter Aufrufanfragen. Drosselung findet statt, wenn keine Gleichzeitigkeit für das Hochskalieren verfügbar ist. Es gibt mehrere Möglichkeiten, um dieses Problem zu beheben. 1) Fordern Sie beim AWS Support in dieser Region eine Erhöhung der Parallelität an. 2) Identifizieren Sie Leistungsprobleme in der Funktion, um die Verarbeitungsgeschwindigkeit und damit den Durchsatz zu verbessern. 3) Erhöhen Sie die Batchgröße der Funktion, sodass bei jedem Funktionsaufruf mehr Nachrichten verarbeitet werden.

Absicht: Dieser Alarm hilft dabei, eine hohe Anzahl gedrosselter Aufrufanfragen für eine Lambda-Funktion zu erkennen. Es ist wichtig zu wissen, ob Anfragen aufgrund von Drosselung ständig abgelehnt werden und ob Sie die Leistung der Lambda-Funktionen verbessern oder die Gleichzeitigkeitskapazität erhöhen müssen, um eine ständige Drosselung zu vermeiden.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Setzen Sie den Schwellenwert auf eine Zahl größer als Null. Der genaue Wert des Schwellenwerts kann von der Toleranz der Anwendung abhängen. Stellen Sie den Schwellenwert entsprechend den Nutzungs- und Skalierungsanforderungen der Funktion ein.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Duration (Dauer)

Abmessungen: FunctionName

Alarmbeschreibung: Dieser Alarm erkennt lange Verarbeitungszeiten eines Ereignisses durch eine Lambda-Funktion. Lange Zeiträume können auf Änderungen im Funktionscode zurückzuführen sein, die dazu führen, dass die Ausführung der Funktion länger dauert, oder dass die Abhängigkeiten der Funktion länger dauern.

Absicht: Dieser Alarm kann eine lange Laufzeitdauer einer Lambda-Funktion erkennen. Eine hohe Laufzeitdauer weist darauf hin, dass der Aufruf einer Funktion länger dauert, und kann sich auch auf die Gleichzeitigkeitskapazität des Aufrufs auswirken, wenn Lambda eine höhere Anzahl von Ereignissen verarbeitet. Es ist wichtig zu wissen, ob die Ausführung der Lambda-Funktion ständig länger dauert als erwartet.

Statistik: p90

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der Schwellenwert für die Dauer hängt von Ihrer Anwendung und Ihren Workloads sowie Ihren Leistungsanforderungen ab. Legen Sie für Hochleistungsanforderungen den Schwellenwert auf einen kürzeren Zeitraum fest, um festzustellen, ob die Funktion die Erwartungen erfüllt. Sie können auch historische Daten für die Dauer analysieren, um festzustellen, ob die benötigte Zeit den Leistungserwartungen der Funktion entspricht, und dann den Schwellenwert auf einen längeren Zeitraum als den historischen Durchschnitt festlegen. Stellen Sie sicher, dass Sie den Schwellenwert unter dem konfigurierten Funktions-Timeout einstellen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

ConcurrentExecutions

Abmessungen: FunctionName

Alarmbeschreibung: Mit diesem Alarm können Sie überwachen, ob sich die Gleichzeitigkeit der Funktion dem Gleichzeitigkeitslimit Ihres Kontos auf Regionsebene nähert. Eine Funktion wird gedrosselt, wenn sie das Gleichzeitigkeitslimit erreicht. Sie können folgende Aktionen durchführen, um Drosselung zu vermeiden.

Beantragen Sie eine Erhöhung der Parallelität in dieser Region.
Identifizieren Sie Leistungsprobleme in den Funktionen, um die Verarbeitungsgeschwindigkeit und damit den Durchsatz zu verbessern.
Erhöhen Sie die Batchgröße der Funktionen, sodass bei jedem Funktionsaufruf mehr Nachrichten verarbeitet werden.

Um einen besseren Überblick über reservierte Parallelität und bereitgestellte Parallelität zu erhalten, sollten Sie stattdessen einen Alarm für die neue Metrik einrichten. ClaimedAccountConcurrency

Absicht: Dieser Alarm kann proaktiv erkennen, ob sich die Gleichzeitigkeit der Funktion dem Gleichzeitigkeitskontingent auf Regionsebene Ihres Kontos nähert, sodass Sie entsprechend handeln können. Eine Funktion wird gedrosselt, wenn sie das Gleichzeitigkeitskontingent auf Regionsebene des Kontos erreicht.

Statistik: Maximum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert auf etwa 90 % des Gleichzeitigkeitskontingents fest, das für das Konto in der Region festgelegt wurde. Standardmäßig verfügt Ihr Konto über ein Gleichzeitigkeitskontingent von 1 000 für alle Funktionen in einer Region. Sie können jedoch das Kontingent Ihres Kontos überprüfen, da es erhöht werden kann, indem Sie sich an den Support wenden. AWS

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_THRESHOLD

memory_utilization

Dimensionen: function_name

Alarmbeschreibung: Dieser Alarm wird verwendet, um festzustellen, ob sich die Speicherauslastung einer Lambda-Funktion dem konfigurierten Grenzwert nähert. Zur Fehlerbehebung können Sie versuchen, 1) Ihren Code optimieren. 2) Die richtige Größe Ihrer Speicherzuweisung festlegen, indem Sie den Speicherbedarf genau abschätzen. Sie können dafür in Lambda Power Tuning mehr dazu erfahren. 3) Verwenden von Verbindungspooling. Informationen zum Verbindungspooling für die RDS-Datenbank finden Sie unter Amazon-RDS-Proxy mit Lambda verwenden. 4) Sie können auch erwägen, Ihre Funktionen so zu gestalten, dass zwischen Aufrufen keine großen Datenmengen im Speicher gespeichert werden.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, ob sich die Speicherauslastung für die Lambda-Funktion dem konfigurierten Grenzwert nähert.

Statistik: Durchschnitt

Schwellenwertvorschlag: 90,0

Begründung des Schwellenwerts: Stellen Sie den Schwellenwert auf 90 % ein, um eine Warnung zu erhalten, wenn die Speicherauslastung 90 % des zugewiesenen Speichers überschreitet. Sie können diesen Wert auf einen niedrigeren Wert anpassen, wenn Sie Bedenken hinsichtlich der Speicherauslastung des Workloads haben. Sie können auch die historischen Daten für diese Metrik überprüfen und den Schwellenwert entsprechend festlegen.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

ComparisonOperator: GREATER_THAN_THRESHOLD

ErrorPortAllocation

Abmessungen: NatGatewayId

Alarmbeschreibung: Dieser Alarm hilft zu erkennen, wenn NAT-Gateway neuen Verbindungen keine Ports zuweisen kann. Informationen zur Behebung dieses Problems finden Sie unter Beheben von Portzuweisungsfehlern auf NAT-Gateway.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob NAT-Gateway keinen Quell-Port zuordnen konnte.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Wenn der Wert von größer als Null ErrorPortAllocation ist, bedeutet das, dass zu viele gleichzeitige Verbindungen zu einem einzigen beliebten Ziel über NatGateway geöffnet sind.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

PacketsDropCount

Abmessungen: NatGatewayId

Alarmbeschreibung: Dieser Alarm hilft zu erkennen, wenn Pakete von NAT-Gateway verworfen werden. Dies kann auf ein Problem mit NAT Gateway zurückzuführen sein. Überprüfen Sie daher das AWS Service Health Dashboard, um den Status von AWS NAT Gateway in Ihrer Region zu überprüfen. Dies kann Ihnen helfen, das Netzwerkproblem im Zusammenhang mit dem Datenverkehr über NAT-Gateway zu korrelieren.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob Pakete von NAT-Gateway verworfen werden.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Sie sollten den Wert von 0,01 Prozent des Gesamtdatenverkehrs auf NAT-Gateway berechnen und dieses Ergebnis als Schwellenwert verwenden. Verwenden Sie historische Daten des Datenverkehrs auf NAT-Gateway, um den Schwellenwert zu bestimmen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

PacketsDropped

Dimensionen: VPC-ID, VPC-Endpunkt-ID, Endpunkt-Typ, Subnetz-ID, Servicename

Alarmbeschreibung: Dieser Alarm hilft zu erkennen, ob der Endpunkt oder der Endpunkt-Service fehlerhaft ist, indem er die Anzahl der vom Endpunkt verworfenen Pakete überwacht. Beachten Sie, dass Pakete, die größer als 8 500 Byte sind und am VPC-Endpunkt ankommen, verworfen werden. Informationen zur Fehlerbehebung finden Sie unter Verbindungsprobleme zwischen einem Schnittstellen-VPC-Endpunkt und einem Endpunkt-Service.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob der Endpunkt oder Endpunkt-Service in einem fehlerhaften Zustand ist.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert entsprechend dem Anwendungsfall fest. Wenn Sie über den fehlerhaften Status des Endpunkts oder Endpunkt-Services informiert werden möchten, sollten Sie den Schwellenwert niedrig ansetzen, damit Sie die Chance haben, das Problem zu beheben, bevor ein großer Datenverlust entsteht. Sie können historische Daten verwenden, um die Toleranz gegenüber verworfenen Paketen zu ermitteln und den Schwellenwert entsprechend festzulegen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

RstPacketsSent

Dimensionen: Service Id, Load Balancer Arn, Az

Alarmbeschreibung: Dieser Alarm hilft Ihnen dabei, fehlerhafte Ziele eines Endpunkt-Services anhand der Anzahl der an Endpunkte gesendeten Reset-Pakete zu erkennen. Wenn Sie Verbindungsfehler mit einem Benutzer Ihres Dienstes debuggen, können Sie anhand der RstPacketsSent Metrik überprüfen, ob der Dienst Verbindungen zurücksetzt oder ob etwas anderes auf dem Netzwerkpfad fehlschlägt.

Absicht: Dieser Alarm wird verwendet, um fehlerhafte Ziele eines Endpunkt-Services zu erkennen.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der Schwellenwert hängt vom Anwendungsfall ab. Wenn Ihr Anwendungsfall toleriert, dass Ziele fehlerhaft sind, können Sie den Schwellenwert hoch setzen. Wenn der Anwendungsfall fehlerhafte Ziele nicht toleriert, können Sie den Schwellenwert als sehr niedrig festlegen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

CPUUtilization

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung einer gleichbleibend hohen CPU-Auslastung. Bei der CPU-Auslastung wird die Betriebszeit gemessen. Erwägen Sie, Erweiterte Überwachung oder Performance Insights zu verwenden, um für MariaDB, MySQL, Oracle und PostgreSQL zu überprüfen, welche Wartezeit die meiste CPU-Zeit (guest, irq, wait, nice, usw.) beansprucht. Analysieren Sie dann, welche Abfragen die größte Menge an CPU-Leistung verbrauchen. Wenn Sie Ihre Workload nicht optimieren können, sollten Sie erwägen, zu einer größeren DB-Instance-Klasse zu wechseln.

Absicht: Dieser Alarm wird verwendet, um eine konstant hohe CPU-Auslastung zu erkennen, um sehr hohe Reaktionszeiten und Timeouts zu vermeiden. Wenn Sie die CPU-Auslastung im Mikro-Bursting überprüfen möchten, können Sie eine kürzere Zeit für die Auswertung von Alarmen festlegen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 90,0

Begründung des Schwellenwerts: Zufällige CPU-Auslastungsspitzen beeinträchtigen möglicherweise nicht die Datenbankleistung, aber ein anhaltend hoher CPU-Wert kann bevorstehende Datenbankanfragen behindern. Abhängig von der Gesamt-Workload der Datenbank kann eine hohe CPU-Auslastung Ihrer RDS/Aurora-Instance die Gesamtleistung beeinträchtigen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

DatabaseConnections

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm erkennt eine hohe Anzahl von Verbindungen. Überprüfen Sie die bestehenden Verbindungen und beenden Sie alle Verbindungen, die sich im Ruhemodus befinden oder die nicht ordnungsgemäß geschlossen wurden. Erwägen Sie die Verwendung von Verbindungspooling, um die Anzahl neuer Verbindungen zu begrenzen. Alternativ können Sie die DB-Instance-Größe erhöhen, um eine Klasse mit mehr Speicher und damit einem höheren Standardwert für `max_connections` zu verwenden, oder erhöhen Sie den Wert von `max_connections` in RDS und Aurora MySQL und PostgreSQL für die aktuelle Klasse, wenn sie Ihre Workload unterstützen kann.

Absicht: Dieser Alarm wird verwendet, um zu verhindern, dass Verbindungen abgewiesen werden, wenn die maximale Anzahl von DB-Verbindungen erreicht ist. Dieser Alarm wird nicht empfohlen, wenn Sie die DB-Instance-Klasse häufig ändern, da sich dadurch der Arbeitsspeicher und die standardmäßige maximale Anzahl von Verbindungen ändern.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Die Anzahl der zulässigen Verbindungen hängt von der Größe Ihrer DB-Instance-Klasse und den Datenbank-Engine-spezifischen Parametern in Bezug auf Prozesse/Verbindungen ab. Sie sollten einen Wert zwischen 90 und 95 % der maximalen Anzahl von Verbindungen für Ihre Datenbank berechnen und dieses Ergebnis als Schwellenwert verwenden.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

EBS% ByteBalance

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft dabei, einen niedrigen Prozentsatz der verbleibenden Durchsatz-Credits zu überwachen. Informationen zur Fehlerbehebung finden Sie unter Latenzprobleme in RDS.

Absicht: Dieser Alarm wird verwendet, um einen niedrigen Prozentsatz an verbleibenden Durchsatz-Credits im Burst-Bucket zu erkennen. Ein niedriger Byte-Restprozentsatz kann zu Durchsatzengpässen führen. Dieser Alarm wird für Aurora-PostgreSQL-Instances nicht empfohlen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 10,0

Begründung des Schwellenwerts: Ein Durchsatzguthaben unter 10 % wird als schlecht angesehen, und Sie sollten den Schwellenwert entsprechend festlegen. Sie können auch einen niedrigeren Schwellenwert festlegen, wenn Ihre Anwendung einen niedrigeren Durchsatz für den Workload toleriert.

Zeitraum: 60

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: LESS_THAN_THRESHOLD

EBSIOBalance%

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft dabei, einen niedrigen Prozentsatz der verbleibenden IOPS-Credits zu überwachen. Informationen zur Fehlerbehebung finden Sie unter Latenzprobleme in RDS.

Absicht: Dieser Alarm wird verwendet, um einen niedrigen Prozentsatz an verbleibenden I/O-Credits im Burst-Bucket zu erkennen. Ein niedriger IOPS-Restprozentsatz kann zu IOPS-Engpässen führen. Dieser Alarm wird für Aurora-Instances nicht empfohlen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 10,0

Begründung des Schwellenwerts: Ein IOPS-Guthaben unter 10 % wird als schlecht angesehen, und Sie sollten den Schwellenwert entsprechend festlegen. Sie können auch einen niedrigeren Schwellenwert festlegen, wenn Ihre Anwendung einen niedrigeren IOPS für den Workload toleriert.

Zeitraum: 60

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: LESS_THAN_THRESHOLD

FreeableMemory

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung eines niedrigen freisetzbarem Speicherplatzes. Dies kann bedeuten, dass die Datenbankverbindungen stark ansteigen oder dass Ihre Instance unter hohem Speicherdruck steht. Prüfen Sie den Speicherdruck, indem Sie die CloudWatch Messwerte für SwapUsage `zusätzlich zu FreeableMemory überwachen. Wenn der Speicherverbrauch der Instance häufig zu hoch ist, bedeutet dies, dass Sie die Workload prüfen sollten oder die Instance aktualisieren müssen. Erwägen Sie für Aurora-Reader-DB-Instance, dem Cluster zusätzliche Reader-DB-Instances hinzuzufügen. Weitere Informationen zur Fehlerbehebung von Aurora finden Sie unter Probleme mit freisetzbarem Speicher.

Absicht: Dieser Alarm wird verwendet, um zu verhindern, dass nicht genügend Arbeitsspeicher zur Verfügung steht, was zu abgelehnten Verbindungen führen kann.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Je nach Workload und Instance-Klasse können unterschiedliche Werte für den Schwellenwert angemessen sein. Idealerweise sollte der verfügbare Arbeitsspeicher über längere Zeiträume nicht unter 25 % des gesamten Arbeitsspeichers fallen. Für Aurora können Sie diesen Schwellenwert nahe an 5 % einstellen, denn wenn sich diese Metrik dem Wert 0 nähert, ist die DB-Instance so weit wie möglich hochskaliert. Sie können das historische Verhalten dieser Metrik analysieren, um sinnvolle Schwellenwerte zu ermitteln.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: LESS_THAN_THRESHOLD

FreeLocalStorage

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung auf niedrigen freien lokalen Speicher. Aurora PostgreSQL-Compatible Edition verwendet lokalen Speicher zum Speichern von Fehlerprotokollen und temporären Dateien. Aurora MySQL verwendet lokalen Speicher zum Speichern von Fehlerprotokollen, allgemeinen Protokollen, langsamen Abfrageprotokollen, Prüfungsprotokollen und temporären Tabellen, die nicht von InnoDB stammen. Diese lokalen Speicher-Volumes werden von Amazon EBS Store gestützt und können durch Einsatz einer größeren DB-Instance-Klasse erweitert werden. Informationen zur Fehlerbehebung finden Sie unter Aurora PostgreSQL-kompatibel und MySQL-kompatibel.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, wie nahe die Aurora-DB-Instance am Erreichen des lokalen Speicherlimits ist, wenn Sie nicht Aurora Serverless v2 oder höher verwenden. Lokaler Speicher kann seine Kapazität erreichen, wenn Sie nicht persistente Daten, wie temporäre Tabellen- und Protokolldateien, im lokalen Speicher speichern. Dieser Alarm kann einen out-of-space Fehler verhindern, der auftritt, wenn Ihrer DB-Instance der lokale Speicher ausgeht.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Sie sollten etwa 10–20 % der verfügbaren Speichermenge auf der Grundlage der Geschwindigkeit und des Trends der Volumennutzung berechnen und dieses Ergebnis dann als Schwellenwert verwenden, um proaktiv Maßnahmen zu ergreifen, bevor das Volumen sein Limit erreicht.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: LESS_THAN_THRESHOLD

FreeStorageSpace

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm sucht nach einer geringen Menge an verfügbarem Speicherplatz. Erwägen Sie eine Skalierung Ihres Datenbankspeichers, wenn Sie häufig an Speicherkapazitätsgrenzen stoßen. Planen Sie einen gewissen Puffer ein, um unvorhergesehene Nachfragesteigerungen seitens Ihrer Anwendungen bewältigen zu können. Erwägen Sie alternativ, das Auto Scaling des RDS-Speichers zu aktivieren. Erwägen Sie außerdem, mehr Speicherplatz freizugeben, indem Sie ungenutzte oder veraltete Daten und Protokolle löschen. Weitere Informationen finden Sie im Dokument zur RDS-Speicherauslastung und im Dokument zu PostgreSQL-Speicherproblemen.

Absicht: Dieser Alarm trägt dazu bei, Probleme mit vollem Speicherplatz zu vermeiden. Dies kann Ausfallzeiten vermeiden, wenn der DB-Instance der Speicherplatz ausgeht. Wir empfehlen, diesen Alarm nicht zu verwenden, wenn Sie Auto Scaling für Speicher aktiviert haben oder wenn Sie die Speicherkapazität der Datenbank-Instance häufig ändern.

Statistik: Minimum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der Schwellenwert hängt vom aktuell zugewiesenen Speicherplatz ab. In der Regel sollten Sie den Wert von 10 % des zugewiesenen Speicherplatzes berechnen und dieses Ergebnis als Schwellenwert verwenden.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: LESS_THAN_THRESHOLD

MaximumUsedTransactionAusweise

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft dabei, den Transaktions-ID-Wraparound für PostgreSQL zu verhindern. Lesen Sie die Schritte zur Fehlerbehebung in diesem Blog, um das Problem zu untersuchen und zu beheben. In diesem Blog können Sie sich auch näher mit den Konzepten, häufigen Problemen und bewährten Methoden von Autovacuum vertraut machen.

Absicht: Dieser Alarm wird verwendet, um den Transaktions-ID-Wraparound für PostgreSQL zu verhindern.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 1,0E9

Begründung des Schwellenwerts: Wenn Sie diesen Schwellenwert auf 1 Milliarde festlegen, sollten Sie Zeit haben, das Problem zu untersuchen. Der Standardwert für autovacuum_freeze_max_age ist 200 Millionen. Wenn das Alter der ältesten Transaktion 1 Milliarde beträgt, hat autovacuum ein Problem damit, diesen Schwellenwert unter dem Ziel von 200 Millionen Transaktions-IDs zu halten.

Zeitraum: 60

Datenpunkte bis Alarm: 1

Auswertungszeiträume: 1

Vergleichsoperator: GREATER_THAN_THRESHOLD

ReadLatency

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung einer hohen Leselatenz. Wenn die Speicherlatenz hoch ist, liegt das daran, dass die Workload die Ressourcenlimits überschreitet. Sie können die I/O-Auslastung im Verhältnis zur Instance und der zugewiesenen Speicherkonfiguration überprüfen. Informationen finden Sie unter Fehlerbehebung der Latenz von Amazon-EBS-Volumes, die durch einen IOPS-Engpass verursacht wurden. Für Aurora können Sie zu einer Instance-Klasse mit I/O-optimierter Speicherkonfiguration wechseln. Anleitungen finden Sie unter I/O in Aurora planen.

Absicht: Dieser Alarm wird verwendet, um eine hohe Leselatenz zu erkennen. Datenbankfestplatten haben normalerweise eine geringe Lese-/Schreiblatenz, sie können jedoch Probleme haben, die zu Vorgängen mit hoher Latenz führen können.

Statistik: p90

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von Ihrem Anwendungsfall ab. Leselatenzen von mehr als 20 Millisekunden sind wahrscheinlich ein Grund für Untersuchungen. Sie können auch einen höheren Schwellenwert festlegen, wenn Ihre Anwendung eine höhere Latenz für Lesevorgänge haben kann. Überprüfen Sie die Wichtigkeit und die Anforderungen der Leselatenz und analysieren Sie das historische Verhalten dieser Metrik, um sinnvolle Schwellenwerte zu ermitteln.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

ReplicaLag

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft Ihnen, die Anzahl von Sekunden zu Verfolgen, die ein Replikat hinter der primären Instance liegt. Ein PostgreSQL-Lesereplikat meldet eine Replikationsverzögerung von bis zu fünf Minuten, wenn keine Benutzertransaktionen in der Quell-Datenbank-Instance erfolgen. Wenn die ReplicaLag Metrik 0 erreicht, hat das Replikat die primäre DB-Instance erreicht. Wenn die ReplicaLag Metrik -1 zurückgibt, ist die Replikation derzeit nicht aktiv. Anleitungen zu RDS PostgreSQL finden Sie unter Bewährte Methoden für die Replikation. Informationen zur Problembehandlung ReplicaLag und damit verbundenen Fehlern finden Sie unter Problembehandlung. ReplicaLag

Absicht: Dieser Alarm kann die Verzögerung bei der Replikation erkennen, die den Datenverlust widerspiegelt, der bei einem Ausfall der primären Instance auftreten könnte. Wenn das Replikat zu weit hinter der primären Instance zurückbleibt und die primäre Instance ausfällt, fehlen dem Replikat Daten, die sich in der primären Instance befanden.

Statistik: Maximum

Empfohlener Schwellenwert: 60,0

Begründung des Schwellenwerts: In der Regel hängt die akzeptable Verzögerung von der Anwendung ab. Wir empfehlen nicht mehr als 60 Sekunden.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: GREATER_THAN_THRESHOLD

WriteLatency

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung einer hohen Schreiblatenz. Wenn die Speicherlatenz hoch ist, liegt das daran, dass die Workload die Ressourcenlimits überschreitet. Sie können die I/O-Auslastung im Verhältnis zur Instance und der zugewiesenen Speicherkonfiguration überprüfen. Informationen finden Sie unter Fehlerbehebung der Latenz von Amazon-EBS-Volumes, die durch einen IOPS-Engpass verursacht wurden. Für Aurora können Sie zu einer Instance-Klasse mit I/O-optimierter Speicherkonfiguration wechseln. Anleitungen finden Sie unter I/O in Aurora planen.

Absicht: Dieser Alarm wird verwendet, um eine hohe Schreiblatenz zu erkennen. Obwohl Datenbankfestplatten in der Regel eine geringe Lese-/Schreiblatenz aufweisen, kann es bei ihnen zu Problemen kommen, die zu Vorgängen mit hoher Latenz führen. Wenn Sie dies überwachen, können Sie sicherstellen, dass die Festplattenlatenz so gering wie erwartet ist.

Statistik: p90

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von Ihrem Anwendungsfall ab. Schreiblatenzen von mehr als 20 Millisekunden sind wahrscheinlich ein Grund für Untersuchungen. Sie können auch einen höheren Schwellenwert festlegen, wenn Ihre Anwendung eine höhere Latenz für Schreibvorgänge haben kann. Überprüfen Sie die Wichtigkeit und die Anforderungen der Schreiblatenz und analysieren Sie das historische Verhalten dieser Metrik, um sinnvolle Schwellenwerte zu ermitteln.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

DBLoad

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung einer hohen DB-Latenz. Wenn die Anzahl der Prozesse die Anzahl der vCPUs übersteigt, werden die Prozesse in die Warteschlange gestellt. Wenn die Warteschlange länger wird, wird die Leistung beeinträchtigt. Wenn die DB-Last häufig über der maximalen vCPU liegt und der primäre Wartezustand „CPU“ lautet, ist die CPU überlastet. In diesem Fall können Sie CPUUtilization, DBLoadCPU und Aufgaben in der Warteschlange für Performance Insights/Enhanced Monitoring überwachen. Sie sollten Verbindungen zur Instance drosseln, SQL-Abfragen mit hoher CPU-Last anpassen oder eine größere Instance-Klasse in Betracht ziehen. Hohe und konsistente Instances von Wartezuständen deuten darauf hin, dass es möglicherweise Engpässe oder Probleme mit Ressourcenkonflikten gibt, die behoben werden müssen.

Absicht: Dieser Alarm wird verwendet, um eine hohe DB-Auslastung zu erkennen. Eine hohe DB-Auslastung kann zu Leistungsproblemen in der DB-Instance führen. Dieser Alarm gilt nicht für Serverless-DB-Instances.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der maximale vCPU-Wert wird anhand der Anzahl der vCPU (virtuellen CPU)-Cores für Ihre DB-Instance bestimmt. Abhängig von der maximalen vCPU können unterschiedliche Werte für den Schwellenwert angemessen sein. Idealerweise sollte die DB-Auslastung nicht über die vCPU-Linie hinausgehen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

AuroraVolumeBytesLeftTotal

Abmessungen: DB ClusterIdentifier

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung eines niedrigen verbleibenden Gesamtvolumens. Wenn das verbleibende Gesamtvolumen die Größenbeschränkung erreicht, meldet der Cluster einen out-of-space Fehler. Der Aurora-Speicher wird automatisch mit den Daten im Cluster-Volume skaliert und je nach DB-Engine-Version auf bis zu 128 TiB oder 64 TiB erweitert. So können Sie Speicherkosten senken, indem Sie Tabellen und Datenbanken verwerfen, die Sie nicht mehr benötigen. Weitere Informationen finden Sie unter Skalierung des Speichers.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, wie nahe der Aurora-Cluster an der maximalen Volumengröße ist. Dieser Alarm kann einen out-of-space Fehler verhindern, der auftritt, wenn auf Ihrem Cluster nicht mehr genügend Speicherplatz zur Verfügung steht. Dieser Alarm wird nur für Aurora MySQL empfohlen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Sie sollten etwa 10–20 % der tatsächlichen maximalen Größe auf der Grundlage der Geschwindigkeit und des Trends der Volumennutzung berechnen und dieses Ergebnis dann als Schwellenwert verwenden, um proaktiv Maßnahmen zu ergreifen, bevor das Volumen sein Limit erreicht.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: LESS_THAN_THRESHOLD

AuroraBinlogReplicaLag

Dimensionen: DBClusterIdentifier, role=Writer

Beschreibung des Alarms: Dieser Alarm hilft dabei, den Fehlerstatus der Aurora-Writer-Instancereplikation zu überwachen. Weitere Informationen finden Sie unter AWS Regionale Replikation von Aurora MySQL-DB-Clustern. Informationen zur Fehlerbehebung finden Sie unter Probleme mit der Aurora-MySQL-Replikation.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob sich die Writer-Instance in einem Fehlerstatus befindet und die Quelle nicht replizieren kann. Dieser Alarm wird nur für Aurora MySQL empfohlen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: -1,0

Begründung des Schwellenwerts: Wir empfehlen, -1 als Schwellenwert zu verwenden, da Aurora MySQL diesen Wert veröffentlicht, wenn sich das Replikat in einem Fehlerstatus befindet.

Zeitraum: 60

Datenpunkte bis Alarm: 2

Auswertungszeiträume: 2

Vergleichsoperator: LESS_THAN_OR_EQUAL_TO_THRESHOLD

BlockedTransactions

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung einer hohen Anzahl blockierter Transaktionen in einer Aurora-DB-Instance. Blockierte Transaktionen können entweder mit einem Rollback oder einem Commit enden. Hohe Parallelität, ungenutzte Transaktionen oder lang andauernde Transaktionen können zu blockierten Transaktionen führen. Informationen zur Fehlerbehebung finden Sie in der Aurora-MySQL-Dokumentation.

Absicht: Dieser Alarm wird verwendet, um eine hohe Anzahl blockierter Transaktionen in einer Aurora-DB-Instance zu erkennen, um Transaktions-Rollbacks und Leistungseinbußen zu verhindern.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Sie sollten 5 % aller Transaktionen Ihrer Instance anhand der ActiveTransactions-Metrik berechnen und dieses Ergebnis als Schwellenwert verwenden. Sie können auch die Wichtigkeit und die Anforderungen von blockierten Transaktionen überprüfen und das historische Verhalten dieser Metrik analysieren, um sinnvolle Schwellenwerte zu ermitteln.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

BufferCacheHitRatio

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft Ihnen dabei, eine gleichbleibend niedrige Cache-Trefferquote des Aurora-Clusters zu überwachen. Wenn die Trefferrate niedrig ist, zeigt dies an, dass Ihre Abfragen für diese DB-Instance häufig zum Datenträger geleitet werden. Untersuchen Sie zur Fehlerbehebung die Workload, um herauszufinden, welche Abfragen dieses Verhalten verursachen und wenden Sie sich an das Dokument Empfehlungen für DB-Instance-RAM.

Absicht: Dieser Alarm wird verwendet, um eine konstant niedrige Cache-Trefferquote zu erkennen, um einen anhaltenden Leistungsabfall in der Aurora-Instance zu verhindern.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 80,0

Begründung des Schwellenwerts: Sie können den Schwellenwert für die Trefferquote im Puffercache auf 80 % festlegen. Sie können diesen Wert jedoch an Ihr akzeptables Leistungsniveau und Ihre Workload-Merkmale anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 10

Auswertungszeiträume: 10

Vergleichsoperator: LESS_THAN_THRESHOLD

EngineUptime

Abmessungen: DBClusterIdentifier, role=Writer

Beschreibung des Alarms: Dieser Alarm hilft dabei, die geringe Ausfallzeit der Writer-DB-Instance zu überwachen. Die Writer-DB-Instance kann aufgrund eines Neustarts, einer Wartung, eines Upgrades oder eines Failovers ausfallen. Wenn die Betriebszeit wegen eines Failovers im Cluster 0 erreicht, und der Cluster über ein oder mehrere Aurora-Replikate verfügt, dann wird während eines Failover-Ereignisses ein Aurora-Replikat zur primären Writer-Instance hochgestuft. Erwägen Sie, ein oder mehrere Aurora-Replikate in zwei oder mehreren verschiedenen Availability Zones zu erstellen, um die Verfügbarkeit Ihres DB-Clusters zu erhöhen. Weitere Informationen finden Sie unter Faktoren, die die Ausfallzeit von Aurora beeinflussen.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob die Aurora-Writer-DB-Instance ausgefallen ist. Dadurch kann ein lang andauernder Ausfall der Writer-Instance verhindert werden, der aufgrund eines Absturzes oder Failovers auftritt.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Ein Fehlerereignis hat eine kurze Unterbrechung zufolge, während der die Lese- und Schreibvorgänge mit einer Ausnahme fehlschlagen. Jedoch wird der Service im Normalfall in weniger als 60 Sekunden und oft sogar schon nach 30 Sekunden wiederhergestellt.

Zeitraum: 60

Datenpunkte bis Alarm: 2

Auswertungszeiträume: 2

Vergleichsoperator: LESS_THAN_OR_EQUAL_TO_THRESHOLD

RollbackSegmentHistoryListLength

Abmessungen: DB InstanceIdentifier

Beschreibung des Alarms: Dieser Alarm hilft dabei, eine konstant hohe Länge des Rollback-Segmentverlaufs einer Aurora-Instance zu überwachen. Wenn die Länge der InnoDB-Verlaufsliste zu groß wird, was auf eine große Anzahl alter Zeilenversionen hinweist, werden Abfragen und Datenbank-Abschaltungen langsamer. Weitere Informationen und Schritte zur Problembehebung finden Sie in der Dokumentation zur InnoDB-Verlaufsliste, die erheblich erweitert wurde.

Absicht: Dieser Alarm wird verwendet, um eine konstant hohe Länge des Rollback-Segmentverlaufs zu erkennen. Dies kann Ihnen helfen, anhaltende Leistungseinbußen und eine hohe CPU-Auslastung in der Aurora-Instance zu verhindern. Dieser Alarm wird nur für Aurora MySQL empfohlen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 1 000 000,0

Begründung des Schwellenwerts: Wenn Sie diesen Schwellenwert auf 1 Million festlegen, sollten Sie Zeit haben, das Problem zu untersuchen. Sie können diesen Wert jedoch an Ihr akzeptables Leistungsniveau und Ihre Workload-Merkmale anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

StorageNetworkThroughput

Abmessungen: DBClusterIdentifier, role=Writer

Beschreibung des Alarms: Dieser Alarm hilft bei der Überwachung eines hohen Durchsatzes im Speichernetzwerk. Wenn der Durchsatz im Speichernetzwerk die gesamte Netzwerkbandbreite der EC2-Instance übersteigt, kann dies zu einer hohen Lese- und Schreiblatenz führen, was zu Leistungseinbußen führen kann. Sie können Ihren EC2-Instance-Typ von der Konsole aus überprüfen. AWS Überprüfen Sie zur Fehlerbehebung alle Änderungen an den Schreib- und Leselatenzen und prüfen Sie, ob Sie auch bei dieser Metrik einen Alarm ausgelöst haben. Wenn das der Fall ist, überprüfen Sie Ihr Workload-Muster zu den Zeiten, in denen der Alarm ausgelöst wurde. Auf diese Weise können Sie herausfinden, ob Sie Ihre Workload optimieren können, um den gesamten Netzwerk-Datenverkehr zu reduzieren. Wenn dies nicht möglich ist, müssen Sie möglicherweise eine Skalierung Ihrer Instance in Betracht ziehen.

Absicht: Dieser Alarm wird verwendet, um einen hohen Durchsatz im Speichernetzwerk zu erkennen. Durch die Erkennung eines hohen Durchsatzes können Netzwerkpaketverluste und Leistungseinbußen verhindert werden.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Sie sollten etwa 80–90 % der gesamten Netzwerkbandbreite des EC2-Instance-Typs berechnen und dieses Ergebnis dann als Schwellenwert verwenden, um proaktiv Maßnahmen zu ergreifen, bevor die Netzwerkpakete betroffen sind. Sie können auch die Wichtigkeit und die Anforderungen des Speichernetzwerk-Durchsatzes überprüfen und das historische Verhalten dieser Metrik analysieren, um sinnvolle Schwellenwerte zu ermitteln.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

HealthCheckStatus

Abmessungen: HealthCheckId

Alarmbeschreibung: Dieser Alarm hilft dabei, fehlerhafte Endgeräte gemäß den Zustandsprüfern zu erkennen. Um den Grund für einen Fehler zu ermitteln, der zu einem fehlerhaften Status führt, verwenden Sie die Registerkarte Route 53 Health Check Console, um den Status für jede Region sowie den letzten Fehler der Zustandsprüfung anzuzeigen. Auf der Registerkarte Status wird auch der Grund angezeigt, warum der Endpunkt als fehlerhaft gemeldet wurde. Weitere Informationen finden Sie unter Schritte zur Fehlerbehebung.

Absicht: Bei diesem Alarm werden Route53-Zustandsprüfer verwendet, um fehlerhafte Endpunkte zu erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 1,0

Begründung des Schwellenwerts: Der Status des Endpunkts wird als 1 gemeldet, wenn er fehlerfrei ist. Alles, was kleiner als 1 ist, zählt als fehlerhaft.

Zeitraum: 60

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: LESS_THAN_THRESHOLD

4xxErrors

Abmessungen:BucketName, FilterId

Alarmbeschreibung: Dieser Alarm hilft uns dabei, die Gesamtzahl der 4XX-Fehlerstatuscodes zu melden, die als Antwort auf Kundenanfragen ausgegeben wurden. 403-Fehlercodes können auf eine falsche IAM-Richtlinie hinweisen, und 404-Fehlercodes können beispielsweise auf ein fehlerhaftes Verhalten der Client-Anwendung hinweisen. Die vorübergehende Aktivierung der Protokollierung des S3-Serverzugriffs hilft Ihnen, die Ursache des Problems anhand der Felder HTTP-Status und Fehlercode zu ermitteln. Weitere Informationen zum Fehlercode finden Sie unter Fehlerantworten.

Absicht: Dieser Alarm wird verwendet, um eine Baseline für typische 4XX-Fehlerraten zu erstellen, sodass Sie alle Auffälligkeiten untersuchen können, die auf ein Einrichtungsproblem hinweisen könnten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Der empfohlene Schwellenwert besteht darin, zu erkennen, ob bei mehr als 5 % der gesamten Anfragen 4XX-Fehler auftreten. Bei häufig auftretenden 4XX-Fehlern sollte ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist. Sie können den Schwellenwert auch an die Auslastung der Anfragen anpassen und dabei eine akzeptable Anzahl von 4XX-Fehlern berücksichtigen. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu ermitteln, und den Schwellenwert dann entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

5xxErrors

Abmessungen:BucketName, FilterId

Alarmbeschreibung: Dieser Alarm hilft Ihnen, eine große Anzahl von serverseitigen Fehlern zu erkennen. Diese Fehler deuten darauf hin, dass ein Client eine Anfrage gestellt hat, die der Server nicht abschließen konnte. So können Sie das Problem, mit dem Ihre Anwendung aufgrund von S3 konfrontiert ist, besser zuordnen. Weitere Informationen, die Ihnen helfen, Fehler effizient zu behandeln oder zu reduzieren, finden Sie unter Optimieren von Leistungsentwurfsmustern. Die Fehler können auch durch ein Problem mit S3 verursacht werden. Überprüfen Sie den Status von Amazon S3 in Ihrer Region im AWS Service Health Dashboard.

Absicht: Dieser Alarm kann dabei helfen, festzustellen, ob bei der Anwendung Probleme aufgrund von 5XX-Fehlern auftreten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Wir empfehlen, den Schwellenwert so festzulegen, dass erkannt wird, ob mehr als 5 % aller Anfragen 5XXError aufweisen. Sie können den Schwellenwert jedoch an den Datenverkehr der Anfragen sowie an die akzeptablen Fehlerraten anpassen. Sie können auch historische Daten analysieren, um festzustellen, welche Fehlerrate für den Anwendungs-Workload akzeptabel ist, und den Schwellenwert entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

OperationsFailedReplication

Abmessungen:SourceBucket, DestinationBucket, RuleId

Alarmbeschreibung: Dieser Alarm hilft beim Verständnis eines Replikationsfehlers. Diese Metrik verfolgt den Status neuer Objekte, die mit S3 CRR oder S3 SRR repliziert wurden, sowie vorhandener Objekte, die mit der S3-Batchreplikation repliziert wurden. Weitere Informationen finden Sie unter Problembehandlung bei der Replikation.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, ob ein Replikationsvorgang fehlgeschlagen ist.

Statistik: Maximum

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Diese Metrik gibt bei erfolgreichen Vorgängen den Wert 0 aus, und nichts, wenn für die Minute keine Replikationsvorgänge ausgeführt wurden. Wenn die Metrik einen Wert größer als 0 ausgibt, ist der Replikationsvorgang nicht erfolgreich.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

4xxErrors

Abmessungen:AccessPointName, DataSource ARN

Beschreibung des Alarms: Dieser Alarm hilft uns, die Gesamtzahl der 4XX-Fehlerstatuscodes zu melden, die als Antwort auf Kundenanfragen ausgegeben wurden. Die vorübergehende Aktivierung der Protokollierung des S3-Serverzugriffs hilft Ihnen, die Ursache des Problems anhand der Felder HTTP-Status und Fehlercode zu ermitteln.

Absicht: Dieser Alarm wird verwendet, um eine Baseline für typische 4XX-Fehlerraten zu erstellen, sodass Sie alle Auffälligkeiten untersuchen können, die auf ein Einrichtungsproblem hinweisen könnten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Wir empfehlen, den Schwellenwert so festzulegen, dass erkannt wird, ob mehr als 5 % aller Anfragen 4XXError aufweisen. Bei häufig auftretenden 4XX-Fehlern sollte ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist. Sie können den Schwellenwert auch an die Auslastung der Anfragen anpassen und dabei eine akzeptable Anzahl von 4XX-Fehlern berücksichtigen. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu ermitteln, und den Schwellenwert dann entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

5xxErrors

Abmessungen:AccessPointName, DataSource ARN

Alarmbeschreibung: Dieser Alarm hilft dabei, eine große Anzahl von serverseitigen Fehlern zu erkennen. Diese Fehler deuten darauf hin, dass ein Client eine Anfrage gestellt hat, die der Server nicht abschließen konnte. Diese Fehler können durch ein Problem mit S3 verursacht werden. Überprüfen Sie den Status von Amazon S3 in Ihrer Region im AWS Service Health Dashboard. So können Sie das Problem, mit dem Ihre Anwendung aufgrund von S3 konfrontiert ist, besser zuordnen. Informationen, die Ihnen helfen, diese Fehler effizient zu behandeln oder zu reduzieren, finden Sie unter Optimieren von Leistungsentwurfsmustern.

Absicht: Dieser Alarm kann dabei helfen, festzustellen, ob bei der Anwendung Probleme aufgrund von 5XX-Fehlern auftreten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Wir empfehlen, den Schwellenwert so festzulegen, dass erkannt wird, ob mehr als 5 % aller Anfragen 5XXError aufweisen. Sie können den Schwellenwert jedoch an den Datenverkehr der Anfragen sowie an die akzeptablen Fehlerraten anpassen. Sie können auch historische Daten analysieren, um festzustellen, welche Fehlerrate für den Anwendungs-Workload akzeptabel ist, und den Schwellenwert entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

LambdaResponse4x

Abmessungen:AccessPointName, DataSource ARN

Alarmbeschreibung: Dieser Alarm hilft Ihnen, Fehler (500s) bei Aufrufen von S3 Object Lambda zu erkennen und zu diagnostizieren. Diese Fehler können durch Fehler oder Fehlkonfigurationen in der Lambda-Funktion verursacht werden, die für die Beantwortung Ihrer Anfragen verantwortlich ist. Wenn CloudWatch Sie die Log-Streams der Lambda-Funktion untersuchen, die dem Object Lambda Access Point zugeordnet ist, können Sie anhand der Antwort von S3 Object Lambda den Ursprung des Problems ermitteln.

Absicht: Dieser Alarm wird verwendet, um 4xx-Client-Fehler bei Aufrufen zu erkennen. WriteGetObjectResponse

Statistik: Durchschnitt

Empfohlener Schwellenwert: 0,05

Begründung des Schwellenwerts: Wir empfehlen, den Schwellenwert so festzulegen, dass erkannt wird, ob mehr als 5 % aller Anfragen 4XXError aufweisen. Bei häufig auftretenden 4XX-Fehlern sollte ein Alarm ausgelöst werden. Die Einstellung eines sehr niedrigen Schwellenwerts kann jedoch dazu führen, dass der Alarm zu empfindlich ist. Sie können den Schwellenwert auch an die Auslastung der Anfragen anpassen und dabei eine akzeptable Anzahl von 4XX-Fehlern berücksichtigen. Sie können auch historische Daten analysieren, um die akzeptable Fehlerrate für den Anwendungs-Workload zu ermitteln, und den Schwellenwert dann entsprechend anpassen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_THRESHOLD

NumberOfMessagesPublished

Abmessungen: TopicName

Alarmbeschreibung: Dieser Alarm kann erkennen, wenn die Anzahl der veröffentlichten SNS-Nachrichten zu gering ist. Überprüfen Sie zur Fehlerbehebung, warum die Publisher weniger Datenverkehr senden.

Absicht: Dieser Alarm hilft Ihnen dabei, proaktiv zu überwachen und signifikante Rückgänge bei der Veröffentlichung von Benachrichtigungen zu erkennen. Auf diese Weise können Sie potenzielle Probleme mit Ihren Anwendungen oder Geschäftsprozessen identifizieren, sodass Sie geeignete Maßnahmen ergreifen können, um den erwarteten Benachrichtigungsfluss aufrechtzuerhalten. Sie sollten diesen Alarm erstellen, wenn Sie davon ausgehen, dass Ihr System ein Minimum an Datenverkehr bedient.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Die Anzahl der veröffentlichten Nachrichten sollte der erwarteten Anzahl veröffentlichter Nachrichten für Ihre Anwendung entsprechen. Sie können auch die historischen Daten, Trends und den Datenverkehr analysieren, um den richtigen Schwellenwert zu finden.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: LESS_THAN_THRESHOLD

NumberOfNotificationsDelivered

Abmessungen: TopicName

Alarmbeschreibung: Dieser Alarm kann erkennen, wenn die Anzahl der übermittelten SNS-Nachrichten zu gering ist. Dies kann auf die unbeabsichtigte Abmeldung eines Endpunkts oder auf ein SNS-Ereignis zurückzuführen sein, das zu Verzögerungen bei Nachrichten führt.

Absicht: Dieser Alarm hilft Ihnen dabei, einen Rückgang der zugestellten Nachrichtenmenge zu erkennen. Sie sollten diesen Alarm erstellen, wenn Sie davon ausgehen, dass Ihr System ein Minimum an Datenverkehr bedient.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Die Anzahl der zugestellten Nachrichten sollte der erwarteten Anzahl der produzierten Nachrichten und der Anzahl der Verbraucher entsprechen. Sie können auch die historischen Daten, Trends und den Datenverkehr analysieren, um den richtigen Schwellenwert zu finden.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: LESS_THAN_THRESHOLD

NumberOfNotificationsFailed

Abmessungen: TopicName

Alarmbeschreibung: Dieser Alarm kann erkennen, wenn die Anzahl fehlgeschlagener SNS-Nachrichten zu hoch ist. Um Fehler bei Benachrichtigungen zu beheben, aktivieren Sie die Protokollierung in CloudWatch Logs. Wenn Sie die Protokolle überprüfen, können Sie herausfinden, welche Subscriber ausfallen und welche Statuscodes sie zurückgeben.

Absicht: Dieser Alarm hilft Ihnen dabei, proaktiv Probleme bei der Zustellung von Benachrichtigungen zu finden und geeignete Maßnahmen zu ihrer Behebung zu ergreifen.

Statistik: Summe

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von den Auswirkungen fehlgeschlagener Benachrichtigungen ab. Prüfen Sie die für Ihre Endbenutzer bereitgestellten SLAs, die Fehlertoleranz und die Wichtigkeit der Benachrichtigungen, analysieren Sie historische Daten und wählen Sie dann einen entsprechenden Schwellenwert aus. Die Anzahl der fehlgeschlagenen Benachrichtigungen sollte für Themen, die nur SQS-, Lambda- oder Firehose-Abonnements haben, 0 sein.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidAttributes

Abmessungen: TopicName

Alarmbeschreibung: Dieser Alarm hilft dabei, potenzielle Probleme mit dem Publisher oder den Subscribern zu überwachen und zu lösen. Prüfen Sie, ob ein Publisher Nachrichten mit ungültigen Attributen veröffentlicht oder ob ein unangemessener Filter auf einen Subscriber angewendet wird. Sie können auch CloudWatch Protokolle analysieren, um die Ursache des Problems zu finden.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob die veröffentlichten Nachrichten nicht gültig sind oder ob unangemessene Filter auf einen Subscriber angewendet wurden.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Ungültige Attribute sind fast immer ein Fehler des Publishers. Wir empfehlen, den Schwellenwert auf 0 zu setzen, da in einem fehlerfreien System keine ungültigen Attribute zu erwarten sind.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidMessageBody

Abmessungen: TopicName

Alarmbeschreibung: Dieser Alarm hilft dabei, potenzielle Probleme mit dem Publisher oder den Subscribern zu überwachen und zu lösen. Prüfen Sie, ob ein Publisher Nachrichten mit ungültigen Nachrichtentexten veröffentlicht oder ob ein unangemessener Filter auf einen Subscriber angewendet wird. Sie können auch CloudWatch Protokolle analysieren, um die Ursache des Problems zu finden.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob die veröffentlichten Nachrichten nicht gültig sind oder ob unangemessene Filter auf einen Subscriber angewendet wurden.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Ungültige Nachrichtentexte sind fast immer ein Fehler des Publisher. Wir empfehlen, den Schwellenwert auf 0 zu setzen, da in einem fehlerfreien System keine ungültigen Nachrichtentexte zu erwarten sind.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

NumberOfNotificationsRedrivenToDlq

Abmessungen: TopicName

Alarmbeschreibung: Dieser Alarm hilft dabei, die Anzahl der Nachrichten zu überwachen, die in eine Warteschlange für unzustellbare Nachrichten verschoben wurden.

Absicht: Dieser Alarm wird verwendet, um Nachrichten zu erkennen, die in eine Warteschlange für unzustellbare Nachrichten verschoben wurden. Wir empfehlen, diesen Alarm auszulösen, wenn SNS mit SQS, Lambda oder Firehose gekoppelt ist.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: In einem fehlerfreien System, egal welchen Subscribertyps, sollten Nachrichten nicht in die Warteschlange für unzustellbare Nachrichten verschoben werden. Wir empfehlen, dass Sie benachrichtigt werden, wenn Nachrichten in der Warteschlange landen, damit Sie die Ursache identifizieren und beheben und die Nachrichten in der Warteschlange für unzustellbare Nachrichten möglicherweise erneut versenden können, um Datenverlust zu verhindern.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

NumberOfNotificationsFailedToRedriveToDlq

Abmessungen: TopicName

Alarmbeschreibung: Dieser Alarm hilft bei der Überwachung von Nachrichten, die nicht in eine Warteschlange für unzustellbare Nachrichten verschoben werden konnten. Prüfen Sie, ob Ihre Warteschlange für unzustellbare Nachrichten existiert und ob sie richtig konfiguriert ist. Stellen Sie außerdem sicher, dass SNS über Berechtigungen für den Zugriff auf die Warteschlange für unzustellbare Nachrichten verfügt. Weitere Informationen finden Sie in der Dokumentation zur Warteschlange für unzustellbare Nachrichten.

Absicht: Dieser Alarm wird verwendet, um Nachrichten zu erkennen, die nicht in eine Warteschlange für unzustellbare Nachrichten verschoben werden konnten.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Es ist fast immer ein Fehler, wenn Nachrichten nicht in die Warteschlange für unzustellbare Nachrichten verschoben werden können. Die Empfehlung für den Schwellenwert ist 0, was bedeutet, dass alle Nachrichten, deren Verarbeitung fehlschlägt, in der Lage sein müssen, die Warteschlange für unzustellbare Nachrichten zu erreichen, wenn die Warteschlange konfiguriert wurde.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

SMS MonthToDateSpent USD

Abmessungen: TopicName

Alarmbeschreibung: Mithilfe des Alarms können Sie überwachen, ob Ihr Konto über ein ausreichendes Kontingent verfügt, damit SNS Nachrichten zustellen kann. Wenn Sie Ihr Kontingent erreichen, kann SNS keine SMS-Nachrichten zustellen. Informationen zum Einrichten Ihres monatlichen SMS-Ausgabenkontingents oder zur Beantragung einer Erhöhung des Ausgabenkontingents mit AWS finden Sie unter Einstellungen für SMS-Nachrichten festlegen.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob Ihr Konto über ein ausreichendes Kontingent verfügt, damit Ihre SMS-Nachrichten erfolgreich zugestellt werden können.

Statistik: Maximum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Legen Sie den Schwellenwert entsprechend dem Kontingent (Ausgabenlimit des Kontos) für das Konto fest. Wählen Sie einen Schwellenwert, der Sie früh genug darüber informiert, dass Sie Ihr Kontingentlimit erreicht haben, sodass Sie Zeit haben, eine Erhöhung zu beantragen.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

SMS SuccessRate

Abmessungen: TopicName

Alarmbeschreibung: Dieser Alarm hilft dabei, die Rate fehlgeschlagener SMS-Nachrichtenzustellungen zu überwachen. Sie können Cloudwatch Logs einrichten, um die Art des Fehlers zu verstehen und auf dieser Grundlage Maßnahmen zu ergreifen.

Absicht: Dieser Alarm wird verwendet, um fehlgeschlagene SMS-Nachrichtenzustellungen zu erkennen.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Stellen Sie den Schwellenwert für den Alarm entsprechend Ihrer Toleranz für fehlgeschlagene SMS-Nachrichtenzustellungen ein.

Zeitraum: 60

Datenpunkte bis Alarm: 5

Auswertungszeiträume: 5

Vergleichsoperator: GREATER_THAN_THRESHOLD

ApproximateAgeOfOldestMessage

Abmessungen: QueueName

Alarmbeschreibung: Dieser Alarm überwacht das Alter der ältesten Nachricht in der Warteschlange. Sie können diesen Alarm verwenden, um zu überwachen, ob Ihre Verbraucher SQS-Nachrichten mit der gewünschten Geschwindigkeit verarbeiten. Erwägen Sie, die Anzahl der Verbraucher oder den Durchsatz der Verbraucher zu erhöhen, um das Alter der Nachrichten zu verringern. Diese Metrik kann in Kombination mit ApproximateNumberOfMessagesVisible verwendet werden, um zu bestimmen, wie groß der Warteschlangenrückstand ist und wie schnell Nachrichten verarbeitet werden. Um zu verhindern, dass Nachrichten vor der Verarbeitung gelöscht werden, sollten Sie in Erwägung ziehen, die Warteschlange für unzustellbare Nachrichten so zu konfigurieren, dass potenzielle Poison-Pill-Nachrichten außer Acht gelassen werden.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, ob das Alter der ältesten Nachricht in der QueueName Warteschlange zu hoch ist. Ein hohes Alter kann ein Hinweis darauf sein, dass Nachrichten nicht schnell genug verarbeitet werden oder dass einige Poison-Pill-Nachrichten in der Warteschlange stecken bleiben und nicht verarbeitet werden können.

Statistik: Maximum

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von der erwarteten Nachrichtenverarbeitungszeit ab. Sie können historische Daten verwenden, um die durchschnittliche Nachrichtenverarbeitungszeit zu berechnen, und dann den Schwellenwert auf einen Wert festlegen, der 50 % über der von den Warteschlangenverbrauchern erwarteten maximalen Verarbeitungszeit für SQS-Nachrichten liegt.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesNotVisible

Abmessungen: QueueName

Alarmbeschreibung: Dieser Alarm hilft bei der Erkennung einer hohen Anzahl von Nachrichten während der Übertragung in Bezug auf QueueName. Zur Fehlerbehebung prüfen Sie Nachrichtenrückstand nimmt ab.

Absicht: Dieser Alarm wird verwendet, um eine hohe Anzahl von Nachrichten während der Übertragung in der Warteschlange zu erkennen. Wenn Verbraucher Nachrichten nicht innerhalb des Sichtbarkeitszeitlimits löschen, werden die Nachrichten beim Abrufen der Warteschlange wieder in der Warteschlange angezeigt. Bei FIFO-Warteschlangen können maximal 20 000 Nachrichten während der Übertragung gespeichert werden. Wenn Sie dieses Kontingent erreichen, gibt SQS keine Fehlermeldungen zurück. Eine FIFO-Warteschlange durchsucht die ersten 20 000 Nachrichten, um die verfügbaren Nachrichtengruppen zu ermitteln. Das heißt, wenn Sie in einer einzelnen Nachrichtengruppe einen Rückstand an Nachrichten haben, können Sie Nachrichten aus anderen Nachrichtengruppen, die zu einem späteren Zeitpunkt an die Warteschlange gesendet wurden, erst verarbeiten, wenn Sie die Nachrichten aus dem Rückstand erfolgreich verarbeitet haben.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Der empfohlene Schwellenwert für diesen Alarm hängt stark von der zu erwartenden Anzahl an Nachrichten während der Übertragung ab. Sie können historische Daten verwenden, um die maximal zu erwartende Anzahl von Nachrichten während der Übertragung zu berechnen und den Schwellenwert auf 50 % über diesem Wert festzulegen. Wenn Verbraucher der Warteschlange Nachrichten verarbeiten, aber nicht aus der Warteschlange löschen, steigt diese Zahl plötzlich an.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesVisible

Abmessungen: QueueName

Alarmbeschreibung: Dieser Alarm überwacht, ob der Rückstand in der Nachrichtenwarteschlange größer als erwartet ist, was darauf hindeutet, dass die Verbraucher zu langsam sind oder nicht genügend Verbraucher vorhanden sind. Ziehen Sie in Erwägung, die Anzahl der Verbraucher zu erhöhen oder die Verbraucher zu beschleunigen, wenn dieser Alarm in den Zustand ALARM übergeht.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, ob die Anzahl der Nachrichten in der aktiven Warteschlange zu hoch ist und die Verbraucher die Nachrichten nur langsam verarbeiten, oder ob nicht genügend Verbraucher vorhanden sind, um sie zu verarbeiten.

Statistik: Durchschnitt

Empfohlener Schwellenwert: Hängt von Ihrer Situation ab

Begründung des Schwellenwerts: Eine unerwartet hohe Anzahl sichtbarer Nachrichten weist darauf hin, dass Nachrichten von einem Verbraucher nicht mit der erwarteten Geschwindigkeit verarbeitet werden. Bei der Festlegung dieses Schwellenwerts sollten Sie historische Daten berücksichtigen.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

NumberOfMessagesSent

Abmessungen: QueueName

Alarmbeschreibung: Dieser Alarm hilft zu erkennen, ob von einem Produzenten keine Nachrichten in Bezug auf QueueName gesendet wurden. Überprüfen Sie zur Fehlerbehebung den Grund, warum der Produzent keine Nachrichten sendet.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, wenn ein Produzent keine Nachrichten mehr sendet.

Statistik: Summe

Empfohlener Schwellenwert: 0,0

Begründung des Schwellenwerts: Wenn die Anzahl der gesendeten Nachrichten 0 ist, sendet der Produzent keine Nachrichten. Wenn diese Warteschlange einen niedrigen TPS-Wert hat, erhöhen Sie die Anzahl der EvaluationPeriods entsprechend.

Zeitraum: 60

Datenpunkte bis Alarm: 15

Auswertungszeiträume: 15

Vergleichsoperator: LESS_THAN_OR_EQUAL_TO_THRESHOLD

TunnelState

Abmessungen: VpnId

Alarmbeschreibung: Dieser Alarm hilft Ihnen zu verstehen, ob der Status eines oder mehrerer Tunnel INAKTIV ist. Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei VPN-Tunneln.

Absicht: Dieser Alarm wird verwendet, um festzustellen, ob sich mindestens ein Tunnel für dieses VPN im Status INAKTIV befindet, sodass Sie eine Fehlerbehebung für das betroffene VPN durchführen können. Dieser Alarm befindet sich bei Netzwerken, in denen nur ein einziger Tunnel konfiguriert ist, immer im ALARM-Status.

Statistik: Minimum

Empfohlener Schwellenwert: 1,0

Begründung des Schwellenwerts: Ein Wert unter 1 gibt an, dass sich mindestens ein Tunnel im Status INAKTIV befindet.

Zeitraum: 300

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: LESS_THAN_THRESHOLD

TunnelState

Abmessungen: TunnelIpAddress

Alarmbeschreibung: Dieser Alarm hilft Ihnen zu verstehen, ob der Status dieses Tunnels INAKTIV ist. Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei VPN-Tunneln.

Absicht: Dieser Alarm wird verwendet, um zu erkennen, ob sich der Tunnel im Zustand INAKTIV befindet, so dass Sie das betroffene VPN auf Fehler untersuchen können. Dieser Alarm befindet sich bei Netzwerken, in denen nur ein einziger Tunnel konfiguriert ist, immer im ALARM-Status.

Statistik: Minimum

Empfohlener Schwellenwert: 1,0

Begründung des Schwellenwerts: Ein Wert unter 1 gibt an, dass sich der Tunnel im Status INAKTIV befindet.

Zeitraum: 300

Datenpunkte bis Alarm: 3

Auswertungszeiträume: 3

Vergleichsoperator: LESS_THAN_THRESHOLD

Themen

Amazon API Gateway

Amazon EC2 Auto Scaling

Amazon CloudFront

Amazon Cognito

Amazon DynamoDB

Amazon EBS

Amazon EC2

Amazon ElastiCache

Amazon EC2 (`AWS/ElasticGPUs`)

Amazon ECS

Amazon ECS mit Container Insights

Amazon EFS

Amazon EKS mit Container Insights

Amazon Kinesis Data Streams

Lambda

Lambda Insights

Amazon VPC (`AWS/NATGateway`)

AWS Privater Link (`AWS/PrivateLinkEndpoints`)

AWS Privater Link (`AWS/PrivateLinkServices`)

`Amazon RDS`

`Amazon Route 53 Public Data Plane`

`Amazon S3`

`S3ObjectLambda`

Amazon SNS

Amazon SQS

AWS VPN

Empfohlene Alarme

Themen

Amazon API Gateway

Amazon EC2 Auto Scaling

Amazon CloudFront

Amazon Cognito

Amazon DynamoDB

Amazon EBS

Amazon EC2

Amazon ElastiCache

Amazon EC2 (AWS/ElasticGPUs)

Amazon ECS

Amazon ECS mit Container Insights

Amazon EFS

Amazon EKS mit Container Insights

Amazon Kinesis Data Streams

Lambda

Lambda Insights

Amazon VPC (AWS/NATGateway)

AWS Privater Link (AWS/PrivateLinkEndpoints)

AWS Privater Link (AWS/PrivateLinkServices)

Amazon RDS

Amazon Route 53 Public Data Plane

Amazon S3

S3ObjectLambda

Amazon SNS

Amazon SQS

AWS VPN

Amazon EC2 (`AWS/ElasticGPUs`)

Amazon VPC (`AWS/NATGateway`)

AWS Privater Link (`AWS/PrivateLinkEndpoints`)

AWS Privater Link (`AWS/PrivateLinkServices`)

`Amazon RDS`

`Amazon Route 53 Public Data Plane`

`Amazon S3`

`S3ObjectLambda`