OpenTelemetry in der Produktion: Hören Sie auf, im Dunkeln zu debuggen

Das erste Mal, dass Sie Beobachtbarkeit wirklich brauchen, ist nicht, wenn Sie ruhig auf ein Dashboard schauen. Wenn ein Benutzer schreibt: „Der Checkout ist langsam“, sieht das Fehlerdiagramm normal aus und in den Protokollen finden Sie nur eine Reihe nicht verbundener Nachrichten.

OpenTelemetry wurde geschaffen, um diesen Moment zu vermeiden: nicht um mehr Grafiken zu haben, sondern um die Teile zu verbinden. Eine Anfrage gelangt in den API, ruft eine Datenbank auf, durchläuft einen externen Anbieter, stellt einen Job in die Warteschlange und schlägt möglicherweise drei Dienste später fehl. Ohne verteilte Ablaufverfolgung rekonstruieren Sie diese Geschichte von Hand. Mit OpenTelemetry haben Sie zumindest eine Karte.

Es geht nicht um die trace, sondern um die Geschichte

Ein trace ist eine Folge von span. So ausgedrückt klingt es kalt. In der Praxis ist jedes span ein Teil der Geschichte: POST /checkout, SELECT inventory, call payment provider, publish order.created.

Der Wert entsteht, wenn Sie anfangen, echte Fragen zu beantworten:

Welcher externe Dienst wird langsamer?
Stammen die Fehler von einer bestimmten Version?
Betrifft das Problem alle oder nur einen Mieter?
Versteckt ein Wiederholungsversuch eine Zeitüberschreitung?
Der asynchrone Job startet, stirbt dann aber woanders?

Diese Fragen können nicht durch eine überstürzte console.log gelöst werden. Tatsächlich hilft Ihnen das im Notfall hinzugefügte Protokoll oft heute und wird morgen zum Lärm.

Wie würde ich das in eine App integrieren Node.js

Die gesündeste Einrichtung ist einfach: Die App erstellt Telemetriedaten, der Collector entscheidet, wohin sie gesendet werden.

Node.js app -> OpenTelemetry Collector -> backend di observability

Warum nicht direkt zum Anbieter exportieren? Denn zunächst scheint es schneller zu sein, aber dann stellt man fest, dass jeder Dienst unterschiedliche Konfigurationen, unterschiedliche Wiederholungsversuche, unterschiedliche Filter und keinen zentralen Punkt hat, um vertrauliche Daten zu entfernen oder das Ziel zu ändern.

Der Collector ist in jeder Hinsicht langweilig. Es empfängt OTLP, führt Stapelverarbeitung durch, kann filtern, Stichproben durchführen, allgemeine Attribute hinzufügen und in mehrere Systeme exportieren.

Selbstinstrumentierung: gut, aber nicht ausreichend

In Node.js würde ich mit der automatischen Instrumentierung beginnen. Sie erhalten sofortigen Einblick in HTTP, unterstützte Frameworks, Datenbanken und gängige Bibliotheken.

npm install @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

Dann initialisieren Sie das SDK vor dem Rest der App:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT,
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Dabei wird jedoch das Framework gesehen, nicht Ihr Produkt. Es weiß, dass Sie eine Anfrage gestellt haben, aber es weiß nicht, dass sich die Anfrage auf „Bestellung erstellen“ oder „Abonnement erneuern“ bezog. Dafür braucht es span Handbücher an den Stellen, an denen es auf Dominanz ankommt.

const span = tracer.startSpan('checkout.create_order');

try {
  span.setAttribute('cart.items_count', input.items.length);
  const order = await createOrder(input);
  span.setAttribute('order.id', order.id);
  return order;
} catch (error) {
  span.recordException(error as Error);
  throw error;
} finally {
  span.end();
}

Ich würde span Handbücher nirgendwo ablegen. Ich würde sie um drei Uhr morgens dort platzieren, wo ich gerne verstehen würde, was passiert ist, ohne die Hälfte der Codebasis zu lesen.

Drei Regeln, die viel Chaos vermeiden

Erste Regel: Jeder Dienst muss service.name, Umgebung und Version haben. Es scheint trivial, aber ohne diese Attribute ist ein trace viel weniger nützlich. Wenn eine Bereitstellung etwas kaputt macht, möchten Sie in zwei Sekunden nach Version filtern.

Zweite Regel: Geben Sie keine sensiblen Daten in die Attribute ein. E-Mails, Token, Integer-Payloads und Adressen sollten nicht versehentlich in einem Observability-Backend landen. Wenn Sie einen Benutzer identifizieren müssen, ziehen Sie interne IDs, Hashing oder weniger vertrauliche Felder in Betracht.

Dritte Regel: Achten Sie auf die Kardinalität. user.id als Attribut von trace kann Sinn machen. Als metrisches Etikett kann es Ihre Kosten und Leistung zerstören.

Kennzahlen: wenige, aber gut

Ich würde mit sehr praktischen Kennzahlen beginnen:

Tarife, Fehler und Dauer der Anfragen;
Latenz externer Abhängigkeiten;
Anzahl der Zeitüberschreitungen und Wiederholungsversuche;
Tiefe der Schwänze;
Beschäftigungsdauer;
Prozentsatz der Fehler pro Version.

Der Rest wird bei Bedarf hinzugefügt. Dashboards voller Grafiken, die niemand anschaut, sind Möbel und keine Beobachtbarkeit.

Protokolle: Immer noch nützlich, aber verlinkt

Protokolle verschwinden nicht. Sie werden einfach viel nützlicher, wenn sie trace_id und span_id tragen. Sie können also mit einem Fehlerprotokoll beginnen und trace öffnen oder mit einem langsamen trace beginnen und nur die in diesem Pfad erstellten Protokolle lesen.

Ohne Korrelation suchen Sie nach Nadeln. Mit der Korrelation wissen Sie zumindest, in welche Schublade Sie schauen müssen.

Die Checkliste, die ich verwenden würde, bevor ich sage „Wir sind abgesichert“

Die trace umfassen tatsächlich mehrere Dienste.
Zu den Protokollen gehören trace_id und span_id.
Der Collector ist mit Batch- und Speicherbegrenzungen konfiguriert.
Fehler werden in span erfasst.
Es gibt eine Probenahmerichtlinie.
Metriken haben eine kontrollierte Kardinalität.
Sensible Daten werden gefiltert.
Warnungen beginnen mit Benutzersymptomen, nicht mit zufälligen Diagrammen.

Fazit

OpenTelemetry allein löst Produktionsprobleme nicht. Aber die Art und Weise, wie man mit ihnen umgeht, ändert sich. Anstatt blind Protokolle hinzuzufügen, beginnen Sie, dem tatsächlichen Pfad einer Anfrage zu folgen.

Für mich ist das Zeichen dafür, dass es funktioniert, einfach: Wenn etwas passiert, fragt das Team nicht mehr: „Wo suchen wir?“ und beginnt zu fragen: „Warum ist das Stück langsam?“. Hier wird Beobachtbarkeit zu einem Werkzeug und nicht zu einer Sammlung von Dashboards.

Quellen