BT

Docker Monitoring: Best Practices, and a Comparison of the cAdvisor and Prometheus Monitoring Tools

| by Daniel Bryant Follow 377 Followers on Dec 06, 2015. Estimated reading time: 3 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

At DockerCon EU 2015 Brian Christner presented an overview of ‘Docker Monitoring’ and shared best practices, a guide to the Docker stats API, and a comparison between three popular monitoring options: cAdvisor, ‘cAdvisor + InfluxDB + Grafana’, and Prometheus.

Christner suggested that best practices included labelling container and setting resource limits, and stated that although Google’s cAdvisor container monitoring tool is easy to use, the combination of cAdvisor, InfluxDB and Grafana offers improved application integration and scalability, and the Prometheus monitoring platform offers client libraries and alerting ‘out of the box’.

Christner, cloud advocate at Swisscom AG, began the talk by introducing the usage of Docker at Swisscom, which included a persistent Database-as-a-Service (DBaaS) offering on Docker and Cloud Foundry (built in partnership with ClusterHQ), and several internal Docker products that support various appllications ‘from application cloud to TV’. These projects utilise Docker due to the possibility of higher density of applications per server (and associated infrastructure cost reduction), decreased time to market for developers, and a ‘one size fits all’ approach to deployment artefacts. A core challenge with using Docker was the required change in the approach to monitoring, from which Christner was keen to share his learnings.

Best practices for monitoring Docker include labelling containers with descriptive key/value pairs e.g. ‘--label environment=”production”’, setting resource limits, and limiting the amount of alerts generated to improve the signal to noise (“Don’t overlert yourself!”). Christner presented an overview of the ‘docker stats’ command, and stated that this tool is great for troubleshooting, both locally and remotely. The Docker stats API was discussed, and Christner commented that this is typically the basis for all other Docker monitoring tools, and can also be used to feed container resource information into an organisation’s existing monitoring solutions.

Google's cAdvisor (Container Advisor) provides "container users an understanding of the resource usage and performance characteristics of their running containers". cAdvisor's container abstraction is based on Google’s lmctfy container stack, and has native support for Docker containers and should support other container types “out of the box”. cAdvisor is deployed as a running daemon that collects, aggregates, processes, and exports information about running containers. The information can include container-level resource isolation parameters, historical resource usage, histograms of complete historical resource usage and network statistics.

cAdvisor can be combined with InfluxDB, a time series database, and Grafana, a metrics dashboard, to stores and display information. Christner has created a “How to setup Docker monitoring” blog post and associated Docker Compose configuration file, which can be used to create a monitoring environment that utilises cAdvisor, InfluxDB and Grafana with a single ‘docker-compose up’ command.

Prometheus is a systems and service monitoring system, which was born out of SoundCloud’s work on an improved monitoring system over StatsD and Graphite. Prometheus collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true. The Prometheus GitHub repository README.md states that the main distinguishing features as compared to other monitoring systems are a multi-dimensional data model, a flexible query language to leverage this dimensionality, multiple modes of graphing and dashboarding support, and support for hierarchical and horizontal federation. A Docker Compose configuration file that can create a fully-functional Prometheus monitoring environment can be found in Christner’s GitHub account.

Christner concluded the talk by comparing the three container monitoring approaches presented above: cAdvisor, ‘cAdvisor + InfluxDB + Grafana’, and Prometheus. Although cAdvisor was stated as the easiest to use, it has limits with scaling and alerting. The combination of ‘cAdvisor + InfluxDB + Grafana’ provides good scalability and also offers client libraries, but does not support alerting out of the box. Prometheus may not scale easily, but does support alerting in addition to providing client libraries for many languages.

Docker Monitoring Roundup

Figure 1. Docker Monitoring Comparison Roundup

The slides for Christner’s “Docker Monitoring” presentation can be found on SlideShare, and additional information can be found in a series of blog posts at brianchristner.io.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Great share! by John Matthews

Yes I too agree! Docker monitoring is mission critical and labelling really helps. Most Devops folks should consider labelling and setting resource limit as a primary best practise. I would also like to share a few more tools like AWS, Ruxit and Sysdig. Moreover, one great monitoring tool that I chanced upon which most of us already know about is New Relic. This blog I went through gives some similar insights, guess you might like going through - bit.ly/1UTOIbc

Docker monitoring tools by Peter Arijs

This is a good roundup. I would add that since this article was originally written, also orchestration platforms such as Kubernetes and Swarm have evolved, and useful data get be obtained through their APIs to monitor at a service level rather than at a pure container level.

Besides the tools mentioned in John's comment, I would like to add CoScale (I work for them), who also does Docker monitoring. We use the Docker and orchestration tool APIs to get relevant metrics, but you can also configure our host agent to get application-specific metrics from the workloads running inside the containers.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT