摘自《Open Source Management Options》
，原文作者Jane Curry.
由于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
Product high points and low points
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前段时间研究过，上述的一些缺点我都有体会。
原文出自 脚趾的博客
由于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前段时间研究过，上述的一些缺点我都有体会。
原文出自 脚趾的博客
转载于:https://blog.51cto.com/xiaozhy/128538
945
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
