cAdvisor (Container Advisor) is an open-source daemon from Google that collects, aggregates, and exports resource-usage and performance metrics for running containers — CPU, memory, network I/O, and filesystem usage — without requiring any changes to the containers themselves. It has quietly become one of the most widely deployed pieces of container-monitoring infrastructure, mostly because it ships built into kubelet on every Kubernetes node.
If you have ever looked at a Grafana dashboard showing per-pod memory usage in a Kubernetes cluster, there is a good chance cAdvisor was the thing that actually collected that number.
What does cAdvisor actually monitor?
cAdvisor reads from the Linux kernel's cgroups (control groups) and namespaces to build a live picture of every container on a host. For each container it tracks:
- CPU usage (total, per-core, and throttling stats)
- Memory usage, including working set and cache
- Network traffic in and out per interface
- Filesystem usage and I/O
- A rolling window of historical resource data (by default, cAdvisor keeps roughly two minutes in memory)
It exposes this data through a small web UI, a JSON API, and — most commonly today — a Prometheus-compatible /metrics endpoint. It does not do anything to the containers; it is purely observational, running as a single daemon per host that auto-discovers every container on that machine.
How does cAdvisor fit into a Kubernetes stack?
In Kubernetes, cAdvisor is embedded directly into kubelet, so every node already runs it whether or not you asked for it. Kubernetes uses cAdvisor's data internally for scheduling decisions, resource-based eviction (deciding which pods to kill when a node runs low on memory), and the kubectl top command.
For cluster-wide dashboards, most teams scrape the kubelet's /metrics/cadvisor endpoint with Prometheus, then visualize it in Grafana alongside kube-state-metrics and node-exporter data. That three-way combination — cAdvisor for container-level resource metrics, kube-state-metrics for Kubernetes object state, node-exporter for host-level metrics — is close to a de facto standard for open-source Kubernetes observability.
Outside Kubernetes, cAdvisor also runs standalone against plain Docker hosts, which is how it started before Kubernetes existed.
Where does cAdvisor fall short?
cAdvisor is a resource-monitoring tool, not a security tool, and it is worth being precise about that boundary. It will tell you a container's memory usage is climbing; it will not tell you why, whether that's a memory leak in a vulnerable dependency, or whether the process consuming that memory is even the one you expect to be running. A few concrete limits:
- No historical storage. cAdvisor keeps a short in-memory window and expects Prometheus or another time-series database to do long-term retention.
- No anomaly detection or alerting. It exposes numbers; alerting rules live elsewhere (Prometheus Alertmanager, typically).
- No vulnerability or configuration awareness. cAdvisor has no idea whether the image running in a container has known CVEs, exposed secrets, or a misconfigured
securityContext. That's the job of image scanning and runtime security tools, not a resource monitor. - Single-host scope. Each cAdvisor instance only sees its own node; cluster-wide views require aggregation via Prometheus federation or a remote-write setup.
That last point about security is the one teams most often miss. Resource monitoring answers "is this container healthy," but it says nothing about "is this container's software supply chain clean." Those are separate questions that need separate tooling — an SCA scanner for the packages and open-source dependencies baked into the image, and runtime or DAST coverage for what the running application actually exposes. A container can look perfectly healthy on a cAdvisor dashboard — flat CPU, steady memory — while shipping a dependency with a known remote-code-execution CVE.
Is cAdvisor still worth using in 2025?
Yes, for the narrow job it does. It remains actively maintained, ships free inside every kubelet, and is a reasonable default for per-container resource metrics without adding another agent to your nodes. Where teams get into trouble is treating "we have monitoring" as equivalent to "we have visibility into container risk." Resource metrics and security posture are different signals; a mature setup pairs cAdvisor-style resource monitoring with dependency and image scanning so both operational health and supply-chain risk get watched.
FAQ
Does cAdvisor need to be installed separately in Kubernetes?
No. It's built into kubelet and runs automatically on every node — you just point Prometheus at the /metrics/cadvisor endpoint to start scraping it.
Can cAdvisor detect vulnerable container images?
No. cAdvisor only reports resource usage (CPU, memory, network, filesystem). Vulnerability detection requires a dedicated image or SCA scanner that checks package manifests against CVE databases.
What's the difference between cAdvisor and node-exporter?
cAdvisor reports metrics scoped to individual containers; node-exporter reports host-level metrics (disk, kernel, hardware). Most Kubernetes observability stacks run both alongside kube-state-metrics.
Does cAdvisor work with Docker without Kubernetes?
Yes, cAdvisor was originally built for standalone Docker hosts and still runs as a single container you deploy per host, independent of Kubernetes.