Skip to content
NeuralSkills
Fehlerbehebung

Log-Instrumentierung-Designer

Strategisches Logging entwerfen, das zukuenftiges Debugging muehelos macht — strukturierte Logs und Observability-Muster.

Fortgeschritten Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Die meisten Logs sind reaktiv — Entwickler fuegen console.log nach einem Fehler hinzu und entfernen es nach dem Fix. Das bedeutet, der NAECHSTE Fehler erfordert eine neue Runde: Logs hinzufuegen, deployen, auf Reproduktion warten, Logs lesen, iterieren. Strategisches, von Anfang an geplantes Logging bedeutet: Jeder zukuenftige Fehler kommt vorinstrumentiert mit den Daten, die zur Diagnose noetig sind. Der Unterschied zwischen “3 Deploy-Zyklen zum Finden” und “Diagnose ab dem ersten Auftreten.”

Der Prompt

Du bist ein Logging- und Observability-Architekt. Entwirf einen strategischen Logging-Instrumentierungsplan:

ANWENDUNG: [Typ, Framework, Architektur]
KRITISCHE FLOWS: [wichtigste User Journeys und Systemoperationen]
AKTUELLES LOGGING: [bestehende Logging-Situation beschreiben]
LOG-ZIEL: [stdout, Datei, CloudWatch, Datadog, ELK, Sentry]

Entwirf die Logging-Instrumentierung:
1. **Log-Level-Strategie**: Definiere exakt, was auf jedem Level steht — ERROR, WARN, INFO, DEBUG. Mit konkreten Beispielen fuer diese Anwendung.
2. **Strukturiertes Log-Schema**: JSON-Log-Format mit Pflichtfeldern entwerfen: timestamp, level, service, requestId, userId, action, duration, metadata.
3. **Korrelationsstrategie**: Request-ID/Trace-ID-Propagierung entwerfen — wie eine einzelne ID durch HTTP-Requests, Message-Queues, Background-Jobs und Datenbank-Aufrufe gefaedelt wird.
4. **Strategische Log-Platzierung**: Fuer jeden kritischen Flow die exakt 5-7 Log-Punkte identifizieren, die den Flow-Lebenszyklus erfassen.
5. **Performance-Kontext**: Jeder Log ab INFO sollte Timing-Daten enthalten. Das Muster fuer Zeitmessung entwerfen.
6. **Alert-wuerdige Muster**: Welche Log-Muster sollen Alerts ausloesen — nicht nur Fehler, sondern Anomalie-Muster.

Beispiel-Ausgabe

Log-Schema: { timestamp, level, service: "order-api", requestId, userId, action: "checkout.complete", durationMs: 1247, metadata: { orderId, itemCount } }
Korrelation: X-Request-Id-Header via Middleware propagiert → in AsyncLocalStorage gespeichert → automatisch in jeden Log injiziert
Strategische Platzierungen fuer Checkout-Flow:
  1. INFO "checkout.started" — {userId, cartItemCount, cartTotal}
  2. INFO "payment.initiated" — {provider, amount, currency}
  3. INFO "payment.completed" — {transactionId, durationMs}
  4. WARN "inventory.low" — {sku, remaining} (nur wenn Bestand < Schwelle)
  5. ERROR "payment.failed" — {provider, errorCode, errorMessage}
  6. INFO "checkout.completed" — {orderId, totalDurationMs}
Alert-Muster: payment.failed Rate > 5% in 5min, checkout.completed p95 > 10s

Wann verwenden

Diesen Skill einsetzen beim Logging-Setup fuer ein neues Projekt, wenn aktuelles Logging fuer Produktions-Debugging unzureichend ist, oder zur Verbesserung der Observability ohne Rauschen hinzuzufuegen. Unverzichtbar vor dem Produktivgang.

Profi-Tipps

  • An Grenzen loggen, nicht in Funktionen — loggen wenn Daten ins System eintreten, wenn externe Systeme aufgerufen werden, und wenn Daten das System verlassen.
  • Strukturiertes Logging ab Tag eins — console.log('User erstellt:', userId) ist nicht suchbar. logger.info({ action: 'user.created', userId }) ist filterbar und alertfaehig.
  • Korrelations-IDs sind nicht verhandelbar — ohne Request-ID, die durch jeden Log faedelt, ist die Korrelation von Eintraegen waehrend eines Incidents wie Nadel im Heuhaufen.
  • Das WARUM fuer Entscheidungen loggen — “Request abgelehnt” ist nutzlos. “Request abgelehnt: Rate-Limit ueberschritten, userId=42, requestCount=101, limit=100” sagt alles.