Am looking for an opensource network monitoring tool with ability to create different views for different users.
Regards,Jacob
Am looking for an opensource network monitoring tool with ability to create different views for different users.
Regards,Jacob
jacob miller (mmzinyi) writes:
Am looking for an opensource network monitoring tool with ability to create different views for different users.
Hi Jacob,
What kind of network monitoring ? Bandwidth utilization, service
availability, RTT, statistics data collection, ... ?
There are tons of open source software tools out there:
Nagios (www.nagios.org)
Zabbix (www.zabbix.com)
OpenNMS (www.opennms.org)
ZenOSS (www.zenoss.com)
SmokePing (http://oss.oetiker.ch/smokeping/)
Cacti (www.cacti.netl)
NetFlow Dashboard (http://trac.netflowdashboard.com/netflowdashboard/)
NFSen (http://nfsen.sourceforge.net/)
etc...
Depends on what you want to achieve!
Cheers,
Phil
Phil,
Am looking for availability reports,bandwidth usage,alerting service and ability to create different logins to users so they can access diff objects
Thnks,
Jacob
jacob miller wrote:
Phil,
Am looking for availability reports,bandwidth usage,alerting service and ability to create different logins to users so they can access diff objects
For all in one, OpenNMS does decent and may meet your needs. We often utilize a mixture of tools and modify for working with what we want. My only issue with OpenNMS was that it's java and I don't care to add java to the list of languages I program in. My only complaint was it could get really weird when you have 3,000 unnumbered interfaces.
Jack
I'd recommend ZenOSS.
-Scott
From: jacob miller
Sent: Thursday, August 19, 2010 4:36 AM
To: nanog@nanog.org
Subject: Re: Monitoring ToolsPhil,
Am looking for availability reports,bandwidth usage,alerting service
and ability to create different logins to users so they can access
diff
objects
Thnks,
Jacob,
I have not yet found a monitoring environment to my liking and I have
seen most of them over the years. That is a project that could keep
someone busy for a decade or so (and is one of the things I might work
on when I retire). It seems that the more configurable they are, the
less intuitive they are and more difficult to get configured properly.
Many of the open source tools have only one or two active developers who
also have lives outside the project and dealing with a flood of feature
requests from the field can be more than they can reasonably
accommodate. The commercial monitoring environments can be extremely
expensive and very difficult to configure. More important than
configuring them is maintaining that configuration over time as things
change. I have seen many monitoring environments installed and
configured only to become somewhat useless and disused over time as the
configuration isn't kept up to date.
Good luck in your search but in my experience it generally comes down to
putting together a hodge-podge of various tools that give a specific
operation the information it needs as those needs vary from one
operation to the next.
One problem, too, with these tools is that they often collect duplicate
information. It would be nice to have some common collector/store so
that other tools can pull the information out of that store. Why have
three different tools querying snmp stats from the same devices? Having
one collector and sharing the data would be a better approach. There is
an attempt to consolidate various open source tools in a common
framework called GroundWorks. They aren't completely there yet but I
believe they are pointed in the right direction.
George
One problem, too, with these tools is that they often collect duplicate
information. It would be nice to have some common collector/store so
that other tools can pull the information out of that store. Why have
three different tools querying snmp stats from the same devices? Having
one collector and sharing the data would be a better approach. There is
an attempt to consolidate various open source tools in a common
framework called GroundWorks. They aren't completely there yet but I
believe they are pointed in the right direction.
One approach to this problem is to use an independent device inventory
database which can be used to feed configurations to all the necessary
tools. This is what we've done at U. of Oregon with Netdot. See:
http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Vicente-netdot-presentation-nanog49.pdf
cv
Too much widsom in just a single email
Paolo
+1
-B
Cacti with the Monitor, Nectar plugins will accomplish what you are asking and is relatively simple to setup, but I'd throw in Phpweathermap, Quicktree, and Thold for giggles, additional monitoring and the ooshiney factor. Its fairly intuitive, but in large installations you will want to look at the autom8 plugin to merely scan your subnets and add devices it finds per the rules you define.
~J
Am looking for an opensource network monitoring tool with ability to create
different views for different users.Regards,Jacob
Just to add another opinion to the pot, I've used zabbix in several large environments, and I like it a lot. The developer team is decently sized, and very responsive to requests and feedback (they operate a commercial 'support' model for the platform, so working on the system is literally their day job - as George pointed out, this is often a problem).
Zabbix also supports distributed monitoring, which is very handy for scaling or for monitoring multiple locations without dealing with VPNS and the like (or if you have places you need to monitor behind NATs!). Its major weakness at the moment is the weak support for SNMP traps (works great in polling mode, though), so you will want a separate simple system for catching traps. In my opinion, that's just fine, because statistics/trending/basic resource alerting/etc are best kept separate from things like "OMG one of my powersupplies is dead!!11one".
Also supports IPMI, which is nice if you have IPMI deployed.
Best Regards,
Nathan Eisenberg
The last time I looked, my main issue with Zabbix was that it required (or
greatly preferred) their proprietary agent on every host. This may have
changed.
-Scott
It hasn't really changed. Almost every monitoring package I've found where you want to monitor something like 'disk space free on /' requires a daemon of some sort on the host - whether that's SNMPD or their agent. FWIW, I have had their agent running on many, many servers over the years - it has never caused me a moment of heartache (for safety's sake, iptables restricts who can talk to the agent, which has its own control mechanism built in to define who it will talk to, and it runs as a restricted user, just in case).
If you don't want to use their agent, you can monitor hosts via SNMP (if you run snmpd on your servers) or via server-side checks (is 80 listening? Does the site at http://www.google.com contain "I'm feeling lucky"? Can I ping 4.2.2.2? Etc...).
However, the OP was about monitoring network environments (which I took to mean routers/switches/firewalls/blah, not hosts). These devices typically speak SNMP, so $MonitoringSolution will just talk SNMP to it, and you don't have to worry about any agents.
-Nathan
Looking at ZenOSS to compliment our OpenView NNM system.
So far has been pretty simple to get up and running and the
support community is pretty responsive to questions.
We have cacti in our environment and it works great for pulling
bandwidth, CPU, interface errors, mem utilization. the reportit plugin
in particular is great for reporting bandwidth utilization for business hours.
Nathan Eisenberg (nathan) writes:
It hasn't really changed. Almost every monitoring package I've found
where you want to monitor something like 'disk space free on /' requires
a daemon of some sort on the host - whether that's SNMPD or their agent.
Anything else than SNMP is a hassle (IMHO).
I understand the idea of having a dedicated agent for some hosts -
Windows for instance, when querying the WMI - and often it's the only
way for a vendor to have a predictable, verified element in the greater
scheme (the network).
But in most cases, monitoring can be achieved by extending the SNMP mib,
and using and custom scripts that will report on mail queue size, in-house
application status, etc...
FWIW, I have had their agent running on many, many servers over the
years - it has never caused me a moment of heartache (for safety's sake,
iptables restricts who can talk to the agent, which has its own control
mechanism built in to define who it will talk to, and it runs as a
restricted user, just in case).
<hat employer=other>
While developing our own monitoring product, we've had to deal with
various constraints from the customer side, for instance pharmaceutical
companies where there was no way installing an agent on PLC machines would
pass internal audit, without having the entire system re-validated (we're
talking FDA-validated medication production here).
</hat>
But often, SNMPD ships with or is available as an optional base
component (Windows, most UNIXes) and it's easier to convince the IT
suits. Go figure.
Oh, and it avoided us having to install an agent on 1000+ servers
Cheers,
Phil
But the configuration learning curve for SNMP is very steep indeed.
--Curtis
Curtis Maurand (cmaurand) writes:
> Oh, and it avoided us having to install an agent on 1000+ servers
>
But the configuration learning curve for SNMP is very steep indeed.
Doing network monitoring and not understanding SNMP is like,
umm, well I fail to come up with an analogy, but you get my drift.
:)
It's a bullet you'll have to bite at one point.
Agreed. And it REALLY isn't that complicated. Go spend some time with
CORBA or TL-1 and then re-evaluate the learning curve.
SNMP is really very straight forward as a protocol. If a specific vendor's
MIB is difficult to understand or use, that is an entirely different matter.
-Scott
Vendor MIBs are the worst part of any new monitoring project. It is made
even worse when they change them ever so slightly during an upgrade making
your free disk space show as -2tb...
Agreed. And it REALLY isn't that complicated. Go spend some time with
CORBA or TL-1 and then re-evaluate the learning curve.SNMP is really very straight forward as a protocol. If a specific vendor's
MIB is difficult to understand or use, that is an entirely different
matter.