TRAP defining - a million hours completed - in under a minute.

Started by paul, June 13, 2019, 05:07:01 AM

Previous topic - Next topic

paul

After completing my first two traps in just over an hour, the prospect of doing the same for the 34,570 traps in my existing NMS was going to take forever - literally. Even if I limited it to the 3,000 critical was going to be too many - plus there is the 900 odd specifically customized as an absolute minimum was still way too many.

And then it hit me.....

NetXMS treats all PDU's / Varbinds the same - exactly the same!!

All I needed to do was to take the "Unmatched trap" event and turn it into an Alarm. I simply added an Alarm definition based on that event - passed the varbinds across - and hey presto, all the traps I could ever need to configure into readable alarms now generate readable alarms (99% readable - transformations such as time ticks to Time format do not work - obviously).

For those traps I want to format specifically, I can simply define them individually, but for the most part, I can simply use the default.

The only real problem with doing this is that NetXMS passes the PDU's / Varbinds as %2 rather than as individual parameters.  I had a look at snmptrap.cpp to see if there were other variables with the individual values, but, for unmatched traps, it does not populate the PDU's into variables.

If this was changed so that unmatched trap returned each of the PDU's / Varbinds / OID's from the trap individually rather than as %2 - this solution would mean that  I would probably never have to define another snmp trap again. I could simply display %1 \n %2 \n %3 \n etc. and see the trap content one line at a time - automatically.

If I was able to have the OID of the trap converted into the trap description in the MIB - I would never define another trap again. Once I know what trap it is - I can work out pretty much what each PDU means. If this was too hard - I can always define an alert.

The snmptrapp takes the OID of the trap and looks up the trap table to see if it is defined. All it would have to do is look up the MIB table to find the trap description for that OID - exactly as it does when adding a trap processor. Not a complete solution, but, a solution that would work for at least 28,000 of my traps.

I do not consider these as features - they are simply simple options that would make trap processing much easier. Have them as two Server options:
Unmatched_TRAP_as_one_var True False with False splitting up the PDU's into individual
Unmatched_TRAP_lookup True False with True looking up the trap from the compiled MIBs (or a master list of all traps extracted from the compiled MIBs)

Now here is the weird part - looking at the code in snmptrap.cpp - around lines 63 - 136 it looks like there is the capability for auto trap creation already existing.

Given that my cooking is better than my coding and I would not recommend anyone eating my cooking, I cannot say for certain what NetXMS can already do - but it certainly looks like that everything above is already catered for already - except for splitting unmatched traps into individual variables rather than passing as %2. this just happens to be the one thing that would help the most.

Anyway - just thought I would put it out there that trap processing can go from complete nightmare to absolute wonder with just a little lateral thinking - and one simple alarm definition :)