Monitoring with Nagios

To monitor containers in existing monitoring solutions, you can obtain plugins. New Relic [8] offers the check_docker extension (written in Go) for Nagios [9] [10]. It uses the Docker REST API to pick up information. However, by default, it only queries the host's (meta)data load, for which the administrator can set warnings and critical thresholds.

If needed, you can also stipulate that a container with a specific image is to be run on a specific host. This can be useful if you want to run check_docker in parallel with cAdvisor. In this case, you need to launch cAdvisor as a container on each host; then, you use Nagios to check that this is really happening and whether a container of this type really is running on each Docker host.

The master version of check_docker also queries certain container names. If you choose mnemonic container names, you can thus keep track of multiple containers that originate from the same image. Additionally, you can use check_docker without a Nagios instance to evaluate your data manually. That said, you would lose one of the biggest benefits included as part of the Icinga and Nagios packages: the ability to send alerts.

The check_docker plugin proves to be a useful supplement to performance monitoring tools such as cAdvisor, and it integrates seamlessly with an existing Nagios/Icinga landscape. However, the REST API does add to the configuration overhead that administrators need to schedule to secure communication with TLS certificates that lock out unauthorized intruders.

Variants and Combinations

Many of the projects listed here are based on a combination of existing tools. The Heapster [11] tool used for resource monitoring in Kubernetes [12], for example, relies on cAdvisor and InfluxDB. Visualization then relies on either Grafana or Kubernetes' own Kubedash [13]. Dockerana [14], which took first place at the DockerCon 2014 Hackathon, also uses Grafana with Graphite [15] for data storage on top.

More complex monitoring solutions require a combination of these tools, including a source that only collects the data, such as cAdvisor or collectd [16]; a cache for the data metrics, such as Graphite or InfluxDB; and a service for visualizing the data (e.g., Grafana). Each of these services comes with its own configuration. Coordinating the way they collaborate is anything but trivial, but if you take the time, you will reap the rewards of versatile monitoring options.

If you do not want to host your monitoring system yourself, you can turn to a commercial service, such as New Relic [8], Sysdig Cloud [17], or Datadog [18]. At the opposite end of the field are plainer, self-hosted solutions, including Cockpit, cAdvisor, or a Nagios instance that offer comparatively fewer features.

For smaller environments, in which only the current load is of interest, you might even get away with using the built-in Docker commands, so no external tools are required. cAdvisor dresses the data in graphics and is easily installed as a Docker container. Red Hat-based systems come with Cockpit, which even includes a basic container deployment tool.

If you are already using a monitoring solution for other servers (e.g., Sensu [19] or Nagios), plugins can make your solution Docker-ready. In this case, you do not need additional, complex monitoring software for your containers, and you can leverage the existing features, such as alerting, into the bargain.

If you are planning a large-scale Docker environment, it makes sense to take a look at monitoring tools tailored for the job. Although they might require more configuration overhead, they do offer the most extensive data aggregation and visualization opportunities. Container tamers can either compose a solution from the individual components or deploy a project, such as Prometheus [20] or Heapster, that handles some of the overhead. A word of warning: The tools are still under pretty heavy development, so you have some risk of incompatibility between versions. A comprehensive test environment is mandatory.