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

I advise a mixed approach

[Limburgher]

I use agents on the few where it's really critical that I be alerted to adverse conditions, say, low disk space, high load, etc. The rest I can jsut check TCP services and be done with it.

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

In a nutshell: speed of alerts vs. footprint

[mildness]

Please know that my perspective is systems monitoring opposed to the mostly NW orientation of the original (very good) article.

The main difference for my company's application is that an agent can tell you immediately of service degradation while an agent-less solution must wait for the next polling interval. As the article mentions, another important consideration is that agents can drill much deeper.

Importantly, agents require less NW overhead but take up more, often cheaper, RAM, disk and CPU resources.

In my current situation, my approach is to deploy agents wherever possible.

Cheers,

Bill

Re:Why the hassle

[m1ndrape]

SNMPv3 is supposed to be more secure, but then again how many products out there really support v3.

To Agent, or Not To Agent, That is the Question

[AndrewStephens]

It all really depends on how important the service is. If you can stand a few minutes delay in getting the information, then pinging the service remotely every 2 minutes is going suit you fine. If not, then a specific agent will be required to send out the alert. To be really safe you really need to do both, in case the whole data centre blows up and takes out your agent as well.

A lot of Windows software that claims to be agentless really just remotely installs a small stub using a domain account behind the scenes to do the task. Microsoft is actually making a decent stab at the problem with WMI, a sort of big brother to SNMP. Unfortunately the implementation is complex, non-standard, and up until now nobody has really used it for the type of remote instrumentation that this article talks about. Even Microsoft's own software has not really been instrumented properly.

Re:To Agent, or Not To Agent, That is the Question

[ocbwilg]

A lot of Windows software that claims to be agentless really just remotely installs a small stub using a domain account behind the scenes to do the task. Microsoft is actually making a decent stab at the problem with WMI, a sort of big brother to SNMP. Unfortunately the implementation is complex, non-standard, and up until now nobody has really used it for the type of remote instrumentation that this article talks about. Even Microsoft's own software has not really been instrumented properly.

Which makes you wonder what the difference is between a really big, complex agent welded into your OS and WMI.

But seriously, I use both agents and agentless monitoring with WMI. I use Insight Manager running on my servers to warn me of hardware issues, and use a VBScript that I wrote to connect to WMI on my servers to measure things that IM doesn't get. It also pings the servers at regular intervals. Between the two I think that we've got it pretty well covered.

The interesting thing is that IM basically plugs into WMI itself, though it does have new WMI classes that are HP/Compaq specific. If you have a decent engineering with good scripting skills (VBS, Perl, Jscript, Python, whatever) then it's really easy to use WMI to monitor and manage just about evrything related to Windows servers.

"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:"Agentless" monitoring does not exist

[Onan]

This is not correct.

It is absolutely true that snmpd, sar, and whathaveyou count as "agents" as much as anything else. However, you've artificially limited the discussion to only the range of monitoring appraoches that use such tools; of course when you only discuss types of monitoring that use agents, there is no such thing as agentless monitoring.

However, many (and arguably many of the best) monitoring approaches simply observe the behaviour of the actual running services, without using any additional tools on the monitored systems.

eg, want to know whether your webserver is up? Don't rely on a tool running on the webserver machine to look for the process and tell you whether it thinks it's up; just give it a request. Want to know how quickly your webserver serves requests? Just give it the request you care about and time how long the interesting bits of it take. This approach is often referred to as "black box" or "end to end" monitoring, though the latter can be something of a misnomer.

I would argue that such approaches not only exist, they have decided advantages. Asking a tool on a monitored machine whether it is correctly handling requests will never be as authoritative as simply asking it to handle a request and confirming the results.

Agent servers

[Spazmania]

At a previous job, the lead engineers used to joke that our email servers were actually agent servers that also ran email. It would have been funnier if it wasn't true.

Most monitoring agents go overboard. They monitor everything under the sun, even things that require a significant amount of computing power to wrangle in to useful data.

Even lightweight agents like Nagios' nrpe do stupid things like an expensive forking scan of the process table once for each monitored process. God help you if you're running HP's Openview.

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.

The biggest downside, overlooked.

[Onan]

I'd say that the biggest drawback to the whole category of approaches involving cooperative monitoring is that it adds complexity. And of course added complexity increases the chances that a system will fail to behave in the way that you expect, or indeed fail to work at all.

Monitoring systems really should be a couple orders of magnitude more reliable than the things which they monitor. One of the most effective ways to ensure that is by having them be far clearer and simpler; an advantage that cooperative monitoring forgoes.