I've seen a number of users reporting a large lack of dependency relationships. Where a failure in one devise can be made to prevent failures from being reported in a list of other devises. We like the product, but this either major flaw or needs better documentation in order to script a solution. The text below explains the problem:
I feel like there is more to this. If you can write something like this http://www.zenoss.com/Members/netdata/create-a-device-dependency/ how is it that we can't create a similar script that would tell the second, or third or fourth devises in a chain to not alert about ANYTHING. The problem is that this is the only example I can find and it's not well documented. I was also told this method of creating a dependency will only work within the same event class. Meaning that you have to create the "transform" with in an event class. The example from the link will only work if you build your dependency in the "status ping" class. So, you can't create a rule like this at the top level of events and then have it be inherited. In other words, the dependency will only prevent the second devise from sending an alert that it is down (because of a ping check failure) it will NOT prevent OTHER checks that you may have running against the second devise. If you're still checking for mysql, for example, or really any check that does not belong to the ping status class, you'll get the other alerts on the second devise. The goa l is to prevent the dependent devises from sending ANY alerts. Without this ability you get page storms. It seems that given the example above, there must be away to write a script that could do this. Just need more examples, unless there is truly no way to build a dependency that can be written for the top level of /Events? -------------------- m2f -------------------- Read this topic online here: http://community.zenoss.com/forums/viewtopic.php?p=20212#20212 -------------------- m2f -------------------- _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
