Beobachtbarkeit in Container-Stacks: Metriken, Logs und Health | mironsoft.de

1. Warum Beobachtbarkeit in Container-Stacks anders funktioniert

Beobachtbarkeit in Container-Stacks ist komplexer als in klassischen VM-Setups, weil Container vergänglich sind. Ein Container kann neu gestartet werden, und mit ihm sind alle lokalen Logs weg. Ein Service kann auf drei Replicas skaliert sein, und man muss Logs aus allen drei Instanzen aggregiert betrachten. Die IP-Adresse eines Containers ändert sich bei jedem Neustart. Diese Eigenschaften machen naive Monitoring-Ansätze – Dateipfad-basiertes Log-Monitoring, feste IP-Adressen in Monitoring-Konfigurationen – unbrauchbar.

Echte Beobachtbarkeit in Container-Stacks erfordert drei Dinge: Logs werden strukturiert (JSON) ausgegeben und an ein zentrales Aggregationssystem gesendet, statt in Dateien geschrieben zu werden. Metriken werden über HTTP-Endpunkte im Prometheus-Format bereitgestellt und per Service-Discovery automatisch gefunden. Health Checks überprüfen die tatsächliche Funktionsfähigkeit des Services, nicht nur ob der Prozess läuft. Wer diese drei Säulen implementiert, verwandelt einen opaken Container-Stack in ein System, das seinen eigenen Zustand kommuniziert.

2. Die drei Säulen: Metriken, Logs und Traces

Die drei Säulen der Beobachtbarkeit – Metriken, Logs und Traces – decken unterschiedliche Aspekte ab und ergänzen sich. Metriken sind aggregierte numerische Werte über Zeit: Anfragen pro Sekunde, Fehlerrate, P99-Latenz. Sie sind kompakt, effizient und eignen sich für Alerting und Dashboards. Logs sind ereignisbasiert und enthalten den vollen Kontext eines einzelnen Vorgangs: welcher Request, welcher Fehler, welche Stack-Trace. Traces verbinden mehrere Services zu einem einzigen Request-Flow und machen sichtbar, welcher Service in einer Kette die meiste Zeit verbraucht.

In einem Container-Stack ergänzen sich die drei Säulen: Eine Metrik schlägt Alarm (Beobachtbarkeit auf Systemebene), die Logs geben den konkreten Fehlerkontext (Beobachtbarkeit auf Ereignisebene), und der Trace zeigt, welcher Upstream-Service das Problem verursacht hat (Beobachtbarkeit auf Request-Ebene). Wer nur eine der drei Säulen implementiert, hat blind spots. Wer alle drei hat, kann in einem Container-Stack jeden Fehler innerhalb von Minuten auf seinen Ursprung zurückführen – unabhängig davon, wie viele Services beteiligt sind.

3. Health Checks: mehr als ein simples ping

Docker Health Checks sind der Mechanismus, mit dem ein Container seinen eigenen Zustand kommuniziert. Ein einfacher Health Check mit CMD curl -f http://localhost/health prüft, ob der HTTP-Server antwortet – aber nicht, ob er korrekte Antworten liefert. Ein echter Beobachtbarkeit-tauglicher Health Check prüft, ob die Datenbankverbindung aktiv ist, ob der Cache erreichbar ist und ob die Queue noch arbeitet. Nur dann kann Docker-Compose die Abhängigkeit depends_on: condition: service_healthy korrekt auflösen.

Die Parameter --interval, --timeout, --start-period und --retries definieren das Timing des Health Checks. --start-period gibt dem Container Startzeit, bevor Fehlschläge zählen – wichtig für Anwendungen, die eine Datenbankmigrierung beim Start durchführen. Mit docker inspect --format '{{json .State.Health}}' CONTAINER sieht man den vollständigen Health-Status inklusive der letzten Log-Ausgaben des Health-Check-Kommandos. Das ist die erste Anlaufstelle bei einem Container, der in den Status unhealthy wechselt, ohne offensichtliche Fehlermeldungen in den normalen Logs zu hinterlassen.

4. Strukturierte Logs in Container-Umgebungen

Strukturierte Logs im JSON-Format sind die Grundlage für effektive Beobachtbarkeit in Container-Stacks. Statt menschenlesbarer Zeilen wie [2026-05-09 10:00:00] ERROR: Database connection failed enthält ein strukturierter Log-Eintrag maschinenlesbare Felder: timestamp, level, message, service, request_id, duration_ms. Diese Felder können in Loki, Elasticsearch oder CloudWatch Logs direkt gefiltert, aggregiert und für Alerting-Regeln verwendet werden – ohne Regex-Parsing auf fragilen Textformaten.

In Docker-Containern gibt es zwei Wege für Logs: stdout/stderr (Docker sammelt sie über den konfigurierten Log-Treiber) und Dateien in einem Volume (erfordern einen Sidecar oder eine separate Aggregation). Für Beobachtbarkeit in Container-Stacks ist stdout der empfohlene Weg: docker logs zeigt sie sofort, und ein Log-Treiber wie fluentd oder loki leitet sie weiter, ohne den Container zu modifizieren. Mit dem Promtail-Sidecar-Container in Docker Compose können alle Container-Logs automatisch an Loki gesendet werden, ohne jede Anwendung anzupassen.

5. Prometheus-Metriken aus Docker-Containern exportieren

Prometheus sammelt Metriken per Pull-Modell: Jeder Service stellt einen HTTP-Endpunkt (/metrics) bereit, von dem Prometheus regelmäßig Metriken abruft. Für Beobachtbarkeit im Docker-Stack bedeutet das, dass jeder Service einen eigenen Metrics-Endpunkt braucht, und Prometheus über Service-Discovery die laufenden Container findet. Mit dem Docker-Provider in Prometheus (docker_sd_configs) werden neue Container automatisch erkannt, sobald sie starten – kein manuelles Bearbeiten der Prometheus-Konfiguration mehr.

Für Container-Infrastruktur selbst gibt es cAdvisor (Container Advisor), der CPU, Memory, Netzwerk und I/O aller laufenden Container als Prometheus-Metriken bereitstellt. Der Node Exporter ergänzt Host-Metriken: Festplattennutzung, CPU-Auslastung, Netzwerkinterfaces. Für die Anwendungsebene sind vier Prometheus-Metriken zentral für Beobachtbarkeit: Request-Rate (wie viele Anfragen pro Sekunde), Error-Rate (wie viele davon scheitern), Duration-Histogramm (P50, P95, P99 Latenz) und Saturation (wie voll sind die Queues). Diese vier Metriken – bekannt als RED-Methode – reichen aus, um den Zustand eines Services vollständig zu beurteilen.

6. Health Checks in Docker Compose konfigurieren

Docker Compose ermöglicht detaillierte Health-Check-Konfigurationen, die weit über das Dockerfile hinausgehen. Der entscheidende Unterschied für Beobachtbarkeit: depends_on: condition: service_healthy startet einen Service erst, wenn der abhängige Service den Health Check besteht. Das verhindert Race Conditions beim Stack-Start, bei denen ein Service startet, bevor die Datenbank bereit ist. Diese Abhängigkeitskette mit Health Checks macht den Startzustand des Stacks beobachtbar und reproduzierbar.

Für persistente Dienste wie PostgreSQL oder Redis gibt es standardisierte Health-Check-Kommandos: pg_isready -U postgres für PostgreSQL, redis-cli ping für Redis. Diese Kommandos prüfen nicht nur, ob der Prozess läuft, sondern ob der Dienst tatsächlich Verbindungen akzeptiert. In Kombination mit Prometheus-Alerting (Beobachtbarkeit auf Metrikebene) und strukturierten Logs entsteht ein dreischichtiges Monitoring: Docker meldet den Service als unhealthy, Prometheus zeigt die Fehlerrate steigen, und die strukturierten Logs geben den konkreten Verbindungsfehler mit Stack-Trace.

7. Verteiltes Tracing mit OpenTelemetry

Verteiltes Tracing ist die dritte Säule der Beobachtbarkeit und unverzichtbar in Microservices-Architekturen, wo ein Request mehrere Services durchläuft. OpenTelemetry hat sich als Standard etabliert: Es ist vendor-neutral, unterstützt alle gängigen Sprachen und kann Traces an Jaeger, Tempo, Zipkin oder kommerzielle APM-Systeme senden. In einem Docker-Stack wird der OpenTelemetry Collector als eigener Container deployt, der Traces aller Services empfängt, verarbeitet und weiterleitet.

Die Integration in eine Anwendung ist dank Auto-Instrumentation in vielen Sprachen minimal aufwändig. Für PHP gibt es OpenTelemetry-Extensions, die automatisch HTTP-Requests, Datenbankabfragen und Cache-Operationen tracen, ohne manuell Spans zu setzen. Für Beobachtbarkeit im Entwicklungsalltag ist Jaeger All-in-One das schnellste Werkzeug: ein einzelner Docker-Container, der alle Traces speichert und eine Web-UI bereitstellt. In Produktion wird Grafana Tempo mit Grafana als Frontend bevorzugt, da es direkt mit Prometheus-Metriken und Loki-Logs korreliert werden kann.

8. Alerting: von der Metrik zur Benachrichtigung

Alerting schließt den Kreislauf der Beobachtbarkeit: Metriken und Logs sind erst dann handlungsrelevant, wenn kritische Zustände automatisch gemeldet werden. In einem Prometheus-basierten Stack definiert man Alerting-Regeln in YAML, die Prometheus-Abfragen mit Schwellwerten verbinden. Der Alertmanager empfängt die Alerts und leitet sie je nach Schweregrad, Tageszeit und Label-Routing an Slack, PagerDuty, E-Mail oder Webhooks weiter. Mit for: 5m wird ein Alert erst ausgelöst, wenn die Bedingung 5 Minuten lang anhält – das reduziert Fehlalarme bei kurzen Spitzen erheblich.

Drei Alerting-Regeln sind in jedem Docker-Stack unverzichtbar für echte Beobachtbarkeit: Ein Alert wenn ein Container in den Status unhealthy wechselt (Health-Check-Failure), ein Alert wenn die Fehlerrate einer Service über 5% steigt (Error-Rate), und ein Alert wenn der Speicherplatz auf dem Host unter 20% fällt (Disk-Full). Diese drei Regeln decken die häufigsten Produktionsprobleme ab. Der Alert bei Health-Check-Failure ergänzt das passive Docker-Monitoring um eine aktive Benachrichtigung – ohne dass jemand manuell docker ps laufen lassen muss.

9. Beobachtbarkeitsstrategien im Vergleich

Für Beobachtbarkeit in Container-Stacks gibt es unterschiedlich aufwändige Ansätze – von minimal bis vollständig. Die richtige Wahl hängt von der Stack-Größe und den Betriebsanforderungen ab.

Die minimale Variante gibt es kostenlos: Docker's eingebaute Health Checks und docker logs bieten einen Basisgrad an Beobachtbarkeit ohne zusätzliche Infrastruktur. Aber: Die Logs sind vergänglich (verloren beim Container-Neustart), und es gibt kein Alerting. Die Standard-Variante mit Prometheus, Loki und Grafana ist der empfohlene Ausgangspunkt für jeden produktiven Container-Stack – die Gesamtkonfiguration besteht aus einem compose.yaml und wenigen Konfigurationsdateien und ist in einem Tag eingerichtet.

10. Zusammenfassung

Beobachtbarkeit in Container-Stacks ist kein optionaler Luxus, sondern eine Betriebsvoraussetzung für produktive Docker-Deployments. Ohne strukturierte Logs gehen Fehlerdetails beim Container-Neustart verloren. Ohne Health Checks meldet Docker Compose einen Service als running, obwohl er keine Datenbankverbindung hat. Ohne Metriken erkennt man Performanceprobleme erst, wenn Nutzer klagen. Die drei Säulen – Metriken (Prometheus + cAdvisor), Logs (JSON + Loki) und Health Checks (Tiefenprüfung) – bauen aufeinander auf und decken gemeinsam alle Zustandsaspekte eines Container-Stacks ab.

Die Implementierung muss nicht komplex sein. Ein Prometheus + Grafana + Loki + cAdvisor Stack in Docker Compose ist in einem Tag eingerichtet und erfordert keine Anpassungen an bestehenden Anwendungen. Health Checks im Dockerfile und in compose.yaml kosten wenige Zeilen. Strukturierte Logs sind eine Konfigurationsfrage in den meisten modernen Frameworks. Der Aufwand ist gering, der Nutzen für die Beobachtbarkeit enorm: Probleme werden in Minuten diagnostiziert statt in Stunden gesucht.

11. FAQ: Beobachtbarkeit in Container-Stacks