87 Inspect, Diff, Stats, Events

Die Befehle inspect, diff, stats und events gehören zu den mächtigsten Diagnosewerkzeugen in Podman. Sie bilden die unteren Schichten einer observability-orientierten Toolchain, die ohne zusätzlichen Agenten oder Daemon funktioniert. Wer diese Kommandos beherrscht, verfügt über einen tiefen, prozessnahen Zugang zu Container- und Pod-Zuständen – und kann Probleme diagnostizieren, lange bevor eine Anwendung in Logs überhaupt sichtbar wird. Dieses Kapitel beleuchtet die Funktionsweise, Einsatzgebiete und typischen Diagnoseszenarien dieser Werkzeuge.

87.1 Inspect – das strukturierte Abbild des Containers

podman inspect ist das zentrale Werkzeug, um Container- oder Podinformationen in strukturierter Form abzurufen. Während Logs Symptome zeigen, liefert inspect Architektur und Fakten – als JSON, vollständig und maschinenlesbar.

Beispiel:

podman inspect <container>

Inspect liefert u. a.:

• Prozessinformationen (PID, Namespaces)
• Netzwerkkonfiguration (IP, MAC, Bridges, Ports)
• Mounts & Volumes
• Storage-Layer & Overlay-Daten
• Umgebungsvariablen
• Labels & Annotations
• State (running, exited, paused)
• Restart-Konfigurationen
• Command & EntryPoint

Dieses JSON dient nicht nur Entwicklern, sondern auch Automatisierungswerkzeugen zur Validierung und Statusermittlung.

87.1.1 Typische Diagnosefragen, die inspect beantwortet

1. Warum ist mein Port nicht erreichbar? → Blick auf NetworkSettings.Ports.

2. Warum startet mein Container nicht? → State.Error und State.ExitCode.

3. Warum kann der Container nicht schreiben? → Mounts + SELinux-Labels prüfen.

4. Wie sieht der tatsächliche Startbefehl aus? → Config.Cmd und Config.Entrypoint.

5. Welche Capabilities besitzt ein Container? → unter HostConfig.CapAdd, CapDrop.

Inspect zeigt also nicht nur Konfiguration, sondern auch die umgesetzte Realität, die Podman tatsächlich ausführt.

87.2 Diff – Veränderungen im Container-Filesystem sichtbar machen

Container-Images sind unveränderlich – aber laufende Container verändern oft ihr Root-Filesystem, etwa durch Logs, generierte Dateien oder temporäre Artifakte. podman diff zeigt exakt diese Unterschiede zwischen dem Image und dem laufenden Container.

podman diff <container>

Es gibt drei Kategorien:

• A – Added
• C – Changed
• D – Deleted

Ein typisches Beispiel:

C /var/log/app.log
A /data/output.json
D /tmp/config.tmp

87.2.1 Einsatzszenarien für diff

• Debugging ungewollter Schreiboperationen → zeigt, ob die Anwendung ins Image-Filesystem statt ins Volume schreibt.

• Identifikation von Konfigurationsänderungen während runtime → Was hat der Prozess modifiziert?

• Diagnose von immutability-Verstößen → Hilft, Clean-Code-Fehler in Containerisierten Anwendungen zu finden.

• Vergleich zweier Containerzustände → Besonders wertvoll, wenn „es funktioniert nur auf meinem Rechner“ auftritt.

Diff ist eines der am meisten unterschätzten Tools in Podmans Werkzeugkasten.

87.3 Stats – Echtzeit-Ressourcenüberwachung

Wenn ein Container „ruckelt“, „hängt“ oder „wie tot aussieht“, liefert podman stats die entscheidende Echtzeitperspektive:

podman stats <container|pod>

Angezeigt werden:

• CPU-Auslastung
• Memory-Usage
• Memory-Limits
• Block-I/O
• Network-I/O
• Anzahl der Prozesse

stats nutzt die cgroup-Daten direkt aus dem Kernel – ohne künstliche Aggregation. Das ergibt präzise, Host-nah interpretierbare Zahlen.

87.3.1 Typische Probleme, die stats aufdeckt

1. CPU-Spikes → Threads hängen in Endlosschleifen oder Garbage-Collector-Sweeps.

2. Memory-Leaks → Steigende Kurve, bis der OOM-Killer zuschlägt.

3. Block-I/O-Sättigung → Container wartet auf langsame Volumes oder NFS-Mounts.

4. Netzwerküberlastung → häufige Ursache für Latenzprobleme.

5. Zombie-Prozesse → viele defunct-Einträge in Kombination mit PID-Leaks.

Wer stats regelmäßig einsetzt, sieht frühzeitig unerwünschte Ressourcendynamiken.

87.4 Events – die Lebenszeit der Container sichtbar machen

podman events zeigt die Echtzeit-Ereignisse aus Podmans Lebenszyklus. Diese Event-Stream-Mechanik ermöglicht eine präzise Diagnose zeitlicher Abläufe.

podman events

Ein Auszug:

2025-11-23 10:01:23 create container 123abc
2025-11-23 10:01:23 start  container 123abc
2025-11-23 10:01:27 stop   container 123abc
2025-11-23 10:01:27 die    container 123abc
2025-11-23 10:01:27 oom    container 123abc

87.4.1 Typische Event-basiert diagnostizierbare Ursachen

• Crashloops → Container startet und stirbt innerhalb weniger Sekunden.

• Out-of-memory → Event: oom zeigt klar die Ursache, auch wenn Logs leer sind.

• Restart Policies werden ausgelöst → Events zeigen eine regelmäßige Restart-Schleife.

• Lifecycle-Fehler von Pods → initContainer starten nicht → Pod bleibt hängen → Events zeigen die Reihenfolge.

87.4.2 Historische Events

Podman kann auch vergangene Events anzeigen:

podman events --since 1h

Ideal, wenn ein Fehler nicht mehr live sichtbar ist.

87.5 Zusammenspiel der Diagnoseinstrumente

Die vier Werkzeuge entfalten ihre Stärke erst im Zusammenspiel.

Typischer Troubleshooting-Flow:

Beispiel: Ein Container stürzt „zufällig“ ab.

• Logs: keine Meldung → Verdacht auf OOM
• Inspect: Speicherlimit gesetzt?
• Events: oom bestätigt das Verhalten
• Stats: Memory steigt kontinuierlich
• Diff: erzeugte Dateien wachsen unkontrolliert → Leak im Applikationslayer

Ohne diese Kette wäre die Diagnose ungleich schwieriger.

87.6 Best Practices für den effizienten Einsatz

• inspect immer zuerst bei Strukturproblemen
• events für zeitbasierte Fehler oder Restart-Loops
• stats bei Performanceproblemen
• diff bei unerklärlichen Laufzeitveränderungen
• Events zusammen mit journalctl -k nutzen, besonders bei OOM
• Automatisiertes Inspect-Parsing in CI/CD einsetzen
• Stats-Monitoring in systemd- oder Cluster-Umgebungen integrieren

inspect, diff, stats und events bilden eine präzise Diagnosesuite für Podman. Jedes Werkzeug beleuchtet eine andere Achse des Containerverhaltens: Struktur, Dateisystem, Ressourcen und Zeit. Zusammen ermöglichen sie eine Diagnosequalität, die nah am Kernel agiert und exakt das liefert, was in produktionsnaher Architekturarbeit unverzichtbar ist.