Event Transform

[Sam Nirmal]

Hello all,

Happy New Year!  

I'm working on re-writing an event transform for a network device. Existing event transform was not written correctly. 

Traps coming from the device have component "null" and the eventclasskey has the trap name. The network devices 

has multiple components sending traps whenever the issue occurs and recovers. 

So typically, one would create sub event classes for each component and entities under including their status. This

approach provides better control on the event management and I think probably better for Zenoss to perform better.

However I'm thinking about having just one event class transform and use eventclasskey to achieve the same result. But

then I need to ensure the events closure happened exactly for the same event which generated the event at the first place.

Then I have to put the event message with the "clear" received message/summary.  e.g. SessionUp / SessionDown

Device H/W status etc..

I understand autoclear considers device name, component, eventclass, eventkey.  So that will have to take car of in the

event transform.  But then how do I do it? 

Please advise.

Thanks

 

[Jane Curry]

Hi Sam - Happy New Year to you too.

For starters, do you have my "Event Management for Zenoss Core 4" paper? https://www.skills-1st.co.uk/papers/jane/zenoss4-events/  Section 9.6 has some examples of rules and transforms for SNMP traps, including a defaultmapping example which you might use if you want to map all your TRAPs into one eventClass.

Does your incoming TRAP have any useful varbinds on it?  A varbind with the name of the offending component would be really handy; then you could get hold of that string (see the examples) and use the transform to set evt.component, which as you rightly point out, is part of both the duplicate fingerprint and the auto-clearing fingerprint.

The other event attribute you may need to tweak in your transform is eventKey.  This is also used in both the duplicate and the auto-clear fingerprint, if it exists. Especially if you are modifying the summary event attribute, for DUPLICATES, if evt.eventKey doesn't exist (ie is null) then the evt.summary will also be used to decide whether an event is a duplicate.  You can set evt.eventKey to anything you want in the event transform - it might be a fixed string or it might be the value of a varbind if there is a useful one.

The actual mechanism for auto-clearing events is not done when the trap is initially processed by zeneventd, but by the zeneventserver daemon when a clearing event (with severity=0) is received and processed into the zep database of events.  

Again, you may need to do tests in your transform to determine whether you have a "good news" event and then set evt.severity=0.

Hope that helps but feel free to continue the conversation here.

Cheers,

Jane

[Sam Nirmal]

Hi Jane,

Yes, I've been referring the great paper of yours.  Thank you for sharing it. 

The devices traps do have a few varbinds associated with them. However those are very specific to a trap.  The "eventKey"  fileld is empty in all traps. Essentially "eventClassKey" is the only field seem unique.

I've created python lists for the  "ok", "critical" and "warning"  eventClassKey's.

Not sure if evt.summary will be used for auto-clear besides for a duplicate.  If it does, then as long as I refer the eventClassKeys, the events will be processed / auto-clear / closed as long as it gets matched.

The events gets sent to an EMS system. I've setup triggers to do the forwarding. In that script, I can pass on the $(evt/eventClassKey) as a "service". Even if there is different varbinds for the same 

eventClassKey, I will have the same service listed separately on the EMS having different event summary. At least I hope it would work that way.

Do you think that would work?

I'm not sure how I can use "eventKey"  here and how it will make it easier/simpler in any way ?

I was trying to examine the incoming trap using "tcpdump" and "wireshark" but for some reason I don't see trap severity, I think, better idea is to look into the DB to get the trap info. I'll have to look out the query etc.

to get that information.

Thanks

--
You received this message because you are subscribed to the Google Groups "Zenoss Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zenoss-core...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zenoss-core/cf982702-5956-4602-a93f-13d3f1888626n%40googlegroups.com.

[Jane Curry]

Hi Sam,

The evt.eventKey will be null, in general, on TRAPs.  Usually eventKey is populated by Zenoss daemons that process Zenoss-generated events - thresholds and some Zenoss-shipped events.  That said, IF it is useful to you, you can set evt.eventKey in a transform and it will then be used by both the duplicate fingerprint and the auto-clear fingerprint.  The only reason you might want to do this is if you want to ensure that the summary field is NOT used in the duplicate fingerprint. evt.summary is never used by the auto-clear fingerprint.

TRAPs do not have a severity on them - it's not in the SNMP architecture.  When the zentrap daemon of Zenoss (/opt/zenoss/Products/ZenEvents/zentrap.py )  receives a trap then it processed the SNMP Protocol Date Units (PDUs) and turns then into Zenoss events.  The event has a few fields set by default ; for example, evt.severity is set to Warning by default.  The value of evt.summary varies a bit depending on what the TRAP is - have a look at the code.

You should be able to find most of the info you want on a Zenoss event from the Event Console without having to dig directly into the zep database.  If you want to modify an event field in a transform but still know what the original value (maybe set by zentrap) was, then I use a trick in a transform to save the  incoming value in a user-defined event field, which you can see in the Detail of an event in the Event Console.  For example, in a transform:

   evt.summaryFromZentrap = evt.summary

   evt.summary = "My new summary"

or

   evt.summary = " My new summary.  Old summary was  " + evt.summaryFromZentrap

Obviously, you only leave the evt.summaryFromZentrap in the transform for debugging.

Hope that moves you forward.

Cheers,

Jane

[George den Boer]

Hi Sam,

Not sure if it applies to your issue but I have attached a file that shows how I handle traps.

George

To view this discussion on the web visit https://groups.google.com/d/msgid/zenoss-core/1439037933.1404727.1706589081714%40mail.yahoo.com.

[Jane Curry]

Thanks George - really helpful set of examples. Should help lots of folk.

Cheers,

Jane

[Sam Nirmal]

Thank you George for sharing it! It is indeed a good and useful reference for handling traps.

Currently I'm going through the device MIBs. I will test by selecting a trap's specific varbind and defining it as a component,

However for some traps, the varbind value is in Base64 format (e.g. IP address is in Base64 format ) which is weird. I've to investigate that to understand why.

Thanks 

To view this discussion on the web visit https://groups.google.com/d/msgid/zenoss-core/CAFZTHNLmoAEqcUMv%3DW-h412sGm7MohJ80NAm_3Up-f0%2Bx%2Bp1SQ%40mail.gmail.com.