Monitoring your containers

Back in the dimness of time Steve Balmer (former CEO of Microsoft) stood on stage at a Microsoft Keynote shouting Developers-developers-developers amidst a plethora of bemused Microsoft execs all looking bewildered as to why they were even on the stage.

Steve Balmer developers
Image Credits to OliverGeary

What Mr. Balmer was rather clumsily attempting to say, was that the world belonged to developers. At the time we were not really in the mood to hear such a refrain, especially from the then floundering tech giant Microsoft. Fast-forward several years to this DevOps-biased world that we live in. It must now seem that he was prophetic, but this developer-led world in infrastructure leads to problems in monitoring.

Monitoring is challenging

Two of the major drivers in this revolution have been virtualization, led by VMware and then the rise of containers, led by Docker. But as with all new technologies, where they lead in functionality, they also cause issues with ecosystem tools for monitoring and security.

Monitoring in the container world is not as straight forward as with a virtual machine where all services are contained within a single entity, and each service needs only to be monitored only once.

With a container-based environment there may be multiple instances of the same software, library or service running in different containers on a single host. These instances could be running the same, or wildly different versions. This very soon gets messy.

Similarly, the ephemeral principles of containers make it hard to track them. They spin up to do a single job, sometimes taking only seconds or even less to complete. Often, if a container has a bug that prevents it from doing its task, it blips out of existence before being able to troubleshoot the root cause. Problems with containers can exist in isolation, affecting just a single container, or be a host-wide (and broader) issue. You can see the problem. Monitoring containers is hard.


Companies like sensu have delivered a codified cloud native monitoring system.

Sensu Logo
Cloud Native Monitoring

Sensu monitors the full event pipeline from initial deployment from Kubernetes deployed containers to devices on bare metal, enabling full life-cycle visibility of issues and performance of every system over every protocol.

Sensu Architecture
Sensu allows multiple inputs to be set to multiple outputs

Sensu is multi-cloud aware, multi-platform aware, multi-protocol and multi-service aware. it can after the successful delivery and registration of the sensu agent auto-enroll and de-register services running on the host OS (be that a cloud instance, ESXi host, or Docker container host) based on pre-configured filters in the Sensu back-end.

Once a device or service has been registered with Sensu, any alterable event will be forwarded to any or all of the deployed receiving engines, perhaps creating a ticket in ServiceNow, and entry in splunk or alerting the support team by pagerduty.

Monitoring is vital for container adoption

The key to new technology being accepted in the enterprise is not the raw ability to solve a problem, but the ability of those who are tasked with supporting past deployment into day one and two operations.

The lack of proper monitoring solutions will kill an enterprise based solution dead in the water. Operations are tasked with keeping the lights on, this is the case not just with legacy applications and services, but with modern cloud native solutions that companies are moving to via the process of digital transformation.

Containers have now passed that rubicon, they can be safely monitored, this means that Operations can be pro-active rather than reactive, and can carry out their tasks from a position of knowledge, based on historical data from all event points.