Zum Inhalt springen
EN Kostenlos starten

Docker-Container überwachen: Compose-Anleitung

Docker-Container überwachen mit Compose: CPU, RAM, Netzwerk, I/O und Zustand jedes Service. Mit Agent-Image, Socket-Proxy und Alarm, wenn ein Service steht.

Zuletzt geprüft am

Docker-Container überwachen Sie mit inping, indem Sie den Agenten als Service in die Compose-Datei Ihres Projekts aufnehmen. Er meldet für jeden Service CPU, Arbeitsspeicher, Netzwerk, Platten-I/O und ob er läuft, dazu die Werte des Hosts. Steht ein Service, öffnet sich mit der nächsten Meldung ein Alarm. Auf den Docker-Socket greift der Agent nur über einen Proxy zu, der jedes Schreiben ablehnt.

Was sehen Sie danach?

  • Services: eine Zeile pro Service des Compose-Projekts mit Zustand, CPU, Arbeitsspeicher, Netzwerk und I/O. Die Raten erscheinen innerhalb von zwei Intervallen, weil sie zwei Messungen brauchen.
  • Der Host: CPU, Arbeitsspeicher, Last und Festplatten, gelesen über schreibgeschützte Mounts von /proc, /sys und /.
  • Projekt → Pakete: die Pakete aus den Lock-Dateien des eingebundenen Projektverzeichnisses.

Nicht gemeldet werden im Container: Host-Pakete und geplante Aufgaben (es wären die des Containers), Laufzeitversionen wie php -v (sie lassen sich nicht über Containergrenzen abfragen) und Pakete innerhalb der Images anderer Services.

Was sollten Sie bei Containern im Blick behalten?

  • Läuft er überhaupt? Der Zustand ist Dockers Zustand running. Ein Container in einer Neustart-Schleife gilt immer dann als nicht laufend, wenn eine Messung ihn beim Neustart erwischt. Ein Container, der läuft, aber nicht mehr antwortet, gilt weiter als laufend. Prüfen Sie Webdienste deshalb zusätzlich von außen mit einem HTTP(S)-Check auf die URL.
  • Arbeitsspeicher gegen das Limit: inping setzt den Speicher ohne Datei-Cache ins Verhältnis zum Limit des Containers, ohne Limit zum Speicher des Hosts. Erreicht ein Container sein Limit, beendet der Kernel Prozesse darin. Ein Alarm vorher ist mehr wert als ein Neustart hinterher.
  • CPU: inping zeigt den Anteil an der CPU des ganzen Hosts (0 bis 100), nicht pro Kern wie docker stats. Die Container addieren sich so gegen die Auslastung des Hosts.
  • Platten des Hosts: Logs und Volumes liegen auf dem Host und füllen seine Platte. Die Regel für Festplatten gilt deshalb auch hier.

Voraussetzungen

  • Docker Engine mit Compose v2 auf dem Host und die docker-compose.yml des Projekts
  • ausgehendes HTTPS zu www.inping.io und zu ghcr.io
  • ein kostenloses inping-Konto und ein Registrierungs-Token (24 Stunden gültig)
  • Version und Digest des Images aus den Release-Hinweisen in der App unter Agents → Installation und Downloads (/agents/install)

Schritt für Schritt

Der Reiter Docker im Dialog Agents → Agent hinzufügen zeigt alle drei Teile mit Ihren Werten. Hier stehen Platzhalter.

1. Drei Zeilen in die .env neben der Compose-Datei

INPING_AGENT_IMAGE=ghcr.io/medienakzent/inping-agent:<version>@sha256:<digest>
INPING_API_URL=https://www.inping.io
INPING_PROJECT_ID=<project-id>

Das Image ist auf Version und Digest festgelegt. Einen beweglichen Tag wie latest gibt es nicht: Eine manipulierte Registry kann den Agenten so beim pull nicht austauschen.

2. Services, Config, Volume und Netz in die Compose-Datei

Fügen Sie die folgenden Teile in die Compose-Datei des Projekts ein. Der Agent läuft mit schreibgeschütztem Dateisystem, ohne Capabilities und als Benutzer 65532; schreiben kann er nur ins Volume inping-agent-state.

services:
  inping-agent:
    image: ${INPING_AGENT_IMAGE:?set INPING_AGENT_IMAGE to a release}
    restart: unless-stopped
    read_only: true
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    configs:
      - source: inping-agent
        target: /etc/inping/agent.toml
    volumes:
      - inping-agent-state:/var/lib/inping-agent
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/host/root:ro
      - ./:/srv/app:ro
    networks: [default, inping]
    depends_on: [inping-docker-proxy]

  inping-docker-proxy:
    image: tecnativa/docker-socket-proxy:0.3.0
    restart: unless-stopped
    environment:
      CONTAINERS: 1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks: [inping]

configs:
  inping-agent:
    content: |
      api_url = "${INPING_API_URL:?set INPING_API_URL}"
      state_dir = "/var/lib/inping-agent"

      [docker]
      endpoint = "tcp://inping-docker-proxy:2375"

      [[project]]
      id = "${INPING_PROJECT_ID:?set INPING_PROJECT_ID}"
      path = "/srv/app"

volumes:
  inping-agent-state:

networks:
  inping:
    internal: true

Der Proxy ist nicht optional: Er ist der einzige Service, der den Socket sieht, und sitzt im internen Netz inping. Er lehnt jedes Schreiben und alles außerhalb von /containers ab. Legen Sie auch sein Image per Digest fest, sobald Sie ihn ermittelt haben:

docker buildx imagetools inspect tecnativa/docker-socket-proxy:0.3.0

3. Einmal registrieren und starten

Das Token geht über die Standardeingabe hinein und landet in keiner Datei.

echo "<token>" | docker compose run --rm -T inping-agent register --token -
docker compose up -d

Pro Compose-Datei gibt es ein Projekt. Ein zweites Projekt auf demselben Host bekommt einen eigenen Agenten in seiner eigenen Compose-Datei.

Ohne Socket-Proxy

Der Agent kann den Socket auch direkt lesen: mit gemountetem /var/run/docker.sock, group_add mit der Gruppe des Sockets und dem Endpunkt unix:///var/run/docker.sock. Er sendet dann dieselben Anfragen, aber wer in seinen Container einbricht, hält den Host in der Hand. Nehmen Sie diesen Weg nur auf einem Host, auf dem nichts Fremdes neben dem Agenten läuft, etwa einem eigenen Synology NAS. Die Einzelheiten stehen in der Installationsanleitung, Kapitel 8.

Wie prüfen Sie, ob es funktioniert?

docker compose ps                        # inping-agent und inping-docker-proxy: Up
docker compose logs --tail 20 inping-agent

Das Log zeigt msg=starting, msg=configuration und msg="docker: reporting the agent's own Compose project" project=<name>. In inping erscheint auf der Seite des Agenten der Abschnitt Services. Fehlt er, schalten Sie unter Einstellungen → Erfasste Metriken die Metrik Services (Docker) ein.

Schwellwerte und Alarme

Die Regel für Services ist bei jedem neuen Agenten aktiv: Läuft ein Service nicht, öffnet sich sofort ein Alarm, der sich von selbst schließt, sobald er wieder läuft. Dazu kommen die Host-Regeln für CPU und Arbeitsspeicher (über 90 % für 5 Minuten) und Festplatten (über 90 % sofort).

Eigene Regeln legen Sie auf der Seite des Agenten unter Einstellungen → Alarmregeln an, für einen bestimmten Service oder für alle. Möglich sind CPU, Arbeitsspeicher in Prozent oder Byte, Netzwerk und I/O je Sekunde. Ein guter Start ist Arbeitsspeicher eines Service über 90 % für 5 Minuten.

Damit Sie davon erfahren, braucht das zugeordnete Projekt eine Benachrichtigungsregel, etwa für Service steht, Server-Schwellwert überschritten oder Agent offline, per Mail oder Webhook. Offline gilt der Agent nach drei ausgebliebenen Meldungen.

Update

Der Agent ersetzt sich im Container nie selbst. Tragen Sie die neue Version und den neuen Digest in die .env ein und ziehen Sie das Image neu:

docker compose pull inping-agent && docker compose up -d inping-agent

Deinstallieren

Entfernen Sie die zwei Services, die Config, das Volume und das Netz aus der Compose-Datei und führen Sie docker compose up -d --remove-orphans aus. Bei einer Kopie der Beispieldatei genügt docker compose down -v, wobei -v das Zustandsvolume löscht. Löschen Sie den Agenten danach in inping.

Wenn nichts ankommt

  • register meldet registration failed: Das Token ist abgelaufen oder benutzt, oder INPING_API_URL stimmt nicht. Die Meldung nennt die Antwort.
  • set INPING_AGENT_IMAGE to a release: Die .env liegt nicht neben der Compose-Datei, oder eine Variable fehlt.
  • Der Agent startet in einer Schleife neu: Sehen Sie in docker compose logs inping-agent nach. cannot start heißt, er wurde nie registriert (Schritt 3). docker source unusable heißt, der Proxy ist nicht erreichbar: Prüfen Sie, ob er im Netz inping hängt und ob der Endpunkt tcp://inping-docker-proxy:2375 lautet.
  • Host-Metriken kommen an, Services nicht: Der Proxy antwortet mit 403, weil CONTAINERS: 1 fehlt. Oder der Container des Agenten gehört zu keinem Compose-Projekt, dann wird jeder Container des Hosts gemeldet.
  • Die Pakete des Projekts fehlen: ./:/srv/app:ro bindet das falsche Verzeichnis ein. Die Lock-Dateien müssen ganz oben in /srv/app liegen.

Häufige Fragen

Was meldet der Agent pro Container?

Pro Service des Compose-Projekts den Namen, das Image, ob er läuft, den CPU-Anteil am gesamten Host, den Arbeitsspeicher ohne Datei-Cache mit dem Limit, außerdem Netzwerk und Platten-I/O je Sekunde. Dazu kommen die Werte des Hosts selbst: CPU, Arbeitsspeicher, Festplatten und Plattform.

Warum zeigt inping andere CPU-Werte als docker stats?

Docker rechnet pro Kern, ein Container kann dort über 100 % liegen. inping zeigt den Anteil an der CPU des ganzen Hosts von 0 bis 100, damit sich die Container gegen die Auslastung des Hosts aufaddieren.

Ist ein schreibgeschützter docker.sock-Mount nicht sicher genug?

Nein. Das :ro schützt nur die Socket-Datei, der Daemon nimmt weiterhin jeden Aufruf an. Wer den Socket erreicht, kann Container starten, stoppen und anlegen. Deshalb sieht der Agent nur den Socket-Proxy, der jedes Schreiben ablehnt.

Schützt der Socket-Proxy auch die Daten der anderen Container?

Nicht vollständig. Der Proxy lässt alle lesenden Aufrufe unter /containers zu, dazu gehören Inspect-Ausgaben mit Umgebungsvariablen, Logs und Dateien. Er schützt den Host vor dem Agenten, er ist aber keine Trennung zwischen den Containern. Der Agent selbst sendet für Metriken nur zwei GET-Anfragen, mit einer Docker-Log-Quelle zusätzlich die Abfrage der Container-Logs: die Containerliste und die Statistik.

Findet inping Schwachstellen in meinen Images?

Nein. Der Agent liest die Lock-Dateien des eingebundenen Projektverzeichnisses, nicht die Images der anderen Services. Das Image jedes Service wird nur mit gemeldet. Host-Pakete und geplante Aufgaben meldet die Container-Variante ebenfalls nicht.

Aktualisiert sich der Agent im Container selbst?

Nein. Im Container lehnt der Befehl inping-agent update das ab. Eine neue Version ist ein neues Image: Sie tragen Version und Digest in die .env ein und ziehen das Image neu.

Wie viele Agents brauche ich für mehrere Compose-Projekte?

Einen pro Compose-Datei, ein zweites Projekt auf demselben Host bekommt einen eigenen Agenten. Im Free-Tarif sind 2 Agents kostenlos enthalten.

Weiterlesen