No Agents Needed to Monitor Containers, Says Sysdig, Just Linux Kernel Changes

What containers still lack is a common platform for rendering telemetry to a monitoring system. Although Docker does provide a way to poll the API within a container to check on its resource consumption, containers don’t have mechanisms for sending “heartbeats” or regular reports to some outside service.

Advocates of conventional VM environments have touted this as a key disadvantage of containers. If it is, then both VMs and containers share the problem. Virtual components are intended to be self-contained. Docker has begun to break through this barrier with its latest exploration of a plugins ecosystem. But even this may underscore the need for containers to report their health, and the opportunity for containers to one-up VMs yet again by beating them to a standard approach.

New Relic has already laid down the gauntlet with a visual monitoring system that’s capable of mapping the relationships between microservices. But it requires the installation of an application performance monitor agent that relays health data back to New Relic’s servers. Although it’s hard to actually measure this directly (because measurement requires an agent … darn you, Werner Heisenberg!), agents could conceivably change the behavior of whatever virtual components they’ve been assigned to monitor.

“Suddenly You See Everything”

This week, a company called Sysdig entered the container monitoring market with a product simply entitled Sysdig Cloud, which the company’s CEO contends is an agent-less system built exclusively for containers, not VMs.

“We tried to imagine what a native container monitoring product would look like,” said Loris Degioanni, Sysdig’s CEO, in an interview with The New Stack. “The big difference in terms of technology between us and other companies that offer container visibility, is that we have a specific set of technology that is designed to see inside containers, in a way that doesn’t require any instrumentation. The deployment is done just by deploying another container. We call this ‘monitoring-as-a-microservice.’”

To say that Sysdig does not require the injection of an independent agent inside the container is technically correct. It might also be a miracle of Clintonian sentence parsing.

Something is indeed injected into the container environment, just not in the usual way and not the usual place. Sysdig is by no means a passive monitoring system. When pressed further on this topic, Degioanni admitted that Sysdig has a number of patent-pending technologies that are covered under the blanket name ContainerVision.

On Tuesday, Digiovanni penned a company blog post that contained this explanation: “Powered by Sysdig’s patent-pending ContainerVision technology, Sysdig Cloud can monitor your entire architecture from its own stand-alone container, with zero configuration, and yet still offer deep visibility into every other service running in your environment. With Sysdig Cloud, you just add an extra container, and you suddenly see everything. Apps, services, networks, processes, infrastructure components.”

Interjection

Was there a step left out, by any chance? I pressed Sysdig on this point, noting that if it was always as simple as just adding an extra container to the mix and suddenly the rest spill their proverbial beans, maybe there’s a security flaw that Solomon Hykes and the good folks at Docker, Inc. should know about.

So there is this bit of small print.

“We install a little module in the Linux module that is running the containers,” Degioanni told The New Stack, “because with containers, the Linux kernel is sort of the hypervisor. We inject, when you deploy your container, a little module in the kernel, and this module is able to inspect any other containers from underneath — see any interaction, any file that is open or closed, any network connection, any application that is running, any process, and so on.”

So it’s sort of being able to see underneath the containers and gaining this type of visibility, by incrementing the machine, the Linux kernel that is running on containers.

Degioanni characterized the module injection process as automatic. Once the Sysdig container to which the module reports is added to the mix, the injected module will work through any version of Linux that is capable of running containers, including CoreOS. This method, he goes on, lets Sysdig be container-agnostic, supporting Docker, rkt, LXC, or whatever may emerge, and supporting any container runtime.

Granularity

We witnessed a demonstration of the Sysdig system at work on a live container environment running Cassandra, and a few features we saw were indeed quite impressive. The depths of the kernel bug’s reporting ability enable Sysdig to rewind and replay long intervals of performance history in real-time, in a feature it calls Time Travel.

Sysdig’s mapping ability, which Degioanni said was inspired by Google Maps, presents an astonishingly effective animated drill-down into the topology of running processes, which the renderer produces as a flowing zoom, from cloud level to network level to container level to process level.

“By the way, this is not as simple as it looks,” Degioanni remarked. “Tools like Docker create little subnets for their containers. So reaching them and understanding how the container in one machine is talking to a container in a different machine, that may be on a different cloud, requires quite a bit of interesting tricks.” One such trick he described involved the splicing together of routing tables.

Degioanni admits that Docker’s recent experiments with a new plugins model for version 1.7 Experimental, may carry a slight risk of affecting how Sysdig’s monitoring container works within its environment — it’s something he’ll have to see for himself to know for sure.

Scott M. Fulton III leads the developer content team at Neo4j, and before this, was a 37-year veteran producer and editor, including for The New Stack, where he created the Context podcast. He produced the Scale blog for ZDNet, was...

Read more from Scott M. Fulton III