Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

Agent-based or Agent-less Network Monitoring 34

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.""
This discussion has been archived. No new comments can be posted.

Agent-based or Agent-less Network Monitoring

Comments Filter:
  • by Limburgher ( 523006 ) on Monday June 19, 2006 @08:13AM (#15560820) Homepage Journal
    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.
    • 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. Deploymen
  • 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 di
    • Re:Why the hassle (Score:2, Insightful)

      by m1ndrape ( 971736 )
      SNMPv3 [snmp.com] is supposed to be more secure, but then again how many products out there really support v3.
      • Re:Why the hassle (Score:3, Informative)

        by Pii ( 1955 )
        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.

    • Re:Why the hassle (Score:4, Informative)

      by arivanov ( 12034 ) on Monday June 19, 2006 @09:23AM (#15561045) Homepage
      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.
  • by mildness ( 579534 ) <bill@bam p h .com> on Monday June 19, 2006 @08:34AM (#15560879) Homepage
    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

    • Since I install monitoring for a while, I have a question for you - how do you deal with new devices coming onboard? Here's the other question: how fast do you need your alert? Keep in mind that before an alert gets acted upon, it has to be received, read and investigated. These are the two areas where agent-less monitoring really shines, and I'm curious what you think of the tradeoffs here.
  • by AndrewStephens ( 815287 ) on Monday June 19, 2006 @08:54AM (#15560943) Homepage
    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.

    • 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.

      Actually, they WERE making a good stab at this - five or so years ago. Since then, the nature of where they're trying to go with this has changed, nearly the entire project-team has disbanded (and was reformed with a different focus), and t

      • WMI is standard, in that the object model was set by an industry wide body, but Microsoft went their own way with the programming interfaces and network transport parts, using DCOM. Remember that the W stands for Windows. I always thought this was a shame, it would be cool to have a single console that managed all the Windows and Unix (and Mac?) machines on the network - which is exactly what Microsoft didn't want, I suppose.

        I am not sure that WMI really counts as agentless anyway, one of its great featur

    • 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
  • by thesandbender ( 911391 ) on Monday June 19, 2006 @08:59AM (#15560959)
    "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.

    • 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 too
    • Another differentiation is management. Do you want to install new agents on every new machine in your infrastructure? Unless of course you're just talking about network devices, for which SNMP is fine.
  • Agent servers (Score:4, Interesting)

    by Spazmania ( 174582 ) on Monday June 19, 2006 @09:15AM (#15561014) Homepage
    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.
  • 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 t
  • by Onan ( 25162 ) on Monday June 19, 2006 @01:15PM (#15562568)
    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.
    http://www.bdnacorp.com/index.shtml [bdnacorp.com]
    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
    • I actually work for one of the biggest software companies out there (Not sure if I'm allowed to say who ;) ). We have a lot of different monitoring processes and systems. We have 55,000 employees, and in the datacenter I physically work at, 5,000+ servers (about the 3rd largest in my co).
      We run at least 3 different monitors at this site that I know of. Some are hardware specific, some are 3rd party. It all comes down to what the different lines of business need. Our QA testers have to have a clea
  • 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 se

UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker

Working...