You have just run into a pretty serious shortcoming in Zenoss, though it seems to be a common shortcoming with most open-source monitoring solutions.  Zenoss can supress "downstream" events (for devices that are beyond the network failure point) only if Zenoss has already collected complete routing tables from all devices between Zenoss and the farthest devices.  You stated you have an MPLS network between your Zenoss server site and your remote sites.  I presume you can't get routing tables from the MPLS network because it is run by a provider and you don't administer it and thus can't get access to it.  Even if you did run the MPLS network, Zenoss will not pick up all the routing tables from the MPLS routers (assuming you have MPLS VPNs configured in the MPLS network).

We routinely just deal with large numbers of "false" events when there is a network failure close to the Zenoss server.  There is at least one manual device dependency solution out there in the community, but it seems complex enough that I don't want to get into it.  So I hope for a robust solution from the Zenoss team.

What Zenoss needs is Layer 2 topology knowledge and needs to suppress events based on layer 2 topology (this is a big deal in a large ethernet switch network).  If Zenoss had this capability, it would learn the Layer 2 connectivity in the network devices you manage and you could hopefully represent the provider's MPLS network as maybe a plain router and add false Layer 2 connections that connect to your remote sites.  Then, Zenoss could effectively suppress "downstream" events.

Zenoss team?

Why Zenoss doesnt copy from Nagios?

I think that Nagios is this case is absolutely superior. You can manually configure your hiearchy (parent & child relationship) and, in this case, the problem is solved. Nothing of complicate, just the annoyance of manually configure dependencies.

Moreover Nagios has anothe GREAT FUTURE: Service dependencies.

Honestly I don't understand why Zenoss doesn't implement these futures. Yes..I know that there are lot of things to be created and that deployment requires time and money and that there are priorities but I think that without these future zenoss will not be a REAL enterprise solution.

I like zenoss and I use it but strictly speaking about "real core futures", I think that these futures are absolutely compulsory.

Yes, if you look at the Community FAQ, and or the wiki, you can see the

snippet of python code to use in event transforms to manually create

device dependencies.

I also strongly support layer 2 mapping and dependencies.

--

James Pulver

Information Technology Area Supervisor

LEPP Computer Group

Cornell University

chitambira wrote, On 11/19/2009 6:21 AM:

You have said it well, "the annoyance of manually configuring dependencies in Nagios" If you can put up with that, then why not do the same thing as well in Zenoss? Nagios is a subset of Zenoss, whilist Zenoss implements auto discovered dependencies, it allows you to manually set you abitrary dependencies manually, you just need a little little little little bit of python skill.

Unfortunately, that's it for layer 2. (So if a switch goes down, you get

alerts on everything behind it).

--

James Pulver

Information Technology Area Supervisor

LEPP Computer Group

Cornell University

Matthew Kitchin (public) wrote, On 11/19/2009 11:14 AM:

I've searched looking for the mentioned methods of adding a manual dependency, but all I have found is this:

docs/DOC-3231

that isn't really practical to do for all my devices.

My network isn't complicated or frequently changing. It sounds like Zenoss shouldn't have a problem with the automatic method for me. I would love some help in troubleshooting this. My network map is a blank page. I don;t know if that is indicative of a larger problem. I have looked through zenping.log, and all I see are the lines where it mentions devices being down. I haven't seen anything related to topology or any info that seems to indicate there is or isn't a problem with it obtianing routing information. Can someone tell me the best way to determine if it is or isn't getting the information it needs to try and handle dependencies properly?

 

Thanks for all the help.

-Matthew

>

No, you need the entire topology between the Zenoss server and the

endpoint for this to work right.

--

James Pulver

Information Technology Area Supervisor

LEPP Computer Group

Cornell University

Matthew Kitchin (public) wrote, On 11/19/2009 12:21 PM:

Zenoss has indeed pulled the routes from the routers at our remote sites. All we want is to supress the alerts pertaining to LAN hosts that are directly connected to a router that is down. So you are saying this should work, even though we don't know all the routes between sites (due to MPLS)?