Management Tools and the Rise of Agents
Agent-based data collection emerged with the decentralized computing model of the 1980s, when networks of servers and powerful desktop computers came into mainstream business use. Such environments were, relative to today’s enterprise IT environments, fairly small and simple to manage. This was particularly true if agents— really just a small amount of code written to reside on a given server, network node, desktop or other device—were deployed to help collect and deliver data regarding the operational health of a given device. Such network and system management (NSM) agents are often proprietary to a given NSM vendor’s tools; for example, Hewlett-Packard’s agents only work with HP management tools, IBM’s with IBM tools, and so on. More recently, standards-based agents using the Simple Network Management Protocol (SNMP) are gaining wide acceptance for “open systems” (e.g., Unix and Linux servers, network devices, environmental and security devices) and are often included on the devices by vendors to enable monitoring.
Agents have evolved to the point where they’ve become very good at “seeing” and collecting data about the health of devices on which they reside. After all, they were designed to collect device-specific information that IT administrators need to track performance and availability and be alerted on inevitable problems that arise.
The downside of agents in use today is that there are significant costs associated with their use. The average purchase price of specialized agents ranges from $700 - $1500 per system or device to be monitored and there is also a real cost of administration of agent-based monitoring tools. Agents must be installed, configured and maintained on all monitored devices (typically hundreds to thousands in an enterprise IT environment).
Standard (SNMP) agents also have limitations. They collect defined, generic sets of performance, usage and availability metrics and make these available through a standard management information base (MIB) to external monitors. The standard MIBs typically do not include important metrics needed to analyze performance and usage of today’s sophisticated application and database servers (e.g. Java platforms like BEA WebLogic™and IBM WebSphere, and vendor proprietary systems like Oracle Enterprise™, and Citrix). Vendors may add metrics to the standard MIB on their systems but typically don’t publish details of custom MIBs for external monitoring.
What makes agents even more problematic is that as networks grow (e.g., become linked via the Internet into broader, interdependent enterprise environments), different tools from different vendors require that multiple agents be added to devices in order for the management tools to be at least somewhat effective. A single server, for example, could have several agents to keep it linked with every monitoring tool in use by an IT department. What’s worse, any time each management tool needs to be updated, all of the hundreds or even thousands of devices being monitored by a given tool often need to be updated as well. This involves major effort that can cause even bigger problems if they aren’t adequately maintained for upkeep. It’s a costly effort as well.
Because event-based tools depend largely upon agents, they can’t tap into the wealth of valuable built-in self-monitoring data now common with today’s systems and applications. Data from those self-monitoring technologies is extremely valuable for troubleshooting, capacity planning and performance monitoring, but it’s often hidden in system logs, database and other files that proprietary agents can’t reach or even see. Take Microsoft’s Performance Monitor (Perfmon) utility, for example. It logs hundreds of Windows status and performance metrics that can be used to track nearly every aspect of Windows system health. Most conventional (eventbased) tools that rely upon agents can’t take advantage of device health data available via Perfmon.
Another major issue inherent with agent-based monitoring tools is that they lack the ability to translate raw management data from simplistic alerts and logs into valuable, actionable information for IT administrators and operations personnel. The ever-growing volume of raw, unprioritized data, epitomized by event storms, often leads to delayed response to problems triggering confusion and operator overload chasing a high volume of trouble tickets. Raw event data originating at the device-level agents is not correlated (associated) with possible impact on key business applications and services – making these alerts even more difficult to manage.
