Freitagabend klickt ein Kunde auf „Bezahlen“. Die Anfrage durchläuft Nginx, die Checkout-API, den Inventardienst in gRPC, Redis, PostgreSQL und dann einen asynchronen Webhook-Job. Der Support erhält „Timeout“. API-Protokolle zeigen „Upstream-Zeitüberschreitung“; Inventarprotokolle, nichts Ungewöhnliches im Volumen. Allerdings erklärt ein einziger langsamer gRPC-Aufruf – der im Durchschnitt untergeht – die Wartezeit. Ohne eine einheitliche Spur sieht es niemand.
Sobald eine Aktion zwei oder mehr Bausteine überschreitet, wird die Diagnose fragmentiert. Die verteilte Ablaufverfolgung fügt der ursprünglichen Anfrage eine trace_id hinzu und zeichnet jedes Segment (Span) auf: Dauer, Dienst, Fehler. Sie sehen den ganzen Baum, nicht einzelne Blätter. Die eigentliche Frage: Wissen Sie, wie man den Thread rekonstruiert, den ein Benutzer als einzelne Aktion erlebt?
Traces, Protokolle und Metriken: drei Säulen, nicht drei Ersatzstoffe
Prometheus meldet einen doppelten p95 auf „/api/checkout“ – siehe Prometheus: Metriken auswählen, die Langsamkeit erklären. Die zentralisierten Protokolle zeigen zu einem bestimmten Zeitpunkt einen Stack-Trace an. Weder verknüpft das Nginx-Timeout mit der langsamen SQL-Abfrage im Katalog noch mit dem Webhook-Job ohne Kontext.
| Säule | Was es verrät | Typischer Grenzwert |
|---|---|---|
| Metriken | Trends, Warnungen, Einhaltung von SLOs | Aggregat – ein seltener Fall verschwindet im p95 |
| Protokolle | Textkontext, Einstellungen, Fehler | Ein Silo pro Abteilung, manuelle Korrelation |
| Spuren | Vollständiger Pfad einer Abfrage | Lagerkosten bei schlechter Probenahme |
Um die Spuren zu beseitigen, muss man raten, wo der Weg gebrochen ist – die Art von Blindheit, die Alarmmüdigkeit fördert.
Span-, Trace- und Kontextweitergabe
Ein Trace stellt den gesamten Verlauf einer Benutzeraktion dar – zum Beispiel „checkout-abc123“. Ein span ist eine Einheitsoperation innerhalb dieser Reise: ein HTTP GET „/stock“-Aufruf, eine SQL SELECT-Abfrage, eine Redis-Veröffentlichung. Jeder Span zeichnet seine Dauer, seinen Status und den Dienst auf, der ihn ausgeführt hat.
Kontextausbreitung ist die häufigste Schwachstelle. Die Trace-ID muss vom Reverse-Proxy über W3C-HTTP-Header („traceparent“, „tracestate“), gRPC-Metadaten oder die in der Warteschlange befindliche Jobnutzlast zu den asynchronen Workern übertragen werden. Ohne diese Übertragung erstellt der Worker einen verwaisten Trace, der nichts mit der ursprünglichen Anfrage zu tun hat – und die Hälfte der Geschichte verschwindet bei der ersten verzögerten Verarbeitung.
| Komponente | Aktuelle Instrumentierung |
|---|---|
| Nginx | OpenTelemetry-Modul oder Service-Mesh-Eingang |
| PHP/Laravel | open-telemetry/opentelemetry-php-Bibliothek |
| Go/Java | ausgereifte native Kits, einfache Integration |
| Warteschlangenarbeiter | Extraktion des Kontexts aus der Jobnachricht |
Die Instrumentierung des Reverse-Proxys ohne die Instrumentierung der Anwendung bedeutet, die Ein- und Ausgabe zu sehen – nicht, was dazwischen passiert.
OpenTelemetry, Jaeger und Tempo: Wählen Sie Ihren Stack
OpenTelemetry (OTel) sammelt Spuren, Metriken und Protokolle mit einzigartiger Instrumentierung. Export nach Jaeger (eigenständige Schnittstelle), Grafana Tempo (Objektspeicher, Loki/Prometheus-Korrelation) oder einen verwalteten Dienst. Auf einem bescheidenen VPS vermeidet ein OTel Collector-Agent für Tempo Cloud oder Grafana Cloud das Hosten von Jaeger und Elasticsearch selbst.
Sampling: Verfolgen Sie nicht den gesamten Datenverkehr
Die Verfolgung jeder Abfrage in der Produktion erzeugt eine Datenmenge, die schwer zu speichern und abzufragen ist. Es dominieren zwei Strategien.
Head-Sampling entscheidet über die Eingabe (z. B. eine von hundert Abfragen) – einfach, aber ein seltener Fall kann dem Netz entgehen. Tail Sampling behält langsame oder fehlerhafte Pfade systematisch bei; Grafana Tempo zeichnet sich bei diesem Modell aus. Konfigurieren Sie diese Regeln vor einer Spitzenlast, nicht während des Vorfalls.
Protokolle und Traces korrelieren: Schließen Sie die Schleife
Fügen Sie die „trace_id“ in Ihre JSON-Protokolle ein („trace_id“: „abc123…“`). In Grafana öffnet ein Klick aus einem langsamen Span das Protokoll mit dem Stack-Trace. Vorfallverfahren: p95-Alarm → langsamster Trace → fehlerhafter SQL-Span → genaue Abfrage im Protokoll. Schließen Sie sensible Daten (E-Mail, Karte, Patienten-ID) von Span-Attributen aus.
Häufige Einschränkungen und Fallstricke
Spannen zu granular → Überlastung und unlesbare Schnittstelle. Uhren nicht synchron → inkonsistenter Baum (NTP erforderlich). Istio verfolgt HTTP zwischen Pods, nicht Ihre SQL-Abfragen ohne Anwendungsinstrumentierung. „Jaeger installiert“ ≠ „langsamer Checkout diagnostizierbar“: Beginnen Sie mit den Routen, die Zahlen generieren.
Der Gipfel: drei Dashboards, null Storys
Folgendes wird bei „beobachtbaren“ Stacks, die schlüsselfertig verkauft werden, oft übersehen.
Entscheide dich und gehe ohne blinden Fleck voran
Machen Sie in ein bis zwei Tagen eine Multi-Service-Architektur diagnostizierbar. Identifizieren Sie zunächst einen kritischen Pfad – Checkout, Login, Partner-API – und instrumentieren Sie ihn als Priorität. Stellen Sie OpenTelemetry für den Reverse-Proxy, die Anwendung und die Worker bereit und überprüfen Sie dann, ob der Kontext die asynchronen Warteschlangen durchläuft. Konfigurieren Sie Tail Sampling, um fehlerhafte Traces und solche oberhalb Ihres Latenzschwellenwerts beizubehalten. Fügen Sie die „trace_id“ in die JSON-Protokolle ein und testen Sie die Span → Protokollnavigation. Simulieren Sie eine absichtlich langsame Anfrage: Wenn sie nicht in einer End-to-End-Ablaufverfolgung erscheint, korrigieren Sie die Ausbreitung vor dem nächsten Vorfall.
Vergleichen Sie die Hosts, auf denen Sie Ihre eigenen Agenten installieren können, über das Verzeichnis und den Vergleich. Wenn Prometheus eine Verschlechterung zeigt, ohne die fehlerhafte Ebene zu lokalisieren, lesen Sie Prometheus: Auswahl von Metriken, die Langsamkeit erklären, bevor Sie ein Dashboard hinzufügen.
Häufig gestellte Fragen
Traces, Protokolle oder Metriken – was soll man wählen?
Die drei ergänzen sich, keines ersetzt das andere. Die Metriken werden im Laufe der Zeit aggregiert und liefern Warnungen; Protokolle beschreiben einen bestimmten Moment mit Textkontext; Traces verbinden Segmente derselben Benutzeranforderung über mehrere Dienste hinweg. Prometheus allein kann nicht sagen, welche SQL-Abfrage den Checkout blockiert hat – ein Trace zeigt es auf einen Blick.
Ist OpenTelemetry der zu übernehmende Standard?
Ja, es ist heute die nachhaltigste Wahl. OpenTelemetry bietet herstellerneutrale Instrumentierung mit Exportern zu Jaeger, Grafana Tempo, Datadog oder anderen Backends. Vermeiden Sie es, Ihre Anwendung an ein einziges proprietäres SDK zu binden: Sie werden wahrscheinlich die Visualisierungstools ändern, bevor Sie Ihren Code neu schreiben.
Wie kann der Kontext zwischen Diensten verbreitet werden?
Verwenden Sie die W3C-Header „traceparent“ und „tracestate“ vom Einstiegspunkt zu asynchronen Workern. Jeder Hop – Reverse-Proxy, gRPC-Aufruf, Nachrichtenwarteschlange – muss dieselbe Trace-ID übertragen. Ohne diese Weitergabe erstellt jeder Dienst einen isolierten verwaisten Trace, und Sie verlieren die Hälfte der Geschichte beim ersten zurückgestellten Auftrag.
Welche Bemusterung in der Produktion?
Für den normalen Verkehr reicht oft eine Kopfprobenahme von 1-10 % aus. Die Schwanzprobenahme – angeboten von Grafana Tempo – behält langsame oder fehlerhafte Spuren systematisch bei, wodurch Speicherkosten und Diagnosefähigkeit in Einklang gebracht werden. Konfigurieren Sie diese Regeln vor einer Spitzenlast, nicht während des Vorfalls.
Wenn ein Vorfall das nächste Mal drei Dienste ohne offensichtlichen Schuldigen betrifft, stellen Sie eine Frage: Können wir eine einzelne Anfrage durchgängig verfolgen? Wenn die Antwort „Nein“ lautet, kostet die fehlende Trace_ID mehr als ihre Instrumentierung.