Amazon DOP-C02: Monitoring, Protokollierung und Beobachtbarkeit — Lernleitfaden

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Teil des AWS DevOps Engineer Professional DOP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Überwachung, Protokollierung und Observability auf AWS erfordern die Kombination von Metriken, Protokollen, Traces, Ereignissen und Zustands-Telemetrie zu handlungsrelevanten Signalen. Effektive Architekturen nutzen Amazon CloudWatch für Metriken, Alarme und Dashboards, CloudWatch Logs und Logs Insights für die Protokoll-Ingestion und -Analyse, AWS X-Ray für verteiltes Tracing, AWS CloudTrail für Auditing und Integrität, Amazon EventBridge für ereignisgesteuerte Erkennung und Automatisierung, AWS Health für kontospezifische Service-Ereignisse und zentralisierte Pipelines (Kinesis Data Firehose und OpenSearch) für die Suche und Korrelation im großen Maßstab. Die folgenden Muster legen den Schwerpunkt auf Rauschreduzierung, präzises Signal-Routing, Automatisierung und konto- sowie regionsübergreifende Operationen.

CloudWatch Metrics, Alarms, Dashboards und Composite Alarms

CloudWatch-Metriken sind die Grundlage für SLOs, Skalierung und Alarmierung. Veröffentlichen Sie benutzerdefinierte Metriken mit feingranularen Dimensionen, um Signale zu isolieren (zum Beispiel apiOperation, appVersion, statusCode). Verwenden Sie das CloudWatch Embedded Metric Format (EMF) mit strukturierten Protokollen, um Dimensionen mit hoher Kardinalität effizient von Lambda, Containern und EC2 auszugeben und so den Overhead der PutMetricData-API zu vermeiden.

Konfigurieren Sie Alarme mit einer robusten Auswertung:

Wählen Sie Zeiträume, die auf die Datengranularität und SLO-Fenster abgestimmt sind.
Setzen Sie datapointsToAlarm (m aus n) für Resilienz gegen vorübergehendes Rauschen.
Verwenden Sie TreatMissingData, um Fehlalarme während Bereitstellungen oder Pausen zu vermeiden.
Nutzen Sie Anomalieerkennungsbänder, wenn Basislinien saisonal schwanken, und Metrik-Mathematik für abgeleitete Indikatoren (p95-Latenz, Fehlerprozentsätze, Sättigungsraten).
Fügen Sie Aktionen zu Alarmen hinzu: Benachrichtigung über SNS, Erstellung von OpsCenter OpsItems, Ausführung von SSM Automation oder Wiederherstellung von EC2-Instanzen. Skalierungsrichtlinien können Alarmzustände für Aktionen referenzieren, aber Composite Alarms können die Skalierung nicht direkt auslösen.

Composite Alarms reduzieren die Alarmmüdigkeit, indem sie mehrere zugrunde liegende Alarme mit UND/ODER-Logik kombinieren. Alarmieren Sie zum Beispiel nur dann, wenn die p95-Latenz hoch ist UND die 5xx-Rate einen Schwellenwert überschreitet UND die CPU-Sättigung anhält, um sich an den Auswirkungen für den Benutzer auszurichten. Composite Alarms akzeptieren Zustandsaktualisierungen von untergeordneten Alarmen über Regionen/Konten hinweg mittels kontoübergreifender Observability oder Metrik-Streams in ein zentrales Konto.

Dashboards visualisieren Schlüsselindikatoren über Dienste hinweg. Verwenden Sie Widgets für Metriken, Logs Insights-Abfrageergebnisse und den Alarmstatus. Standardisieren Sie Dashboard-Konventionen (Benennung, Zeitbereiche, SLO-Overlays) und nutzen Sie regions- und kontoübergreifende Ansichten mit dem CloudWatch Observability Access Manager (OAM). Für Ad-hoc-Korrelationen heften Sie Logs Insights- und X-Ray ServiceLens-Widgets nebeneinander mit Service-Map-Widgets und den Fehlerraten von Kinesis Firehose an.

CloudWatch Logs: Protokollgruppen, Metrikfilter, Abonnementfilter und Logs Insights

Strukturieren Sie Protokollgruppen pro Anwendung/Komponente und Lebenszyklusphase. Legen Sie explizite Aufbewahrungsrichtlinien fest (verlassen Sie sich nicht auf „Never Expire“) und aktivieren Sie bei Bedarf die KMS-Verschlüsselung. Verwenden Sie Ressourcenrichtlinien und feingranulares IAM, um Producer und Subscriber zu steuern. Stellen Sie bei der Ingestion mit hohem Durchsatz eine angemessene Gleichzeitigkeit der Protokoll-Streams und Batch-Verarbeitung sicher.

Metrikfilter wandeln Protokollmuster in Metriken um. Definieren Sie ein Filtermuster mit extrahierten Token (JSON oder durch Leerzeichen getrennt) und mappen Sie die Token auf Metrikdimensionen. Dies unterstützt Anwendungsfälle wie Metriken pro API, pro Version und pro Antwortcode, die direkt aus den Protokollen veröffentlicht werden, ohne die Producer zu ändern. Stellen Sie sicher, dass Einheiten und Standardwerte korrekt sind; bevorzugen Sie 1 pro Ereignis und leiten Sie Raten mittels Metrik-Mathematik ab. Verwenden Sie diese Metriken für SLO-Alarmierungen und Dashboards.

Abonnementfilter streamen Protokolle in nahezu Echtzeit an:

Kinesis Data Firehose zur Transformation und Lieferung an S3/OpenSearch.
Kinesis Data Streams für benutzerdefinierte Consumer.
Lambda für benutzerdefiniertes Routing, Schwärzung von PII oder ereignisgesteuerte Benachrichtigungen. Verwenden Sie ein CloudWatch Logs-Ziel (Destination) mit einer IAM-Rolle für kontoübergreifende Abonnements. Planen Sie Wiederholungsversuche und Backpressure ein; Lambda und Firehose bieten jeweils integrierte Wiederholungsversuche und DLQs/Fehler-S3-Buckets.

CloudWatch Logs Insights bietet interaktive, serverlose Abfragen über Protokolle. Zu den Kernoperatoren gehören fields, filter, parse, stats, sort, limit, dedup und bin für das Zeit-Bucketing. Parsen Sie JSON-Felder oder verwenden Sie Grok-ähnliches Parsing für Textprotokolle. Beispiele:

filter status >= 500 | stats count() by apiOperation, appVersion
parse @message /duration=(?<ms>\d+)/ | stats pct(@ms,95) by service Speichern Sie häufig verwendete Abfragen mit QueryDefinition zur Wiederverwendung im Team und betten Sie sie als Abfrage-Widgets in Dashboards ein. Für die Automatisierung planen Sie eine Lambda-Funktion über EventBridge, um StartQuery/GetQueryResults auszuführen und Zusammenfassungen in SNS oder OpsCenter zu veröffentlichen. Beschränken Sie den Abfragebereich auf bestimmte Protokollgruppen und Zeitfenster, um die Kosten zu kontrollieren.

AWS X-Ray: Tracing, Sampling-Regeln, Service-Maps und Annotationen

X-Ray erfasst verteilte Traces über Services hinweg, um Latenzverursacher und Fehlergrenzen zu finden. Instrumentieren Sie Services mit der AWS Distro for OpenTelemetry (ADOT) oder den X-Ray SDKs, propagieren Sie den Trace-Header (z. B. X-Amzn-Trace-Id) und führen Sie den X-Ray-Daemon/Agenten aus, wo er benötigt wird (ECS/EKS/EC2). Viele verwaltete Services integrieren sich nativ (API Gateway, ALB über Access-Logs-Proxying von Traces, Lambda mit aktivem Tracing, Step Functions über Subsegmente).

Sampling-Regeln steuern das Datenvolumen und die Signaltreue. Verwenden Sie einen zentralen Satz von Sampling-Regeln mit:

Einem festen Reservoir pro Sekunde für Basis-Traces pro Service.
Einem ratenbasierten Sampling-Prozentsatz, der mit dem Durchsatz skaliert.
Regelpriorität und Service/URL-Matching für kritische Pfade und Fehlerszenarien. Erhöhen Sie das Sampling bei Incidents und für Canary-Traffic, um die Observability sicherzustellen und gleichzeitig die Kosten zu verwalten.

Service-Maps visualisieren den Aufrufgraphen und zeigen Kanten mit Latenz, Fehlerraten und Drosselungsindikatoren. Führen Sie einen Drilldown in Traces durch, um Segmente und Subsegmente auf nachgelagerte Abhängigkeiten zu untersuchen. Verwenden Sie Annotationen (indizierte Schlüssel-Wert-Paare) für die Filterung mit hoher Kardinalität, wie z. B. customerTier, apiOperation, appVersion oder AWS-Request-IDs. Verwenden Sie Metadaten für ausführlichen, nicht indizierten Kontext, um ein Überlaufen des Indexes zu vermeiden. Kombinieren Sie X-Ray-Trace-Gruppen mit CloudWatch ServiceLens, um Protokolle, Metriken und Traces in einer einzigen Ansicht zu korrelieren. Erstellen Sie Filterausdrücke (z. B. annotation.appVersion = “2.3.1” and fault = true), um Regressionen zu isolieren und Trace-IDs für eine gezielte Protokollsuche zu exportieren.

Governance und Ereignisse: CloudTrail, EventBridge und AWS Health

CloudTrail zeichnet API-Aktivitäten für Governance und forensische Analysen auf. Aktivieren Sie einen Organization Trail über alle Konten und alle Regionen hinweg, liefern Sie ihn an einen zentralisierten S3-Bucket mit SSE-KMS, aktivieren Sie die Validierung von Protokolldateien und integrieren Sie ihn mit CloudWatch Logs für eine nahezu in Echtzeit erfolgende Erkennung. Unterscheiden Sie zwischen Ereignisklassen:

Management-Ereignisse: Steuerungsebene (Control Plane) (z. B. CreateUser, RunInstances). Konfigurieren Sie diese nach Bedarf so, dass sie schreibgeschützte und nur schreibende Vorgänge umfassen.
Datenereignisse: volumenintensive Operationen der Datenebene (Data Plane) wie S3-Objektzugriff, Lambda Invoke, DynamoDB-Item-APIs, EKS-API-Server-Aufrufe. Legen Sie den Geltungsbereich von Datenereignissen selektiv fest (nach Bucket/Funktion/Tabelle), um die Kosten zu kontrollieren. Verwenden Sie CloudTrail Insights, um ungewöhnliche API-Spitzen zu erkennen, und leiten Sie CloudTrail-Ereignisse zur automatischen Behebung an EventBridge weiter. Validieren Sie die Integrität der Protokolle während Audits mithilfe von Digest-Dateien und dem AWS CLI-Befehl cloudtrail validate-logs.

EventBridge stellt eine Event-Fabric für Erkennung und Automatisierung bereit. Verwenden Sie den Standard-Event-Bus für AWS-Service-Ereignisse und erstellen Sie benutzerdefinierte Busse für anwendungsdomänenspezifische Ereignisse. Definieren Sie Ereignismuster, die auf Quelle, detail-type, Detail-Felder, Präfixe, numerische Bereiche und „anything-but“ passen. Wenden Sie Input Transformers an, um Ereignisse umzuformen, fügen Sie ressourcenbasierte Richtlinien für kontoübergreifendes Veröffentlichen hinzu und konfigurieren Sie Wiederholungsversuche/DLQ für Ziele. Gängige Ziele sind Lambda (Behebung), Step Functions (Orchestrierung), SQS (Entkopplung), Systems Manager Automation (Betriebsaktionen), CodePipeline (CI-Trigger) und SNS (Benachrichtigungen). Archivieren und wiederholen Sie Ereignisse, um sich von Ausfällen bei Consumern zu erholen, und verwenden Sie die Schema-Registry, um stark typisierte Ereignismodelle zu generieren.

AWS Health macht kontospezifische Service-Ereignisse, geplante Änderungen und betriebliche Probleme sichtbar. Integrieren Sie über EventBridge mit der Quelle aws.health und dem detail-type AWS Health Event, um sie an Incident-Kanäle weiterzuleiten, OpsCenter OpsItems zu öffnen oder sichere Shutdown- oder Skalierungsaktionen für Wartungsfenster auszulösen. Verwenden Sie die Organizational View mit einem delegierten Administratorkonto, um Health-Ereignisse über alle Konten hinweg zu aggregieren, und ziehen Sie die AWS Health API oder die AWS Health Aware-Lösung in Betracht, um kuratierte Benachrichtigungen in Bereitschaftssysteme zu pushen.

Zentralisierte Protokollierung mit Kinesis Data Firehose und OpenSearch

Eine konten- und regionenübergreifende Protokollierungsstrategie standardisiert die Erfassung und Suche. Konfigurieren Sie in jedem Producer-Konto CloudWatch Logs-Abonnementfilter für ein kontoübergreifendes Logs-Ziel, das von einem zentralen Kinesis Data Firehose unterstützt wird. Aktivieren Sie die folgenden Firehose-Funktionen:

Datentransformation über Lambda zur Normalisierung (JSON), Schwärzung von personenbezogenen Daten (PII) und Anreicherung mit Metadaten wie AWS-Konto, Region, VPC und Service.
Komprimierung (GZIP) und dynamische Partitionierung bei der Bereitstellung in S3 zur Optimierung der Abfrageleistung in Athena.
Verschlüsselung mit KMS und Bereitstellung in einer VPC für private Endpunkte. Stellen Sie die Daten für eine Suche mit geringer Latenz und zur Visualisierung mit Kibana/OpenSearch Dashboards an den Amazon OpenSearch Service bereit. Verwenden Sie Indexvorlagen, ILM/ISM-Richtlinien für Rollover und Aufbewahrung sowie fein abgestufte Zugriffsrichtlinien, die Benutzer auf Indexmuster (z. B. Konto/Team/Service) abbilden. Konfigurieren Sie die Fehlerausgabe nach S3 für fehlgeschlagene Dokumente und überwachen Sie die Metriken für die Firehose-Bereitstellung und die OpenSearch-Erfassung (DeliveryToElasticsearch.Success, ElasticsearchFailedRequests). Bei sehr hohem Volumen sollten Sie erwägen, alle Protokolle über Firehose in S3 zu speichern und nur eine Teilmenge an OpenSearch zu streamen. On-Demand-Abfragen mit Athena über S3 können dann zur Kostenkontrolle für Long-Tail-Untersuchungen verwendet werden.

Kombinieren Sie diese Pipeline mit CloudWatch-Metrikfiltern für schnelle, kostengünstige Zähler und mit Logs Insights für Ad-hoc-Tiefenabfragen. Verwenden Sie EventBridge-Regeln, die durch Anomalien in Firehose/OpenSearch oder durch CloudWatch-Alarme ausgelöst werden, um Korrekturmaßnahmen einzuleiten oder Incidents zu erstellen.

Praktisches Problemszenario

Bei Airbnb treten sporadische Spitzen bei API-Fehlern und Latenzzeiten über Microservices hinweg auf, die auf EKS und Lambda bereitgestellt sind, während mehrere Versionen der mobilen App im Umlauf sind. Der Betrieb (Operations) benötigt eine Erkennung nahezu in Echtzeit nach API-Operation, Antwortcode und App-Version, eine schnelle Ursachenanalyse über Traces und Protokolle hinweg, eine automatisierte Behebung bekannter Fehlermuster und revisionssichere Audit-Trails.

Strukturiertes Logging standardisieren

Implementieren Sie EMF-strukturierte JSON-Protokolle in Services (EKS, Lambda), die Felder für apiOperation, statusCode, appVersion, tenantId und latencyMs enthalten.
Warum: EMF ermöglicht die direkte Extraktion von Metriken in CloudWatch mit geringem Overhead und Dimensionen mit hoher Kardinalität für präzise Alarme.

CloudWatch Logs-Metrikfilter erstellen

Definieren Sie für jede Service-Protokollgruppe Metrikfilter, die Zähler nach apiOperation, statusCode und appVersion erhöhen.
Warum: Erzeugt Metriken pro Dimension ohne zusätzliche Codepfade und ermöglicht so Dashboards und handlungsrelevante Alarme pro API und Client-Version.

Gestaffelte CloudWatch-Alarme und einen zusammengesetzten Alarm erstellen

Alarm bei p95-Latenz, 5xx-Rate und Sättigung (CPU, Arbeitsspeicher, Concurrency/Throttle). Erstellen Sie einen zusammengesetzten Alarm: LatencyHigh AND ErrorsHigh für 2 von 3 aufeinanderfolgenden Perioden.
Warum: Reduziert Störgeräusche (Noise) und konzentriert sich auf Vorfälle, die den Benutzer beeinträchtigen.

X-Ray-Tracing mit gezieltem Sampling bereitstellen

Verwenden Sie ADOT-Kollektoren auf EKS und aktives Tracing für Lambda. Definieren Sie Sampling-Regeln, um alle Fehler-Traces und eine repräsentative Stichprobe erfolgreicher Aufrufe zu erfassen, mit einem höheren Sampling bei neuen App-Versionen.
Warum: Garantiert Einblick in Fehler und eine ausreichende Abdeckung von Performance-Hotspots bei gleichzeitiger Kostenkontrolle.

Mit ServiceLens und Logs Insights korrelieren

Erstellen Sie Dashboards, die Metrik-Widgets, die X-Ray Service Map und Logs Insights-Abfragen (z. B.

undefined

) kombinieren.

Warum: Die Korrelation in einer einzigen Ansicht (Single-Pane) beschleunigt die Diagnose, bei welcher Operation und Client-Version eine Regression aufgetreten ist.

Protokolle über Firehose in OpenSearch und S3 zentralisieren

Konfigurieren Sie Abonnementfilter zu einem zentralen Firehose mit Lambda-Transformation zur Normalisierung, Schwärzung von PII und Anreicherung mit Konto/Region. Liefern Sie die Daten an OpenSearch für eine 7-tägige „Hot“-Suche und an S3 für eine dauerhafte Aufbewahrung und Athena-Abfragen.
Warum: Schnelle, teamübergreifende Suche nach aktuellen Problemen mit kostengünstiger historischer Analyse.

Erkennung und Behebung mit EventBridge automatisieren

Erstellen Sie EventBridge-Regeln für Zustandsänderungen von CloudWatch-Alarmen und ausgewählte CloudTrail-Schreib-API-Ereignisse (z. B. Änderungen an Sicherheitsgruppen). Ziele: Lambda für sichere Rollbacks (z. B. Zurücksetzen von Feature-Flags) und Step Functions für mehrstufige Korrekturmaßnahmen.
Warum: Ereignisgesteuerte Regelkreise (Control Loops) verkürzen die MTTR (Mean Time To Repair) und setzen Leitplanken (Guardrails) durch.

AWS Health und Wartungsmanagement integrieren

Fügen Sie EventBridge-Regeln für aws.health-Ereignisse hinzu, die EC2, EKS oder das Netzwerk betreffen. Ziel ist SSM Automation, um Knoten abzusperren und zu leeren (cordon/drain) oder den Datenverkehr zu verlagern.
Warum: Die proaktive Minderung geplanter oder betrieblicher Probleme reduziert Ausfallzeiten.

Governance mit CloudTrail Org-Trail und Integritätsprüfung härten

Aktivieren Sie einen organisationsweiten, multi-regionalen Trail mit Datenereignissen für S3 und Lambda, SSE-KMS-Verschlüsselung und Protokolldatei-Validierung. Streamen Sie die Daten zur Anomalieerkennung und für Untersuchungen an CloudWatch Logs und OpenSearch.
Warum: Ein vollständiger, manipulationssicherer Audit-Trail erfüllt Compliance-Anforderungen und beschleunigt die RCA (Root Cause Analysis).

Benachrichtigungen und Ops-Integration

Leiten Sie kritische Ereignisse an SNS und Bereitschaftssysteme weiter, öffnen Sie OpsCenter OpsItems mit angehängten Runbooks und fügen Sie Alarm-Tags für Zuständigkeit und Schweregrad hinzu.
Warum: Klare Zuständigkeiten und automatisierte Runbooks verbessern die Qualität und Geschwindigkeit der Reaktion.

Dieses Design wurde gewählt, um Metriken mit geringer Latenz und vielen Dimensionen (CloudWatch + EMF), tiefgehende Trace-Korrelation (X-Ray + ServiceLens), Suche im großen Maßstab (OpenSearch + S3/Athena), ereignisgesteuerte Problembehebung (EventBridge + Lambda/SSM/Step Functions) und auditierbare Governance (CloudTrail mit Integritätsprüfung) zu kombinieren. Es gleicht Kosten und Detailtreue durch Sampling, Aufbewahrungsstufen (Retention Tiers) und gezielte Alarme, die tatsächliche Auswirkungen auf die Benutzer widerspiegeln, aus.

← Infrastruktur als Code und Konfigurationsmanagement · Alle Domänen · Sicherheit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →