Observability, die um 3 Uhr nachts hilft: Logs, Traces und was wirklich zählt

Die drei Säulen sind falsch

Jeder Observability-Vortrag beginnt mit "den drei Säulen: Logs, Metriken und Traces." Dieses Framing ist unvollständig. Es sagt dir, was du sammeln sollst, aber nicht, was du damit machen sollst. Die echte Frage um 3 Uhr nachts ist nicht "habe ich Logs?" Sondern: "Kann ich die eine Log-Zeile finden, die erklärt, warum die Bestellung dieses Kunden fehlgeschlagen ist, über 7 Services hinweg, in unter 2 Minuten?"

Wir betreiben Produktionssysteme mit mehreren Services, Background-Workern, Message Queues und KI-Pipelines. Dieser Artikel behandelt, was tatsächlich hilft, wenn Dinge kaputtgehen. Für OpenTelemetry-spezifische Implementierungsmuster schau dir unseren OpenTelemetry-Guide an. Für KI-spezifische Observability schau in unseren KI-Observability-Guide.

Strukturiertes Logging: Das Format, das dich rettet

Unstrukturierte Logs sind im großen Maßstab nutzlos. console.log('Processing order ' + orderId) wird zu Rauschen in einem System, das 10.000 Log-Zeilen pro Minute produziert.

Strukturierte Logs sind abfragbar, filterbar und alarmierbar:

// Unstrukturiert (nutzlos im großen Maßstab)
console.log('Processing order 12345 for customer sara@beispiel.de');

// Strukturiert (abfragbar, PII-frei)
logger.info('order_processing_started', {
    order_id: 'ord_12345',
    customer_id: 'cust_abc',  // ID, nicht E-Mail
    channel: 'web',
    tenant_id: 'tenant_acme',
    items_count: 3,
    total_cents: 15900,
});

Log-Level-Disziplin

Produktion sollte auf info-Level laufen. debug erzeugt zu viel Volumen. error und warn sollten immer ein Review auslösen (wenn nicht Alerts).

Keine PII in Logs

Dein Log-Aggregator (Datadog, CloudWatch, Loki, Elasticsearch) indexiert alles. Wenn Logs E-Mails, Namen oder Telefonnummern enthalten, wird deine Log-Infrastruktur DSGVO-reguliert.

// Schlecht: PII in Logs
logger.info('Email sent to sara.mustermann@beispiel.de about order 12345');

// Gut: Nur IDs
logger.info('notification_sent', {
    recipient_id: 'cust_abc',
    notification_type: 'order_confirmation',
    order_id: 'ord_12345',
    channel: 'email',
});

Für die vollständige PII-Schutzarchitektur schau dir unseren Leitfaden zur Vermeidung von Datenlecks an.

Correlation IDs: Einen Request über Services hinweg verfolgen

Ein einzelner Benutzer-Request kann ein API-Gateway, einen Auth-Service, einen Produkt-Service, einen Payment-Service, einen Notification-Worker und einen Search-Indexer berühren. Ohne Correlation ID erfordert das Finden aller Log-Einträge für einen Request das Raten von Timestamps und grep.

// Am Edge generieren (API-Gateway oder erster Service)
const correlationId = crypto.randomUUID();

// Durch jeden Service via Headers weitergeben
const response = await httpClient.post('/api/orders', body, {
    headers: { 'X-Correlation-Id': correlationId },
});

// In jeden Log-Eintrag aufnehmen
logger.info('order_created', {
    correlation_id: correlationId,
    order_id: order.id,
    tenant_id: ctx.tenantId,
});

// In jede Nachricht an Queues aufnehmen
await queue.add('send_confirmation', {
    orderId: order.id,
    correlationId,
});

Beim Debuggen nach Correlation ID abfragen:

correlation_id = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"

Jeder Log-Eintrag von jedem Service für diesen Request erscheint. Die gesamte Kette ist sichtbar. Das ist das einzelne wirkungsvollste Debugging-Tool in verteilten Systemen.

Alert Fatigue: Weniger Alerts, bessere Alerts

Der Standard-Ansatz: Auf alles alerten. Error Rate > 0? Alert. Latenz > 500ms? Alert. Queue Depth > 10? Alert. Das Ergebnis: 200 Alerts pro Tag, alle ignoriert.

Alert-Design-Prinzipien

Alert-Stufen

Das Ziel: P1-Alerts feuern weniger als einmal pro Woche. Wenn sie täglich feuern, sind sie entweder falsch konfiguriert oder dein System hat fundamentale Zuverlässigkeitsprobleme.

Kostenmanagement

Observability ist teuer. Log-Ingestion, Metrik-Speicherung, Trace-Aufbewahrung und Dashboard-Hosting summieren sich schnell.

Log-Volumen reduzieren ohne Signal zu verlieren

// Nicht jeden Health Check loggen
if (req.path === '/health' || req.path === '/ready') {
    return next(); // Logging überspringen
}

// Verbose Operationen sampeln
if (req.path.startsWith('/api/search') && Math.random() > 0.1) {
    ctx.skipLogging = true; // Nur 10% der Such-Requests loggen
}

// Immer Fehler, Business-Events und langsame Requests loggen
logger.info('request_completed', {
    path: req.path,
    status: res.statusCode,
    duration_ms: duration,
    // Detaillierte Felder nur für langsame oder fehlerhafte Requests
    ...(duration > 1000 || res.statusCode >= 400 ? {
        query_params: sanitize(req.query),
        response_size: res.contentLength,
    } : {}),
});

Das Observability-Reifegradmodell

Die meisten Teams sind bei L1-L2. L3 (Correlation IDs) ist die größte einzelne Verbesserung. L4 (gutes Alerting) verhindert Burnout. L5 ist ambitioniert, aber erreichbar.

Häufige Fallstricke

1. Unstrukturierte Logs. console.log mit String-Konkatenation ist Rauschen im großen Maßstab. Verwende strukturiertes JSON mit typisierten Feldern.

2. PII in Logs. Dein Log-Aggregator wird DSGVO-reguliert. Logge IDs, nicht Werte.

3. Auf alles alerten. 200 Alerts pro Tag bedeutet, dass null Alerts gelesen werden. Stufe Alerts nach Schweregrad und Business Impact.

4. High-Cardinality-Metrik-Labels. User-IDs oder Request-IDs als Metrik-Labels erzeugen Millionen von Zeitreihen. Verwende begrenzte Labels (Statuscode, Endpoint, Tenant).

5. Keine Correlation IDs. Ohne sie erfordert das Debuggen eines Requests über 7 Services Timestamp-Raten und Beten.

6. Kein Log-Sampling. Jeden Health Check und Such-Request mit voller Ausführlichkeit zu loggen verdoppelt deine Log-Rechnung. Sample verbose Operationen, logge immer Fehler.

7. Kein Kostenbudget für Observability. Observability-Ausgaben sollten 5-15% der Infrastrukturausgaben betragen. Tracke es. Optimiere es.

8. Dashboards, die keiner anschaut. Wenn ein Dashboard seit 30 Tagen nicht angesehen wurde, lösch es. Dashboard-Wildwuchs kostet Geld und sorgt für Verwirrung.

Wichtige Erkenntnisse

• Strukturiertes Logging ist nicht verhandelbar. JSON mit typisierten Feldern. Abfragbar, filterbar, alarmierbar. Niemals String-Konkatenation.

• Correlation IDs sind das wirkungsvollste Debugging-Tool. Generiere sie am Edge, propagiere sie durch jeden Service und jede Queue. Frage nach Correlation ID ab, um die gesamte Request-Kette zu sehen.

• Keine PII in Logs. Niemals. Logge Kunden-IDs, nicht Kunden-E-Mails. Logge Bestell-IDs, nicht Bestellinhalte. Deine Log-Infrastruktur darf keine Datenschutz-Haftung werden.

• Weniger Alerts, bessere Alerts. P1-Alerts sollten weniger als einmal pro Woche feuern. Jeder Alert muss handlungsfähig sein. Füge den Business Impact in die Alert-Nachricht ein.

• Budgetiere deine Observability. Log-Volumen, Metrik-Kardinalität, Trace-Sampling und Aufbewahrungsrichtlinien beeinflussen alle die Kosten. Tracke Observability-Ausgaben als Prozentsatz der Infrastrukturausgaben.

Wir bauen Observability in jedes System ein, das wir deployen, ob KI-Services, Cloud-Infrastruktur oder Custom Software. Wenn du Hilfe mit Produktions-Observability brauchst, sprich mit unserem Team oder fordere ein Angebot an.