A container reporting “up” tells you the process is running, not that the workload is healthy – but that caveat is true of any service, on a container or a bare server. What makes containers their own monitoring problem is the layer around the process: per-container CPU and memory limits that throttle or kill workloads, automatic restart policies that mask a crash loop as “running,” images that drift from the registry, and counts that shift as containers are created and removed. None of that shows up if you only watch the host the container sits on.
If you already run Docker in production, you know this. The question is usually not why to monitor containers but how to fold container health into the monitoring you already have, without standing up yet another separate tool for one part of your stack.
What Icinga is
Icinga is an open-source monitoring system for infrastructure of any size. It monitors hosts, services, network devices, databases, applications, cloud resources, and containers from one place, and it scales from a single server to millions of checks across distributed environments. Checks run as plugins, small programs that test one thing and return a status, so anything you can query, you can monitor.
For containers, that matters in a specific way: Docker becomes one more set of checks alongside the operating system underneath it, the load balancer in front of it, and the database behind it. You see the container and its surroundings on the same dashboard, with the same alerting rules and the same notification paths. No separate silo for the container layer.
How Icinga monitors Docker
Icinga checks Docker through plugins that talk to the Docker daemon, either over the local Unix socket or a remote TCP connection. Each plugin focuses on a particular angle: container health and resources, daemon-wide status, or per-container CPU and memory. You pick the ones that match what you need to watch and wire them into your Icinga configuration like any other check.
We maintain a directory of Docker monitoring plugins at icinga.com/plugin-vendor/docker. It is the best starting point: it lists the community-built and vendor-built plugins for Docker, Docker Swarm, and daemon health, with links straight to each project. Below are three that cover the most common needs.
Docker Container Health Check (by timdaman)
This plugin monitors individual Docker containers and Docker Swarm services. For a single container it checks CPU and memory usage (with both absolute and percentage-based thresholds), container status, health check results, uptime, automatic restart counts, and container presence. It can also compare the running image version against the registry and flag image age, which is useful for catching containers running stale builds. For Swarm, it verifies node membership and service availability.
It talks to the Docker daemon over a local Unix socket or a remote TCP connection, with optional TLS, and supports regex-based matching for container and service names. Checks run concurrently via threading, and the plugin outputs standard Icinga performance data. It needs Python 3 and installs via pip or direct download.
This is the plugin to reach for when you want detailed per-container health and resource checks, including the running-image-versus-registry comparison.
Docker Info Check (by Linuxfabrik)
This plugin reports system-wide Docker information by running docker info and parsing the output. It reports container counts (running, paused, stopped), image count, storage driver, logging driver, registry, Docker version, available CPUs, and total memory. It also watches the daemon’s stderr: warnings return WARN, errors or a non-zero exit code return CRIT.
Known benign warnings, such as No swap limit support or bridge-nf-call-iptables is disabled, can be filtered out with the --ignore parameter using Python regular expressions, so you are not alerted on noise. The plugin needs root or sudo to read daemon information and provides performance data for total containers, running/paused/stopped counts, image count, CPU count, and total RAM. A check once per day is the recommended interval. For Podman environments, use the separate podman-info plugin instead.
Use this one to keep an eye on the health and configuration of the Docker daemon itself, rather than individual workloads.
Docker Stats Check (by Linuxfabrik)
This plugin reports CPU and memory usage for all running Docker containers by running docker stats --no-stream together with docker info. CPU usage is normalized by the number of host CPU cores, so 100% means full host utilization rather than a single core. To avoid alerting on short spikes, CPU alerts only fire after the threshold has been exceeded for a configurable number of consecutive runs (default: 5); memory alerts fire immediately. Memory usage is measured against the container’s memory limit if one is set, otherwise against total host memory.
Per-container CPU values are stored in a local SQLite database for trend tracking across runs. The plugin needs root or sudo and can take up to 10 seconds per run. Container names are shortened after the replica number by default, with the --full-name flag to show full names, and warning and critical thresholds are configurable for both CPU and memory. For Podman, use the dedicated podman-stats check instead.
This is the plugin for resource usage across all running containers at once, with built-in spike suppression and trend history.
Other Docker monitoring plugins
The Docker plugin directory covers more than the three plugins above. Additional plugins available include:
- Swarm replica counts – verify that all expected replicas are running for a given Swarm service
- Container state parsing – detailed state inspection beyond running/stopped/paused
- Package upgrade checks – flag containers running outdated packages inside the image
- Synthetic checks in containers – run website or endpoint tests from inside a container
- Broader plugin collections – suites like Linuxfabrik’s monitoring plugins cover Docker alongside hundreds of other services, useful if you want consistent check formatting across your stack
Browse the directory filtered by “Docker” to find what fits your environment. Most plugins follow the same Icinga plugin API, so adding them is the same as adding any other check.
Docker containers versus Kubernetes clusters
The plugins above monitor Docker directly: containers on a host (or a set of hosts), and Swarm services. That model fits when your unit of work is “a container running on a machine I can point a check at.” You know which host runs what, container lifetimes are relatively stable, and a check against the Docker daemon gives you a clear picture.
Kubernetes is a different problem. A cluster adds layers that plain Docker monitoring does not see: Pods, Deployments, ReplicaSets, scheduling decisions, and a control plane that moves workloads around on its own. Containers come and go as the scheduler reacts to load and failures, so there is often no fixed host to check, and the question shifts from “is this container healthy” to “is the desired state being maintained across the cluster.” A per-container Docker check cannot answer that on its own.
For Kubernetes, Icinga provides a dedicated Kubernetes module. Rather than checking one container at a time, it connects to the Kubernetes API, automatically discovers cluster resources, and shows their relationships, how Deployments, ReplicaSets, and Pods connect, with calculated states that tell you what is broken and why. It complements Prometheus rather than replacing it: Prometheus collects the metrics, and Icinga adds context, health states, and alerts, so a stuck restart loop or a Pod failing on a missing volume mount surfaces as a clear cause instead of a metric you have to interpret. It also handles multiple clusters, and on-premises systems, from one interface.
The short version: for containers running directly on Docker or in Swarm, use the Docker plugins. For full Kubernetes clusters, use the Icinga Kubernetes module. Many environments run both, and Icinga monitors both from the same place, next to the rest of your infrastructure.
Getting started
If you already run Icinga, start at the Docker plugin directory, pick the plugins that match what you need to watch, and add them as checks. If you are new to Icinga, the quickstart guide walks through a working setup, and from there your containers become part of the same monitoring as everything else you run.
