We’ve all heard of Docker by now. One of the main reasons for using Docker is to eliminate the support-matrix hell. Instead of developing on a machine that has little in common with the test and production environments, you’re creating a closed container or environment with everything your application needs to run.
You can then put this container on any kind of (x86-Linux) machine with Docker support, and it will behave in the same manner. And so, everyone in the development and deployment chain is happy – developers get a single, consistent environment where their code runs and DevOps gets a simple deployment procedure. You can even automate most of the container creation and deployment process by integrating it into the build systems. It is, from high orbit, a Virtual Machine without all of the redundant components. After all, why run a Linux executable on top of a Linux kernel, on top of QEMU, for example, which runs on … Linux?
Once the container runs smoothly on your development machine, it is then deployed to the test environment, and from there, to production. The application runs in the same manner, but the machines running the containers are probably different to your development machine, and DevOps probably wants to monitor them for performance and availability. So DevOps goes ahead and installs its choice of monitoring tools, including APM software (such as SharePath by Correlsense).
I’m not going to talk about monitoring the Docker environment (for example, container start/stop or number of running containers). Instead, I’m going to talk about monitoring your application – the same application you’d want to monitor even if it were running on a physical server or a cloud-based VM.
In non-Docker environments, you’d install the monitoring software on the server and it would monitor the application processes running on that particular server. In a Docker-enabled environment, there’s a middle-man – Docker. If you attempt to install the monitoring software in the same way, you will be able to monitor the Docker processes, but everything running inside the container is isolated by design from the host machine, with the exception of the connections you allow.
In order to monitor your application, you’d have to move some part of the monitoring software inside the container, where it can interact with the monitored processes, such as Java, node.js, or Apache. Since the monitoring part of the APM software is usually split into two logical components, you need to decide on the one of the following structure options for your monitoring architecture:
- Running a single host manager process outside the Docker environment (on the host OS) and communicating with the collectors running inside the container(s).
- Running the host manager completely inside the Docker container(s).
While the former makes some sense when you have complete access to the host machine, or when running multiple containers on a single host, the latter has the appeal of being completely contained, together with the monitored application.
Another point we have to address is the stage at which the monitoring software is installed inside the container. If you keep the host manager outside the container, especially in multi-container hosts, you can get better performance, as there are less monitoring-related processes running. On the other hand, you need to make sure it is installed on all the hosts where the container may be deployed. This can lead to added complexity when new machines are introduced into the development/test/production pool.
In addition, if for example, you decide to add APM software only to the production pool, then you require container changes when moving from test to production. Although this can be done as part of the automatic deployment process, it may still be problematic to make any container changes at this stage.
If you decide to install the APM software completely inside the container, you may end up running multiple instances of the APM software manager process (one inside every container), but you get better integration with the Docker ecosystem:
- Monitoring software can be integrated into the container at very early stages, requiring none or minor changes to the container during the deployment processes.
- Out-of-the-box monitoring of development, test and production environments.
- Less contact points between the container and the host machine.
In my opinion, installing the monitoring tools inside the Docker container during the initial stages will result in a cleaner development-testing-deployment process, one which integrates the monitoring tools from the start and gives you deeper visibility into the behavior of your application throughout the process.
With the correct installation, it may just be a matter of setting environment variables for the Docker container to point it to the correct monitoring server (whether on-premise or SaaS) and monitor it as soon as it starts up.
About the Author: Zvika Meiseles, is the CTO of Correlsense and has over 20 years’ of software development experience − ranging from embedded, low-level driver development and hardware integration to scripting and back-end programming. Zvika also manages the Data Collection team which he helped establish.