NetXMS Support Forum

I am setting up traps ==> events ==> alarms and Event Description would be the logical place to put the OID text and parameters as returned from the OID lookup when adding the trap and pass it through to Alarm Browser as %D for event description similar to <DCIDescription> is passed for threshold alarms.

Apart from the fact you cannot tick a box that says "create event from trap OID" that would do it for you, and the fact that the mib itself tells you the OID names it will pass yet you need to look up the OID number in order to search; the text of the trap from the OID description that I add to the event is not visible anywhere!!

Event Log does not show it. Alarm Browser does not show it. Event Configuration does not have it as a variable to be able to display or insert. I have to open up event configuration in order to see a description of the event.

This to me seems like I am missing something obvious!! Hence my thinking this has to be a really dumb question.

OK - so you think that was dumb - what about this....

I add the trap to the trap processor. I do not need to add anything to the Event Configuration other than it being a unique match as all variables get passed through to Event Processing Policy. Description is pointless a it is not visible - so why do I spend any time with event processing when dealing with Traps other than to pick out the description of the problem from the trap configuration and include that in the Message - the same way all other events have been set up - except no point in adding Description as it is not available for display.

Except - and here is the really dumb bit - the fact that the Description is kept and stored against the event - it probably is available - I just cannot find it.

I have looked at the macro variables and found nothing there - so why go to all the effort to add the Description to the event - which explains what parameters are provided and why, but then make that text / field not available anywhere else?

It really just seems that when adding trap Processing, an event could be autogenerated based on the MIB severity, using the MIB name for that alert - and Message -  and we could skip straight through to Event Processing Policy to setup how the alarm looks. Am I missing something - again?

Nope - it is not there. 

https://wiki.netxms.org/wiki/NXSL:Alarm   -    nope

https://wiki.netxms.org/wiki/NXSL:Event   -    nope

As Event Description is not available for an alarm, or even an event, will bypass this potentially fantastic usable option.

Given that for Trap based Alarms, the DCI section is not relevant - its part on the screen would be the perfect place to display Event Description.

I am pretty sure the event description (just like the names of the varbinds) is more like a "comment" field.
Though I guess if you wanted to, you could create a script that pulls the relevant data out of the NetXMS database via an action called on the agent on the NetXMS server itself, then call that script as part of your processing policy?

My SNMP Trap setup is very limited at present, but I did run into a few stumbling blocks like lack of transform scripts (so I could translate the values of each varbind into something human-readable as required). Automatically pulling available information from the MIB would be a great start, but I'd still like to be able to add my own "spin" on the returned values.

When I first started with traps, I created one event per trap and just returned whatever the trap gave me. That was quite an undertaking and in the end meant wasn't helpful to technicians reading logs who had no idea what the values translated to.
Lately I've been moving towards attempting to create more generic events and using event processing policy filter scripts to adjust the event after the fact. That does for example allow me to change event severity depending on a varbind value or transform numerical status values into human-readable strings. However, that also comes with a downside. Once a device is in maintenance mode, event processing rules aren't parsed anymore, which means all that processing logic is completely ignored during that period. For most of our devices sending traps, that's a non-issue as they are never set to maintenance mode, but there are a few exceptions.

Its been a hectic week, very hectic.

Went live with me estimated 600-700 devices and as of today, 3300+ devices have decided they want to be monitored. Found out 10 years ago the intention was that "in the future, when we have the capacity...." that trap settings were made in the hope that something would arrive that would listen. NetXMS's arrival has now done that.

With traps lagging at over 90 minutes to appear in the console, plus 5 times the number of devices, some emergency tuning and lots of head scratching.

For traps - sending them through with matching varbinds was a killer. APC alerts with 19 varbinds was harsh - and with a minimum of 8 alerts to configure, I simply gave up as too hard - and not worth it. Now it is pos 1 pos 2 pos 3 - and if I will go back and tune any trap hat has flexible varbinds.

I must also be pretty unlucky in that the trap I get not only are most mibs missing, the ones I found would not compile for one reason or another.

As of now, 3,400 nodes, 108,000 DCI's and down to 489 alarms. I have managed to limp by at 80 traps and 109 event policies which I thought would be a lot worse.

Worst moment was when bouncing NetXMS and I got the DB locked by NetXMS problem - 05:45 in the morning, alerts an hour behind - looking like backing out. Found a few posts for the check option which worked - NetXMS back up and 500 Million events to process - but now with enough pollers and collectors to grind through so all good.

At the end of the day, I have ended up doing pretty much the same - Event Processing Policy - but that is a crappy solution as I am still limited to 255 chars in the Message to display, the formatting is limited, the description of the trap from the mib, along with the OID description of the varbinds, both intended to be visible to the trap reader - are not visible. Most trap descriptions have extra info regarding the trap, helpful on many occasions, but getting NetXMS to display it is simply not possible.

The funniest thing so far - after first doing the nxdbmgr check which cleared the lock - started the console which failed - cannot connect - and I just froze. then I remembered - helps if the service is started - and all good from that point onwards.

Real shame about the trap information not being available and me having to hard code oid descriptions into the alarm message field. For something as advanced and progressive as NetXMS - I am really surprised at how hard turning traps into alarms is. I suppose that goes hand in hand with the Alarm Browser view - filtering by severity / status was requested and noted as a feature request years ago bit never got anywhere.

Don't get me wrong - I am still absolutely stoked with NetXMS - it is just that this part sux - really, really sux

Perhaps Version 3 with its much improved interface???

Hi,

we have request for simplifying SNMP trap configuration so there should be improvements in 3.x branch in July/August.

Best regards,
Victor

Hi Vistor,

Thanks for that. If you need a beta tester, happy to help out.

Currently grinding through Dell normal, Dell IDRAC, AVAYA G3 and G7, and CISCO. - which includes finding and fixing the necessary support mibs.

Be patient enough and all gets revealed!!

https://www.netxms.org/forum/configuration/actions-parameter/

$event-> message gives me the message based on the Event message whereas $alarmMessage gives me the whole alarm text - which is available as  """%m""".

This not only solves my Description vs. Detail for ticket creation - but also gives me a basis to design my event message as the summary and alarm message as the detail.

Happy enough with this as a good reason for both and when and where to use both