Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Definieren und konfigurieren Sie Alarme in Incident Detection and Response
AWS arbeitet mit Ihnen zusammen, um Metriken und Alarme zu definieren, um einen Überblick über die Leistung Ihrer Anwendungen und der zugrunde liegenden AWS Infrastruktur zu erhalten. Wir bitten darum, dass Alarme bei der Definition und Konfiguration von Schwellenwerten die folgenden Kriterien erfüllen:
+ Alarme gehen nur dann in den Status „Alarm“ über, wenn es kritische Auswirkungen auf die überwachte Arbeitslast gibt (Umsatzverlust oder vermindertes Kundenerlebnis, wodurch die Leistung erheblich beeinträchtigt wird), die sofortige Aufmerksamkeit des Bedieners erfordern.
+ Bei Alarmen müssen außerdem die von Ihnen angegebenen Resolver für die Arbeitslast aktiviert werden, und zwar gleichzeitig oder zuvor, indem das Incident-Management-Team eingeschaltet wird. Die Techniker für das Incident-Management sollten bei der Schadensbegrenzung mit den von Ihnen angegebenen Lösungskräften zusammenarbeiten und nicht als Ersthelfer fungieren und dann an Sie weiterleiten.
+ Die Alarmschwellenwerte müssen auf einen angemessenen Schwellenwert und eine angemessene Dauer festgelegt werden, sodass bei jedem Auslösen eines Alarms eine Untersuchung durchgeführt werden muss. Wenn ein Alarm zwischen „Alarm“ und „OK“ wechselt, ist die Wirkung so groß, dass die Reaktion und Aufmerksamkeit des Bedieners gewährleistet ist.
**Arten von Alarmen**:
+ Alarme, die das Ausmaß der Auswirkungen auf das Unternehmen aufzeigen und relevante Informationen zur einfachen Fehlererkennung weitergeben.
+ CloudWatch Amazonas-Kanaren. [Weitere Informationen finden Sie unter [Canaries and X-Ray Tracing und X-Ray](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html).](https://aws.amazon.com/xray/)
+ Generelle Alarmierung (Überwachung von Abhängigkeiten)
Die folgende Tabelle enthält Beispielalarme, die alle das CloudWatch Überwachungssystem verwenden.
****
| Name der Metrik//Alarmschwellenwert | Alarm-ARN oder Ressourcen-ID | Wenn dieser Alarm ausgelöst wird | Wenn Sie in Anspruch genommen werden, stellen Sie einen Premium-Supportfall für diese Services |
| --- | --- | --- | --- |
| API-Fehler/ Anzahl der Fehler >= 10 für 10 Datenpunkte | arn:aws:cloudwatch:us-west- 2:000000000000:alarm:e2 Lambda-Fehler MPmim | Das Ticket wurde an das Datenbankadministrator-Team (DBA) weitergeleitet | Lambda, API Gateway |
| ServiceUnavailable (HTTP-Statuscode 503) Anzahl der Fehler >=3 für 10 Datenpunkte (verschiedene Clients) in einem 5-Minuten-Fenster | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode503 | Das Ticket wurde an das Serviceteam weitergeleitet | Lambda, API Gateway |
| ThrottlingException (HTTP-Statuscode 400) Anzahl der Fehler >=3 für 10 Datenpunkte (verschiedene Clients) in einem 5-Minuten-Fenster | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode400 | Das Ticket wurde an das Serviceteam weitergeleitet | EC2, Amazon Aurora |
Weitere Details finden Sie unter [Überwachung und Beobachtbarkeit von AWS-Incident Detection and Response](observe-idr.md).
Wenn Sie lieber Automatisierungstools für das Onboarding von Alarmen verwenden möchten, hilft Ihnen das Incident Detection and Response Command Line Interface (CLI) bei der Bereitstellung und Einbindung Ihrer Alarme. Weitere Details finden Sie unter [AWS-CLI zur Erkennung und Reaktion auf Vorfälle](idr-cli.md).
**Die wichtigsten Ergebnisse:**
+ Definition und Konfiguration von Alarmen für Ihre Workloads.
+ Ausfüllen der Alarmdetails im Onboarding-Fragebogen.
**Topics**
+ [CloudWatch Alarme erstellen](idr-alarms-fit-purpose.md)
+ [Erstellen Sie CloudWatch Alarme mit CloudFormation Vorlagen](idr-create-alarms-with-cfn.md)
+ [Beispielhafte Anwendungsfälle für CloudWatch Alarme](idr-ex-alarm-use-cases.md)
# Erstellen Sie in Incident Detection and Response CloudWatch Alarme, die Ihren Geschäftsanforderungen entsprechen
Wenn Sie CloudWatch Amazon-Alarme erstellen, können Sie mehrere Schritte unternehmen, um sicherzustellen, dass Ihre Alarme Ihren Geschäftsanforderungen am besten entsprechen.
**Anmerkung**
Beispiele für empfohlene CloudWatch Alarme AWS-Services zur Integration von Incident Detection and Response finden Sie unter [Bewährte Methoden zur Erkennung und Reaktion auf Alarme bei Vorfällen](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr) unter AWS re:Post.
## Prüfen Sie Ihre vorgeschlagenen CloudWatch Alarme
Prüfen Sie Ihre vorgeschlagenen Alarme, um sicherzustellen, dass sie nur dann in den Status „Alarm“ übergehen, wenn es kritische Auswirkungen auf die überwachte Arbeitslast gibt (Umsatzverlust oder vermindertes Kundenerlebnis, wodurch die Leistung erheblich beeinträchtigt wird). Halten Sie diesen Alarm beispielsweise für so wichtig, dass Sie sofort reagieren müssen, wenn er in den Status „Alarm“ übergeht?
Im Folgenden werden Metriken vorgeschlagen, die wichtige Auswirkungen auf Ihr Unternehmen haben könnten, z. B. die Auswirkungen auf die Erfahrung Ihrer Endbenutzer mit einer Anwendung:
+ **CloudFront:** Weitere Informationen finden Sie unter [Metriken zur Anzeige CloudFront und Edge-Funktion](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html).
+ **Application Load Balancers:** Es hat sich bewährt, wenn möglich die folgenden Alarme für Application Load Balancers zu erstellen:
+ HTTPCode\$1ELB\$15xx\$1Count
+ HTTPCode\$1Ziel\$15xx\$1Anzahl
Die oben genannten Alarme ermöglichen es Ihnen, Antworten von Zielen zu überwachen, die sich hinter dem Application Load Balancer oder hinter anderen Ressourcen befinden. Dadurch ist es einfacher, die Ursache von 5XX-Fehlern zu identifizieren. Weitere Informationen finden Sie unter [CloudWatch Metriken für Ihren Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
+ **Amazon API Gateway:** Wenn Sie WebSocket API in Elastic Beanstalk verwenden, sollten Sie die Verwendung der folgenden Metriken in Betracht ziehen:
+ Fehlerraten bei der Integration (gefiltert auf 5XX Fehler)
+ Latenz bei der Integration
+ Ausführungsfehler
Weitere Informationen finden Sie unter [Überwachen der WebSocket API-Ausführung mit CloudWatch Metriken](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html).
+ **Amazon Route 53:** Überwachen Sie die **EndPointUnhealthyENICount**Metrik. Diese Metrik gibt die Anzahl der Elastic Network-Schnittstellen mit dem Status **Automatische Wiederherstellung** an. Dieser Status weist auf Versuche des Resolvers hin, eine oder mehrere der Amazon Virtual Private Cloud Cloud-Netzwerkschnittstellen wiederherzustellen, die dem Endpunkt zugeordnet sind (angegeben durch **EndpointId**). Während des Wiederherstellungsprozesses funktioniert der Endpunkt mit begrenzter Kapazität. Der Endpunkt kann DNS-Abfragen erst verarbeiten, wenn er vollständig wiederhergestellt ist. Weitere Informationen finden Sie unter [Überwachen von Amazon Route 53 Resolver-Endpunkten mit](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html) Amazon. CloudWatch
## Überprüfen Sie Ihre Alarmkonfigurationen
Nachdem Sie sich vergewissert haben, dass Ihre vorgeschlagenen Alarme Ihren Geschäftsanforderungen entsprechen, überprüfen Sie die Konfiguration und den Verlauf der Alarme:
+ Überprüfen Sie den **Schwellenwert** für die Metrik, um in den Status „Alarm“ überzugehen, anhand des Trenddiagramms der Metrik.
+ Überprüfen Sie den **Zeitraum**, der für die Abfrage von Datenpunkten verwendet wurde. Das Abfragen von Datenpunkten nach 60 Sekunden hilft bei der Früherkennung von Vorfällen.
+ Überprüfen Sie die **DatapointToAlarm**Konfiguration. In den meisten Fällen hat es sich bewährt, diesen Wert auf 3 von 3 oder 5 von 5 zu setzen. Bei einem Vorfall wird der Alarm nach 3 Minuten ausgelöst, wenn er auf [60-Sekunden-Metriken mit 3 von 3 DatapointToAlarm] eingestellt ist, oder nach 5 Minuten, wenn er auf [60-Sekunden-Metriken mit 5 von 5 DatapointToAlarm] eingestellt ist. Verwenden Sie diese Kombination, um laute Alarme zu vermeiden.
**Anmerkung**
Die oben genannten Empfehlungen können je nachdem, wie Sie einen Dienst nutzen, variieren. Jeder AWS Dienst arbeitet innerhalb einer Arbeitslast unterschiedlich. Und derselbe Dienst kann unterschiedlich funktionieren, wenn er an mehreren Orten verwendet wird. Sie müssen sicher sein, dass Sie verstehen, wie Ihr Workload die Ressourcen nutzt, die den Alarm auslösen, sowie die vor- und nachgelagerten Auswirkungen.
## Überprüfen Sie, wie Ihre Alarme mit fehlenden Daten umgehen
Einige Metrikquellen senden Daten nicht CloudWatch in regelmäßigen Abständen an. Bei diesen Metriken hat es sich bewährt, fehlende Daten als „**NotBreaching**“ zu behandeln. Weitere Informationen finden Sie unter [Konfiguration der Behandlung fehlender Daten durch CloudWatch Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) und [Vermeidung vorzeitiger Übergänge in den Alarmzustand](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition).
Wenn eine Metrik beispielsweise eine Fehlerrate überwacht und es keine Fehler gibt, dann meldet die Metrik keine Datenpunkte (Null). Wenn Sie den Alarm so konfigurieren, dass er fehlende Daten als **Fehlend** behandelt, führt ein einziger Datenpunkt, bei dem eine Verletzung vorliegt, gefolgt von zwei Datenpunkten ohne Daten (Null) dazu, dass die Metrik in den Status „Alarm“ wechselt (für 3 von 3 Datenpunkten). Das liegt daran, dass die Konfiguration für fehlende Daten den letzten bekannten Datenpunkt im Bewertungszeitraum auswertet.
In Fällen, in denen Metriken die Fehlerrate messen, können Sie ohne Leistungseinbußen davon ausgehen, dass das Fehlen von Daten eine gute Sache ist. Es hat sich bewährt, fehlende Daten als **NotBreaching** zu behandeln, sodass fehlende Daten als „OK“ behandelt werden und die Metrik nicht bei einem einzelnen Datenpunkt in den Status „Alarm“ übergeht.
## Überprüfen Sie den Verlauf jedes Alarms
Wenn aus der Historie eines Alarms hervorgeht, dass er häufig in den Status „Alarm“ wechselt und sich dann schnell wieder erholt, kann der Alarm zu einem Problem für Sie werden. Stellen Sie sicher, dass Sie den Alarm so einstellen, dass Geräusche oder Fehlalarme vermieden werden.
## Überprüfen Sie die Metriken für die zugrunde liegenden Ressourcen
Stellen Sie sicher, dass Ihre Metriken gültige zugrunde liegende Ressourcen berücksichtigen und die richtigen Statistiken verwenden. Wenn ein Alarm so konfiguriert ist, dass er ungültige Ressourcennamen überprüft, kann der Alarm die zugrunde liegenden Daten möglicherweise nicht verfolgen. Dies kann dazu führen, dass der Alarm in den Status „Alarm“ übergeht.
## Erstellen Sie zusammengesetzte Alarme
Wenn Sie den Abteilungen Incident Detection and Response eine große Anzahl von Alarmen für das Onboarding zur Verfügung stellen, werden Sie möglicherweise aufgefordert, zusammengesetzte Alarme zu erstellen. Kombinierte Alarme reduzieren die Gesamtzahl der Alarme, die integriert werden müssen.
# Erstellen Sie CloudWatch Alarme in Incident Detection and Response mithilfe von Vorlagen CloudFormation
Um die Einführung in AWS Incident Detection and Response zu beschleunigen und den Aufwand für die Erstellung von Alarmen zu reduzieren, AWS bietet Ihnen diese CloudFormation Vorlage Vorlagen. Diese Vorlagen enthalten optimierte Alarmeinstellungen für häufig integrierte Dienste wie Application Load Balancer, Network Load Balancer und Amazon. CloudFront
**Erstellen Sie Alarme mit Vorlagen CloudWatch CloudFormation**
1. Laden Sie über die bereitgestellten Links eine Vorlage herunter:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/IDR/latest/userguide/idr-create-alarms-with-cfn.html)
1. Überprüfen Sie die heruntergeladene JSON-Datei, um sicherzustellen, dass sie den Betriebs- und Sicherheitsprozessen Ihres Unternehmens entspricht.
1. Erstellen Sie einen CloudFormation Stack:
**Anmerkung**
Die folgenden Schritte verwenden den Standardprozess zur Erstellung von CloudFormation Stacks. Ausführliche Schritte finden Sie unter [Einen Stack auf der CloudFormation Konsole](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) erstellen.
1. Öffnen Sie die AWS CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie **Stack erstellen** aus.
1. Wählen Sie „**Vorlage ist bereit**“ und laden Sie dann die Vorlagendatei aus Ihrem lokalen Ordner hoch.
Im Folgenden finden Sie ein Beispiel für den Bildschirm „**Stapel erstellen**“.
![\[Beispiel für eine Stack-Upload-Vorlagendatei erstellen\]](http://docs.aws.amazon.com/de_de/IDR/latest/userguide/images/create-cfn-stack1.png)
1. Wählen Sie **Weiter** aus.
1. Geben Sie die folgenden erforderlichen Informationen ein:
+ **AlarmNameConfig**und **AlarmDescriptionConfig**: Geben Sie einen Namen und eine Beschreibung für Ihren Alarm ein.
+ **ThresholdConfig**: Passen Sie den Schwellenwert an die Anforderungen Ihrer Anwendung an.
+ **Verteilung IDConfig**: Stellen Sie sicher, dass die Verteilungs-ID auf die richtigen Ressourcen in dem Konto verweist, in dem Sie den CloudFormation Stack erstellen.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Standardwerte in den **DatapointsToAlarmConfig**Feldern **PeriodConfig**EvalutionPeriodConfig****, und. Es hat sich bewährt, die Standardwerte für diese Felder zu verwenden. Sie können bei Bedarf Anpassungen vornehmen, um die Anforderungen Ihrer Anwendung zu erfüllen.
1. Geben Sie optional nach Bedarf Tags und SNS-Benachrichtigungsinformationen ein. Es hat sich bewährt, den **Kündigungsschutz** zu aktivieren, um ein versehentliches Löschen des Alarms zu verhindern. Um den Kündigungsschutz zu aktivieren, wählen Sie das Optionsfeld **Aktiviert** aus, wie im folgenden Beispiel gezeigt:
![\[Beispiel für Stack erstellen, Kündigungsschutz aktivieren\]](http://docs.aws.amazon.com/de_de/IDR/latest/userguide/images/create-cfn-stack2.png)
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie Ihre Stack-Einstellungen und wählen Sie dann **Stack erstellen** aus.
1. Nachdem Sie den Stack erstellt haben, wird der Alarm in der CloudWatch **Amazon-Alarm-Liste** aufgeführt, wie im folgenden Beispiel gezeigt:
![\[Beispiel für eine CloudWatch Alarmliste\]](http://docs.aws.amazon.com/de_de/IDR/latest/userguide/images/create-cfn-stack3.png)
1. Nachdem Sie alle Ihre Alarme im richtigen Konto und in der richtigen AWS Region erstellt haben, benachrichtigen Sie Ihren Technical Account Manager (TAM). Das AWS-Incident Detection and Response-Team überprüft den Status Ihrer neuen Alarme und setzt dann Ihr Onboarding fort.
# Beispiele für Anwendungsfälle für CloudWatch Alarme in Incident Detection and Response
Die folgenden Anwendungsfälle bieten Beispiele dafür, wie Sie CloudWatch Amazon-Alarme in Incident Detection and Response verwenden können. Diese Beispiele zeigen, wie CloudWatch Alarme so konfiguriert werden können, dass sie wichtige Kennzahlen und Schwellenwerte für verschiedene AWS Dienste überwachen, sodass Sie potenzielle Probleme identifizieren und darauf reagieren können, die sich auf die Verfügbarkeit und Leistung Ihrer Anwendungen und Workloads auswirken könnten.
## Beispiel für Anwendungsfall A: Application Load Balancer
Sie können den folgenden CloudWatch Alarm erstellen, der auf mögliche Auswirkungen auf die Arbeitslast hinweist. Zu diesem Zweck erstellen Sie eine metrische Mathematik, die einen Alarm ausgibt, wenn erfolgreiche Verbindungen einen bestimmten Schwellenwert unterschreiten. Die verfügbaren CloudWatch Metriken finden Sie unter [CloudWatch Metriken für Ihren Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
**Metrik:** `HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`
**NameSpace: AWS/Anwendung ApplicationELB**
**ComparisonOperator(Schwellenwert):** Weniger als x (x = Schwellenwert des Kunden).
**Zeitraum:** 60 Sekunden
**DatapointsToAlarm:** 3 von 3
Behandlung **fehlender Daten: Behandeln** Sie fehlende Daten als [Sicherheitsverletzung.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)
**Statistik:** Summe
Das folgende Diagramm zeigt den Ablauf für Anwendungsfall A:
![\[Beispiel für einen Anwendungsfall für Application Load Balancer\]](http://docs.aws.amazon.com/de_de/IDR/latest/userguide/images/UseCaseAALB.png)
## Beispiel für einen Anwendungsfall B: Amazon API Gateway
Sie können den folgenden CloudWatch Alarm erstellen, der auf mögliche Auswirkungen auf die Arbeitslast hinweist. Zu diesem Zweck erstellen Sie eine zusammengesetzte Metrik, die bei hoher Latenz oder einer hohen durchschnittlichen Anzahl von 4XX-Fehlern im API Gateway alarmiert. Die verfügbaren Metriken finden Sie unter [Amazon API Gateway Gateway-Dimensionen und -Metriken](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)
**Metrik:** `compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`
**NameSpace:** AWS/API-Gateway
**ComparisonOperator(Schwellenwert):** Größer als (x- oder y-Schwellenwerte des Kunden)
**Zeitraum:** 60 Sekunden
**DatapointsToAlarm:** 1 von 1
Behandlung **fehlender Daten: Behandeln** Sie fehlende Daten so, als ob es sich [nicht um Datenschutzverletzungen handelt.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)
**Statistik:**
Das folgende Diagramm zeigt den Ablauf für Anwendungsfall B:
![\[Beispiel für einen Anwendungsfall für API Gateway\]](http://docs.aws.amazon.com/de_de/IDR/latest/userguide/images/UseCaseBAPIGW.png)
## Beispiel für Anwendungsfall C: Amazon Route 53
Sie können Ihre Ressourcen überwachen, indem Sie Route 53-Zustandsprüfungen erstellen, bei denen Rohdaten gesammelt und CloudWatch zu lesbaren Metriken verarbeitet werden, die nahezu in Echtzeit verfügbar sind. Sie können den folgenden CloudWatch Alarm erstellen, der auf mögliche Auswirkungen auf die Arbeitslast hinweist. Sie können die CloudWatch Metriken verwenden, um einen Alarm zu erstellen, der ausgelöst wird, wenn der festgelegte Schwellenwert überschritten wird. Die verfügbaren CloudWatch Metriken finden Sie unter [CloudWatch Metriken für Route 53-Zustandsprüfungen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)
**Metrik:** `R53-HC-Success`
**NameSpace:** AWS/Route 53
**Schwellenwert HealthCheckStatus:** HealthCheckStatus < x für 3 Datenpunkte innerhalb von 3 Minuten (entspricht dem Schwellenwert von x beim Kunden)
**Zeitraum: 1 Minute**
**DatapointsToAlarm:** 3 von 3
Behandlung **fehlender Daten: Behandeln** Sie fehlende Daten als [Sicherheitsverletzung.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)
**Statistik:** Minimum
Das folgende Diagramm zeigt den Ablauf für Anwendungsfall C:
![\[Beispiel für einen Anwendungsfall für Route 53\]](http://docs.aws.amazon.com/de_de/IDR/latest/userguide/images/UseCaseCR53.png)
## Beispiel für einen Anwendungsfall D: Überwachen Sie einen Workload mit einer benutzerdefinierten App
In diesem Szenario ist es wichtig, dass Sie sich die Zeit nehmen, einen geeigneten Gesundheitscheck zu definieren. Wenn Sie nur überprüfen, ob der Port einer Anwendung geöffnet ist, haben Sie nicht überprüft, ob die Anwendung funktioniert. Darüber hinaus ist ein Aufruf der Startseite einer Anwendung nicht unbedingt der richtige Weg, um festzustellen, ob die App funktioniert. Wenn eine Anwendung beispielsweise sowohl von einer Datenbank als auch von Amazon Simple Storage Service (Amazon S3) abhängt, muss der Health Check alle Elemente validieren. Eine Möglichkeit, dies zu tun, besteht darin, eine Monitoring-Webseite wie **/monitor** zu erstellen. Die Überwachungswebseite ruft die Datenbank auf, um sicherzustellen, dass sie eine Verbindung herstellen und Daten abrufen kann. Und die Monitoring-Webseite ruft Amazon S3 auf. Anschließend verweisen Sie bei der Integritätsprüfung auf dem Load Balancer auf die Seite **/monitor**.
Das folgende Diagramm zeigt den Ablauf für Anwendungsfall D:
![\[Beispiel für einen Anwendungsfall für die Überwachung mit einer benutzerdefinierten App\]](http://docs.aws.amazon.com/de_de/IDR/latest/userguide/images/CustomAlarm.png)