Believe me…I like Zenoss in fact I purchased the Enterprise version and I’m migrating from Nagios and Hp Open View.
Zenoss is a good product with more and more features compared to Nagios.
That said I simply exposed some limits or aspect that should be improved and…in my opinion, Zenoss is in the right direction and maybe that in a couple of years we won’t need to discuss if Zenoss is better or not respect to Nagios. Zenoss probably will be the killer application.
But I think that positive criticism are constructive and usually are appreciated by people that want seriosly help to improve products.
That said I must admint that is human and normal to have some preference.
Anyway at the end I think that discuss (always) is a positive thing!

bye
Marco

I appreciate the fact that the environments that we work with are vastly different and their requirements will similarly differ.

Clearly you are one of the many that really need layer 2 dependencies. I had already indicated my reservation for this one when I said I can excuse dependencies issue.

My push is for zenoss core to come out strong on the strength of the community. Already there is an indication in that direction thats why i have a strong passion for it.

Believe me I have come accross hard-core nagios admins who think zenoss is a non-starter and no-brainer, so I thot your post was leaning towards that…..

honestly I’m a little bit surpri
sed by your reply because when someone speak about technical aspects, should avoid comments based on a personal preference.

you say:
1) “Generation of events…..is less than 2, you can specify that in the filters”

Interesting is that I just found YOUR comment at http://community.zenoss.org/message/48705#48705 in which YOU say:
—–
you cannot use event count in a transform im afraid. count only gets updated when after transformation, so its not available before that
—–

So..what have I misunderstood?
I simply said that you can prevent the email generation but NOT the event generation. And..please note that I’m speaking about the real generation of an event and not just of the filtering using the event console.
This is quite a big limit in fact I have some problems. Chett Luther through the Enterprise support replied to me that he agree with me and told to me that Zenoss has already aware of this problem and will implement a kind of “quarantine” in next release.
I’m a dummy user but…Chett Luther is a Zenoss guru. Thus…what are we speaking about?

2) You say:
“Moreso, there is the event transform…history table”

I never said that this is not possible. I have lot of transforms that change serverity or send to history or drop.

3) You say:
“The other issue about….solution for that”

I’m an Enterprise customer and what I said has been confirmed by Chett Luther (that you surely know) through the Enteprise support thus I don’t understand your comment. The solution is not a Zenpack but just to use the workaround I described (really provide by Chett again….). The point of question is that this is confusing and Zenoss has already confirmed that will be fixed in the feature and as buil-in function and not as a separate Zenpack. Isn’t logic that this should be the base?

4) You say:
“About dependencies…device dependencies”.
Zenoss confirmed to me (and there is a thread in the forum also…) that this is one of the most requested features. So…I’m the only one that thinks that is not possible to manage hundreds of dependeces writing python code? In my opinion you are not impartial due to your Zenoss passion.

5) You say:
“Its only that most users…way/manner”

This is part true but isn’t my case. I used Nagios for 3 years and now I’m using Zenoss as main NMS for 1 year and…although I must admit that my knowledege is less than Nagios, I think that I can say with humility that I know Zenoss quite well now. I never thought that I would have to switch to Zenoss magically.

To summarize:
I think that when you compare two products, you should be objective as possible and leave aside personal preferences and you should should rely on reliable data. My statements have been analyzed by Zenoss Company also. Moreover I follow this argument with passion for many years and I found confirmation from many experts, perhaps a little more impartial than you.

I specifically refer to you post about the 3 cons that you listed about Zenoss. I want to point out that all of your cons (together with mb’s) are actually false.
I would excuse the layer 2 dependency one however, but for the other two, we cannot excuse(confuse) lack of understanding of the product for lack of features.

Generation of events if a background process thats similar even with nagios. What you require is to filter out events from your event view (similar to the filtering that you mentioned for nagios) so if you dont want to see events in your event view/dashboard when count is less than 2, you can specify that in the filters.

Moreso, there is the event transform, you can drop any event that meet a certain criteria and it will not be available in the status or history table.

The other issue about thresholds is also false. Did you try range thresholds? this is available prior 2.5 as a zenpack, so there is still a solution for that.

About dependencies, I take it that nagios configuration itself is as takesome as a simple python statement. So there is no excuse for those who do not want to copy-paste-edit a few python lines to take care of dependecies. there is a lot of info in the FAQs and forum on how one can implement manual device dependencies.

Its only that most users, after working with nagios for years and mastering it, fail to realise that they also need experience with any new system. We cant expect to just switch to zenoss and find every little trick we had in nagios to be automagically done in the same way/manner.

i find most issues or sceptism come from seasoned nagios admins, (new horses are easier to teach new tricks …lol)

That said, Zenoss is a good product that enable to monitor both windows and *nix servers without much difficult. Moreover the fact that Zenoss managers continuosly ask to users what they think or what they suggest is very very positive. I think that if Zenoss developers will develop these features, Zenoss will became the best Monitoring solutions!

And i wanted to thank you if you work for zenoss, that you actually replied Most software devs usually just ignore rants like my previous comments.

Though nagios does not provide a report like this, it provides the data to compile such a report, and we have written a nagios csv report parser which gives us such reports.

The availability reports will be “wrong” and indicate that alot of our equipment is faulty and not just unreachable f eks because of that one switch which lost network connectivity.

Basically it drills down to: fix or lose customers, and that alone should make it a pretty high priority task for zenoss.

(sorry if this sounds like a flame report, but im pretty frustrated about this being the open-source lover that i am)

You specify “manual” so it seems you’re aware that dependencies do work, sort of, if you feed Zenoss your routing table(s).

I agree, though. Most people yearn for dependency mappings. I could understand leaving this out if they provided a crazily robust and innovative new auto-discovery system — but that’s near impossible to discover. Human intervention is pretty necessary to define these relationships.

I do, however, believe that most IT environments can live without this feature. Define better alerting groups. And ok when something blows up you get bombarded with TXT messages. Just make sure to pay for all your employees’ unlimited TXT plans ..the benefits of Zenoss in my opinion make this worth dealing with.

- Manuel dependency mappings which does not require python scripting for layer2 devices and applications.

There are multiple request in the forums and on the trac site for this feature, why it has been ignored is beyond my comprehension

I think I was trying to get at the need for Configuration Management (puppet) and Monitoring convergence. Total convergence/integration, I mean. Hmm, I should do an article about that topic, actually – I think I will.

(also, this may all sound familiar.. it was originally published on http://enterprisenetworkingplanet.com and another blog.. I’m currently consolidating all past articles here)