Containerization is a popular topic of discussion these days. One reason for this is the hype surrounding microservices architectures and the requisite need for tooling that supports the building and deployment of such services. Containerization technologies offer such support using a lightweight framework. Most notably, Docker has done a great job in the containerization space by simplifying the process of packaging, deploying, and running container-backed microservices. But how are you supposed to monitor the performance of containers and the applications that they support?

The black-box Docker monitoring approach

There are a number of tools available for collecting and visualizing the container-related information that can be pulled from the Docker Stats API. These tools fetch lots of container-related data, like number of running containers on each host, and CPU, network, and memory utilization per container. Of course, such tools give you a rough overview of a container’s resource utilization, but they can’t provide insights into the services within a container.

Docker Stats data

Cargo scanning for containers

You can’t verify that your containerized microservices work as expected by only monitoring CPU load or memory consumption of the respective containers. Placing an emphasis on monitoring of the cargo itself (i.e., your applications and services) rather than the containers enables you to gather deep insights into how your services perform and whether or not they are healthy.

Service breakdown within container

Bringing all your services’ monitoring data into context allows you to see the big picture of your application’s performance. With this information in hand you are able to make informed decisions regarding improving your software architecture and deployment.

Service clustering with containers

Agents in Docker images

Application monitoring tools usually rely on agent technology to inspect call graphs in applications and communication between processes. Agents dedicated to specific technologies are injected into respective execution runtimes (i.e., JVM in the case of Java) or code in order to enable monitoring. In the case of containerized applications and processes, such agents also need access to these runtimes or code.

The easiest way for other tool vendors to make agents available to containerized applications is to add the required agents to Docker images. In principle there are two ways of achieving this:

  1. Modifying the Docker images by adding the agents directly to their build scripts.
  2. Providing the respective agents with a separate image that is used as the base image for containers.

In either case you need to touch your images, which isn’t ideal from both, a user’s and a monitoring perspective. Furthermore you may need to rebuild your images each time you update your monitoring agents.

New base image needed

Don’t break the seal!

A more sophisticated way of monitoring applications in Docker containers doesn’t require users to touch their images at all. Ruxit provides such a solution. It seamlessly integrates with existing Docker environments and automatically detects the creation of containers. Upon creation of a new container on a Docker host, Ruxit Agent hooks into the container and provides code for injecting the respective sensor into the containerized processes.

Monitoring JBoss in container

In this way users don’t have to touch their images; they only need to install Ruxit Agent on the hosts that have a Docker engine installed. They are freed from configuration efforts each time a new agent version becomes available.

Auto-inject agent into container

Ruxit offers full-featured Docker monitoring, giving you all the same monitoring functionality for dockerized applications that is available for non-containerized applications.