Slashdot Mirror
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.""
. . . . how much of this overlaps with conventional AI ?
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.
You are not the customer.
Inventing, reinventing and treinventing agents, paying for extra management tools then you discover they're broken or din't fulfill your needs (although otherwise advertised), and of course the cross platform headache; all this and we simply forget the standards, the keyword is SNMP.
OK, it's not secure, but again what else is secure if we don't give it enough research and care, it can be simply implmented and it's integrated in most of the equipment that need monitoring, but hey we ignore it, as long we didn't pay zillions for it then it's ignorable.
Don't you just hate it when vendors force you to think out of the open standard and cost you more for a lesser featured solution, people please wake up.
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
bamph
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.
sheep.horse - does not contain information on sheep or horses.
"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.
We run into this ALL THE TIME. I work at a small software startup http://www.certalertsoftware.com/ and everytime we present/install to a cuatomer this very issue comes up. Our software performs network monitoring of several security metrics including the validity of SSL certificates. So, from a scanning prespective, agent-less monitoring gets us 90%+ of what we need and is fully acceptable by many of the customers.
.... would this be of any benefit to you?
Where it gets interesting is when the customer finds out that our software has the ability to UPDATE those remote certificates in an agent/agentless fashion. This is why it gets interesting, because there are SO MANY polocies in corporate America that we never run into the same rationalization for either way to do things.
Lastly, and most interesting to me is some of our customers have suggested that we champion a standard for Agent Monitors where the agent monitor can be installed once and have the properties like polling, summation, and communication. Then all the different network monitoring packages they have could adopt this spec and be way more manigable by them. Easier to implement by us. And standards based for everyone.
Seems like a great idea, and we are exploring how to do this, but I ask slashdoters
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Cynic meet optomist. In Mr cynics world, all things happen for the wrong reasons. e.g. greed. In optomists world things happen for more practical reasons. e.g. customer demand. Tune in next week as we see if we can't get cats and dogs to live together.
Configuring Nagios to execute remote commands via SSH and the deposit them on a central server has worked for us. I have reduced the CPU/memory footprint that many other "agent-based' monitoring systems have consumed. By making the central server do all the work and keeping the data encrypted, I have let the server we monitor do what they need to do, run ciritical applications only without allowing anyone to see or alter the data in mid-strem. The only thing this setup really uses is the under utilized bandwidth on GB connection to the server.
I don't think it really matters. We use a combination of technologies including Nagios (OSS), and some of the offerings from Klir Technologies. The Nagios stuff we do relies heavily on agents, and the stuff from Klir relies heavily on SNMP and is completely agentless. For ease of deployment the Klir stuff wins easily and it offers sufficient information for many of our servers, for those where we want something special or more specific to our application we create custom scripts and use the Nrpe agent under Nagios.
What ultimately matters is are you getting the data you need? Often you may find you do get this data from agentless solutions, sometimes you may not. I'd recommend going with some of the agentless stuff to start, see where it doesn't quite meet your needs and then supplement it.
Note: I work for a company that makes agents + their upgrades.
Others already mentioned you need agents to do a deep dive... lots of companies are running at least 2 of them (one from the vendor to handle the OS + hardware, one from a 3rd party to do "everything else").
To monitor and manage a large amount of systems you need to push the "smarts" of the system as far down as possible. Pure agentless/polling systems either run into network issues (saturate links with polling) or CPU issues (what do I do with these alarms?)... usually both. With an agent on each box a lot of intelligence about when to trigger an alarm and what to do about it is baked in, resulting in lower CPU use by whatever the "server" is, and network traffic only generated when something actually goes wrong.
You do end up with agentless tech built in anyways.. since synthetic transactions are so useful, and you'll always need simple periodic polls to make sure the agents are alive and healthy.
Mike
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.
I write agentless network inventory software for a living.
:P) implies that there will be no 3rd party application installation overhead. If you are working in IT and are the one who would have to roll out an agent, you can understand why the distinction is important. Using the device's own management interface is typically seen as safer than an agent as well, because it was written by that device's OEM, not the management software company.
http://www.bdnacorp.com/index.shtml
That said, my opinions here are not those of my employer. (I'm an engineer - why else would I be reading slashdot non-main-page article?) My opinions also aren't specifically about our product because it does inventory, not monitoring.
It's hard to say agent or agentless. Someone in a previous comment said there is no such thing as "agentless" and mentioned SNMP, WMI, sar, etc. Naturally, there needs to be *something* giving values. However, the moniker "agentless" (usually quoted
There are downsides to agentless as well, indeed the polling issues are somewhat true. Some technologies, like SNMP Traps, are capable of notifications for monitoring, but some are not. In the case when a machine only has some kind of shell interface, the only choice is to attempt to use that as periodically as desired.
I also can't break any NDAs, but to those who think that agentless "doesn't scale"
http://www.bdnacorp.com/customers.shtml
http://www.gcn.com/print/24_24/36708-1.html
We work with several of the largest IT installations in the *world*, and we do it with relative ease. However, we're not a monitoring solution - we do inventory. YMMV with monitoring, and with different vendors.
Is the Q.3 Based Approach.
I worked in telecomms, and used/administered both a Nokia NMS2000 and a Siemens OMC-S and OMC-B
While is WAY more complex than SNMP (rmeember te S is for simple) is Extremely reliable, and has many advantages over SNMP:
Atomic transactions: In Q.3 you can specify a complex configuration change and be certain that, in case of a failure mid-process, your system will be either in the initial state, or the final one, but not in an intermediate state (the lack of this feature, plus the security issues are the reason no one uses SET in SNMP).
In Q.3 traps can be acknowledged, therefore, no need to send and resend time and time again.
In Q.3 the concept of trap clearance is part of the standard, and not something that each vendor implements on its own.
So, more than only monitoring, Q.3 provides REAL management. Is sad that telecom equipment makers are moving away from it and to an inferior standard (SNMP)
Just my 0,02
*** Suerte a todos y Feliz dia!