Docker Monitoring
What Is Docker?
Docker is an open platform that packages applications and their dependencies into lightweight, portable units called containers. A container bundles everything the software needs to run — code, runtime, system tools, libraries, and settings — so it behaves the same way on a developer’s laptop, in staging, and in production. Because containers share the host operating system’s kernel instead of shipping a full guest OS, they start in milliseconds and use far fewer resources than virtual machines.
Under the hood, containers are built from two Linux kernel features: namespaces, which isolate what a process can see (its own filesystem, network, and process tree), and control groups (cgroups), which limit and account for the resources a group of processes can use. Understanding cgroups matters for monitoring, because that is exactly where the most useful container metrics come from.
What Is the Docker Engine?
The Docker Engine is the core of the platform — the daemon (dockerd) that builds images, creates and runs containers, and manages their networks and volumes. It is the industry’s de facto container runtime and runs on the major Linux distributions (CentOS, Debian, Fedora, Oracle Linux, RHEL, SUSE, Ubuntu) as well as Windows Server. When people say “monitor Docker,” they are usually interested in two related layers: the containers themselves (their resource usage and health) and the Docker Engine daemon that orchestrates them.
Why Is Docker Monitoring Important?
Containers are lightweight and efficient, but without visibility they become a black box. Monitoring Docker lets you:
- Detect performance bottlenecks early — catch CPU spikes, memory leaks, and disk I/O saturation before they reach users.
- Understand behavior at scale — see how services behave under load or during autoscaling when tracking metrics per container.
- Meet SLAs and uptime targets — get alerted on resource saturation, restart storms, and unexpected exits.
- Right-size and control cost — use real usage data to avoid overprovisioning and prevent noisy-neighbor problems.
- Troubleshoot faster — drill into real-time and historical metrics to isolate an issue in a single container without recreating the bug.
What Are the Benefits of Docker Monitoring Tools?
A good Docker monitoring tool gives you:
- Real-time visibility into container state, health, and resource usage.
- Insight into which container — and which process inside it — is consuming resources.
- The ability to evaluate images and containers and track their current state.
- Alerting that catches health-check failures, out-of-memory kills, and restart loops.
How Netdata Monitors Docker
Netdata collects Docker telemetry from three complementary sources, all with zero configuration and at per-second granularity:
Per-container resource metrics via cgroups. Netdata reads the virtual files Linux exposes (usually under
/sys/fs/cgroup/) to report each container’s CPU, memory, disk I/O, and network usage. It scans for new and removed cgroups every few seconds (configurable viacheck for new cgroups everyinnetdata.conf), so containers are picked up automatically as they start and cleaned up when they stop. This is the same cgroups mechanism Docker itself uses for resource isolation.Container state and health via the Docker collector. Netdata connects to the Docker instance over a TCP or UNIX socket and calls the Docker API — System info, List images, and List containers — to report how many containers are running, paused, or stopped, their health-check status, and image counts and sizes.
Daemon-level metrics via the Docker Engine collector. For the
dockerddaemon itself, Netdata uses the built-in Prometheus exporter to collect engine-wide metrics: container actions, build failures, health-check failures, and Docker Swarm manager state.
Because collection is per-second and auto-discovered, you see the exact moment a problem begins — not a 30- or 60-second average that hides it.
Key Docker Metrics to Monitor — and Why
Container state and health (Docker collector)
- docker.containers_state — total number of containers by state (running, paused, stopped). Sudden shifts here often signal crash loops or a failed deploy.
- docker.containers_health_status — health status across containers (healthy, unhealthy, starting). A rising unhealthy count is an early outage warning.
- docker.images — count of active and dangling images. Dangling images are a common cause of creeping disk usage.
- docker.images_size — total size of all images, useful for capacity planning.
- docker.container_state — per-container state (running, paused, exited, and more).
- docker.container_health_status — per-container health-check result.
- docker.container_writeable_layer_size — the writable-layer size of each container, a key capacity-planning metric.
| Metric | Description |
|---|---|
| docker.containers_state | Number of containers in each state |
| docker.containers_health_status | Health status across all containers |
| docker.images | Active and dangling image counts |
| docker.images_size | Total size of Docker images |
| docker.container_state | State of an individual container |
| docker.container_health_status | Health status of an individual container |
| docker.container_writeable_layer_size | Writable-layer size per container |
Per-container resource usage (cgroups)
For every container, Netdata tracks CPU usage and throttling, memory (used, cache, swap, and pressure), disk reads and writes, and network bandwidth, packets, and errors per interface — all per second, on both cgroups v1 and v2 with automatic detection. These are the metrics you reach for when an application slows down and you need to know which container is starving for CPU or leaking memory.
Docker Engine daemon metrics (Docker Engine collector)
- Engine daemon container actions — the rate of container actions (create, delete, start, commit, change) the daemon performs. Useful for spotting churn and unexpected spikes in container activity.
- Engine daemon container states — how many containers the daemon is managing in each state (running, paused, stopped).
- Builder builds failed total — the rate of failed image builds, broken down by reason. A spike points to a broken base image, registry issue, or bad Dockerfile.
- Engine daemon health checks failed total — the rate of failed container health checks the daemon runs.
- Swarm manager leader — whether this node is the current Swarm manager leader. Flapping leadership indicates cluster instability.
- Swarm manager object store — number of objects (nodes, services, tasks, networks, secrets, configs) held by the Swarm manager.
- Swarm manager nodes per state — Swarm nodes by state (ready, down, unknown, disconnected).
- Swarm manager tasks per state — Swarm tasks across their lifecycle states (running, failed, ready, rejected, shutdown, complete, and more).
Zero-Configuration Auto-Discovery
The best part of monitoring Docker with Netdata is that it is zero-configuration. If containers are already running when you install Netdata, it auto-detects them and starts collecting metrics immediately. Spin up new containers afterward — docker compose up, a docker run, a Swarm task, or a Kubernetes pod — and they appear in the dashboard within seconds, with the right charts and alerts already attached. Stop a container and it is cleaned up automatically. Netdata handles ephemeral, short-lived containers without complaint, which is exactly what dynamic environments need.
Monitor Many Containers — and the Apps Inside Them
Netdata auto-populates its menus with your containers by ID or name and scales to any number of them, whether you run 1, 100, or 1,000. It organizes CPU and memory charts into families so you can quickly see which containers use the most CPU, memory, disk I/O, or network, and correlate that with the rest of the system.
Monitoring doesn’t stop at the container boundary. Netdata can also monitor the applications running inside containers — a MySQL database, an Nginx web server, a Postgres instance — using the same auto-discovery, so you get application-specific metrics and pre-configured alerts alongside the container’s resource usage.
Pre-Configured Alarms
Netdata ships with alarms for every running container out of the box. As soon as a container is detected, Netdata attaches CPU-utilization, RAM-usage, and RAM+swap-usage alarms for its cgroup, calculated against the limits you set — so they adapt automatically to any container size. You can edit health.d/cgroups.conf to change thresholds or add your own. On top of static thresholds, Netdata’s edge-based machine learning trains models per metric to flag genuine anomalies — restart storms, throttling, OOM kills, and health-check failures — without threshold guesswork.
Is Docker Monitoring Secure With Netdata?
Security matters when you instrument production containers. Netdata is designed with this in mind:
- Read-only by default — Netdata collects container metrics without elevated privileges or modifying containers.
- Minimal footprint — the agent is lightweight and exposes little attack surface.
- Container isolation — metrics are collected externally via cgroups and system files, so monitoring never interferes with container behavior.
- Data stays local — when connected to Netdata Cloud, metric data is encrypted in transit and stays on your infrastructure; only metadata leaves the node.
For stricter environments, Netdata can run with reduced permissions and inside its own container for additional isolation.
Advanced Docker Monitoring and Root-Cause Analysis
Beyond charts and alarms, effective Docker monitoring means being able to answer “why” quickly. Netdata’s Anomaly Advisor correlates thousands of metrics to surface the handful most likely responsible for an incident, and its browser-based troubleshooting tools show the processes and network connections inside a container — with history — so you can diagnose problems without docker exec or SSH. For hands-on, symptom-specific procedures, see the Docker operations guides: step-by-step runbooks for disk exhaustion, OOM cascades, daemon hangs, log explosions, container restart loops, and network isolation.
When you are ready to see it running against your own containers, the Live Demo needs no login, and you can learn how the full platform approaches this on the Docker monitoring solution page.
Troubleshooting Docker Monitoring in Netdata
If container metrics or alarms are not appearing as expected, work through these checks:
- Verify cgroup access — make sure the Netdata agent can read from
/sys/fs/cgroup/. - Check container timing — containers started before Netdata are detected on the next scan; if in doubt, restart Netdata to trigger immediate detection.
- Confirm cgroup version — Netdata supports both cgroups v1 and v2, but a misconfigured kernel can interfere. Confirm your system’s cgroup version.
- Review container limits — on hosts running many containers, consider adjusting Netdata’s resource limits or update frequency.
- Inspect alarm configuration — check
health.d/to confirm alarms are enabled and thresholds are calibrated for your environment.
FAQs
What is Docker monitoring?
Docker monitoring is the practice of tracking the performance, resource usage, and health of Docker containers and the Docker Engine daemon, using tools that collect metrics such as CPU, memory, disk I/O, network, container state, and health-check status.
Why is Docker monitoring important?
It prevents downtime, keeps performance optimized, controls cost through right-sizing, and enables real-time troubleshooting when something goes wrong in a containerized application.
What does a Docker monitor do?
A Docker monitor tracks container states, health status, per-container resource utilization, and daemon-level metrics, and alerts you when key indicators cross a threshold or behave anomalously.
What is the difference between Docker and the Docker Engine?
Docker is the overall platform for building and running containers. The Docker Engine is the daemon (dockerd) at its core that actually builds images and runs containers. Netdata monitors both the containers and the engine.
Do I need to run Netdata inside every container?
No. One Netdata agent per host monitors all containers on that host. It reads cgroup metrics directly from the kernel — no sidecars and no per-container agents.
Why don’t I see my containers in Netdata?
Confirm the agent can read from /sys/fs/cgroup/ and that containers were running when Netdata started. If they were started afterward, wait for the next auto-discovery scan or restart Netdata to detect them immediately.
Does Netdata support Kubernetes and Docker Swarm?
Yes. Netdata monitors containers regardless of orchestrator. It reads per-container metrics via cgroups under Docker, Docker Compose, Docker Swarm, and Kubernetes, and adds Swarm-manager metrics via the Docker Engine collector.
How can I monitor Docker in real time?
Install Netdata on any host running the Docker daemon. It auto-discovers your containers and gives you per-second dashboards, alerts, and ML-based anomaly detection out of the box.






