Agent-based or Agent-less Network Monitoring

An anonymous reader writes "ITO has published an interesting article on agent-based and agent-less network monitoring approaches: "Agents can monitor the status (availability and performance) of applications, servers, and network components in significantly more depth than generic management tools, since they are able to gather data through application-specific interfaces, exercise the full application functionality, and perform localised aggregation and summarisation of high volume metrics for example.""

Comments

Re:I advise a mixed approach

[Total_Wimp]

Mixed works well for us as well. I know less about large data centers, but on our medium sized network(a couple hundred servers), the performance and instalation costs don't really matter, as long as we restrict the agents to machines the really need it. In actual practice, this works out to about a couple dozen servers. We may add more in the future, but this is totaly managable at the moment.

I know this article doesn't really cover it, but we feel very different about client computer agents. Deployment is the kicker here. When you have a quarter of your workforce highly mobile, some of whom almost never come into the office, then installing agents is a real headache. Sometimes you can't help it because the agents you need to instal are the very ones that will make managing large numbers of mobile users practicle. But where we can avoid it, we do.

TW

"Agentless" monitoring does not exist

[thesandbender]

"Agentless" monitoring is a misnomer dreamt up by marketing and sales types to differentiate their product as "better". All monitoring is agent based, the only difference is if the agent you are using is bundled with the system or a 3rd party agent. Most "agentless" monitoring systems acquire their data through SNMP, sar, netstat, iostat, WMI, etc. All these providers will consume system resources in some manner or another so the argument that agents incur more overheard is usually nonsense (unless the agent is very poorly written). In most cases the monitoring packages bundled with the system can be disabled so the new agents will consume resources that would have been used by the system utilities. And poorly conceived/written monitoring schemes will be a drag on any system. The only real differentiation is:

a) specific metrics gathered
b) frequency of update
c) "agent" based required distribution and control of a 3rd-party piece of software

Performance and resource utilization are a red herring.

Re:Why the hassle

[arivanov]

I admire your optimism regarding the availability of SNMP and its capabilities. The reality is considerably bleaker.

First of all, as far as hosts are concerned only a small fraction of people writing an application bother to define a MIB and register OIDs. The fraction that has bothered to read the proxy agent specs and plug themselves correctly into the SNMP agent is even smaller. Even really trivial things like RAID status are simply not present on most OS-es. Plenty of things in the MIB are still 32 bit counters while the OS-es have moved on to 64 bit internally. SNMP on a Unix (or Winhoze for that matter) platform is a disaster area.

Second, SNMP is too inflexible for large network applications like modern access boxes and high end routers. These nowdays discard most of SNMP functionality and replace it with proprietary protocols or XML. Cisco HFR and the ex-Uniphase (now Juniper) boxes are prime examples.

Third SNMP has never been the favourite due to its inflexibility for applications related to deep telco nuts and bolts like element management, mobile comms systems, etc. The reasons are too long for a slashdot rant, but they are there and they are real. This is mostly corba territory with some web services sprinkled in a few places. SNMP does not play there.

Overall, SNMP is used only in places where minimal surface level monitoring is required and the requirement for reliable transfer of alarms and data is not present. It is either discarded or supplemented by custom agents in nearly all cases where people need to look into the guts of the system.

Re:Why the hassle

[Pii]

It is actually more secure, in that it supports encryption (if you enable it). Currently, it's only single DES encryption, but efforts within the standards community are looking to add support for 3DES and AES.

In the interim, however, you can always use IPSEC to provide the security that SNMP lacks, providing your equipment supports it.

On the NMS front, there are a number of platforms that support SNMPv3. NetCool and Spectrum as a couple of examples, and Concorde will have it by 3rd Q this year.