# REL 6. Wie werden Ihre Workload-Ressourcen überwacht?
Protokolle und Metriken sind leistungsstarke Tools, mit denen Sie sich einen Überblick über den Zustand Ihrer Workload verschaffen können. Sie können Ihre Workload so konfigurieren, dass Protokolle und Metriken überwacht und Benachrichtigungen gesendet werden, wenn Schwellenwerte überschritten werden oder wichtige Ereignisse auftreten. Dank der Überwachung kann die Workload erkennen, wenn Schwellenwerte für eine niedrige Leistung unterschritten werden oder Ausfälle auftreten, sodass als Reaktion drauf eine automatische Wiederherstellung erfolgen kann.
**Topics**
+ [
# REL06-BP01 Überwachen aller Komponenten der Workload (Generierung)
](rel_monitor_aws_resources_monitor_resources.md)
+ [
# REL06-BP02 Definieren und Berechnen von Metriken (Aggregierung)
](rel_monitor_aws_resources_notification_aggregation.md)
+ [
# REL06-BP03 Senden von Benachrichtigungen (Verarbeitung und Benachrichtigung in Echtzeit)
](rel_monitor_aws_resources_notification_monitor.md)
+ [
# REL06-BP04 Automatisieren von Antworten (Verarbeitung und Benachrichtigung in Echtzeit)
](rel_monitor_aws_resources_automate_response_monitor.md)
+ [
# REL06-BP05 Analysieren von Protokollen
](rel_monitor_aws_resources_storage_analytics.md)
+ [
# REL06-BP06 Regelmäßiges Durchführen von Prüfungen von Umfang und Metriken
](rel_monitor_aws_resources_review_monitoring.md)
+ [
# REL06-BP07 Überwachen der gesamten Nachverfolgung von Anfragen im System
](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 Überwachen aller Komponenten der Workload (Generierung)
Überwachen Sie die Komponenten der Workload mit Amazon CloudWatch oder Tools von Drittanbietern. Überwachen Sie AWS-Services mit dem AWS Health Dashboard.
Alle Komponenten Ihres Workloads sollten überwacht werden, einschließlich Frontend, Geschäftslogik und Speicherstufen. Definieren Sie Schlüsselmetriken, beschreiben Sie, wie Sie diese gegebenenfalls aus Protokollen extrahieren, und legen Sie Schwellenwerte für das Auslösen entsprechender Alarmereignisse fest. Stellen Sie sicher, dass die Metriken für die wichtigen Leistungskennzahlen (KPIs) Ihrer Workload relevant sind und verwenden Sie Metriken und Protokolle, um frühe Warnzeichen einer Serviceverschlechterung zu identifizieren. Beispielsweise kann eine mit Geschäftsergebnissen zusammenhängende Metrik wie etwa die Anzahl der pro Minute erfolgreich verarbeiteten Bestellungen schneller auf Workload-Probleme hinweisen als eine technische Metrik wie etwa die CPU-Auslastung. Verwenden Sie das AWS Health Dashboard für eine personalisierte Ansicht der Leistung und Verfügbarkeit der AWS-Services, die Ihren AWS-Ressourcen.
Die Überwachung in der Cloud bietet neue Möglichkeiten. Die meisten Cloudanbieter haben anpassbare Hooks entwickelt und können Einblicke liefern, mit denen Sie mehrere Ebenen Ihrer Workload überwachen können. AWS-Services wie Amazon CloudWatch wenden statistische und Machine-Learning-Algorithmen an, um Metriken von Systemen und Anwendungen kontinuierlich zu analysieren, normale Basiswerte zu erkennen und Oberflächenanomalien anhand eines minimalen Benutzereingriffs aufzudecken. Anomalieerkennungsalgorithmen berücksichtigen saisonale und trendbasierte Änderungen von Metriken.
AWS stellt zahlreiche Überwachungs- und Protokollinformationen bereit, die genutzt werden können, um workload-spezifische Metriken und Bedarfsänderungsprozesse zu definieren und Machine-Learning-Verfahren unabhängig von der ML-Erfahrung einzuführen.
Zudem können Sie auch all Ihre externen Endpunkte überwachen, um sicherzustellen, dass diese von Ihrer Basisimplementierung unabhängig sind. Diese aktive Überwachung kann anhand von synthetischen Transaktionen erfolgen (auch *Benutzer-Canaries* genannt, jedoch nicht zu verwechseln mit Canary-Bereitstellungen). Diese führen regelmäßig eine Reihe gängiger Aufgaben aus, die mit Aktionen übereinstimmen, die von Clients der Workload durchgeführt werden. Diese Aufgaben sollten nicht zu lang sein und Sie sollten darauf achten, Ihre Workload beim Testen nicht zu überlasten. Mit Amazon CloudWatch Synthetics können Sie [synthetische Canaries erstellen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), um Ihre Endpunkte und APIs zu überwachen. Sie können die synthetischen Canary-Client-Knoten auch mit der AWS X-Ray-Konsole kombinieren, um zu bestimmen, bei welchen synthetischen Canaries im ausgewählten Zeitraum Probleme mit Fehlern, Störungen oder Drosselungsraten auftreten.
**Gewünschtes Ergebnis:**
Erfassen und Nutzen kritischer Metriken aus allen Komponenten der Workload, um die Workload-Zuverlässigkeit und eine optimale Benutzererfahrung sicherzustellen. Wenn Sie erkennen, dass mit einem Workload keine Geschäftsergebnisse erzielt werden, können Sie schnell einen Systemausfall deklarieren und das System nach einem Vorfall wiederzustellen.
**Typische Anti-Muster:**
+ Es werden nur externe Schnittstellen zum Workload überwacht.
+ Es werden keine workload-spezifischen Metriken erzeugt und Sie verlassen sich nur auf Metriken, die Ihnen von den AWS-Services, die Ihre Workload verwendet, bereitgestellt werden.
+ Es werden nur technische Metriken in Ihrer Workload verwendet und es werden keinerlei Metriken im Zusammenhang mit nicht-technischen KPIs, zu denen die Workload beiträgt, überwacht.
+ Sie verlassen sich auf den Produktionsdatenverkehr und einfache Zustandsprüfungen für die Überwachung und Bewertung des Workload-Status.
**Vorteile der Nutzung dieser bewährten Methode:** Durch die Überwachung aller Ebenen Ihrer Workload können Sie Probleme in den darin enthaltenen Komponenten schneller vorhersehen und beheben.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
1. **Aktivieren Sie die Protokollierung, wann immer verfügbar.** Von allen Workload-Komponenten sollten Überwachungsdaten erzielt werden. Aktivieren Sie eine zusätzliche Protokollierung, wie etwa S3 Access Logs, und ermöglichen Sie es Ihrer Workload, die workload-spezifischen Daten zu protokollieren. Erfassen Sie Metriken für die Durchschnittswerte zu CPU, Netzwerk-E/A und Laufwerk-E/A von Services wie Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling und Amazon EMR Unter [AWS Services That Publish CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) finden Sie eine Liste an AWS-Services, die Metriken in CloudWatch veröffentlichen.
1. **Sehen Sie sich alle Standardmetriken an, um mehr über mögliche Datenerfassungslücken zu erfahren.** Jeder Service generiert Standardmetriken. Durch die Erfassung von Standardmetriken erhalten Sie ein besseres Verständnis über die Abhängigkeiten zwischen Workload-Komponenten und darüber, wie die Komponentenzuverlässigkeit und -leistung die Workload beeinträchtigen. Sie können auch [Ihre eigenen Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) in CloudWatch unter Verwendung der AWS CLI oder einer API erstellen und veröffentlichen.
1. **Bewerten Sie alle Metriken, um zu entscheiden, für welche eine Warnmeldung für jeden AWS-Service in Ihrer Workload eingerichtet werden soll.** Sie können eine Metriken-Untergruppe auswählen, die eine höhere Auswirkung auf die Workload-Zuverlässigkeit hat. Wenn Sie sich auf kritische Metriken und Schwellenwerte konzentrieren, können Sie die Anzahl an [Warnmeldungen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) genauer definieren und so Falschmeldungen reduzieren.
1. **Definieren Sie Warnungen und den Wiederherstellungsprozess für Ihre Workload nach dem Auslösen der Warnmeldung.** Das Definieren von Warnmeldungen ermöglicht es Ihnen, schnell zu benachrichtigen, zu eskalieren und die für die Wiederherstellung nach einem Vorfall erforderlichen Schritte durchzuführen, um so Ihren festgelegten Recovery Time Objective (RTO) zu erfüllen. Sie können [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) für das Aufrufen von automatisierten Workflows und die Initiierung von Wiederherstellungsverfahren basierend auf definierten Schwellenwerten verwenden.
1. **Erfahren Sie mehr über die Verwendung von synthetischen Transaktionen für das Erfassen relevanter Daten zum Workload-Status.** Die synthetische Überwachung folgt denselben Routen und führt dieselben Aktionen aus wie ein Kunde. Dadurch haben Sie die Möglichkeit, die Kundenerfahrung kontinuierlich zu überprüfen, selbst, wenn Sie keinen Kundendatenverkehr auf Ihren Workloads haben. Durch die Verwendung von [synthetischen Transaktionen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) können Sie Probleme erkennen, bevor Ihre Kunden dies tun.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL11-BP03 Automatisieren der Reparatur auf allen Ebenen](rel_withstand_component_failures_auto_healing_system.md)
**Zugehörige Dokumente:**
+ [Getting started with your AWS Health Dashboard – Your account health](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [AWS Services That Publish CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Access Logs for Your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Access logs for your application load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [Accessing Amazon CloudWatch Logs for AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Amazon-S3-Server-Zugriffsprotokollierung](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Enable Access Logs for Your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Exporting log data to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Install the CloudWatch agent on an Amazon EC2 instance](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [Publishing Custom Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Verwenden von Amazon-CloudWatch-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Using Canaries (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [What are Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**Benutzerhandbücher:**
+ [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Monitoring memory and disk metrics for Amazon EC2 Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [Using CloudWatch Logs with container instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC Flow Logs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Was ist AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**Verwandte Blogs:**
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**Zugehörige Beispiele:**
+ [The Amazon Builders' Library: Instrumentieren verteilter Systeme für Einblicke in die Betriebsabläufe](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Workshop zur Beobachtbarkeit](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 Definieren und Berechnen von Metriken (Aggregierung)
Erfassen Sie Metriken und Protokolle aus Ihren Workload-Komponenten und berechnen Sie daraus relevante aggregierte Metriken. Diese Metriken bieten eine umfassende und tiefgehende Beobachtbarkeit über Ihre Workloads und können Ihre Resilienzlage erheblich verbessern.
Beobachtbarkeit bedeutet mehr als nur das Erfassen von Metriken aus Workload-Komponenten und die Möglichkeit, diese einzusehen und entsprechende Warnmeldungen zu erstellen. Es geht vielmehr darum, ein ganzheitliches Verständnis des Verhaltens Ihrer Workloads zu erhalten. Diese Verhaltensinformationen stammen aus allen Komponenten Ihrer Workloads, einschließlich der Cloud-Services, von denen sie abhängen, gut ausgearbeiteten Protokolle und Metriken. Diese Daten geben Ihnen einen Überblick über das Verhalten Ihrer Workloads insgesamt sowie ein detailliertes Verständnis der Interaktion jeder Komponente mit jeder Arbeitseinheit.
**Gewünschtes Ergebnis:**
+ Sie erfassen Protokolle Ihrer Workload-Komponenten und AWS-Serviceabhängigkeiten und veröffentlichen sie an einem zentralen Ort, wo sie leicht abgerufen und verarbeitet werden können.
+ Ihre Protokolle enthalten äußerst präzise Zeitstempel.
+ Ihre Protokolle enthalten relevante Informationen über den Verarbeitungskontext, wie z. B. eine Ablaufverfolgungs-ID, eine Benutzer- oder Kontokennung und eine Remote-IP-Adresse.
+ Sie erstellen aus Ihren Protokollen aggregierte Metriken, die das Verhalten Ihrer Workloads aus einer übergeordneten Perspektive darstellen.
+ Sie können Ihre aggregierten Protokolle abfragen, um tiefe und relevante Einblicke in Ihre Workloads zu gewinnen und tatsächliche und potenzielle Probleme zu identifizieren.
**Typische Anti-Muster:**
+ Sie erfassen keine relevanten Protokolle oder Metriken von den Computing-Instanzen, auf denen Ihre Workloads ausgeführt werden, oder von den Cloud-Services, die sie verwenden.
+ Sie übersehen die Erfassung von Protokollen und Metriken, die Ihre Leistungskennzahlen (KPIs) betreffen.
+ Sie analysieren die auf Workloads bezogene Telemetrie isoliert, ohne Aggregation und Korrelation.
+ Sie lassen zu, dass Metriken und Protokolle zu schnell ablaufen, was Trendanalysen und die Identifizierung wiederkehrender Probleme erschwert.
**Vorteile der Nutzung dieser bewährten Methoden:** Sie können mehr Anomalien erkennen und Ereignisse und Metriken zwischen verschiedenen Komponenten Ihrer Workloads korrelieren. Sie können anhand Ihrer Workload-Komponenten Erkenntnisse gewinnen, die auf Informationen in Protokollen basieren, die häufig nicht nur in Form von Metriken verfügbar sind. Sie können Fehlerursachen schneller ermitteln, indem Sie Ihre Protokolle in großem Umfang abfragen.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Hoch
## Implementierungsleitfaden
Identifizieren Sie die Quellen von Telemetriedaten, die für Ihre Workloads und deren Komponenten relevant sind. Diese Daten stammen nicht nur aus Komponenten, die Metriken veröffentlichen, wie Ihrem Betriebssystem (OS) und Anwendungslaufzeiten wie Java, sondern auch aus Anwendungs- und Cloud-Serviceprotokollen. Beispielsweise protokollieren Webserver in der Regel jede Anfrage mit detaillierten Informationen wie Zeitstempel, Verarbeitungslatenz, Benutzer-ID, Remote-IP-Adresse, Pfad und Abfragezeichenfolge. Der Detaillierungsgrad dieser Protokolle hilft Ihnen dabei, detaillierte Abfragen durchzuführen und Metriken zu generieren, die sonst möglicherweise nicht verfügbar gewesen wären.
Erfassen Sie die Metriken und Protokolle mithilfe geeigneter Tools und Prozesse. Protokolle, die von Anwendungen generiert werden, die auf einer Amazon-EC2-Instance ausgeführt werden, können von einem Agenten wie dem [Amazon CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) erfasst und in einem zentralen Speicherservice wie [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) veröffentlicht werden. AWS-verwaltete Computing-Services wie [AWS Lambda](https://aws.amazon.com/lambda/)[Amazon Elastic Container Service](https://aws.amazon.com/ecs/) veröffentlichen Protokolle automatisch in CloudWatch Logs für Sie. Aktivieren Sie die Protokollerfassung für AWS-Speicher- und Verarbeitungsservices, die von Ihren Workloads wie [Amazon CloudFront](https://aws.amazon.com/cloudfront/), [Amazon S3](https://aws.amazon.com/s3/), [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/) und [Amazon API](https://aws.amazon.com/api-gateway/) Gateway verwendet werden.
Reichern Sie Ihre Telemetriedaten mit *[Dimensionen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)* an, anhand derer Sie Verhaltensmuster klarer erkennen und korrelierte Probleme anhand von Gruppen verwandter Komponenten isolieren können. Nach dem Hinzufügen können Sie das Verhalten der Komponenten detaillierter beobachten, korrelierte Fehler erkennen und geeignete Abhilfemaßnahmen ergreifen. Beispiele für nützliche Dimensionen sind Availability Zone, EC2-Instance-ID und Container-Task- oder Pod-ID.
Sobald Sie die Metriken und Protokolle erfasst haben, können Sie Abfragen erstellen und daraus aggregierte Metriken generieren, die nützliche Einblicke in normales und anomales Verhalten bieten. Sie können beispielsweise [Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) verwenden, um benutzerdefinierte Metriken aus Ihren Anwendungsprotokollen abzuleiten, [Amazon CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html), um Ihre Metriken in großem Umfang abzufragen, [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) zum Sammeln, Aggregieren und Zusammenfassen von Metriken und Protokollen aus Ihren containerisierten Anwendungen und Microservices oder [Amazon CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html), wenn Sie AWS Lambda-Funktionen verwenden. Um eine aggregierte Fehlerratenmetrik zu erstellen, können Sie einen Zähler jedes Mal erhöhen, wenn eine Fehlerantwort oder Meldung in Ihren Komponentenprotokollen gefunden wird, oder Sie können den Gesamtwert einer vorhandenen Fehlerratenmetrik berechnen. Sie können diese Daten verwenden, um Histogramme zu generieren, die das *Verhalten von Vorgängen zeigen,* z. B. die Anfragen oder Prozesse mit der schlechtesten Leistung. Mithilfe von Lösungen wie der [Anomalieerkennung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html) von CloudWatch Logs können Sie diese Daten auch in Echtzeit nach anomalen Mustern durchsuchen. Diese Erkenntnisse können in Dashboards platziert werden, sodass sie Ihren Anforderungen und Präferenzen entsprechend organisiert werden können.
Mithilfe von Protokollabfragen können Sie besser verstehen, wie bestimmte Anfragen von Ihren Workload-Komponenten bearbeitet wurden, und Anforderungsmuster oder andere Kontexte aufdecken, die sich auf die Resilienz Ihres Workloads auswirken. Es kann nützlich sein, Abfragen auf der Grundlage Ihres Wissens über das Verhalten Ihrer Anwendungen und anderer Komponenten im Voraus zu recherchieren und vorzubereiten, so dass Sie sie bei Bedarf einfacher ausführen können. Beispielsweise können Sie mit [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) Protokolldaten in Amazon CloudWatch Logs interaktiv durchsuchen und analysieren. Sie können auch [Amazon Athena](https://aws.amazon.com/athena/) verwenden, um Protokolle aus mehreren Quellen, einschließlich [zahlreicher AWS-Services](https://docs.aws.amazon.com/athena/latest/ug/querying-aws-service-logs.html), im Petabyte-Bereich abzufragen.
Wenn Sie eine Richtlinie zur Aufbewahrung von Protokollen definieren, sollten Sie den Wert historischer Protokolle berücksichtigen. Historische Protokolle können dabei helfen, langfristige Nutzungs- und Verhaltensmuster, Regressionen und Leistungsverbesserungen Ihrer Workloads zu identifizieren. Dauerhaft gelöschte Protokolle können später nicht analysiert werden. Der Wert historischer Protokolle nimmt jedoch über längere Zeiträume hinweg tendenziell ab. Wählen Sie eine Richtlinie, die Ihren Anforderungen angemessen Rechnung trägt und alle gesetzlichen oder vertraglichen Anforderungen erfüllt, denen Sie möglicherweise unterliegen.
### Implementierungsschritte
1. Wählen Sie die Erfassungs-, Speicher-, Analyse- und Anzeigemechanismen für Ihre Beobachtbarkeitsdaten.
1. Installieren und konfigurieren Sie Metrik- und Protokollkollektoren für die entsprechenden Komponenten Ihrer Workloads (z. B. für Amazon-EC2-Instances und in [Sidecar-Containern](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)). Konfigurieren Sie diese Kollektoren so, dass sie automatisch neu gestartet werden, wenn sie unerwartet beendet werden. Aktivieren Sie die Festplatten- oder Speicherpufferung für die Kollektoren, sodass temporäre Veröffentlichungsfehler Ihre Anwendungen nicht beeinträchtigen oder zu Datenverlusten führen.
1. Aktivieren Sie die Protokollierung für AWS-Services, die Sie im Rahmen Ihrer Workloads verwenden, und leiten Sie diese Protokolle an den ausgewählten Speicherservice weiter, wenn notwendig. Ausführliche Anweisungen finden Sie in den Benutzer- oder Entwicklerhandbüchern der jeweiligen Services.
1. Definieren Sie die für Ihre Workloads relevanten betrieblichen Metriken, die auf Ihren Telemetriedaten basieren. Diese können auf direkten Metriken basieren, die von Ihren Workload-Komponenten ausgegeben werden, zu denen auch Metriken im Zusammenhang mit Geschäftskennzahlen oder die Ergebnisse aggregierter Berechnungen wie Summen, Raten, Perzentile oder Histogramme gehören können. Berechnen Sie diese Metriken mit Ihrem Protokollanalysator und platzieren Sie sie gegebenenfalls in Dashboards.
1. Bereiten Sie geeignete Protokollabfragen vor, um Workload-Komponenten, Anfragen oder das Transaktionsverhalten nach Bedarf zu analysieren.
1. Definieren und aktivieren Sie eine Protokollaufbewahrungsrichtlinie für Ihre Komponentenprotokolle. Löschen Sie regelmäßig Protokolle, wenn sie älter sind, als es die Richtlinie zulässt.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL06-BP01 Überwachen aller Komponenten des Workloads (Generierung)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Senden von Benachrichtigungen (Verarbeitung und Benachrichtigung in Echtzeit)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL06-BP04 Automatisieren von Antworten (Verarbeitung und Benachrichtigung in Echtzeit)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_automate_response_monitor.html)
+ [REL06-BP05 Analysieren von Protokollen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_storage_analytics.html)
+ [REL06-BP06 Regelmäßiges Durchführen von Prüfungen von Umfang und Metriken](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_review_monitoring.html)
+ [REL06-BP07 Überwachen der gesamten Nachverfolgung von Anfragen im System](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
**Zugehörige Dokumentation:**
+ [Funktionsweise von Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon Managed Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)
+ [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)
+ [Analysieren von Protokolldaten mit CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Amazon CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html)
+ [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)
+ [Abfragen Ihrer Metriken mit CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
+ [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debuggen mit Amazon CloudWatch Synthetics und AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Suchen und Filtern von Protokolldaten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Senden von Protokollen direkt an Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
**Zugehörige Workshops:**
+ [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/)
**Zugehörige Tools:**
+ [AWS Distro for OpenTelemetry (GitHub)](https://aws-otel.github.io/)
# REL06-BP03 Senden von Benachrichtigungen (Verarbeitung und Benachrichtigung in Echtzeit)
Wenn Organisationen potenzielle Probleme erkennen, senden sie Benachrichtigungen und Warnungen in Echtzeit an das entsprechende Personal und die entsprechenden Systeme, um schnell und effektiv auf diese Probleme reagieren zu können.
**Gewünschtes Ergebnis:** Durch die Konfiguration relevanter Alarme auf der Grundlage von Service- und Anwendungsmetriken ist eine schnelle Reaktion auf operative Ereignisse möglich. Bei Überschreitung der Alarmschwellen werden das entsprechende Personal und die entsprechenden Systeme benachrichtigt, damit sie die zugrunde liegenden Probleme beseitigen können.
**Typische Anti-Muster:**
+ Sie konfigurieren Alarme mit einem übermäßig hohen Schwellenwert, was dazu führt, dass wichtige Benachrichtigungen nicht gesendet werden können.
+ Sie konfigurieren Alarme mit einem zu niedrigen Schwellenwert, was dazu führt, dass bei wichtigen Warnungen aufgrund des Lärms übermäßiger Benachrichtigungen keine Aktion erfolgt.
+ Sie aktualisieren keine Alarme und ihre Schwellenwerte, wenn sich die Nutzung ändert.
+ Bei Alarmen, die am besten durch automatische Aktionen behoben werden, führt das Senden der Benachrichtigung an das Personal, anstatt die automatische Aktion zu generieren, dazu, dass übermäßig viele Benachrichtigungen gesendet werden.
**Vorteile der Nutzung dieser bewährten Methode:** Das Senden von Benachrichtigungen und Warnungen in Echtzeit an das entsprechende Personal und die entsprechenden Systeme ermöglicht eine frühzeitige Erkennung von Problemen und eine schnelle Reaktion auf betriebliche Vorfälle.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Hoch
## Implementierungsleitfaden
Workloads sollten mit der Verarbeitung und Benachrichtigung in Echtzeit ausgestattet sein, um die Erkennbarkeit von Problemen zu verbessern, die sich auf die Verfügbarkeit der Anwendung auswirken und als Auslöser für automatische Reaktionen dienen könnten. Organisationen können die Verarbeitung und Benachrichtigung in Echtzeit durchführen, indem sie Warnungen mit definierten Metriken erstellen, um Benachrichtigungen zu erhalten, wenn wichtige Ereignisse eintreten oder eine Metrik einen Schwellenwert überschreitet.
[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) ermöglicht es Ihnen, [Metrik-Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) und zusammengesetzte Alarme mithilfe von CloudWatch-Alarmen zu erstellen, die auf statischen Schwellenwerten, der Erkennung von Unregelmäßigkeiten und anderen Kriterien basieren. Weitere Informationen zu den Alarmtypen, die Sie mit CloudWatch konfigurieren können, finden Sie im [Abschnitt über Alarme in der CloudWatch-Dokumentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Sie können benutzerdefinierte Ansichten von Metriken und Warnungen Ihrer AWS-Ressourcen für Ihre Teams erstellen, indem Sie [CloudWatch-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) nutzen. Die anpassbaren Startseiten in der CloudWatch-Konsole ermöglichen es Ihnen, Ihre Ressourcen in einer einzigen Ansicht über mehrere Regionen hinweg zu überwachen.
Alarme können mindestens eine Aktion ausführen, z. B. das Senden einer Benachrichtigung an ein [Amazon SNS-Thema](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html), das eine [Amazon EC2](https://aws.amazon.com/ec2/)-Aktion oder eine [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/)-Aktion durchgeführt, oder das Erstellen eines [OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)-Elements oder [Vorfalls](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) in AWS Systems Manager.
Amazon CloudWatch verwendet [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) zum Senden von Benachrichtigungen, wenn sich der Status des Alarms ändert, und ermöglicht so die Nachrichtenzustellung von den Publishern (Produzenten) an die Subscriber (Verbraucher). Weitere Informationen zum Einrichten von Amazon SNS-Benachrichtigungen finden Sie unter [Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html).
CloudWatch sendet [EventBridge](https://aws.amazon.com/eventbridge/)-[Ereignisse](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html), wenn ein CloudWatch-Alarm erstellt, aktualisiert oder gelöscht wird oder sich sein Status ändert. Sie können EventBridge mit diesen Ereignissen verwenden, um Regeln zu erstellen, die Aktionen ausführen, z. B. Sie benachrichtigen, wenn sich der Status eines Alarms ändert, oder automatisch Ereignisse in Ihrem Konto mit [Systems Manager-Automatisierung](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) auslösen.
Bleiben Sie auf dem Laufenden mit [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/). AWS Health ist die maßgebliche Informationsquelle über den Zustand Ihrer AWS Cloud-Ressourcen. Verwenden Sie AWS Health, um über bestätigte Serviceereignisse benachrichtigt zu werden, so dass Sie schnell Maßnahmen ergreifen können, um etwaige Auswirkungen zu minimieren. Erstellen Sie maßgeschneiderte AWS Health-Ereignisbenachrichtigungen für E-Mail- und Chat-Kanäle über [AWS-Benutzerbenachrichtigungen](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html), und integrieren Sie sie programmgesteuert in [Ihre Überwachungs- und Warnmeldungstools über Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). Wenn Sie AWS Organizations verwenden, können Sie AWS Health-Ereignisse kontenübergreifend zusammenfassen.
** Wann sollten Sie EventBridge im Vergleich zu Amazon SNS verwenden? **
Sowohl EventBridge als auch Amazon SNS können zur Entwicklung ereignisgesteuerter Anwendungen verwendet werden. Ihre Wahl hängt von Ihren spezifischen Anforderungen ab.
Amazon EventBridge wird empfohlen, wenn Sie eine Anwendung erstellen möchten, die auf Ereignisse aus Ihren eigenen Anwendungen, SaaS-Anwendungen und AWS-Services reagiert. EventBridge ist der einzige ereignisbasierte Service, der direkt in SaaS-Partner von Drittanbietern integriert werden kann. EventBridge nimmt außerdem automatisch Ereignisse von über 200 AWS-Services auf, ohne dass Entwickler Ressourcen in ihrem Konto erstellen müssen.
EventBridge verwendet eine definierte JSON-basierte Struktur für Ereignisse und hilft Ihnen bei der Erstellung von Regeln, die auf den gesamten Ereignistext angewendet werden, um Ereignisse auszuwählen, die an ein [Ziel](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) weitergeleitet werden sollen. EventBridge unterstützt derzeit über 20 AWS-Services als Ziele, darunter [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), [Amazon SQS](https://aws.amazon.com/sqs/), Amazon SNS, [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) und [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/).
Amazon SNS wird für Anwendungen empfohlen, die eine hohe Verteilung benötigen (Tausende oder Millionen von Endpunkten). Ein gängiges Muster, das wir beobachten, ist, dass Kunden Amazon SNS als Ziel für ihre Regel verwenden, um die Ereignisse zu filtern, die sie benötigen, und dann an mehrere Endpunkte zu verteilen.
Nachrichten sind unstrukturiert und können in jedem Format vorliegen. Amazon SNS unterstützt die Weiterleitung von Nachrichten an sechs verschiedene Zieltypen, darunter Lambda, Amazon SQS, HTTP/S-Endpunkte, SMS, mobile Push-Benachrichtigungen und E-Mail. Die [typische Latenz von Amazon SNS liegt unter 30 Millisekunden](https://aws.amazon.com/sns/faqs/). Eine Vielzahl von AWS-Services sendet Amazon SNS-Nachrichten, indem sie den Service entsprechend konfigurieren (mehr als 30, einschließlich Amazon EC2, [Amazon S3](https://aws.amazon.com/s3/), and [Amazon RDS](https://aws.amazon.com/rds/)).
### Implementierungsschritte
1. Erstellen Sie einen Alarm mithilfe von [Amazon CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
1. Ein metrischer Alarm überwacht eine einzelne CloudWatch-Metrik oder einen Ausdruck, der von CloudWatch-Metriken abhängig ist. Der Alarm initiiert eine oder mehrere Aktionen auf der Grundlage des Werts der Metrik oder des Ausdrucks im Vergleich zu einem Schwellenwert über eine Reihe von Zeitintervallen. Die Aktion kann darin bestehen, eine Benachrichtigung an ein [Amazon SNS-Thema](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) zu senden, das eine [Amazon EC2](https://aws.amazon.com/ec2/)-Aktion oder eine [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/)-Aktion durchführt, oder ein [OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)-Element oder einen [Vorfall](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) in AWS Systems Manager zu erstellen.
1. Ein zusammengesetzter Alarm besteht aus einem Regelausdruck, der die Alarmbedingungen anderer von Ihnen erstellter Alarme berücksichtigt. Der zusammengesetzte Alarm wechselt nur dann in den Alarmstatus, wenn alle Regelbedingungen erfüllt sind. Die im Regelausdruck eines zusammengesetzten Alarms angegebenen Alarme können metrische Alarme und zusätzliche zusammengesetzte Alarme enthalten. Zusammengesetzte Alarme können Amazon SNS-Benachrichtigungen senden, wenn sich ihr Status ändert, und sie können Systems Manager [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)-Elemente oder [Vorfälle](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) auslösen, wenn sie in den Alarmzustand wechseln, aber sie können weder Amazon EC2- noch Auto Scaling-Aktionen ausführen.
1. Richten Sie [Amazon SNS-Benachrichtigungen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html) ein. Wenn Sie einen CloudWatch-Alarm erstellen, können Sie ein Amazon SNS-Thema hinzufügen, um eine Benachrichtigung zu senden, wenn sich der Status des Alarms ändert.
1. [Erstellen Sie Regeln in EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html), die bestimmten CloudWatch-Alarmen entsprechen. Jede Regel unterstützt mehrere Ziele, einschließlich Lambda-Funktionen. Jede Regel unterstützt mehrere Ziele, einschließlich Lambda-Funktionen. Sie können beispielsweise einen Alarm definieren, der initiiert wird, wenn der verfügbare Festplattenspeicher knapp wird, wodurch über eine EventBridge-Regel eine Lambda-Funktion ausgelöst wird, um den Speicherplatz zu bereinigen. Weitere Informationen zu EventBridge-Zielen finden Sie unter [EventBridge-Ziele](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html).
## Ressourcen
**Zugehörige bewährte Methoden für Well-Architected:**
+ [REL06-BP01 Überwachen aller Komponenten der Workload (Generierung)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Definieren und Berechnen von Metriken (Aggregierung)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL12-BP01 Untersuchen von Fehlern mit Playbooks](rel_testing_resiliency_playbook_resiliency.md)
**Zugehörige Dokumente:**
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ CloudWatch Logs Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Verwenden von Amazon-CloudWatch-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Using Amazon CloudWatch dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Verwenden von Amazon-CloudWatch-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [ Setting up Amazon SNS notifications ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [ CloudWatch anomaly detection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch Logs data protection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [ Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [ Amazon Simple Notification Service ](https://aws.amazon.com/sns/)
**Zugehörige Videos:**
+ [ reinvent 2022 observability videos ](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 - Observability best practices at Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
**Zugehörige Beispiele:**
+ [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/)
+ [ Amazon EventBridge to AWS Lambda with feedback control by Amazon CloudWatch Alarms ](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)
# REL06-BP04 Automatisieren von Antworten (Verarbeitung und Benachrichtigung in Echtzeit)
Automatisieren Sie bei Erkennung von Ereignissen die erforderlichen Maßnahmen, wie etwa den Austausch fehlerhafter Komponenten.
Die automatische Echtzeitverarbeitung von Alarmen ist implementiert, sodass die Systeme bei Auslösung von Alarmen schnell korrigierend eingreifen und versuchen können, Ausfälle oder Beeinträchtigungen des Services zu verhindern. Zu den automatisierten Reaktionen auf Alarme könnten der Austausch ausgefallener Komponenten, die Anpassung der Rechenkapazität, die Umleitung des Datenverkehrs auf fehlerfreie Hosts, Availability Zones oder andere Regionen sowie die Benachrichtigung der Betreiber gehören.
**Gewünschtes Ergebnis:** Echtzeitalarme werden ermittelt und die automatische Verarbeitung von Alarmen wird eingerichtet, um die entsprechenden Maßnahmen zur Einhaltung von Service-Level-Zielen und Service Level Agreements (SLAs) einzuleiten. Die Automatisierung kann von der Selbstreparatur einzelner Komponenten bis hin zum Failover eines ganzen Standorts reichen. Die Automatisierung kann von der Selbstreparatur einzelner Komponenten bis hin zum Failover eines ganzen Standorts reichen.
**Typische Anti-Muster:**
+ Fehlen einer genauen Bestandsaufnahme oder eines Katalogs der wichtigsten Echtzeitalarme
+ Keine automatischen Reaktionen auf kritische Alarme (z. B. automatische Skalierung, wenn die Rechenkapazität fast erschöpft ist)
+ Widersprüchliche Alarmreaktionen
+ Fehlen von Standard-Betriebsabläufen (SOPs), an die sich die Bediener halten müssen, wenn sie Alarmmeldungen erhalten
+ Keine Überwachung von Konfigurationsänderungen, da unentdeckte Konfigurationsänderungen zu Ausfallzeiten bei Workloads führen können
+ Keine Strategie, um unbeabsichtigte Konfigurationsänderungen rückgängig zu machen
**Vorteile der Nutzung dieser bewährten Methode:** Die Automatisierung der Alarmverarbeitung kann die Ausfallsicherheit des Systems verbessern. Das System ergreift automatisch Korrekturmaßnahmen und reduziert so manuelle Tätigkeiten, bei denen es zu einem menschlichen, fehleranfälligen Eingreifen kommen kann. Der Workload-Betrieb erfüllt die Verfügbarkeitsziele und reduziert Serviceunterbrechungen.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Mittel
## Implementierungsleitfaden
Zur wirksamen Verwaltung von Alarmen und zur Automatisierung ihrer Beantwortung kategorisieren Sie die Alarme nach ihrer Kritikalität und Auswirkung, dokumentieren die Reaktionsverfahren und planen die Reaktionen, bevor Sie die Aufgaben einordnen.
Ermitteln Sie Aufgaben, die bestimmte Aktionen erfordern (oft in Runbooks detailliert beschrieben), und untersuchen Sie alle Runbooks und Playbooks, um festzustellen, welche Aufgaben automatisiert werden können. Lassen sich Aktionen definieren, können sie oft auch automatisiert werden. Wenn Aktionen nicht automatisiert werden können, dokumentieren Sie die manuellen Schritte in einer SOP und schulen Sie die Mitarbeiter darin. Hinterfragen Sie kontinuierlich manuelle Prozesse und suchen Sie nach Möglichkeiten zur Automatisierung, um einen Plan für die Automatisierung von Alarmreaktionen zu erstellen und zu verwalten.
### Implementierungsschritte
1. **Erstellen eines Inventars von Alarmen:** Um eine Liste aller Alarme zu erhalten, können Sie die [AWS CLI](https://aws.amazon.com/cli/) mit dem [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)-Befehl `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)` verwenden. Je nachdem, wie viele Alarme Sie eingerichtet haben, müssen Sie möglicherweise eine Paginierung verwenden, um eine Untergruppe von Alarmen für jeden Anruf aufzurufen. Alternativ können Sie das AWS-SDK verwenden, um die Alarme über [einen API-Aufruf](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html) aufzurufen.
1. **Dokumentieren aller Alarmaktionen:** Aktualisieren Sie ein Runbook mit allen Alarmen und ihren Aktionen, unabhängig davon, ob sie manuell oder automatisiert sind. [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) bietet vordefinierte Runbooks. Ausführliche Informationen zum Anzeigen von Runbook-Inhalten finden Sie unter [Working with runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html). Ausführliche Informationen zum Anzeigen von Runbook-Inhalten finden Sie unter [View runbook content](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json).
1. **Einrichten und Verwalten von Alarmaktionen:** Für jeden der Alarme, die eine Aktion erfordern, geben Sie die [automatische Aktion mithilfe des CloudWatch-SDK an](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html). So können Sie beispielsweise den Zustand Ihrer Amazon EC2-Instances automatisch auf Grundlage eines CloudWatch-Alarms ändern, indem Sie Aktionen für einen Alarm erstellen und aktivieren oder Aktionen für einen Alarm deaktivieren.
Sie können [Amazon EventBridge](https://aws.amazon.com/eventbridge/) auch verwenden, um automatisch auf Systemereignisse zu reagieren, z. B. auf Probleme mit der Anwendungsverfügbarkeit oder auf Ressourcenänderungen. Sie können Regeln erstellen, um anzugeben, an welchen Ereignissen Sie interessiert sind, und welche Aktionen auszuführen sind, wenn ein Ereignis mit einer Regel übereinstimmt. Zu den Aktionen, die automatisch ausgelöst werden können, gehören der Aufruf einer [AWS Lambda](https://aws.amazon.com/lambda/)-Funktion, der Aufruf von [Amazon EC2](https://aws.amazon.com/ec2/) `Run Command`, die Weiterleitung des Ereignisses an [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) und [Automatisieren von Amazon EC2 mithilfe von EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html).
1. **Standard-Betriebsabläufe (SOPs):** Basierend auf den Komponenten Ihrer Anwendung empfiehlt [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) mehrere [SOP-Vorlagen](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html). Sie können diese SOPs verwenden, um alle Prozesse zu dokumentieren, die ein Bediener im Falle eines Alarms befolgen sollte. Sie können auch eine [SOP](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html) auf Grundlage von Resilience Hub-Empfehlungen erstellen, für die Sie eine Resilience Hub-Anwendung mit einer zugehörigen Resilienzrichtlinie sowie eine historische Resilienzbewertung für diese Anwendung benötigen. Die Empfehlungen für Ihre SOP ergeben sich aus der Resilienzbewertung.
Resilience Hub arbeitet mit Systems Manager zusammen, um die einzelnen Schritte Ihrer SOPs zu automatisieren. Dazu erhalten Sie eine Reihe von [SSM-Dokumenten](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html), die Sie als Grundlage für diese SOPs verwenden können. So kann Resilience Hub zum Beispiel eine SOP für das Hinzufügen von Speicherplatz auf Grundlage eines bestehenden SSM-Automatisierungsdokuments empfehlen.
1. **Durchführen automatisierter Aktionen mit Amazon DevOps Guru:** Sie können [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) verwenden, um Anwendungsressourcen automatisch auf anomales Verhalten zu überwachen und gezielte Empfehlungen für eine schnellere Problemerkennung und -behebung zu geben. Mit DevOps Guru können Sie Ströme von Betriebsdaten aus verschiedenen Quellen wie Amazon CloudWatch-Metriken, [AWS Config](https://aws.amazon.com/config/), [AWS CloudFormation](https://aws.amazon.com/cloudformation/) und [AWS X-Ray](https://aws.amazon.com/xray/) nahezu in Echtzeit überwachen. Sie können DevOps Guru auch verwenden, um automatisch [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) in OpsCenter zu erstellen und Ereignisse an [EventBridge zu senden, um eine zusätzliche Automatisierung zu erreichen](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html).
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL06-BP01 Überwachen aller Komponenten der Workload (Generierung)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Definieren und Berechnen von Metriken (Aggregierung)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Senden von Benachrichtigungen (Verarbeitung und Benachrichtigung in Echtzeit)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL08-BP01 Verwenden von Runbooks für Standardaktivitäten wie die Bereitstellung](rel_tracking_change_management_planned_changemgmt.md)
**Zugehörige Dokumente:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Creating an EventBridge Rule That Triggers on an Event from an AWS Resource](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/)
+ [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [What is Amazon DevOps Guru?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Working with Automation Documents (Playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
**Zugehörige Videos:**
+ [AWS re:Invent 2022 - Observability best practices at Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [ Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [ Create Custom Ticket Systems for Amazon DevOps Guru Notifications ](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [ Enable Multi-Account Insight Aggregation with Amazon DevOps Guru ](https://www.youtube.com/watch?v=MHezNcTSTbI)
**Zugehörige Beispiele:**
+ [ Workshop zu Amazon CloudWatch und Systems Manager ](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)
# REL06-BP05 Analysieren von Protokollen
Erfassen Sie Protokolldateien und Metrikverläufe und analysieren Sie diese, um allgemeine Trends zu erkennen und Workload-Einblicke zu erhalten.
Amazon CloudWatch Logs Insights unterstützt eine [einfache, aber leistungsstarke Abfragesprache](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html), mit der Sie Protokolldaten analysieren können. Amazon CloudWatch Logs unterstützt auch Abonnements, mit denen Daten nahtlos zu Amazon S3 fließen können, wo Sie sie nutzen oder Amazon Athena verwenden können, um die Daten abzufragen. Abfragen für eine große Auswahl von Formaten werden ebenfalls unterstützt. Unter [Supported SerDes and Data Formats](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) im Amazon Athena-Benutzerhandbuch finden Sie weitere Informationen dazu. Für die Analyse riesiger Protokolldateisätze können Sie einen Amazon EMR-Cluster ausführen, um Analysen im Petabyte-Bereich auszuführen.
Es gibt es eine Reihe von Werkzeugen von AWS-Partnern und externen Anbietern, die Aggregierung, Verarbeitung, Speicherung und Analyse ermöglichen. Dazu gehören u. a. die Tools New Relic, Splunk, Loggly, Logstash, CloudHealth und Nagios. Die Generierung außerhalb von System- und Anwendungsprotokollen weicht jedoch bei jedem Cloud-Anbieter und häufig sogar bei den einzelnen Services ab.
Ein häufig übersehener Teil des Überwachungsprozesses ist die Datenverwaltung. Sie müssen Aufbewahrungsanforderungen für die Überwachung von Daten definieren und anschließend entsprechende Lebenszyklusrichtlinien anwenden. Amazon S3 unterstützt die Lebenszyklusverwaltung auf der Ebene von S3-Buckets. Diese Lebenszyklusverwaltung kann auf unterschiedliche Weise auf verschiedene Pfade im Bucket angewendet werden. Gegen Ende des Lebenszyklus können Sie die Daten zur Langzeitspeicherung an Amazon Glacier übertragen und die Speicherung nach Ablauf des Aufbewahrungszeitraums beenden. Die S3 Intelligent-Tiering-Speicherklasse wurde entwickelt, um die Kosten zu optimieren. Daten werden automatisch in die kostengünstigste Zugriffsstufe verschoben, ohne Auswirkungen auf die Leistung oder höheren Betriebsaufwand.
**Risikostufe bei fehlender Befolgung dieser bewährten Methode:** Mittel
## Implementierungsleitfaden
+ Mit CloudWatch Logs Insights können Sie Protokolldaten in Amazon CloudWatch Logs interaktiv durchsuchen und analysieren.
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Senden Sie mit Amazon CloudWatch Logs Protokolle an Amazon S3. Dort können Sie die Daten mit Amazon Athena abfragen.
+ [Wie verwende ich Amazon Athena, um meine Amazon-S3-Serverzugriffsprotokolle zu analysieren?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ Erstellen Sie eine S3-Lebenszyklusrichtlinie für Ihren Bucket mit den Serverzugriffsprotokollen. Konfigurieren Sie die Richtlinie so, dass Protokolldateien regelmäßig entfernt werden. Dadurch wird die Menge der Daten reduziert, die Athena in einer Abfrage analysiert.
+ [How Do I Create a Lifecycle Policy for an S3 Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## Ressourcen
**Zugehörige Dokumente:**
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [How Do I Create a Lifecycle Policy for an S3 Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Wie verwende ich Amazon Athena, um meine Amazon-S3-Serverzugriffsprotokolle zu analysieren?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/)
+ [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 Regelmäßiges Durchführen von Prüfungen von Umfang und Metriken
Prüfen Sie häufig, wie die Workload-Überwachung implementiert ist, und aktualisieren Sie sie, wenn sich Ihre Workloads und ihre Architektur weiterentwickeln. Regelmäßige Prüfungen Ihrer Überwachung tragen dazu bei, das Risiko zu verringern, dass Fehlerindikatoren übersehen werden. Sie helfen außerdem Ihrem Workload, die Verfügbarkeitsziele zu erreichen.
Eine effektive Überwachung ist in wichtigen Geschäftsmetriken verankert, die entsprechend neuen Geschäftsprioritäten geändert werden. Ihr Monitoring-Überprüfungsprozess sollte den Schwerpunkt auf Service-Level-Indikatoren (SLIs) legen und Erkenntnisse aus Infrastruktur, Anwendungen, Clients und Benutzern einbeziehen.
**Gewünschtes Ergebnis:** Sie verfügen über eine effektive Überwachungsstrategie, die regelmäßig überprüft und in regelmäßigen Abständen sowie nach allen wichtigen Ereignissen oder Änderungen aktualisiert wird. Sie stellen sicher, dass die wichtigsten Indikatoren für den Zustand Ihrer Anwendungen relevant bleiben, wenn sich Ihre Workloads und Ihre Geschäftsanforderungen weiterentwickeln.
**Typische Anti-Muster:**
+ Sie erfassen nur Standardmetriken.
+ Sie richten eine Überwachungsstrategie ein, überprüfen sie aber nie.
+ Bei der Bereitstellung größerer Änderungen wird die Überwachung nicht berücksichtigt.
+ Sie vertrauen veralteten Metriken, um den Zustand eines Workloads zu bestimmen.
+ Ihre operativen Teams werden aufgrund veralteter Metriken und Schwellenwerte mit Fehlalarmen überlastet.
+ Ihnen fehlt die Beobachtbarkeit von Anwendungskomponenten, die nicht überwacht werden.
+ Sie konzentrieren sich bei der Überwachung nur auf technische Metriken auf untergeordneter Ebene und schließen geschäftliche Metriken aus.
**Vorteile der Nutzung dieser bewährten Methode:** Wenn Sie die Überwachung regelmäßig überprüfen, können Sie potenzielle Probleme antizipieren und sicherstellen, dass Sie diese erkennen. Außerdem können Sie so blinde Flecken aufdecken, die Sie bei früheren Überprüfungen möglicherweise übersehen haben, was Ihre Fähigkeit, Probleme zu erkennen, weiter verbessert.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: **Mittel
## Implementierungsleitfaden
Überprüfen Sie Metriken und Umfang der Überwachung im Rahmen Ihrer [Operational Readiness Review, ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Führen Sie regelmäßige Prüfungen der operativen Bereitschaft nach einem konsistenten Zeitplan durch, um festzustellen, ob zwischen Ihren aktuellen Workloads und der von Ihnen konfigurierten Überwachung Lücken bestehen. Der Aufbau einer Struktur mit regelmäßigen Überprüfungen der operativen Leistung und einem Wissensaustausch verbessert Ihre Fähigkeit, höhere Leistungen bei Ihren operativen Teams zu erzielen. Prüfen Sie, ob die vorhandenen Schwellenwerte für Warnmeldungen immer noch ausreichend sind, und prüfen Sie, ob operative Teams falsch-positive Warnmeldungen erhalten oder Aspekte der Anwendung, die überwacht werden sollten, nicht überwachen.
Das [Framework für die Resilienzanalyse](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html) bietet nützliche Hinweise, die Ihnen bei der Steuerung des Prozesses helfen können. Der Schwerpunkt des Frameworks liegt auf der Identifizierung potenzieller Arten von Ausfällen und der präventiven und korrigierenden Maßnahmen, mit denen Sie ihre Auswirkungen abmildern können. Dieses Wissen kann Ihnen helfen, die richtigen Metriken und Ereignisse zu identifizieren, die Sie überwachen und bei denen Sie gewarnt werden sollten.
### Implementierungsschritte
1. Planen und prüfen Sie die Workload-Dashboards regelmäßig. Was die Gründlichkeit der Untersuchungen angeht, sind unterschiedliche Intervalle denkbar.
1. Spüren Sie Trends in den Metriken auf. Vergleichen Sie die Metrikwerte mit Werten aus der Vergangenheit, um Trends zu erkennen, die darauf hinweisen könnten, dass etwas untersucht werden muss. Beispiele hierfür sind: zunehmende Latenz, Nachlassen der primären Geschäftsfunktion und zunehmende Anzahl von Reaktionen auf Fehler.
1. Suchen Sie in Ihren Metriken nach Ausreißern und Anomalien, die durch Durchschnitts- oder Medianwerte maskiert sein können. Sehen Sie sich die höchsten und niedrigsten Werte in einem bestimmten Zeitraum an und untersuchen Sie die Ursachen für Beobachtungen, die weit außerhalb der normalen Grenzen liegen. Beseitigen Sie nach und nach die Ursachen und legen Sie dabei einen immer engeren Maßstab für die erwarteten Metriken an, um auf die verbesserte Konsistenz der Workload-Leistung zu reagieren.
1. Spüren Sie plötzliche Änderungen im Verhalten auf. Eine plötzliche Veränderung in der Menge oder Richtung einer Metrik kann auf eine Änderung in der Anwendung hindeuten. Sie kann aber auch ein Hinweis auf externe Faktoren sein, für deren Verfolgung sie möglicherweise weitere Metriken hinzufügen müssen.
1. Prüfen Sie, ob die aktuelle Überwachungsstrategie für die Anwendung weiterhin relevant ist. Beurteilen Sie auf der Grundlage einer Analyse früherer Vorfälle (oder des Frameworks für die Resilienzanalyse), ob es weitere Aspekte der Anwendung gibt, die in den Überwachungsumfang aufgenommen werden sollten.
1. Überprüfen Sie Ihre RUM-Metriken (Real User Monitoring), um festzustellen, ob es Lücken bei der Abdeckung der Anwendungsfunktionen gibt.
1. Prüfen Sie Ihren Änderungsmanagementprozess. Aktualisieren Sie Ihre Verfahren bei Bedarf um einen Schritt zur Überwachung und Analyse, der durchgeführt werden sollte, bevor Sie eine Änderung genehmigen.
1. Implementieren Sie die Überprüfung der Überwachung als Teil Ihrer Prozesse zur Überprüfung der operativen Bereitschaft und zur Korrektur von Fehlern.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL06-BP01 Überwachen aller Komponenten des Workloads (Generierung)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP02 Definieren und Berechnen von Metriken (Aggregierung)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_aggregation.html)
+ [REL06-BP07 Überwachen der gesamten Nachverfolgung von Anfragen im System](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
+ [REL12-BP02 Durchführen von Analysen nach Vorfällen](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_rca_resiliency.html)
+ [REL12-BP06 Regelmäßiges Durchführen von Gamedays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html)
**Zugehörige Dokumente:**
+ [Warum sollten Sie eine Fehlerkorrektur (Correction of Error,CoE) entwickeln)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
+ [Amazon CloudWatch Dashboards verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Erstellen von Dashboards für operative Sichtbarkeit](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/?did=ba_card&trk=ba_card)
+ [Erweiterte Multi-AZ-Resilienzmuster – Graue Ausfälle](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
+ [Amazon CloudWatch Logs Insights Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Debuggen mit Amazon CloudWatch Synthetics und AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Workshop zur Beobachtbarkeit](https://observability.workshop.aws/)
+ [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [AWS Bewährte Methoden zur Beobachtbarkeit für](https://aws-observability.github.io/observability-best-practices/)
+ [Framework für Resilienzanalyse](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)
+ [Framework für die Resilienzanalyse – Beobachtbarkeit](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/observability.html)
+ [Überprüfen der operativen Bereitschaft – ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
# REL06-BP07 Überwachen der gesamten Nachverfolgung von Anfragen im System
Verfolgen Sie Anfragen während der Bearbeitung durch die Servicekomponenten, damit Produktteams Probleme einfacher analysieren und beheben und die Leistung verbessern können.
**Gewünschtes Ergebnis:** Workloads mit umfassender Nachverfolgung über alle Komponenten hinweg lassen sich leicht debuggen und verbessern so die [durchschnittliche Zeit für die Behebung](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) (MTTR) von Fehlern und Latenz durch eine vereinfachte Ursachenerkennung. Die durchgängige Nachverfolgung reduziert die Zeit, die benötigt wird, um betroffene Komponenten zu erkennen und die Ursachen von Fehlern oder Latenzen genau zu ermitteln.
**Typische Anti-Muster:**
+ Nachverfolgung wird für einige Komponenten verwendet, aber nicht für alle. Ohne Nachverfolgung in AWS Lambda können Teams beispielsweise die durch Kaltstarts bei hohen Workloads verursachte Latenz nicht genau nachvollziehen.
+ Synthetische Canaries oder Real-User Monitoring (RUM) sind nicht für Nachverfolgung konfiguriert. Ohne Canaries oder RUM wird die Telemetrie der Client-Interaktion in der Spurenanalyse ausgelassen, was zu einem unvollständigen Leistungsprofil führt.
+ Hybride Workloads umfassen sowohl cloudnative Nachverfolgungs-Tools als auch Tools von Drittanbietern, es wurden jedoch keine Schritte unternommen, um eine einzige Nachverfolgungs-Lösung auszuwählen und vollständig zu integrieren. Basierend auf der gewählten Nachverfolgungs-Lösung sollten cloudnative Nachverfolgungs-SDKs verwendet werden, um Komponenten zu instrumentieren, die nicht cloudnativ sind. Oder Tools von Drittanbietern sollten so konfiguriert werden, dass sie cloudnative Nachverfolgungstelemetrie aufnehmen.
**Vorteile der Nutzung dieser bewährten Methode:** Wenn Entwicklungsteams über Probleme informiert werden, können sie sich ein vollständiges Bild der Interaktionen zwischen den Systemkomponenten machen, einschließlich der Beziehung zwischen Komponenten, Protokollierung, Leistung und Ausfällen. Da die Nachverfolgung die visuelle Identifizierung der Ursachen erleichtert, können diese schneller untersucht werden. Teams, die die Interaktionen der Komponenten im Detail verstehen, treffen bessere und schnellere Entscheidungen bei der Lösung von Problemen. Entscheidungen, z. B. wann ein Notfallwiederherstellung (DR)-Failover eingeleitet werden sollte oder wo Strategien zur Selbstreparatur am besten implementiert werden sollten, können durch die Analyse von Systemprotokollen verbessert werden, was letztlich die Kundenzufriedenheit mit Ihren Services erhöht.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Mittel
## Implementierungsleitfaden
Teams, die verteilte Anwendungen betreiben, können mithilfe von Nachverfolgungs-Tools eine Korrelationskennung einrichten, Spuren von Anfragen erfassen und Service-Maps für verbundene Komponenten erstellen. Alle Anwendungskomponenten sollten in den Anforderungsspuren enthalten sein, einschließlich Service-Clients, Middleware-Gateways und Event Busse, Rechenkomponenten und Speicher, einschließlich Schlüssel-Wert-Speicher und -Datenbanken. Integrieren Sie synthetische Canaries und Real-User Monitoring in Ihre Konfiguration für die gesamte Nachverfolgung, um die Interaktionen und Latenz von Remote-Clients zu messen, sodass Sie die Leistung Ihres Systems anhand Ihrer Service Level Agreements und Ziele genau bewerten können.
Nutzen Sie Instrumentierungsservices wie [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) und [Amazon CloudWatch-Anwendungsüberwachung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html), um einen vollständigen Überblick über die Anfragen zu erhalten, die in Ihrer Anwendung verarbeitet werden. X-Ray erfasst Anwendungstelemetrie und ermöglicht es Ihnen, diese nach Payloads, Funktionen, Spuren, Services und APIs zu visualisieren und zu filtern. Sie kann für Systemkomponenten aktiviert werden, bei denen kein Code oder Low-Code verwendet wird. Die CloudWatch-Anwendungsüberwachung umfasst ServiceLens, um Ihre Spuren in Metriken, Protokollen und Alarmen zu integrieren. Die CloudWatch-Anwendungsüberwachung umfasst auch synthetische Funktionen zur Überwachung Ihrer Endpunkte und APIs sowie Real-User Monitoring zur Instrumentierung Ihrer Webanwendungsclients.
## Implementierungsschritte
+ Verwenden Sie AWS X-Ray X-Ray auf allen unterstützten nativen Services wie [Amazon S3, AWS Lambda und Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html). Diese AWS-Services ermöglichen X-Ray mit Konfigurationsschaltern unter Verwendung von Infrastruktur als Code, AWS SDKs oder der AWS-Managementkonsole.
+ Instrumentenanwendungen [AWS Distro for Open Telemetry und X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) oder Erfassungs-Agenten von Drittanbietern.
+ Im [AWS X-Ray-Entwicklerhandbuch](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) finden Sie weitere Informationen für die programmiersprachenspezifische Implementierung. In diesen Dokumentationsabschnitten wird detailliert beschrieben, wie HTTP-Anfragen, SQL-Abfragen und andere Prozesse, die für Ihre Anwendungsprogrammiersprache spezifisch sind, instrumentiert werden.
+ Verwenden Sie X-Ray-Nachverfolgung für [Amazon CloudWatch synthetische Canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) und [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html), um den Anforderungspfad von Ihrem Endbenutzer-Client durch Ihre AWS-Infrastruktur zu analysieren.
+ Konfigurieren Sie CloudWatch-Metriken und -Alarme auf der Grundlage des Ressourcenzustands und der Canary-Telemetrie, sodass Teams schnell über Probleme informiert werden und dann mit ServiceLens Spuren und Servicemaps eingehend untersuchen können.
+ Aktivieren Sie die X-Ray-Integration für Nachverfolgungs-Tools von Drittanbietern wie [Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/), [New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/) oder [Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics), wenn Sie Tools von Drittanbietern als primäre Nachverfolgungslösung verwenden.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL06-BP01 Überwachen aller Komponenten der Workload (Generierung)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL11-BP01 Überwachen aller Komponenten der Workload auf Fehler](rel_withstand_component_failures_monitoring_health.md)
**Zugehörige Dokumente:**
+ [Was ist AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Amazon CloudWatch-Anwendungsüberwachung ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)
+ [Debugging with Amazon CloudWatch Synthetics and AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Die Amazon Builders' Library: Verteilte Systeme instrumentieren, um betriebliche Transparenz zu erzielen](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [ Integrating AWS X-Ray with other AWS services ](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry und AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [ Amazon CloudWatch: Using synthetic monitoring ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [ Amazon CloudWatch: Use CloudWatch RUM ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Set up Amazon CloudWatch synthetics canary and Amazon CloudWatch alarm ](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [Verfügbarkeit und mehr: Verdeutlichung und Verbesserung der Ausfallsicherheit bei verteilten Systemen in AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
**Zugehörige Beispiele:**
+ [ Workshop zur Beobachtbarkeit ](https://catalog.workshops.aws/observability/en-US)
**Zugehörige Videos:**
+ [AWS re:Invent 2.022 - How to monitor applications across multiple accounts ](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [ How to Monitor your AWS Applications ](https://www.youtube.com/watch?v=UxWU9mrSbmA)
**Zugehörige Tools:**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/pm/cloudwatch/)
+ [ Amazon Route 53 ](https://aws.amazon.com/route53/)