X-Ray: Konzepte und Architektur

Überwachung und Fehlersuche in AWS

John Q. Martin

Principal Consultant

Die Herausforderung verteilter Systeme

Monolithische Anwendung

Linearer Ablauf, in einem Prozess enthalten
Einfach zu debuggen

Verteilte Anwendung

Eine Anfrage berührt mehrere Services, DBs, externe APIs
Wenn sie fehlschlägt: Welcher Service war die Ursache?

Ein großer Knoten aus vielen bunten Fäden, der zeigt, wie schwer sich eine einzelne Anfrage in einem verteilten System nachverfolgen lässt

Was ist AWS X-Ray?

X-Ray ist ein verteiltes Tracing‑Service, das:

Anfragen ende‑zu‑ende über Services nachverfolgt
Latenz misst und Fehler in jedem Schritt erkennt
Die Architektur als Service‑Map visualisiert

Beispiel für einen Anfragepfad:

Diagramm eines Anfragepfads durch mehrere Services in einem verteilten Trace

Fünf Kernfunktionen

Fünf Kernfunktionen von X-Ray: Request Tracing, Performanceanalyse, Fehlererkennung, Service-Map und Insights

Wie Tracing funktioniert

Ablauf des verteilten Tracings: Eine Anfrage erreicht Service A, der Service B und dann Service C aufruft; die Trace-ID wird im HTTP-Header weitergegeben; jeder Service sendet ein Segment mit derselben Trace-ID an den X-Ray-Daemon, der sie an X-Ray weiterleitet, wo sie zu einem vollständigen Trace zusammengeführt werden

Trace-ID und Header-Weitergabe

Trace-ID-Format:

X-Ray Trace-ID-Format mit Versionsnummer, Unix-Zeitstempel in Hex und eindeutiger Kennung

HTTP-Header:

X-Amzn-Trace-Id:
  Root=1-5e8c1234-...;
  Parent=abc123;
  Sampled=1

Root, Trace-ID, gleich über alle Services
Parent, Upstream-Segment-ID
Sampled, 0 oder 1, getraced oder übersprungen

Der X-Ray-Daemon

Was er macht:

Hört auf UDP-Port 2000
Empfängt Segmentdaten von deiner Anwendung
Puffert, bündelt und leitet an die X-Ray-API weiter
Entkoppelt deine App vom X-Ray-Service

Bereitstellung nach Umgebung:

Bereitstellung des X-Ray-Daemons je Umgebung: automatisch auf Lambda, als Service auf EC2 und als Sidecar auf ECS

Sampling

Standardregel:

Erste Anfrage pro Sekunde – immer getraced
5 % der übrigen Anfragen – gesampelt

Benutzerdefinierte Regelfelder:

fixed_target – Anfragen/Sek., die immer getraced werden
rate – Prozentsatz der übrigen Anfragen
priority – kleinere Zahl gewinnt

Beispielstrategie:

Rule 1 (priority 1):
  5xx errors -> 100% sampling

Rule 2 (priority 10):
  Normal traffic -> 5% sampling

Segmente

Was ein Segment erfasst:

Servicename
Start- und Endzeit
Trace-ID
Details zu HTTP-Request und -Response
AWS-Konto und Region

Segmentzustände:

Fünf X-Ray-Segmentzustände: in progress, ok, error, fault und throttle

Subsegmente

Zeitachsenvergleich: ohne Subsegmente ein einzelner 800-ms-Balken; mit Subsegmenten dieselben 800 ms aufgeteilt in DynamoDB 50 ms, PaymentService 400 ms als Engpass markiert und InventoryService 300 ms

Was Subsegmente leisten:

Feinere Zeitmessung innerhalb eines Segments
Verfolgen Downstream-Aufrufe
Machen aus 800 ms:
- DynamoDB.PutItem: 50 ms
- PaymentService-Aufruf: 400 ms
- InventoryService-Aufruf: 300 ms

Namespaces:

Drei Subsegment-Namespaces: aws für AWS-Aufrufe, remote für externe HTTP und local für eigenen Code

Annotations

Kerndaten:

Indexierte Key-Value-Paare – durchsuch- und filterbar
Limit: 50 indexierte pro Trace
Typen: string, number, boolean

Einsatz für:

user_id, order_id, environment
version, Feature-Flags, Fehlercodes

Filtersyntax:

annotation.user_id = "user-123"

annotation.environment = "production"
AND annotation.version = "1.2.3"

Metadata

Kerndaten:

Nicht indexiert – nicht durchsuch- oder filterbar
Keine Größenbeschränkung
Unterstützt beliebige JSON-Strukturen

Einsatz für:

Vollständige Request- und Response-Bodies
Fehlermeldungen und Stacktraces
Geschäftskontext (Bestellpositionen, Adressen)

Annotations vs. Metadata:

Vergleichstabelle: Annotations indexiert und durchsuchbar versus Metadata detailliert und nicht indexiert

Vollständige Tracestruktur

Vollständige Tracestruktur mit vier Segmenten; die externe Payment-API ist die langsamste Operation

Lektionszusammenfassung

X-Ray – verteiltes Tracing-Service für End‑to‑End‑Sichtbarkeit über Services
Tracing-Mechanismus – Trace-ID-Weitergabe via HTTP-Header, Segmente vom Daemon gesammelt, konfigurierbare Sampling-Regeln
Trace-Komponenten:
- Segmente – Arbeitsaufzeichnungen auf Serviceebene
- Subsegmente – feine Zeitmessung von Downstream-Operationen
- Annotations – indexierte Key-Value-Paare zum Filtern und Suchen
- Metadata – detaillierter Kontext, nicht indexiert

Lass uns üben!

Überwachung und Fehlersuche in AWS