Docker exposes metrics via three mechanisms:
- pseudo-files in sysfs
- the stats command
Metrics coverage across these three mechanisms is uneven:
|Access via||CPU metrics||Memory metrics||I/O metrics||Network metrics|
|stats command||Basic||Basic||Some, as of v1.9.0||Basic|
|pseudo-files||Yes||Yes||Some||Yes, as of v1.6.1|
The docker stats command will continuously report a live stream of basic CPU, memory, and network metrics. As of version 1.9.0, docker stats also includes disk I/O metrics.
# Usage: docker stats CONTAINER [CONTAINER...] $ docker stats $CONTAINER_ID
Linux Containers rely on control groups which not only track groups of processes, but also expose metrics about CPU, memory, and block I/O usage. You can access those metrics and obtain network usage metrics as well. This is relevant for “pure” LXC containers, as well as for Docker containers.
Control groups are exposed through a pseudo-filesystem. In recent distros, you should find this filesystem under ' /sys/fs/cgroup' . Under that directory, you see multiple sub-directories, called devices, freezer, blkio, etc.; each sub-directory actually corresponds to a different cgroup hierarchy.
On older systems, the control groups might be mounted on /cgroup, without distinct hierarchies. In that case, instead of seeing the sub-directories, you see a bunch of files in that directory, and possibly some directories corresponding to existing containers.
To figure out where your control groups are mounted, you can run:
$ grep cgroup /proc/mounts
Find the cgroup for a given container
For each container, one cgroup is created in each hierarchy. On older systems with older versions of the LXC userland tools, the name of the cgroup is the name of the container. With more recent versions of the LXC tools, the cgroup is
For Docker containers using cgroups, the container name is the full ID or long ID of the container. If a container shows up as ae836c95b4c3 in docker ps, its long ID might be something like
ae836c95b4c3c9e9179e0e91015512da89fdec91612f63cebae57df9a5444c79. You can look it up with
docker inspect or
docker ps --no-trunc.
Putting everything together to look at the memory metrics for a Docker container, take a look at
Like the docker stats command, the API will continuously report a live stream of CPU, memory, I/O, and network metrics. The difference is that the API provides far more detail than the stats command.
The daemon listens on unix:///var/run/docker.sock to allow only local connections by the root user. When you launch Docker, however, you can bind it to another port or socket; instructions and strong warnings are here. This article describes how to access the API on the default socket.
You can send commands to the socket with nc. All API calls will take this general form:
echo "" | nc -U /var/run/docker.sock
To collect all metrics in a continuously updated live stream of JSON, run:
$ echo -ne "GET /containers/$CONTAINER_ID/stats HTTP/1.1\r\n\r\n" | sudo nc -U /var/run/docker.sock
- Run the follwoing command to see the current metrics of the running container:
- Container Advisor (cAdvisor) is a container monitoring tool by Google. It’s one of the oldest tools available and works by running a daemon collecting several different stats. run the follwoing container to use the cAdvisor:
docker run --rm --name cadvisor -p 8080:8080 google/cadvisor