sq.

Einen Stack gezielt untersuchen

Konfiguration, Prozessstatus, Routen, Logs und Speicherplatz vor Änderungen prüfen.

Veröffentlicht:

Arbeite im Übungsverzeichnis. Diese Befehle prüfen den Zustand und löschen keine Daten. Logs echter Anwendungen können private Werte enthalten. Prüfe und bereinige sie vor dem Teilen.

sudo docker compose config --quiet
sudo docker compose ps -a
sudo docker compose logs --tail 50 web gateway metrics
sudo docker stats --no-stream
sudo docker compose port gateway 8080
df -h

Lies den ersten Fehler, nicht nur die letzte Zusammenfassung. Unterscheide die Ebenen:

  • Konfiguration abgelehnt: Einrückung, Dateipfade und fehlende Variablen vor dem Start prüfen.
  • Beendet oder Neustartschleife: Logs des Dienstes lesen. Rechte, fehlende Einstellungen, Datenbankversion und Speichermangel brauchen unterschiedliche Lösungen.
  • Verbindung abgelehnt: Prozess und veröffentlichten Port prüfen. Ein anderer Hostname startet keinen Listener.
  • 404: Hostnamen und Route prüfen; die Antwort kann auch von der Anwendung kommen.
  • 502 oder 504: Der Proxy erhält keine gültige Backendantwort. Dienstname, Port, Netzwerk, Bereitschaft und Logs prüfen.
  • Anmeldeschleife: Basis-URL, Cookies, HTTPS und vertrauenswürdige Proxys prüfen. Anmeldung nicht einfach abschalten.
  • Speicher voll: df -h, df -i und sudo docker system df vergleichen. Erst die wachsenden Daten bestimmen. Volumes nicht pauschal bereinigen.

Nur die Übungsanwendung unterbrechen

Das stoppt absichtlich den entbehrlichen Webdienst. Nicht in einem Produktivprojekt ausführen.

sudo docker compose stop web
curl --max-time 20 -i --resolve lab.test:18080:127.0.0.1 http://lab.test:18080/
sudo docker compose logs --tail 20 gateway
sudo docker compose start web
curl --fail --resolve lab.test:18080:127.0.0.1 http://lab.test:18080/

Während des Stopps erwartest du einen Gatewayfehler oder eine Zeitüberschreitung statt der HTML-Seite. Nach dem Start sollte die Seite nach wenigen Sekunden wieder antworten. Prometheus kann währenddessen für den Gateway weiterhin up=1 melden: Dessen Metriken sind erreichbar, obwohl die Anwendung ausfällt. Deshalb ergänzen Erreichbarkeitsprüfungen die Metriken.

Bei einem getöteten Container prüfst du State.OOMKilled mit einer gezielten docker inspect --format-Abfrage und vergleichst Speicherlimit und Verbrauch. Veröffentliche keine vollständige inspect-Ausgabe; sie kann Zugangsdaten enthalten.

Notiere Symptom, Fehlermeldung, eine Änderung und Ergebnis. Das hilft später mehr als eine Liste von Neustarts. Weiter: Backup und Wiederherstellung.

Alle Notizen →