I have to rebuild a new Nagios box and thought this might be a good time to migrate away. I use snmp mostly for everything but with the fork Nagios endured I wonder about putting any more effort into the project.
I probably should look at OpenNMS again, but the other options I think might work are Icinga (Should be trivial to migrate) or Zenoss or maybe even Zabbix?
Anyone have experience in Nagios and care to share comparisons with similar projects with strong community involvement?
Also, anyone currently running OpenNMS that can comment on the learning curve and level of flexibility coming from a Nagios user?
Thanks! jlc
I am a pretty hardcore ZenOSS user.. We use it to monitor over 1000 devices in different fashions - using a combination of SNMP (Linux), WMI (windows) and SSH (Unix/Aix). While there is a slight learning curve to get everything working the way you want - it is, in my opinion, the most powerful open source NMS. It is a very active project with excellent community (and even commercial) support.
I'd definitely suggest that you take a look at it.
Josh
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Joseph L. Casale Sent: Friday, June 18, 2010 10:32 AM To: 'centos@centos.org' Subject: [CentOS] Migrating away from Nagios
I have to rebuild a new Nagios box and thought this might be a good time to migrate away. I use snmp mostly for everything but with the fork Nagios endured I wonder about putting any more effort into the project.
I probably should look at OpenNMS again, but the other options I think might work are Icinga (Should be trivial to migrate) or Zenoss or maybe even Zabbix?
Anyone have experience in Nagios and care to share comparisons with similar projects with strong community involvement?
Also, anyone currently running OpenNMS that can comment on the learning curve and level of flexibility coming from a Nagios user?
Thanks! jlc _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I am a pretty hardcore ZenOSS user.. We use it to monitor over 1000 devices in different fashions - using a combination of SNMP (Linux), WMI (windows) and SSH (Unix/Aix). While there is a slight learning curve to get everything working the way you want - it is, in my opinion, the most powerful open source NMS. It is a very active project with excellent community (and even commercial) support.
Yeah, the WMI capability is a big plus for me... I am downloading the pdf's to print for some weekend reading.
On 6/18/2010 10:31 AM, Joseph L. Casale wrote:
I have to rebuild a new Nagios box and thought this might be a good time to migrate away. I use snmp mostly for everything but with the fork Nagios endured I wonder about putting any more effort into the project.
I probably should look at OpenNMS again, but the other options I think might work are Icinga (Should be trivial to migrate) or Zenoss or maybe even Zabbix?
Anyone have experience in Nagios and care to share comparisons with similar projects with strong community involvement?
Also, anyone currently running OpenNMS that can comment on the learning curve and level of flexibility coming from a Nagios user?
It depends on what you are doing, but if it is mostly snmp data collection and icmp/tcp application monitoring, OpenNMS will probably do it out of the box with autodiscovery and no client setup. If you have lots of custom nagios client code, you'll probably have to twiddle some ugly XML config files to get that data collected. The mail list support is fairly good if you have problems.
It depends on what you are doing, but if it is mostly snmp data collection and icmp/tcp application monitoring, OpenNMS will probably do it out of the box with autodiscovery and no client setup. If you have lots of custom nagios client code, you'll probably have to twiddle some ugly XML config files to get that data collected. The mail list support is fairly good if you have problems.
Les, Compared to Nagios, how difficult was it to get OpenNMS running in your environment? I found Nagios trivial but have never really rolled my sleeves up with OpenNMS, I have just sort of kicked the tires over the years...
I have to say the WMI capability of Zenoss is a real plus for me and the documentation for Zenoss looks way better than OpenNMS which even they admit on the wiki isn't very good:)
jlc
On 6/18/2010 12:06 PM, Joseph L. Casale wrote:
It depends on what you are doing, but if it is mostly snmp data collection and icmp/tcp application monitoring, OpenNMS will probably do it out of the box with autodiscovery and no client setup. If you have lots of custom nagios client code, you'll probably have to twiddle some ugly XML config files to get that data collected. The mail list support is fairly good if you have problems.
Les, Compared to Nagios, how difficult was it to get OpenNMS running in your environment? I found Nagios trivial but have never really rolled my sleeves up with OpenNMS, I have just sort of kicked the tires over the years...
I've never done Nagios - I don't want to think about anything that needs per-host configuration and I want to get router/switch/link details in the same tool. 'Getting it running' should be a yum install these days plus configuring a discovery range which you can now do through the web interface. If you have a server for a test install and the same snmp community string everywhere it should be painless to test.
The one thing I find a bit cumbersome is building pages with the graph groupings that I want to see together. It's not a difficult process, just several steps to pick and position each one on a page. But that's just for convenience - you can go to the node page and pick graphs individually without this.
I have to say the WMI capability of Zenoss is a real plus for me and the documentation for Zenoss looks way better than OpenNMS which even they admit on the wiki isn't very good:)
I tried WMI on opennms a while back and couldn't make it work, but I'm sure it is much better now. As for documentation in general, you shouldn't need much to get started and the mail list is pretty good if you have specific questions. In fact I usually look at mail list archives before making choices like this. If people are asking about problems with the basic application functionality I'm less likely to try it than if the discussions are about adding new stuff or extensions.
Greetings,
On 6/18/10, Joseph L. Casale jcasale@activenetwerx.com wrote:
I have to rebuild a new Nagios box and thought this might be a good time to migrate away.
Try Zabbix.
It is very responsive. in forums, mailing lists, bugzilla, etc.
Important: try trunk
Regards,
Rajagopal
On 06/19/2010 09:39 AM, Rajagopal Swaminathan wrote:
It is very responsive. in forums, mailing lists, bugzilla, etc.
I can offer some insight into this.
We recently moved a 150 node network from cacti / nagios / monit to Zabbix; Its been an exceptional mixed bag. The API is extremely basic, and does not work as documented - a fact that the developers are aware of but dont seem keen on moving it forward. Which has the affect that everything on the management side ends up being point and click on a web interface ~ massive waste of time and counter productive. Not being able to version control the config changes brings back memories of 1990's! Secondly, there are very fundamental issues in zabbix, like not being able to run counters for high throughput network interfaces. And not being very efficient with its data store ( 150 machines of ours are generating 230MB of data per day. We are expecting to turn the year with over 130GB of data in the mysql db. At which point we go back into only storing trend data. Then there is the manic process of creating active tests and inter machine or location dependencies.
Just to be clear - I'm not saying its a bad system; its usable and easy to deploy. There are places where it will fit in well,specially if you have a small client load ( maybe 40 machine instances or less ). If you don't like running client side agents, pass on zabbix.
btw, we considered moving to zabbix for *.centos.org as well and did an evaluation in Apr 2009 and it just did not scale up for us. On the other hand the Fedora infrastructure guys are running it. And from what I hear, they are quite happy with things.
- KB
On Sat, Jun 19, 2010 at 12:24:41PM +0100, Karanbir Singh wrote:
On 06/19/2010 09:39 AM, Rajagopal Swaminathan wrote:
It is very responsive. in forums, mailing lists, bugzilla, etc.
I can offer some insight into this.
We recently moved a 150 node network from cacti / nagios / monit to Zabbix; Its been an exceptional mixed bag. The API is extremely basic, and does not work as documented - a fact that the developers are aware of but dont seem keen on moving it forward. Which has the affect that everything on the management side ends up being point and click on a web interface ~ massive waste of time and counter productive.
Care to talk a bit more about this? What do you need more? Just trying to understand the limitations..
Not being able to version control the config changes brings back memories of 1990's! Secondly, there are very fundamental issues in zabbix, like not being able to run counters for high throughput network interfaces.
Wasn't the 64bit counter fixed/added already?
-- Pasi
And not being very efficient with its data store ( 150 machines of ours are generating 230MB of data per day. We are expecting to turn the year with over 130GB of data in the mysql db. At which point we go back into only storing trend data. Then there is the manic process of creating active tests and inter machine or location dependencies.
Just to be clear - I'm not saying its a bad system; its usable and easy to deploy. There are places where it will fit in well,specially if you have a small client load ( maybe 40 machine instances or less ). If you don't like running client side agents, pass on zabbix.
btw, we considered moving to zabbix for *.centos.org as well and did an evaluation in Apr 2009 and it just did not scale up for us. On the other hand the Fedora infrastructure guys are running it. And from what I hear, they are quite happy with things.
- KB
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 20/06/2010 10:20, Pasi Kärkkäinen wrote:
of but dont seem keen on moving it forward. Which has the affect that everything on the management side ends up being point and click on a web interface ~ massive waste of time and counter productive.
Care to talk a bit more about this? What do you need more?
I'd like the monitoring and tracking app to integrate with my provisioning and management stack of apps. So if there was a good usable api, I would be able to add and remote monitors, take actions based on triggers from Zabbix and be able to do all this dynamically ( or via code from within the management stack ). I'll tell you one thing though - whatever Zabbix has right now, broken and dis-functional - its a world better than generating nagios templates using perl and having to call service nagios relaod all the time.
Wasn't the 64bit counter fixed/added already?
its got nothing to do with 64bit counters, its how the backend storage stuff is handled.
-KB
PS: try trimming your replies a bit!
On 6/21/2010 9:24 AM, Karanbir Singh wrote:
On 20/06/2010 10:20, Pasi Kärkkäinen wrote:
of but dont seem keen on moving it forward. Which has the affect that everything on the management side ends up being point and click on a web interface ~ massive waste of time and counter productive.
Care to talk a bit more about this? What do you need more?
I'd like the monitoring and tracking app to integrate with my provisioning and management stack of apps. So if there was a good usable api, I would be able to add and remote monitors, take actions based on triggers from Zabbix and be able to do all this dynamically ( or via code from within the management stack ). I'll tell you one thing though
- whatever Zabbix has right now, broken and dis-functional - its a world
better than generating nagios templates using perl and having to call service nagios relaod all the time.
Did you consider opennms - and if so was there a reason for not using it? It has some integration for provisioning, but I'm not exactly sure how it works and the latest release made some changes.
On 21/06/2010 15:47, Les Mikesell wrote:
Did you consider opennms - and if so was there a reason for not using it? It has some integration for provisioning, but I'm not exactly sure how it works and the latest release made some changes.
its on the list of things I want to get to one day, not quite there yet. Although, higher on the list at the moment is the whole flapjack stack and how it integrates with cucumber!
- KB
On 6/21/2010 10:01 AM, Karanbir Singh wrote:
Did you consider opennms - and if so was there a reason for not using it? It has some integration for provisioning, but I'm not exactly sure how it works and the latest release made some changes.
its on the list of things I want to get to one day, not quite there yet. Although, higher on the list at the moment is the whole flapjack stack and how it integrates with cucumber!
I didn't know about that, but the first googled hit says you are supposed to be able to write reusable tests in a human-readable language which sounds way too unrealistic to ever work. And I want a tool that understands network equipment natively, not just it's own clients on only the hardware/OS's where you are able to run them.
I can understand putting off testing OpenNMS back in the day when you had to get your own Sun JVM which was particularly painful on CentOS, but it has been bundled in the yum repo for a while now. And maybe someday enough bugs will be shaken out of the version of openjdk in Centos that it won't be needed...
On 21/06/2010 18:05, Les Mikesell wrote:
I didn't know about that, but the first googled hit says you are supposed to be able to write reusable tests in a human-readable language which sounds way too unrealistic to ever work. And I want a tool that understands network equipment natively, not just it's own clients on only the hardware/OS's where you are able to run them.
I dont think its a one or the other situation. Flapjack + cucumber is more oriented towards app developers being able to also contribute to the monitoring and state management policies. And for that I've seen it work well, but not used it myself.
We have a hom ebrew setup in place right now for the app and services monitoring, that I am quite keen to replace as time permits.
- KB
On 6/22/2010 6:06 AM, Karanbir Singh wrote:
On 21/06/2010 18:05, Les Mikesell wrote:
I didn't know about that, but the first googled hit says you are supposed to be able to write reusable tests in a human-readable language which sounds way too unrealistic to ever work. And I want a tool that understands network equipment natively, not just it's own clients on only the hardware/OS's where you are able to run them.
I dont think its a one or the other situation. Flapjack + cucumber is more oriented towards app developers being able to also contribute to the monitoring and state management policies. And for that I've seen it work well, but not used it myself.
Can't the app developer side either expose some status values via xml over http or add an extension for net-snmp? It seems to me that if you have to design a new framework you've already missed the point.
-
Baird, Josh -
Joseph L. Casale -
Karanbir Singh -
Les Mikesell -
Pasi Kärkkäinen -
Rajagopal Swaminathan