tcranfield wrote: > Elmerfud, thanks for the suggestion - I had already seen that page, the > problem is that I'm not clear how or whether I could apply that to our > situation. My main issue is that I'm finding the concepts and > interface/fields not completely intuitive, and the depth of documentation and > examples not sufficient to allow someone without much time (me!) to apply it > generically to their own situation.
QFT!! I'm sure their is some method of doing what you want. I'm sorry I can't be more help, but let me offer my understanding of why the severity is included in the dedupid. Let's say a given component triggers an alarm of level warning, and then later the same component triggers an alarm of level critical. Just because the component is has now issued a critical alarm it doesn't mean that the warning level alarm has passed. So in essence these are separate events that need to be dealt with. I think in your example with the thread usage, instead just issuing simple traps indicating the thread usage, it should be issuing rising/falling threshold traps. This way, even though they may not be deduped on to a single line, they would auto cleared as the falling thresholds happen. It may not be possible with your equipment, but to me, it seems the correct way to go when trapping a thresholded value. -------------------- m2f -------------------- Read this topic online here: http://community.zenoss.com/forums/viewtopic.php?p=17858#17858 -------------------- m2f -------------------- _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
