cAdvisor

Last reviewed Aug 26, 2026 · 673 words

Sixty-four megabytes of RAM, zero configuration, and a live per-container view of CPU, memory, network and disk the moment it starts: cAdvisor is the fastest way to answer "which container is eating the box". The catch is that it keeps almost no history. On its own it remembers roughly the last two minutes. Treat it as a metrics exporter for Prometheus, not as a dashboard, and it becomes a permanent fixture of the monitoring stack rather than a toy.

The compose block that actually sees your containers

cAdvisor reads cgroups and the Docker socket directly, so it needs a stack of read-only host mounts. Miss one and you get an empty UI with no error:

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    privileged: true
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    devices:
      - /dev/kmsg
    restart: unless-stopped

Port 8080 serves both the web UI at / and the Prometheus endpoint at /metrics. The privileged flag and /dev/kmsg mapping are what let it read per-container disk I/O on most kernels; on a hardened host you can drop them and lose the disk panels. Bind the port to a LAN or VPN address only. The UI has no authentication and lists every container name, image and environment summary on the host.

It forgets everything after about two minutes

The built-in UI is a live window, not a database. The --storage_duration flag defaults to 2 minutes of in-memory samples, and raising it just spends RAM to see slightly further back. That is by design: Google built cAdvisor as the collector under Kubernetes' kubelet, where something else always stores the numbers. So the second half of the setup is a scrape job:

scrape_configs:
  - job_name: cadvisor
    scrape_interval: 15s
    static_configs:
      - targets: ["cadvisor:8080"]

With Prometheus holding 15 days of samples by default and Grafana on top, you get the history the UI cannot give you. The three series worth alerting on are container_memory_working_set_bytes (what the OOM killer actually looks at, not RSS), rate(container_cpu_usage_seconds_total[5m]) for CPU, and container_fs_usage_bytes when a log-heavy container is quietly filling a disk.

cAdvisor's own CPU bill, and how to cut it

The irony people notice first: on a host with 40 containers, cAdvisor is often in the top three CPU consumers. The default housekeeping runs every second per container. Three flags fix most of it:

--housekeeping_interval=30s
--docker_only=true
--disable_metrics=percpu,sched,tcp,udp,hugetlb,referenced_memory,cpu_topology,resctrl

docker_only stops it walking every systemd cgroup on the host, and disabling the per-CPU, TCP and UDP metrics removes the highest-cardinality series, which also keeps Prometheus's memory down. On my hosts those three lines took it from a steady 5 to 8 percent of one core to under 1 percent, with nothing I ever graphed going missing.

It measures containers, not the host

Container metrics tell you a service's share; they do not tell you the machine's temperature, load average, or whether the root filesystem is full. Pair cAdvisor with node-exporter for the host and, if you want a friendlier all-in-one for a single box, look at Beszel, which ships its own agent and storage and needs no Prometheus at all. For a Kubernetes cluster you do not deploy cAdvisor separately; the kubelet already embeds it and exposes the same metrics.

What I'd do

One cAdvisor per Docker host with the compose block above, the three tuning flags, and port 8080 bound to a private address. Prometheus scraping every 15 seconds, node-exporter beside it, one Grafana dashboard with memory working set, CPU rate and filesystem usage per container, and an alert when any container's working set exceeds 90 percent of its memory limit for 10 minutes. Open the cAdvisor UI itself only when something is on fire right now; for everything else, ask Grafana.