how to monitor docker container cpu usage in real-time without open-source overhead

why real-time cpu visibility matters for containers

containers are ephemeral and dense. a single host might run 30–100 containers, each competing for cpu shares. without per-container granularity you're flying blind: you know the host is at 90% cpu but you don't know which container is the culprit. that gap turns a five-minute debug into a thirty-minute fire drill.

the docker stats API (`docker stats`) gives you a live stream of cpu, memory, and i/o metrics per container. the problem is it outputs raw numbers to your terminal and disappears the moment you close the session. building something useful on top of it — aggregation, alerting, retention — requires real engineering work.

the traditional path and why it's expensive

the standard open-source answer is cadvisor (container advisor) feeding metrics into Prometheus, visualized in Grafana. that stack works, but you're signing up to deploy three separate services, write scrape configs, design dashboards, set up persistent volumes for Prometheus storage, handle upgrades, and debug cardinality explosions when someone adds too many label dimensions. an engineer on hacker news put it plainly: "there are open source tools like heapster which have to be manually deployed" — and that deployment cost is real and recurring.

that overhead is fine for a platform team with dedicated SRE capacity. it's brutal for a two-person startup, a product team that just wants to ship, or a developer who picked up devops duties by default.

what gromitor does instead

gromitor ships a single binary agent that you run as a Docker container (`docker run -d ... gromitor/agent`). it connects to the host's Docker socket in read-only mode, collects cpu, memory, network i/o, and disk i/o per container, and forwards those metrics to the gromitor cloud backend over a lightweight websocket. your team sees live per-container cpu graphs in the gromitor dashboard within about 90 seconds of starting the agent.

the agent adds under 2% host cpu. it keeps 24–48 hours of recent raw metrics for context, but the heavy storage and query lifting happens in gromitor's backend, not on your host. you get the signal without the operational surface area.

• single docker run command to install — no helm chart, no persistent volume claim
• read-only access to the Docker socket — the agent cannot modify or restart your containers
• per-container cpu % plotted live, with configurable alert thresholds
• email and in-app alerts when any container exceeds your threshold
• works on any linux host running Docker, including EC2, GCE, DigitalOcean, and bare metal

setting cpu alert thresholds

once the agent is running, head to the gromitor dashboard, pick a container, and click 'alerts'. you set a threshold (say, 80% cpu for 5 minutes) and choose delivery: in-app notification, email, or both. the alert fires when a rolling average crosses the threshold, not just a single spike, so you don't get woken up at 3am because one cron job did two seconds of intensive work.

thresholds are per-container, so you can set tighter limits on your api server (where cpu spikes usually mean a bad query or runaway loop) and looser limits on a batch worker (where sustained high cpu is expected and normal).

getting started

gromitor is free to start. create an account on the product page, copy your agent token, and run one docker command. you don't need to open firewall ports — the agent initiates outbound connections only. most teams go from zero to live metrics in under five minutes.

if you're also running Kubernetes, gromitor supports that too — the same dashboard shows docker and kubernetes side by side, which is covered in more detail in the kubernetes resource monitoring saas article and the cross-platform container monitoring saas piece.