Agent Client Collector – an in-depth analysis of the future
If I had a dollar for every time I stated “ServiceNow is not a monitoring tool in itself”, I would be making money in a very odd way. Luckily for my revenue model, that statement is no longer true, in a matter of fact; ServiceNow is de-facto entering the space of the lucrative monitoring market.
The question is, what footprint will it create? What will it mean for the AIOps value proposition? All of a sudden puzzle pieces are coming together and I am excited to present this in-depth analysis of the future Agent Client Collector.
Manager of managers – where it all began
To set the stage let’s look at the fundamentals of the Agent Client Collector and what problem it tries to resolve. This will not be a technical deep-dive into the tool or technology, as there will be plenty of such resources moving forward. Yet it’s important to be aligned on the basics before we continue speaking about the value it provides.
As indicated by the introduction of the article, historically, ServiceNow has never had any built-in monitoring capabilities in regards to event management and IT Operations. The pitch has been to position ServiceNow event management as the “manager of managers”. In other words, an engine which in theory any monitoring source can integrate into.
According to a report by Forrester called “Intelligent Application And Service Monitoring, Q2 2019” a quarter of the enterprises in the study have 50 or more monitoring tools. Almost half of the organizations in the report generates over 1 million events per day, and 11% have an event volume of more than 10 million events per day.
It goes without saying that having a unified way of dealing with alert- and event logic is a very attractive proposition. Placing event management on top of all monitoring tools allows SRE teams and the organization to plan- and build monitoring using a single “language”. Ultimately reducing the cost of training, enablement, and implementation of monitoring operations.
What is the Agent Client Collector?
The biggest strength of ServiceNow Event Management has ironically enough also been its greatest weakness. For VP’s and CTO’s, the primary KPI will always be consolidation and cost optimization. Justifying the investment of a new event management tool is always a tough sell, especially if your organization already has dozens running in the enterprise. Trying to convince a VP to invest in a monitoring tool without monitoring capabilities though? Unless you're careful your sanity might be put into question.
Until today, that is. Starting from the Paris release, the ServiceNow value proposition for Event Management has gone from good to great. The Agent Client Collector is, as indicated by the name, a monitoring agent for the enterprise. Based on the open-source monitoring agent called “Sensu”, ServiceNow has made sure to invest in the future already from day one.
Sensu is a child of the "monitoring sucks" movement, and according to many industry experts the future of monitoring, especially if you have a large dynamic infrastructure. Architecturally, it's miles ahead of Nagios and its various descendants. Written in Go, Sensu uses etcd datastore to handle messages in a queue-based approach.
In a nutshell, Sensu has the following advantages compared to traditional monitoring tools:
- From host-based to role-based monitoring, the ability to monitor and alert on certain actions and services, not just machines
- From remote polling to publish-subscribe and push API’s, funneling data into pipelines no matter its origin or format, rather than aggressively polling individual servers
- Replacing point-and-click interfaces with infrastructure-as-code that align with modern DevSecOps approaches
Will Sensu change the positioning of ServiceNow ITOM?
Sensu is scalable, light-weight and oriented towards a developer mindset rather than traditional operations. Meaning, developers can write their own “service checks” of what type of data they want to monitor with the help of Sensu. This allows for a lot of flexibility in what you can monitor, from ephemeral infrastructure to distributed applications. But why is not every enterprise switching to Sensu in a DevOps driven world?
The primary challenge for an organization undertaking Sensu is two-fold:
- A streamlined way of maintaning the checks and configs (code)
- How to push and install Sensu monitoring agents (deploy)
When you treat monitoring as code, it also means you need an easy way to track changes, roll-back and configure the code. It not only becomes a monitoring exercise, but also one of maintaining code bases.
But don’t just take my word for it. Harvard University is using Sensu and was facing these exact challenges themselves. Having to monitor over 500 lab groups, 5500 users and a cluster of 100 000 CPU cores, using Sensu was the right choice. Yet to deploy and configure Sensu Go, Harvard ended up having to write their own custom tool they named “Hinoki” simply to manage all the code and deployments.
Generating ROI suddenly becomes much easier
This is where ServiceNow has done something groundbreaking in my opinion. Some of you might already be guessing where this is heading, but through ServiceNow – you can configure Sensu checks and deploy monitoring agents directly from the platform. As most of the customers using Event Management already have MID-servers in place, deploying agents and configs is a piece of cake.
In short, ServiceNow will utilize the already existing access to the customer network through the MID-servers to assist in the rollout of Sensu. If that isn’t a creative use of the product I don’t know what is.
All of a sudden the platform is playing an entirely different ballgame, not only being “the manager of managers" but indeed shipped with modern monitor capabilities. This means that for anybody wanting to invest in Event Management, they can make some serious cost reduction through phasing out old legacy tools of monitoring.
The capability of having Sensu monitoring agents and a streamlined way of maintaining the code behind the service checks is something quite unique for an enterprise ITOM platform.
Dare I say, ServiceNow is the only?
Where it will all lead – the bigger picture
The agent client collector is not only isolated to Event Management and monitoring. I have a gut-feeling it has the potential to become the beating heart of ITOM moving forward similar to the MID-server. Some other very exciting topics that the agent brings through Sensu is:
- Collecting metrics for machine learning to apply anomaly detection – no more need to integrate to external metric sources
- Agent-based discovery for client computers – no need to rely on SCCM or similar repository
- Pushing remediation actions to infrastructure - rollbacks, fixes, software installations and more
To speak in less technical terms. Thanks to the agent an organization can automate more, fix issues faster and entertain the idea of phasing out legacy tools much more seriously. With the sheer amount of monitoring tools that organizations have, and with the serverless, stateless architectures that are on the rise; the value proposition hits the jackpot.
From a portfolio perspective ServiceNow is taking a giant leap into the modern world of monitoring through incorporating the agent-based client collector as part of their AIOps offering. As such, Event Management is no longer just about receiving events and monitoring, but more so about observability. Where it will lead we can only speculate in, but at least the hypothetical future that ServiceNow is trying to paint is one of beautiful colors.
What impact do you think the agent client collector will have on the overall future of ServiceNow AIOps & ITOM? What will be the biggest challenge?
https://www.linkedin.com/pulse/agent-client-collector-in-depth-analysis-future-alexander-ljungstr%25C3%25B6m/?trackingId=IHTu8OEoVYhwNbQo6blpHA%3D%3D