A few weeks ago, I wrote two articles on agent and agentless monitoring, and I received an interesting note from a reader who shared his experiences with both. Today’s column includes excerpts from the note by our reader, a global program manager for a large outsourcer who was “in charge of developing and installing new monthly response-time performance metrics for more than 150 critical applications” for a large client.
“In the beginning of the project, we thought we would be using an active agent solution - installing ‘robot’ workstations at various locations around the network, in close proximity to end users. The robots would perform a series of typical tasks from each of the pertinent applications, in endless cycles, and then accumulate and report response-time performance data to feed the monthly metric calculations required in the contract. I should point out that availability was not a measurement issue here - we were interested only in application response time (of course any availability issues did impact our response-time performance).
“We quickly uncovered three obstacles from a business standpoint: cost, scalability, and network impact. Our active agent approach was superb at the detailed level - the client embraced it in concept, but scaling it to a global coverage level was getting way too expensive. In addition, the networks were already strained and were suffering from capacity issues. We could only get agreement for about 3% coverage. Otherwise, we got in the embarrassing position of destroying response time in order to measure response time. I kept asking our engineering team if there wasn't another approach that I could afford and that would scale to a global solution without straining the client's networks. They exposed me to a relatively new tool that offered an agentless, passive approach to measuring application response times. I was skeptical at first, but after thorough testing in the client's network space we validated that the tool could handle this enormous metrics challenge at a cost we could afford and without placing a significant load on the client's networks.
“There were some twists - the tool required that TCP/IP be present somewhere in the circuit, and the tool reported response-time performance at the packet level. We crafted another approach for those cases, mostly mainframe, where there was no TCP/IP, and the client agreed that having 100% coverage of all transactions at the packet level was better than having a 3% sample at the synthetic business task level.
“I understand that there are perfectly valid cases where active agents are needed and preferred, but I must admit that this new passive, agentless technology has made a believer out of me for certain situations. We were able to deliver a global solution to this huge contract-required response-time SLA to our largest client, at a cost significantly under our original budget and about seven months ahead of schedule. And after we installed this technology in the client's infrastructure, we were able to begin exploiting the massive amount of new information that the tool provided to help us improve our day-to-day operations - far beyond the required monthly response-time reports.”
This reader admits that his strength is on the business side of things rather than the technical. And even though he couldn’t understand all of the technical aspects particularly during internal debates on agent vs. agentless approaches, he goes on to say, “I completely understood significant cost avoidance and coming in way ahead of schedule. Now that I've deployed both approaches, I think the passive approach to measuring response-time performance is about ready to explode into much greater use.”
This is another user perspective on the agent vs. agentless discussion. And I’d like to thank our reader for sharing his experiences with us.