JEnterprise Senior Java Workbench
Production Diagnostics

Runbooks

Geführte Diagnosewege, die Symptome, Evidenz und Hypothesen trennen. Vor jedem produktiven Eingriff gelten lokale Incident- und Freigaberegeln. Nutze die Seite für eine konkrete Engineering-Aufgabe: Kläre zuerst Ziel und Risiko und halte danach Ergebnis, Nachweis und nächsten Schritt fest.

Anwendung ist langsam
  1. Auswirkung und betroffene Endpunkte eingrenzen
  2. p50/p95/p99 und Fehlerquote vergleichen
  3. DB-Pool, Threading, GC und externe Latenzen prüfen
  4. Trace eines langsamen Beispiels analysieren
  5. Hypothese mit gezielter Messung bestätigen
Datenbankverbindungen erschöpft
  1. Aktive, idle und wartende Verbindungen prüfen
  2. lange Transaktionen und Connection Leaks suchen
  3. DB-Limits und Pool-Konfiguration vergleichen
  4. Timeout- und Retry-Kaskaden prüfen
  5. Fix unter realistischer Last verifizieren
Kafka Consumer steht
  1. Consumer Group und Lag prüfen
  2. Rebalance- und Fehlerlogs prüfen
  3. Poison Message und Deserialisierung ausschließen
  4. Downstream-Abhängigkeiten und Transaktionen prüfen
  5. Offset-Strategie vor Eingriff dokumentieren
Speicherverbrauch steigt
  1. Heap, Native Memory und Containerlimit trennen
  2. GC-Verlauf und Allocation Rate prüfen
  3. Heap Dump nur kontrolliert erzeugen
  4. Retained Size und dominierende Pfade analysieren
  5. Soak Test nach Fix durchführen
Deployment gesund, Service unerreichbar
  1. Readiness und Service-Endpunkte prüfen
  2. Port, Bind Address und Network Policy prüfen
  3. Ingress/Route und TLS kontrollieren
  4. Start- und Shutdown-Logs korrelieren
  5. Smoke Test aus Zielnetz ausführen
Fehler nur unter Last
  1. Lastprofil und Datenverteilung reproduzieren
  2. Sättigung bei CPU, Pool, Threads und Broker prüfen
  3. Timeouts und Retries als Verstärker analysieren
  4. Race Conditions oder Locking prüfen
  5. Fix mit Peak- und Soak-Test absichern
Kafka Consumer Lag und DLT
  1. Consumer Group, Topic und betroffene Partitionen feststellen.
  2. Input-/Processing-Rate, Rebalances, DB-Latenz und Fehlerquote vergleichen.
  3. DLT nach Fehlerklasse und Schemaversion gruppieren.
  4. Ursache beheben; Replay zunächst mit kleiner Stichprobe durchführen.
  5. Idempotenzmarker, Projektion, Lag und DLT nach dem Replay kontrollieren.
⌂ Cockpit