Docker-Containerprotokolle nach Dockerd-Neustart nicht gefunden

Docker-Containerprotokolle nach Dockerd-Neustart nicht gefunden

Ich betreibe einen Ubuntu 18.04-Server mit darauf laufenden Docker-Containern (v20.10.12). Ich habe ungefähr 5 Container gleichzeitig laufen und sie verbrauchen regelmäßig ungefähr 1,5 GB Speicher, während mein Server 8 GB Speicher zur Verfügung hat. Einer dieser 5 Container verliert alle 18-24 Stunden Speicher, er verbraucht den gesamten verbleibenden Speicher und benötigt ungefähr 4-5 GB im Swap, wodurch meine CPU- und Festplattenauslastung auf 100 % ansteigt, was wiederum dazu führt, dass der OOM-Killer erscheint und mit der Aussonderung von Prozessen beginnt, und einer davon ist Dockerd.

Nachdem Dockerd beendet wurde, kann ich die Protokolle des besagten Containers mit dem Speicherverlust nicht finden, da die einzigen, die ich im Dateisystem habe, die der Container sind, die nach dem Neustart von Dockerd erstellt wurden. Ohne die Protokolle tappe ich also völlig im Dunkeln, was in diesem Container tatsächlich vor sich ging, und genau das versuche ich herauszufinden.

Ich habe herausgefunden, welcher Container mit durchgesickert ist, grep VmPeak /proc/{PID}/statusund habe die PIDs mit erhalten docker inspect -f '{{.State.Pid}}' {CONTAINER_ID}, die in einem Fall die maximale Speichernutzung von ~11 GB auflisteten. Aber als ich /var/lib/docker/containers/alle Ordner überprüft habe, hatte keiner Protokolle vor dem eigentlichen OOM-Killer-Swipe und dem Neustart von Dockerd. Ich habe auch versucht, mir anzusehen, var/log/syslogund es hat mir nur gezeigt, wie der OOM-Killer seine Arbeit macht und Dockerd mit verschiedenen Netzwerk- und Firewall-Fehlern in Panik gerät. Wenn ich falsch liege und tief in das Syslog eintauchen sollte, lassen Sie es mich bitte wissen.

Ich muss diese Protokolle nicht unbedingt abrufen. Etwas Hilfe beim Einrichten einer anderen Lösung, die die Protokolle an einem anderen Ort speichert, sodass ich sie beim nächsten Absturz überprüfen kann, wäre ebenfalls sehr hilfreich und könnte das Problem möglicherweise lösen. Dies hat jedoch nichts mit dem vorliegenden Problem zu tun, daher verstehe ich, wenn es ignoriert wird.

verwandte Informationen