MAISON CODE .
/ DevOps · OpenTelemetry · SRE · Monitoring · Backend

Beobachtbarkeit: Röntgensicht für verteilte Systeme

Warum Protokolle nicht ausreichen. Ein umfassender technischer Leitfaden zu OpenTelemetry, strukturierter Protokollierung und der SRE-Alarmierungsphilosophie (SLI/SLO).

AB
Alex B.
Beobachtbarkeit: Röntgensicht für verteilte Systeme

„Die Seite ist langsam.“

Dieses aus vier Wörtern bestehende Ticket ist der Fluch eines jeden Ingenieurteams. Langsam wo? Ist die Datenbank CPU-gesperrt? Ist das Mobilfunknetz instabil? Kommt es zu einer Zeitüberschreitung der Drittanbieter-Versand-API? Haben wir gestern fehlerhaften Code bereitgestellt?

Wenn Ihre Debugging-Strategie auf „console.log“ und der Überprüfung von Server-CPU-Diagrammen basiert, tappen Sie beim Debuggen im Dunkeln. Überwachung zeigt Ihnen an, dass das System defekt ist (rotes Dashboard). Beobachtbarkeit sagt Ihnen, warum es kaputt gegangen ist.

Bei Maison Code Paris betreiben wir hochfrequentierte Handelsplattformen, bei denen eine Minute Ausfallzeit Zehntausende Euro ausmacht. Wir raten nicht. Wir verwenden Code-Instrumentierung, um Röntgenblick in den verteilten Stapel zu erhalten.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Die drei Säulen der Beobachtbarkeit

Um ein komplexes System zu verstehen, benötigen Sie drei verschiedene Arten von Telemetriedaten:

  1. Protokolle: Diskrete Ereignisse. „Um 10:00:01 Uhr ist etwas passiert.“
  2. Metriken: Aggregierte Zahlen. „CPU war 5 Minuten lang 80 %.“
  3. Traces: Der Lebenszyklus einer Anfrage. „Benutzer hat auf die Schaltfläche -> API -> DB -> API -> UI geklickt.“

1. Protokolle: Strukturiert und durchsuchbar

Entwickler lieben „console.log(“Fehler Benutzer nicht gefunden ” + id)“. DevOps hassen es. In einem System, das 1.000 Protokolle pro Sekunde produziert, ist die Suche nach „Fehlerbenutzer“ langsam. Eine Analyse ist unmöglich. Sie können die „Fehlerrate pro Benutzer-ID“ nicht grafisch darstellen.

Die goldene Regel: Protokolle müssen strukturiertes JSON sein.

„json { „level“: „Fehler“, „message“: „Payment Gateway Timeout“, „timestamp“: „2025-10-23T14:00:00Z“, „service“: „checkout-api“, “Kontext”: { „userId“: „u_123“, „cartId“: „c_456“, „gateway“: „stripe“, „Latenz“: 5002 }, „traceId“: „a1b2c3d4e5f6“ } „

Jetzt können Sie in Tools wie Datadog oder ELK (Elasticsearch) Abfragen ausführen:

  • service:checkout-api @context.gateway:stripe @level:error
  • „Zeigen Sie mir ein Diagramm der Zahlungsfehler, gruppiert nach Gateway.“

2. Metriken: Der Puls

Metriken sind günstig zu speichern. Es sind nur Zahlen.

  • Zähler: „Gesamtanzahl der Anfragen“ (steigt).
  • Anzeigen: „Speichernutzung“ (geht nach oben und unten).
  • Histogramme: „Latenzverteilung“ (95 % der Anfragen < 200 ms).

Die Kardinalitätsfalle: Nachwuchsingenieure versuchen häufig, Metriken mit Daten hoher Kardinalität zu kennzeichnen. http_request_duration_seconds{user_id="u_123"}. Wenn Sie 1 Million Benutzer haben, erstellen Sie 1 Million Zeitreihen. Dies führt zum Absturz Ihres Prometheus-Servers oder zum Bankrott Ihres Datadog-Kontos. Regel: Metriken gelten für den Systemzustand. Protokolle/Ablaufverfolgungen dienen Benutzerspezifischen.

3. Nachverfolgung: Der Kontext

In einer Microservices- oder Headless-Architektur führt ein einzelner Benutzerklick zu Folgendem: CDN -> Edge-Funktion -> Knoten-API -> Datenbank -> Drittanbieter-API. Wenn die Anfrage 3 Sekunden dauert, lautet die Metrik „Latenz hoch“. Eine Spur zeigt Ihnen:

  • Knoten-API: 10 ms
  • Datenbank: 5 ms
  • Versand-API: 2900 ms

Rückverfolgung löst das „Blame Game“.

OpenTelemetry: Der Industriestandard

In der Vergangenheit mussten Sie das Datadog SDK oder das New Relic SDK installieren. Wenn Sie den Anbieter wechseln wollten, mussten Sie den Code neu schreiben. OpenTelemetry (OTel) ist der offene Standard (CNCF) zum Sammeln von Telemetriedaten. Sie instrumentieren Ihren Code einmalig mit OTel. Sie können diese Daten dann an Datadog, Prometheus, Jaeger oder einfach an „stdout“ weiterleiten.

Automatische Instrumentierung von Node.js

Modernes OTel ermöglicht „Auto-Instrumentierung“. Sie schreiben Ihre Express-Handler nicht neu. Es patcht Standardbibliotheken („http“, „pg“, „redis“) zur Laufzeit.

„Javascript // instrumentation.ts import { NodeSDK } aus ‘@opentelemetry/sdk-node’; import { HttpInstrumentation } from ‘@opentelemetry/instrumentation-http’; import { PgInstrumentation } from ‘@opentelemetry/instrumentation-pg’; import { OTLPTraceExporter } from ‘@opentelemetry/exporter-trace-otlp-proto’;

const sdk = neues NodeSDK({ TraceExporter: neuer OTLPTraceExporter({ URL: ‘https://api.honeycomb.io/v1/traces’, // Oder Ihr Sammler }), Besetzungen: [ new HttpInstrumentation(), // Verfolgt alle eingehenden/ausgehenden HTTP new PgInstrumentation(), // Verfolgt alle Postgres-Abfragen ], serviceName: ‘maison-code-api’, });

sdk.start(); „

Mit dieser 20-Zeilen-Datei verfügen Sie sofort über Wasserfalldiagramme für jede Datenbankabfrage und jeden API-Aufruf in Ihrem Produktionssystem.

Kontextweitergabe verfolgen

Woher weiß die Datenbank, welcher „Benutzerklick“ die Abfrage verursacht hat? Kontextweitergabe. Wenn Dienst A Dienst B aufruft, fügt er einen generischen HTTP-Header ein: „traceparent“. „traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01“.

Dienst B liest diesen Header. Es startet seine eigene Spanne und verwendet die ID von A als „Eltern-ID“. Dadurch werden die verteilten Operationen in einem einzigen DAG (Directed Asymmetric Graph) verknüpft.

RUM (Real User Monitoring)

Die serverseitige Beobachtbarkeit funktioniert einwandfrei, dennoch beschweren sich Benutzer immer noch. „Ich habe auf den Button geklickt und nichts ist passiert.“ Serverprotokolle: „Keine Anfrage erhalten.“ Fazit: Das JavaScript stürzte im Browser ab, bevor die Anfrage gesendet wurde.

Für die Frontend-Beobachtbarkeit verwenden wir RUM (Sentry, LogRocket). Es erfasst automatisch:

  1. Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP).
  2. Konsolenfehler: „undefiniert ist keine Funktion“.
  3. Session Replay: Eine videoähnliche Aufzeichnung der Mausbewegungen des Benutzers.

Fallstudie: Wir hatten einen Checkout-Fehler mit 0 Protokollen. Als wir uns die Sitzungswiedergabe ansahen, sahen wir, dass Benutzer auf dem iPhone SE (kleiner Bildschirm) nicht zur Schaltfläche „Bezahlen“ scrollen konnten, weil sie von einem „Cookie-Banner“ mit „.zIndex: 9999“ verdeckt wurde. Kein Protokoll hätte uns das sagen können. Visual Observability tat es.

Alarmierungsphilosophie: SRE-Prinzipien

Rufen Sie den Techniker nicht um 3 Uhr morgens an, weil „CPU zu 90 % ausgelastet“ ist. Vielleicht sind 90 % in Ordnung. Möglicherweise wird die Warteschlange schnell verarbeitet. Warnung bei Symptomen, nicht bei Ursachen.

SLI (Service Level Indicator): Eine Metrik, die für den Benutzer wichtig ist.

  • Beispiel: „Homepage-Verfügbarkeit“.
  • Beispiel: „Checkout-Latenz“.

SLO (Service Level Objective): Das Ziel.

  • „Die Startseite sollte in 99,9 % der Fälle in Ordnung sein.“
  • „Der Checkout sollte in 95 % der Fälle unter 2 Sekunden erfolgen.“

Alarmbedingung:

  • „Wenn Fehlerrate > 0,1 % für 5 Minuten -> PagerDuty.“
  • „Wenn die Fehlerquote > 5 % ist -> Wecken Sie den CEO auf.“

Die Kosten der Beobachtbarkeit

Alles zu beobachten ist teuer. Wenn Sie 100 % der Anfragen nachverfolgen, übersteigt Ihre Überwachungsrechnung möglicherweise Ihre Hosting-Rechnung. Probenahme ist die Lösung.

  • Kopfbasierte Probenahme: Entscheiden Sie zu Beginn einer Anfrage. „Verfolgen Sie 10 % der Benutzer.“
  • Tail-Based Sampling (Erweitert): Behalten Sie alle Spuren im Speicher. Wenn ein Fehler auftritt, senden Sie den vollständigen Trace. Wenn es gelingt, verwerfen Sie es.
    • Dies stellt sicher, dass Sie 100 % der Fehler, aber 0 % der langweiligen Erfolgsprotokolle erfassen.

10. Überwachung der Geschäftslogik (Die goldenen Signale)

CPU-Grafiken zahlen nicht die Rechnungen. Bestellungen bezahlen die Rechnungen. Zugriffsprotokolle sagen Ihnen nicht, ob die Schaltfläche „In den Warenkorb“ defekt ist (wenn sie defekt ist, gibt es keine Protokolle). Wir definieren Geschäftskennzahlen:

  • orders_per_minute
  • add_to_cart_value_total
  • zahlungsgateway_rejection_rate Wir setzen Warnungen zur „Anomalieerkennung“. „Wenn Bestellungen/Minute im Vergleich zum letzten Dienstag um 50 % sinken -> PagerDuty.“ Dadurch werden „stille Fehler“ (z. B. ein defekter Javascript-Ereignis-Listener) abgefangen, die Serverprotokolle niemals sehen.

11. Strategien zur Kostenkontrolle

Datadog ist teuer. Das Speichern jedes „console.log“ ist verschwenderisch. Wir implementieren Protokollebenen nach Umgebung:

  • „Entwicklung“: Debug (Alles).
  • „Produktion“: Info (Schlüsselereignisse) + Fehler. Wir verwenden auch Ausschlussfilter auf Agentenebene: „Löschen Sie alle Protokolle, die „Health Check OK“ enthalten.“ Dadurch wird die Lautstärke um 40 % reduziert, ohne dass das Signal verloren geht.

12. Die Kardinalitätsexplosion (Wie man die Beobachtbarkeit ruiniert)

Es beginnt unschuldig. metrics.increment('request_duration', { url: req.url }) Dann klickt ein Bot auf „/login?random=123“. Dann /login?random=456. Plötzlich haben Sie 1 Million eindeutige Tag-Werte. Datadog stellt Ihnen „benutzerdefinierte Metriken“ in Rechnung. Rechnung: 15.000 €/Monat. Fix: Normalisieren Sie Ihre Abmessungen. Ersetzen Sie „/login?random=123“ durch „/login?random=*“ in Ihrer Middleware, bevor die Metrik ausgibt.

13. Protokollierungs-ROI: Ist dieses Protokoll 0,001 € wert?

Wir behandeln Baumstämme wie Immobilien. „Benutzer angemeldet“ -> Hoher Wert. 30 Tage aufbewahren. „Gesundheitsprüfung bestanden“ -> Niedriger Wert. Sofort fallen lassen. „Array-Dump debuggen“ -> Negativer Wert. Es erschwert die Suche. Wir implementieren Dynamic Sampling: Aktivieren Sie während eines Vorfalls DEBUG für 1 % der Benutzer. Halten Sie es in Friedenszeiten fern.

14. Fazit

Beobachtbarkeit ist der Unterschied zwischen „Ich denke, es funktioniert“ und „Ich weiß, dass es funktioniert.“ Es verschiebt die Kultur von „Schuld“ („Das Netzwerkteam hat versagt“) zu „Daten“ („Der Trace zeigt eine Zeitüberschreitung von 500 ms auf dem Switch an“).

In einer modernen, verteilten Umgebung mit hohen Einsätzen ist Code ohne Instrumentierung kaum noch Code. Es ist eine Blackbox, die nur darauf wartet, Sie zu verwirren.


**[Beauftragen Sie unsere Architekten](/contact)**.