Docker Monitoring für jeden Container auf jedem Host
Erfassen Sie CPU, Speicher, Netzwerk, Disk-I/O und Restarts jedes Docker-Containers, verknüpfen Sie sie mit Container-Logs und Traces und sehen Sie, welcher Service hinter jedem Container steht.
Warum Docker mit Obseria überwachen
Automatische Container-Erkennung
Neue Container werden beim Start erkannt, mit Image, Name und Labels. So sind auch kurzlebige Workloads abgedeckt.
Metriken, Logs und Traces zusammen
Container-Statistiken, stdout-Logs und OpenTelemetry-Traces teilen dieselben Container- und Service-Metadaten.
Vom Container zum Service
Obseria TopoGraph ordnet Container den Services, Hosts und Abhängigkeiten zu. Sie sehen die Auswirkung, nicht nur eine Container-ID.
Docker-Komponenten, die Obseria überwacht
- Container. CPU, Speicher, Netzwerk, Block-I/O, PIDs, Restarts und Uptime jedes laufenden Containers.
- Docker-Hosts. CPU, Speicher, Disk und Netzwerk des Hosts aus dem Obseria Agent, direkt neben seinen Containern.
- Images und Labels. Image-Name, Tag und Container-Labels als Attribute zum Filtern und Gruppieren.
- Container-Logs. stdout- und stderr-Logs pro Container, geparst und mit Container-Metadaten angereichert.
- Docker-Compose-Stacks. Services aus Compose-Dateien, gruppiert nach Projekt- und Service-Labels.
- Containerisierte Anwendungen. Traces und Anwendungsmetriken aus OpenTelemetry SDKs im Container.
Die Docker-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Genutzte Rechenleistung
Zeigt, wie stark Ihre Container arbeiten und ob sie durch zu enge Grenzen ausgebremst werden.
Reserven beim Speicher
Zeigt, wie nah jeder Container an seiner Speichergrenze ist, damit Abstürze durch vollen Speicher vermieden werden.
Netzwerk- und Festplattenverkehr
Macht sichtbar, wie viele Daten Ihre Container senden, empfangen und schreiben, um Engpässe und Auffälligkeiten zu finden.
Stabilität der Container
Hebt Container hervor, die ständig neu starten oder zu viele Prozesse öffnen, frühe Hinweise auf versteckte Probleme.
Alle 9 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
container.cpu.utilization | 1 | Anteil der Host-CPU, den der Container nutzt. |
container.cpu.throttling_data.throttled_time | ns | Zeit, in der der Container durch sein CPU-Limit gedrosselt wurde. |
container.memory.usage.total | By | Vom Container genutzter Speicher, ohne Page Cache, sofern gemeldet. |
container.memory.usage.limit | By | Speicherlimit des Containers; im Vergleich zur Nutzung lassen sich OOM Kills vorhersehen. |
container.network.io.usage.rx_bytes | By | Vom Container empfangene Bytes pro Netzwerkschnittstelle. |
container.network.io.usage.tx_bytes | By | Vom Container gesendete Bytes pro Netzwerkschnittstelle. |
container.blockio.io_service_bytes_recursive | By | Vom Container gelesene und geschriebene Bytes auf Block-Devices. |
container.restarts | {restart} | Anzahl der Neustarts des Containers. |
container.pids.count | {pid} | Prozesse und Threads im Container, hilfreich gegen Fork-Stürme und Lecks. |
Docker-Monitoring in wenigen Minuten einrichten
- Schritt 1
Agent auf dem Host installieren
Installieren Sie den Obseria Agent auf jedem Docker-Host oder betreiben Sie ihn als Container mit Lesezugriff auf den Docker-Socket.
- Schritt 2
Alternativ den OpenTelemetry Collector nutzen
Konfigurieren Sie den docker_stats Receiver gegen den Docker-Socket und exportieren Sie per OTLP an Obseria.
- Schritt 3
Anwendungen instrumentieren
Übergeben Sie OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT und OTEL_EXPORTER_OTLP_HEADERS als Umgebungsvariablen an Container mit OpenTelemetry SDKs.
receivers:
docker_stats:
endpoint: unix:///var/run/docker.sock
metrics:
container.restarts:
enabled: true
container.cpu.throttling_data.throttled_time:
enabled: true
hostmetrics:
scrapers:
cpu: {}
memory: {}
processors:
batch: {}
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [docker_stats, hostmetrics]
processors: [batch]
exporters: [otlphttp]Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Übersicht über Docker-Hosts und Container
- Top-Container nach CPU und Speicher
- Alerts für Container-Restarts und OOM
- CPU-Drosselung pro Container
- Netzwerk und Disk-I/O der Container
Docker-Monitoring: Darauf kommt es an
Warum Docker Monitoring anders ist
Docker Monitoring ist kein Host-Monitoring mit mehr Prozessen. Container starten und stoppen innerhalb von Sekunden, teilen sich den Kernel des Hosts, laufen mit eigenen CPU- und Speicherlimits und tragen IDs, die sich mit jedem Deployment ändern. Klassische Werkzeuge, die Maschinen und langlebige Prozesse verfolgen, verlieren hier schnell den Faden. Container Monitoring muss Container automatisch erkennen, aussagekräftige Metadaten wie Image, Compose-Service oder Labels anhängen und die Historie auch dann behalten, wenn ein Container längst beendet ist.
Docker Observability heißt außerdem, in den Container hineinzuschauen. Ressourcenmetriken zeigen, dass ein Container ausgelastet ist oder nahe am Speicherlimit läuft. Logs und Traces der Anwendung zeigen, warum. Beide Sichten brauchen dieselben Kennungen, damit Sie mit einem Klick von der einen in die andere wechseln können.
Die Docker-Container-Metriken, auf die es ankommt
Die Docker Engine stellt Statistiken pro Container über ihre API bereit, dieselben Daten, die auch docker stats anzeigt. Die wichtigsten Signale:
- CPU:
container.cpu.utilizationzeigt die Nutzung im Verhältnis zum Host.container.cpu.throttling_data.throttled_timezeigt, wie lange der Container wegen seines CPU-Limits warten musste, oft die versteckte Ursache für Latenz. - Speicher:
container.memory.usage.totalim Vergleich zucontainer.memory.usage.limit. Erreicht die Nutzung das Limit, beendet der Kernel den Prozess. - Netzwerk:
container.network.io.usage.rx_bytesundtx_bytessowie Fehler und verworfene Pakete pro Schnittstelle. - Block-I/O:
container.blockio.io_service_bytes_recursivefür Lese- und Schreibvorgänge, wichtig für Datenbanken und Container mit viel Log-Ausgabe. - Lebenszyklus:
container.restarts, Uptime undcontainer.pids.countdecken Crash Loops und außer Kontrolle geratene Prozesse auf.
Typische Docker-Probleme und wie Sie sie erkennen
OOM Kills. Ein Container, der sein Speicherlimit überschreitet, wird beendet und mit Restart Policy wieder gestartet, oft unbemerkt. Steigende Speichernutzung bis zum Limit mit anschließendem Restart ist das Muster, auf das Sie alarmieren sollten.
CPU-Drosselung. Ein Container kann im Mittel moderate CPU zeigen und trotzdem in kurzen Spitzen gedrosselt werden, was Requests verlangsamt. Die gedrosselte Zeit pro Container macht das sichtbar, Traces bestätigen die Auswirkung auf die Antwortzeiten.
Laute Nachbarn. Mehrere Container auf einem Host konkurrieren um Disk und Netzwerk. Der Vergleich von Block-I/O und Netzwerk-Bytes der Container auf demselben Host zeigt, welcher die anderen ausbremst.
Volle Host-Disk. Container-Logs, Image-Layer und Volumes füllen die Disk des Hosts mit der Zeit. Dateisystem-Metriken des Agents warnen frühzeitig, bevor der Docker-Daemon Fehler meldet.
Crash Loops nach einem Deployment. Ein neues Image, das beim Start fehlschlägt, erzeugt eine Folge kurzlebiger Container. Restart-Zähler pro Image-Tag zeigen zusammen mit den Container-Logs schnell das fehlerhafte Release.
Best Practices für Docker Monitoring
- Setzen Sie explizite CPU- und Speicherlimits, damit sich die Nutzung mit einer bekannten Obergrenze vergleichen lässt.
- Verwenden Sie Labels für Service, Team und Version und halten Sie sie über Images und Compose-Dateien hinweg konsistent.
- Schreiben Sie Logs strukturiert nach stdout und stderr, damit sie ohne eigene Regeln geparst werden können.
- Alarmieren Sie auf Restarts, OOM Kills und Drosselung, nicht nur auf hohe CPU.
- Instrumentieren Sie Anwendungen mit OpenTelemetry, damit Traces die Identität von Container und Service tragen.
So überwacht Obseria Docker
Der Obseria Agent läuft auf jedem Docker-Host, erkennt Container über die Docker-API und erfasst Container-Metriken, Host-Metriken und Container-Logs mit Image- und Label-Metadaten. Wenn Sie offene Standards bevorzugen, sendet der OpenTelemetry Collector mit dem Docker Stats Receiver dieselben Signale per OTLP. Anwendungen im Container senden Traces über OpenTelemetry SDKs. Obseria TopoGraph verknüpft Container mit Hosts, Services und Abhängigkeiten, Obseria Pipeline filtert und maskiert Logs bei der Ingestion, und Obseria Intelligence findet anhand der Topologie die Ursache, wenn ein Container Probleme macht. Wechseln Sie später von Docker-Hosts zu Kubernetes oder OpenShift, bleibt das Metadatenmodell gleich, und Ihre Dashboards und Alerts funktionieren weiter.
Abgerechnet wird nach Nutzung pro Signal, nicht nach Hosts oder Containern. Viele kurzlebige Container verursachen also keine zusätzlichen Lizenzkosten, und gefilterte Logs kosten nur die Ingestion.
Verwandte Integrationen
Passende Funktionen
Kubernetes Monitoring
Sehen Sie jeden Cluster, Node, Pod und Workload im Kontext. Obseria verknüpft Metriken, Events, Logs und Traces, damit Sie die Ursache eines fehlerhaften Rollouts in Minuten finden.
Mehr erfahrenDistributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenMehr erfahren
Was ist Observability?
Was ist Observability? Wie Metriken, Logs, Traces und Profile Ihre Systeme verständlich machen und was Observability vom Monitoring unterscheidet.
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Häufige Fragen zum Docker-Monitoring
Der Obseria Agent oder der OpenTelemetry Collector liest die Statistiken pro Container über den Docker-Socket aus der Docker-Engine-API, dieselbe Datenquelle wie docker stats.
Ja. Der Agent erfasst stdout- und stderr-Logs pro Container und reichert sie mit Container-Name, Image und Labels an. Obseria Pipeline kann die Logs vor der Speicherung filtern und maskieren.
Ja. Restarts und Speichernutzung im Verhältnis zum Limit werden pro Container erfasst, und vorkonfigurierte Alerts melden Restart-Schleifen und Container nahe am Speicherlimit.
Für Metriken und Logs nicht, sie werden vom Host erfasst. Für Traces ergänzen Sie ein OpenTelemetry SDK oder Auto-Instrumentierung und setzen die OTLP-Umgebungsvariablen.
Ja. Projekt- und Service-Labels von Compose werden automatisch an die Container angehängt, sodass Sie Metriken und Logs nach Compose-Service gruppieren können.
Starten Sie heute mit dem Docker-Monitoring
Binden Sie Docker in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.