Distributed Tracing und X-Ray Service Maps

Prüfungsbezug: DOP-C02 Domain 4 — collection, analysis, detection, and automated monitoring.

Lernziel

Traces, Segments, Subsegments, Annotations, Metadata, Sampling, Latency und Fault Propagation mit sicherer Collection, actionable Detection, Correlation, Lifecycle Controls und gemessenen Kosten entwerfen, implementieren und troubleshooten.

Berufliches Szenario

Ein Production-Team besitzt nur teilweise Telemetrie für Traces, Segments, Subsegments, Annotations, Metadata, Sampling, Latency und Fault Propagation. Bei Incidents sind Signale inkonsistent, Zugriff unklar und Operatoren kommen nicht zuverlässig von Detection zu Diagnosis und Response.

Kernkonzepte

• Die Lektion fokussiert Traces, Segments, Subsegments, Annotations, Metadata, Sampling, Latency und Fault Propagation.
• Mit Operational- oder User-Frage beginnen, nicht mit AWS Service.
• Telemetry Identity, Fields, Dimensions, Time und Correlation sind konsistent.
• Collection Pipelines benötigen Permissions, Encryption, Buffering, Retention, Failure Monitoring und Cleanup.
• Detection benötigt getestete Thresholds/Modelle, Owner, Kontext und Response Action.
• Monitoring Configuration wird versioniert und als Code deployt.

Architektur-Schrittfolge

1. Service Outcome und Failure Condition definieren.
2. Metrics, Logs, Traces oder Events wählen.
3. Source Identity, Dimensions, Fields und Correlation definieren.
4. Collection, Encryption, Retention und Least Privilege konfigurieren.
5. Dashboards, Queries, Alarms oder Automation erstellen.
6. Normal-, Failure- und Missing-Data-Fälle erzeugen.
7. Alert Quality, Query Speed, Coverage und Kosten messen.

Entscheidungshilfe

Anforderung	Bevorzugte Richtung	Warum
Bekannte numerische Bedingung	Metric und Alarm	Schnelle Continuous Evaluation
Detailuntersuchung	Structured Logs und Queries	Reicher Event Context
Distributed Request Path	Trace mit Context Propagation	Dependencies und Latency
AWS Configuration Change	CloudTrail und AWS Config	API Activity und resultierender State

Fehlerbilder und Fehlersuche

• Producer und Consumer nutzen unterschiedliche Dimensions/Fields.
• KMS, IAM, Resource Policy oder Destination Permissions blockieren Delivery.
• High-Cardinality Attributes erzeugen Kosten-/Query-Probleme.
• Missing Data wird falsch interpretiert.
• Dashboard/Alarm existiert, aber Action/Notification wurde nie getestet.

Sicherheit, Datenschutz und Betrieb

• Secrets, Credentials, Tokens und prohibited personenbezogene Daten vor Ingestion ausschließen.
• Telemetry Writer, Reader, Administrator und Security Auditor trennen.
• Central Archives, KMS Keys, Subscriptions und Alarm Actions schützen.
• Retention-, Encryption-, Destination- und Rule-Changes auditieren.

Praxislabor

Ziel: Ein kontrolliertes Beispiel für dieses Thema bauen und validieren.

Aufgaben

1. Operational Question und erwartete Response schreiben.
2. Telemetry Path von Source zu Storage, Query, Alarm und Action zeichnen.
3. Minimale Implementierung oder detaillierte Config.
4. Controlled Delivery-/Detection-Failure einführen.
5. Erste fehlerhafte Komponente diagnostizieren.
6. Kosten, Retention, Security und Cleanup dokumentieren.

Validierung

• Signal beantwortet die Operational Question.
• Delivery Failure ist erkennbar.
• Keine sensitive/unbounded Attributes.
• Response Path ist getestet.

Kostenkontrolle: Synthetic Data und kleinen Scope verwenden. Test-Alarme, Logs, Streams, Indexes, Functions und Dashboards löschen.

Prüfungsfallen

• Jedes Signal ohne Frage sammeln.
• CPU als Universal Health-/Scaling-Metric.
• Metric Filter, Subscription Filter und Logs Insights verwechseln.
• Encryption verhindert jede Löschung/Administration.
• Centralization ohne Account-/Region-Coverage.

Wichtigste Erkenntnisse

• Traces, Segments, Subsegments, Annotations, Metadata, Sampling, Latency und Fault Propagation.
• Telemetrie muss sicher, korreliert, actionable und kostenkontrolliert sein.
• Monitoring selbst benötigt Monitoring und Tests.

Wiederholungsfragen

1. Welche Operational Question wird beantwortet?
2. Welches Telemetry Signal ist primär?
3. Welche Identity-/Correlation-Fields?
4. Welche Permission Layers wirken?
5. Was ist Retention-/Cost-Modell?
6. Was bedeutet Missing Data?
7. Welche Action folgt Detection?
8. Wie wird Design getestet?

Antworten

1. Explizite User-, Service-, Audit- oder Operational-Bedingung.
2. Signal, das die Bedingung direkt erkennt oder erklärt.
3. Service, Environment, Version, Time, Request/Trace Context und sichere Resource Identity.
4. IAM, Resource Policies, KMS Policies, Destination Permissions und Organizations Controls.
5. Dokumentierter Lifecycle passend zu Investigation, Compliance und Budget.
6. Abhängig davon, ob Signal kontinuierlich erwartet oder nur bei Events emittiert wird.
7. Notification, Runbook, Ticket, Scaling, Recovery oder kontrollierte Automation.
8. Mit Synthetic Normal-, Failure-, Missing-Data-, Permission- und Delivery-Tests.