Docker monitoring for every container on every host
Collect CPU, memory, network, disk I/O and restart data for every Docker container, correlate it with container logs and traces, and see which service is behind each container.
Why monitor Docker with Obseria
Automatic container discovery
New containers are picked up as they start, with image, name and labels attached, so short-lived workloads are covered too.
Metrics, logs and traces together
Container stats, stdout logs and OpenTelemetry traces share the same container and service metadata.
From container to service
Obseria TopoGraph maps containers to the services, hosts and dependencies they belong to, so you see impact, not just a container ID.
Docker components Obseria monitors
- Containers. CPU, memory, network, block I/O, PIDs, restarts and uptime for every running container.
- Docker hosts. Host CPU, memory, disk and network from the Obseria Agent, next to the containers they run.
- Images and labels. Image name, tag and container labels as attributes for filtering and grouping.
- Container logs. stdout and stderr logs per container, parsed and enriched with container metadata.
- Docker Compose stacks. Services from Compose files grouped by project and service labels.
- Containerized applications. Traces and application metrics from OpenTelemetry SDKs running inside containers.
The Docker signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Processing power
Shows how hard your containers are working and whether they are being slowed down by limits that are too tight.
Memory headroom
Tells you how close each container is to its memory limit, so crashes from running out are avoided.
Network and disk traffic
Reveals how much data your containers send, receive and write, helping you find bottlenecks and unusual activity.
Container stability
Highlights containers that keep restarting or start too many processes, which are early signs of hidden problems.
Show all 9 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
container.cpu.utilization | 1 | Share of host CPU used by the container. |
container.cpu.throttling_data.throttled_time | ns | Time the container was throttled by its CPU limit. |
container.memory.usage.total | By | Memory used by the container, excluding page cache where reported. |
container.memory.usage.limit | By | Memory limit of the container; compare with usage to predict OOM kills. |
container.network.io.usage.rx_bytes | By | Bytes received by the container per network interface. |
container.network.io.usage.tx_bytes | By | Bytes sent by the container per network interface. |
container.blockio.io_service_bytes_recursive | By | Bytes read from and written to block devices by the container. |
container.restarts | {restart} | Number of times the container was restarted. |
container.pids.count | {pid} | Processes and threads in the container, useful to catch fork storms and leaks. |
Set up Docker monitoring in minutes
- Step 1
Install the agent on the host
Install the Obseria Agent on each Docker host or run it as a container with read-only access to the Docker socket.
- Step 2
Or use the OpenTelemetry Collector
Configure the docker_stats receiver against the Docker socket and export to Obseria over OTLP.
- Step 3
Instrument the applications
Pass OTEL_SERVICE_NAME, OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS as environment variables to containers with 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]Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- Docker host and container overview
- Top containers by CPU and memory
- Container restart and OOM alerts
- CPU throttling per container
- Container network and disk I/O
Docker monitoring: what matters
Why Docker monitoring is different
Docker monitoring is not host monitoring with more processes. Containers start and stop within seconds, share the host kernel, run with their own CPU and memory limits and are identified by IDs that change on every deployment. Traditional tools that track machines and long-lived processes lose the thread quickly. Container monitoring needs to discover containers automatically, attach meaningful metadata such as image, Compose service or labels, and keep history even after a container is gone.
Docker observability also means looking inside the container. Resource metrics tell you that a container is busy or near its memory limit. Logs and traces from the application tell you why. Both views need the same identifiers so you can move from one to the other in a single click.
The Docker container metrics that matter
The Docker Engine exposes per-container statistics through its API, the same data behind docker stats. The most useful signals are:
- CPU:
container.cpu.utilizationshows usage relative to the host.container.cpu.throttling_data.throttled_timeshows how long the container waited because of its CPU limit, which is often the hidden cause of latency. - Memory:
container.memory.usage.totalcompared withcontainer.memory.usage.limit. When usage reaches the limit, the kernel kills the process. - Network:
container.network.io.usage.rx_bytesandtx_bytes, plus errors and dropped packets per interface. - Block I/O:
container.blockio.io_service_bytes_recursivefor reads and writes, important for databases and log-heavy containers. - Lifecycle:
container.restarts, uptime andcontainer.pids.countreveal crash loops and runaway processes.
Common Docker problems and how to detect them
OOM kills. A container that exceeds its memory limit is terminated, and with a restart policy it comes back, often silently. Memory usage climbing towards the limit, followed by a restart, is the pattern to alert on.
CPU throttling. A container can show moderate average CPU and still be throttled for short bursts, which adds latency to requests. Throttled time per container makes this visible, and traces confirm the effect on response times.
Noisy neighbors. Several containers on one host compete for disk and network. Comparing block I/O and network bytes across containers on the same host identifies the one that starves the others.
Disk full on the host. Container logs, image layers and volumes fill the host disk over time. Host filesystem metrics from the agent give early warning before the Docker daemon starts failing.
Crash loops after a deploy. A new image that fails on start produces a sequence of short-lived containers. Restart counts by image tag, together with the container logs, show the failing release quickly.
Docker monitoring best practices
- Set explicit CPU and memory limits so usage can be compared with a known ceiling.
- Use labels for service, team and version and keep them consistent across images and Compose files.
- Write logs to stdout and stderr in a structured format so they can be parsed without custom rules.
- Alert on restarts, OOM kills and throttling, not only on high CPU.
- Instrument applications with OpenTelemetry so traces carry the container and service identity.
How Obseria monitors Docker
The Obseria Agent runs on each Docker host, discovers containers through the Docker API and collects container metrics, host metrics and container logs with image and label metadata. If you prefer open standards, the OpenTelemetry Collector with the Docker stats receiver sends the same signals over OTLP. Applications inside containers send traces through OpenTelemetry SDKs. Obseria TopoGraph links containers to hosts, services and dependencies, Obseria Pipeline filters and masks logs at ingest, and Obseria Intelligence uses the topology to find the root cause when a container misbehaves. When you move from Docker hosts to Kubernetes or OpenShift, the same metadata model carries over, so dashboards and alerts keep working.
Related integrations
Related capabilities
Kubernetes Monitoring
See every cluster, node, pod and workload in context. Obseria connects Kubernetes metrics, events, logs and traces so you find the cause of a failing rollout in minutes.
Learn moreDistributed Tracing
Follow each request across services, queues and databases with OpenTelemetry-native distributed tracing, and find the slow span or failing dependency in seconds.
Learn moreAnomaly Detection
Obseria Intelligence learns the normal rhythm of every service, flags real deviations instead of threshold noise and groups related anomalies into one problem with a probable root cause.
Learn moreLearn more
What is observability?
What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.
The four golden signals: latency, traffic, errors and saturation
The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.
Docker monitoring FAQ
The Obseria Agent or the OpenTelemetry Collector reads per-container statistics from the Docker Engine API through the Docker socket, the same data source as docker stats.
Yes. The agent collects stdout and stderr logs per container and enriches them with container name, image and labels. Obseria Pipeline can filter and mask the logs before storage.
Yes. Restart counts and memory usage against limits are collected per container, and out-of-the-box alerts notify you about restart loops and containers close to their memory limit.
No for metrics and logs, which are collected from the host. For traces, add an OpenTelemetry SDK or auto-instrumentation and set the OTLP environment variables.
Yes. Compose project and service labels are attached to containers automatically, so you can group metrics and logs by Compose service.
Start monitoring Docker today
Connect Docker in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.