Monitoring containers


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.

The Author

Sebastian Meyer works for B1 Systems GmbH, Vohburg, Germany, as a Linux consultant and trainer, with a focus on system and configuration management.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Server administration with Cockpit
    Administer a small server farm, virtual machines, and the Docker alternative Podman with just a web browser.
  • Grafana and time series databases
    We look at database back ends for monitoring, alerting, and trending analysis in the Grafana visualization tool.
  • Fedora 22 Server Edition (64-bit)
    Warning: Fedora 22 Server is not a Live distribution. Please run in a virtual environment for test purposes.

    The Fedora community unveils Fedora 22 Server, an operating system designed with various data center technologies to assist you in controlling your infrastructure and services. Server roles allow deployment and management of prepared roles with the Rolekit tool. DNF (Dandified Yum) replaces Yum as the default packaging tool. The web-based Cockpit server manager lets you access various subsystems across multiple servers from a single interface. Cockpit features include:

    • systemd service management
    • Journal log viewer
    • Storage configuration, including LVM
    • Docker container management
    • Basic network configuration
    • local user management
  • Monitoring, alerting, and trending with the TICK Stack
    If you are looking for a monitoring, alerting, and trending solution for large landscapes, you will find all the components you need in the TICK Stack.
  • Docker image security analysis
    Up your security by determining the provenance of a container image.
comments powered by Disqus