Challenges to Docker Monitoring Relieved, Ruxit Claims

A joint survey from O’Reilly and Ruxit says that container monitoring (including Docker monitoring) is an important issue and a challenge for Docker users, according to Ruxit. Sponsored surveys seem to provide only results the vendor finds useful for marketing. You would probably benefit as much from asking yourself whether YOU see Docker container monitoring as challenging as you would from reading the survey.

If you agree that monitoring containers is more difficult than predicting what GOP candidate is going to earn the privilege of standing in the center during the next Presidential debate, Ruxit has a container monitoring solution (obviously) and it works something like this.

Ruxit’s Approach to Docker Transparency

Ruxit’s offering attempts to use a single agent (as many monitoring vendors such as Scout and Datadog do). The Ruxit agent works on the OS without disrupting automated, plug and play container operation or the tools such as Marathon that manage containers. Ruxit determines what containers are running and monitors the infrastructure using its agents.

According to Alois Reitbauer, Chief Evangelist, Ruxit, the Ruxit agent is “hands free” in its approach to installation and management using a single wget-based install. “We instrument at the OS level and automatically detect processes and trigger deeper instrumentation like Java byte code, node.js, and JavaScript. We instrument web servers and inject a JavaScript agent into the delivered web content. Usually agents only cover one aspect in an automated fashion and do not collect information on all application levels automatically,” says Reitbauer. The agent can self-diagnose and the customer can turn it off in real-time if needed, to avoid creating technical issues.

Ruxit monitors the Docker runtime and each newly started container through the underlying OS (again, this sounds similar to how other monitoring solutions work). “We monitor Java, nginx, and other technologies running inside the container. For application environments we instrument the code and see actual code execution details. For the web server we instrument the delivered HTML. We also use the Docker API to get CPU metrics for the container,” says Reitbauer.

According to Ruxit, people expect APM and monitoring solutions to serve multiple purposes. “Sharing metrics and health metrics is kind of the basis for everything. We get some of the greatest feedback about how we’re able to visualize all the dependencies amongst containers,” says Reitbauer.

Ruxit also scales up with Docker containers. “One of the reasons you might use Docker is that you eventually want to scale up and you need to scale up your monitoring infrastructure to the same level of scale,” says Reitbauer.

Ruxit Customer Cases

“One customer used to run about 100 JVMs and each one hosted about 20 services,” says Reitbauer; “they moved to Docker to separate all the individual services for the obvious reasons, including better isolation.” In the transition, the Ruxit customer’s infrastructure scaled up from 100 JVMs to 2K.

Ruxit provided them with a solution including a micro-service based view that helped them understand the dependencies in their application and find problems despite the very high infrastructure complexity, according to Reitbauer.

“A customer that runs a large ecommerce environment on Docker is monitoring the Docker infrastructure as well. They run Marathon and Marathon crashed,” says Reitbauer.

Ruxit instrumented Marathon and helped them to discover that they had an issue where the task queue was slowing down; they discovered that their newer version of Marathon was keeping old tasks in the queue by default, causing them to pile up, so-to-speak.

Final Thoughts

No matter what a vendor says, no one container monitoring solution is right for everyone’s needs, if it is a fit for anyone’s needs. Selecting a container monitoring solution or any solution is about knowing where any existing products or approaches fail and how, and then knowing how to investigate and properly vet potential solutions. You should certainly look at many solutions, ask for references, and ask about trials, track records, and customer support options.

David Geer

David Geer’s work has appeared in ScientificAmerican, The Economist Technology Quarterly, CSO & CSOonline, FierceMarkets, TechTarget, InformationWeek, Computerworld, Byte.com, ITWorld.com, IEEE Computer Society’s Computer magazine, IEEE Distributed Systems Online, Government Security News, Laptop, Smart Computing, Technical Support, The Hosting Standard (Canada), TechWorld.com (UK), SIGnature, Processor, and the Engineering News-Record. David served as a technician at CoreComm in Cleveland, OH prior venturing into writing.

David Geer has 24 posts and counting. See all posts by David Geer