由於PDF裏的表格我無法導出，所以下面的對比表格我用的是圖片，也能看清，就是加載慢了點，還望見諒！
Comparison of Nagios, OpenNMS and Zenoss
Necessarily, comparisons are based . a mixture of “fact” and “feeling” and you need a clear definition of what features are important to your environment before comparisons can be valid for you.
Nagios is an older, more mature product. It evolved from the NetSaint project, emerging as Nagios in 2002. OpenNMS also dates back to 2002 but feels like the lead developer, Tarus Balog, has learned some lessons from observing Nagios. Zenoss is a more recent offering, evolving from an earlier project by developer Erik Dahl and emerging to the community as Zenoss around 2006.
All the products expect to use SNMP OpenNMS and Zenoss use SNMP as the default monitoring protocol. They all provide other alternatives – Zenoss supports ssh and telnet along with customised ZenPacks; Nagios has NRPE and NSCA agents (both of which, of course, require installing . remote nodes); OpenNMS doesn't have much else to offer outofthebox but it can support JMX and HTTP as well as having support for Nagios plugins.
All the products have some user management to define users, passwords and roles with customisation of what a user sees.
OpenNMS and Zenoss use RRD Tool to hold and display performance data; Nagios doesn't really have a performance data capability – Cacti might be a good companion product.
Most surprisingly, given that they all rely . SNMP, none of the products has an SNMP MIB Browser builtin to assist with selecting MIBs for both status monitoring and performance data collection.
There are advocates for and against “agentless” monitoring. Personally, I don't believe in “agentless”. .ce you have got past ping then you have to have some form of “agent” to do monitoring. The question is, should a management paradigm use an agent that is typically part of a box build (like ssh, SNMP or WMI for Windows), or should the management solution provide its own agent, like Nagios provides NRPE (and most of the commercial management products come with their own agents). If your management system wants its own agents, you then have the huge problem of how you deploy them, check they are running, upgrade them, etc, etc. OpenNMS and Zenoss have a strong dependency . SNMP although Zenoss also supports ssh and telnet monitoring, outofthebox(if your environment permits these). SNMP may be old and “Simple” , but all three products support SNMP V3 (for those who are worried about the security of SNMP) and virtually everything has an SNMP agent available.
The other form of “agentless” monitoring basically comes down to port sniffing forservices. Whilst this can work fine for smaller installations, the nsquared nature of lots of devices and lots of services doesn't scale too well. All three products do port sniffing so it comes down to how easy it is to configure economic monitoring.
Feature comparisons
The following tables start with my requirements definition and compare the three products . a featurebyfeature basis. (OOTB = OutOfTheBox).
Discovery
Availability monitoring
Problem management
Performance management
Product high points and low points
Nagios “goodies” and “baddies”
OpenNMS “goodies” and “baddies”
Zenoss “goodies” and “baddies”
Conclusions
What to choose? Back to your requirements!
For smallish, systems management environments, Nagios is well tested and reliable with a huge community behind it. For anything more than simple ping checks plus SNMP checks, bear in mind that you may need a way to install remote plugins . target hosts. Notifications are fairly easy to setup but if you need to produce analysis . your event log then Nagios may not be the best choice.
OpenNMS and Zenoss are both extremely competent products covering automatic discovery, availability monitoring, problem management and performance management and reporting. Zenoss has some topology mapping and has better documentation but the code feels less reliable. OpenNMS currently has a rather messy architecture around events, alarms and notifications, though this is said to be under review. I also struggle to believe that you have to recycle the whole of OpenNMS if you have changed a configuration file! The code feels very stable though.
My choice, hoping fervently that code reliability and documentation improves, is Zenoss.
========
從這篇文章來看，Zenoss值得研究一下。OpenNMS前段時間研究過，上述的一些缺點我都有體會。
原文出自腳趾的博客