Container monitoring: Agents or no Agents?
The explosion of containers on the tech scene continues to evolve quickly, and they present some innovative and interesting capabilities. One of the hallmarks of containers are their small footprint and portability. The ability to run applications, processes, and microservices within them, along with the ability to start and stop them quickly for transactional and other one-time tasks present some interesting prospects.
As with any new technology, containers bring with them some challenges. First, how do you monitor and manage them? Second, how do you monitor the applications, processes, and microservices that are running inside them? Traditional network monitoring solutions on the market are simply not designed for monitoring containers. Newer solutions on the market that were designed to monitor containers lack the ability to monitor the applications, processes, and microservices running inside. The ability to monitor containers both on the inside and out is critical to network and application continuity.
Installed software agents have been a mainstay in the network monitoring market with regards to monitoring servers, both physical and virtual. Their ability to be installed to an operating system provides them with a much broader range of real-time metrics than what can be accessed from the outside. They also have a greater range of actionable capabilities. Properly designed, agents can directly monitor the applications, processes, and databases that are installed on the server. On its face, software agents would also appear to be a good fit for monitoring containers.
One of the things that you will hear consistently from container purists is that container monitoring and installed software agents are incompatible. The line goes that agents are incongruent with the small footprint of containers. Agents are too bloated and monolithic, and therefore should not be used to monitor containers under any circumstances. While I agree with this statement to a point, I disagree with it because it is too broad a statement. The key word here is “bloated”. I agree that bloated and unstable agents are incompatible with containers, and should not be deployed. I disagree with broader statement that agents are incompatible.
Developing software agents is as much an art as it is a development effort, and many software vendors simply lack the artistry. The majority of software agents developed by vendors are proprietary, single-use, and in many cases are bloated and unstable. I wrote a blog post about poorly written agents and that software vendors need to get out of the business of writing agents. You can read it here.
Those that are adamantly against software agents being used to monitor containers are some of the very same vendors that lack the artistry to develop them, or they are those that have been victimized by poorly written agents. Software agents have received a bad reputation as a result of those that do not know how to effectively write them. Monitoring the inside of the container is an important element for effective container and application monitoring, and a well written, stable and open agent is the best solution.
Vallum Software is one of the few vendors that has the artistry for writing software agents. Our agent, the Halo Agent, has a very low profile, and is stable. It is also open, and has an architecture that allows for microservice applications called Halo Apps to be deployed to them. Halo Apps can be developed for just about any purpose, and can directly monitor applications, processes, and microservices running inside a container. They can also be deployed to a running container without having to stop them. This capability provides organizations with the critical visibility they need with their container deployments.
About the Author:
Lance Edelman is a technology professional with 25+ years of experience in enterprise software, security, document management and network management. He is co-founder and CEO at Vallum Software and currently lives in Atlanta, GA.