Notification OID/MIB help

I am receiving SNMP traps and want the notification to contain the translated mib params, not the OIDs. The mib has been loaded, and the event properly translates OIDs, but the notification and email does not. How can I make the notification look like the log message of the event?

Expected outcome:
The notification to display the trap params as their mib values, not OIDs, like the event does.

OpenNMS version:

Other relevant data:
Here is the log message from the event (which successfully uses the mib)

agentEventReport trap received sysName=KPBAL alarmTrapCounter=4332 connAgentUID2= basicCurrentTime=0x07e6010601280c002b0000 basicAgentEventText=User[ione-tech] <--- Logged in basicAgentEventUser=ione-tech basicAgentEventUserGroup= basicAgentLocationIdentification= basicAgentLocationAlias=

And here is the notification when I use parm (specifically parm[all] here) -

Event parameters: ."KPBAL" ."4332" ."" ."" ."0x07e6010601280c002b0000" ."User[ione-tech] <--- Logged in" ."ione-tech" ."" ."" ."" 
      Basic agent event: User[ione-tech] <--- Logged in 

Post the relevant eventconf. I’m willing to bet that those names are hard-coded in the event description generated from the MIB and referenced by %parm[##]% numeric references. You can do the same thing in the notification, but you can’t do %parm[someFriendlyName]%.

Oh, gotcha! This is the log message for that event-

<logmsg dest="logndisplay">&lt;p>
	agentEventReport trap received

So in my notification message, I need to reference the params the same way? With all respect, that seems a little clunky. Is there a better way to do it? I get a lot of traps and it would be very time consuming to set up notifications for each of them this way. Why doesn’t OpenNMS store a map of OIDs to Mibs so you can do %parm[someFriendlyName]% ?

I’ll just lift the notification message from the eventconf logmsg for now, but it’d be nice if this could be handled automatically.

Thanks for the help!

1 Like

Scalability, I imagine. The OIDs are how those varbinds are referenced in the raw trap, we’re just copying them into the event rather than doing a lookup somewhere to figure out what OID corresponds to what friendly name for every incoming trap we process. That compute time matters when you’re processing millions of traps.

Wouldn’t that just be O(1)? And it seems like a good trade-off compared to the operator having to go through every trap and set up notifications for each of them this way. Just my two cents. This works for now. Thanks again!

I’m dumb, I should be using %descr% and %logmsg% anyway.