← Zur Uebersicht
docs/30-troubleshooting-runbooks/01-runbooks.md

Troubleshooting-Runbooks

Status: Werkzeuge/Befehle sind verifiziert (siehe docs/20-monitoring-tuning/ für die realen jcmd-/ server javadump-Läufe gegen concordiaPortalServer). Die konkreten Incident-Szenarien unten sind bewusst als Runbook-Anleitung formuliert, nicht als tatsächlich provozierter Ausfall — ein OOM/Deadlock absichtlich zu erzeugen bringt für ein Lernprojekt wenig zusätzlichen Erkenntnisgewinn gegenüber der korrekten Beschreibung des Diagnose-Wegs.

Runbook 1: Anwendung reagiert langsam / Requests stauen sich

Erster Reflex: nicht raten, sondern einen Thread-Dump ziehen, bevor der Server ggf. neu gestartet wird (ein Neustart vernichtet den Beweis):

cd concordia-portal/target/liberty/wlp/bin
./server javadump concordiaPortalServer

Auswertung:

  1. Wie viele Threads sind im Zustand RUNNABLE, und teilen sich mehrere davon denselben Stacktrace? → deutet auf einen konkreten Code-Hotspot hin (z. B. eine teure Query, ein ineffizienter Loop) — der gemeinsame Stacktrace zeigt direkt, WO.
  2. Wie viele Threads sind BLOCKED, und warten sie auf dasselbe Lock-Objekt? → Verdacht auf Lock-Contention, siehe Runbook 3.
  3. Wie viele Default Executor-thread-N-Threads existieren insgesamt, im Vergleich zum konfigurierten maxThreads in server.xml (siehe docs/20-monitoring-tuning/03-thread-und-connection-pool-tuning.md)? Nahe am Maximum + viele wartende Requests → der Pool selbst ist der Engpass, nicht eine einzelne Methode.

Nächster Schritt je nach Befund: Code-Hotspot → an Java-Entwicklung zurückspielen (mit dem Stacktrace als Beleg); Pool-Engpass → Tuning-Diskussion wie in docs/20-monitoring-tuning/03-thread-und-connection-pool-tuning.md beschrieben (Thread-Pool selbst vs. dahinterliegender DB2-Connection-Pool unterscheiden!).

Runbook 2: OutOfMemoryError

Vorbeugend, nicht erst danach: -XX:+HeapDumpOnOutOfMemoryError gehört in jede produktive jvm.options (siehe docs/20-monitoring-tuning/01-jvm-heap-und-gc.md) — ohne dieses Flag verliert man beim OOM den wichtigsten Diagnose-Datenpunkt.

Nach dem Vorfall:

  1. Heap-Dump-Datei sichern (wird sonst beim nächsten Neustart überschrieben/verworfen).
  2. Klassen-Histogramm zuerst prüfen (schneller Überblick, bevor man den vollen Dump in einem Analyse-Tool öffnet): jcmd <pid> GC.class_histogram bzw. bei bereits abgestürztem Prozess direkt im Heap-Dump-Analyzer (Eclipse MAT o. ä.) nach "häufigste Instanz" sortieren.
  3. Typische Ursachen bei einer Web-Anwendung dieser Art einordnen: unbegrenzt wachsender Cache, Session-Objekte, die nie invalidiert werden, oder — spezifisch für den DB2-Anbindungsfall (siehe docs/40-bindeglied-dev-ops-db2-netzwerk/) — ein Connection-Leak (Verbindungen werden angefordert, aber nie zurückgegeben, sodass der Pool sich langsam mit toten/hängenden Objekten füllt).
  4. Auf IBM Semeru statt HotSpot (siehe docs/20-monitoring-tuning/01-jvm-heap-und-gc.md): derselbe Vorfall erzeugt statt einer .hprof-Datei ein javacore.txt + .phd-Heapdump-Paar — anderes Dateiformat, gleiches Diagnose-Prinzip.

Runbook 3: Verdacht auf Deadlock/Lock-Contention

jcmd <pid> Thread.print

Im echten Thread-Dump-Format (siehe docs/20-monitoring-tuning/02-heap-und-thread-dumps.md für das konkrete Format) nach zwei Mustern suchen:

Runbook 4: DB2-Verbindungsfehler (SQLCODE -30081 & Co.)

Ausführlich in docs/40-bindeglied-dev-ops-db2-netzwerk/01-db2-fuer-zos-und-mainframe-grundlagen.md behandelt — hier nur der Verweis, damit alle Runbooks an einer Stelle auffindbar sind: dieser Fehlerbereich ist der einzige, bei dem die erste Anlaufstelle nicht der WAS-Admin allein ist, sondern eine Koordination mit dem DB2-for-z/OS- bzw. Netzwerk-Team erfordert (siehe docs/40-bindeglied-dev-ops-db2-netzwerk/03-netzwerksegmentierung.md).

⌂ Cockpit