Thank you, this is good info to have.
In lieu of using count could I use the firstTime, lastTime and
stateChange values?  This is more accurate to what I want anyway.  Who
cares how many time the message has come up, minuets and hours is much
more tangible.  Also it will not be effected if the poll time changes.

Something like: 
Evt.lastTime - evt.firstTime > 6 min and < 15 min evt.priority++
etc...
or if you want all the steps to have the same time between them you may
be able to do something like:
evt.priority = int(evt.lastTime - evt.firstTime / 10)

So, to revisit my mapping rule I would either:

set a mapping rule to be evt.priorty=2 and then a regex to find the
threshold warning.  Finally use a transform to increment the
evt.priority based on the above rules.

Or

Not worry about the current priority, just catch the event and use a
transform to create the priority from scratch based on the above rules.

James


James Alspach
Systems Applications Technician
Shasta County Office of Education

 
> Date: Wed, 19 Mar 2008 08:59:22 -0400
> From: Chet Luther <[EMAIL PROTECTED]>
> 
> On Mar 14, 2008, at 2:56 PM, James Alspach wrote:
> 
> > I know that this should be easy but I just can not seem to figure it
> > out.  I would like to take a new event (in this case a when an
> > interface exceeds the 75% threshold) and allow it to be at the
> > default severity until count is , lets say, 5  then bump it up to
> > the next severity and keep doing this until it becomes critical.
> > Even better would be to have different counts between jumps.  For
> > instance, 10 moves it up from info to warning, 5 more from warning
> > up to error...
> > My overall feeling is that I should be able to set a mapping rule to
> > be evt.priorty=2 AND evt.count=10 and then a regex to find the
> > threshold warning then use a transform to add one to the priority.
> > I have 3 problems with the above
> 
> Unfortunately this isn't possible using event mapping rules at the
> moment. The reason for this is that at "mapping time" the count is
> unknown. Zenoss has no idea what the count on the event is because you
> could easily affect the event's dedupid within the mapping rule
> (zProperties or Transform) and thus entirely change the count.
> 
> Basically the count value only exists once the event has already been
> inserted into the database. So doing this kind of thing would require
> post-processing on the events.

_______________________________________________
zenoss-users mailing list
[email protected]
http://lists.zenoss.org/mailman/listinfo/zenoss-users

Reply via email to