Trap Viewer - Filtering Logic - OID Creation? - Email Alerts

Thank you in advance for any help you can offer.

Using the Trap Viewer utility program (which I really wish was simply part of NPM, so it can flow through the same business rules and use the same alerting templating system), I have setup some very trivial test alerts. From a Sol10 Box, I use the following test alert (going to fictional server "orion_box":

snmp_trapsend -h orion_box -c public -i orion_box -a ".1.3.6.1.4.1.42.2.1.1 STRING (firefirefire)"

I have no incredibly logical reason for using that MIB other than it seems popular with the cool kids on Google.

The above works for getting an alert into Trap Viewer. I'm then catching and alerting on it using the following filter rule:

SNMPv2-MIB:snmpTrapOID is equal to KERNEL-READER-SUNMANAGEMENTCENTER-MIB:prod.1.1.0.1

and have it send a simple email alert that works and looks a little like:

8/28/2009 1:25 PM : KERNEL-READER-SUNMANAGEMENTCENTER-MIB:prod.1.1.0.1 SNMP Trap

Received Time:8/28/2009 1:25:28 PM

Source:***.***.***.***(***.***.***.***)

Community:public

Variable Bindings

sysUpTime:= 0.00 seconds (0)

snmpTrapOID:= KERNEL-READER-SUNMANAGEMENTCENTER-MIB:prod.1.1.0.1 (1.3.6.1.4.1.42.2.1.1.0.1)

mbufs.1.2.0:= firefirefire

experimental.1057.1:= ***.***.***.***

snmpTrapEnterprise:= KERNEL-READER-SUNMANAGEMENTCENTER-MIB:prod.1.1 (1.3.6.1.4.1.42.2.1.1)

Questions:

1) Is there any way to have it filter based on the String portion of the alert? I tried hand typing in "SNMPv2-MIB:mbufs.1.2.0 is equal to firefirefire" - which was not rejected by the editor, but it doesn't work.

2) What is the best way to approach this, outside of trying to define an OID for each type of user generated trap (and we're using them sparingly, but they're very important) that will be received?

3) If I do have to create my own OIDs.. can anyone suggest a best practice? Is there a defined userspace for safely creating your own universe such that it will never collide with anything you would expect to get from a vendor? (A logical equivalent to using a non-routeable IP space.)

4) Am I just missing an entirely larger picture here? I'm fine with that and would like to be set straight.

My alternative at this point is just to have it call a simple Perl script and setup a simple decision and alerting tree based on the origin IP and the text in the alert. I'd like to utilize the product as is, and follow what would be considered best practices by industry on this one, however.

Again, thanks for any help in advance.

-Nordberg

PS - I did see the posting on having it shell out to a VB script to inject an artificial event into NPM/APM to allow for the alerts to be part of the normal email flow, but I'd rather not tinker with the logic of the product in such a fashion.

Find more posts tagged with

trap_viewer_alerts

Accepted answers

All comments

tdanner

1) Yes, you can filter on the string portion of the alert. I think the problem you had in your firefirefire test is that your hand-typed "SNMPv2-MIB:mbufs.1.2.0" did not match the OID that was actually in the trap. I don't have a Solaris box handy and a quick google did not turn up the man page for snmp_trapsend, so I'm not sure exactly what your command line is doing. 1.3.6.1.4.1.42.2.1.1 is the trap OID, but what OID is it using for your string value? From the email you copied in, I can see that the SolarWinds MIB database mapped it to "mbufs.1.2.0", but there are several OIDs named "mbufs", and none of them really make sense in this context. My suggestion? See if snmp_trapsend lets you specify the OID for your extra values, or use Wireshark to see what the trap really looks like. Then use the numeric OID in your trap rule, not the name.

2) Making up new OIDs for each distinct type of trap you define seems reasonable to me. If you don't like that option, you could always prefix the string value with information about the type of trap.

3) I don't know of any well-defined area for creating personal OIDs. I would just pick a branch that is unlikely to ever be used, like 1.3.6.1.4.2.

4) As to whether you are missing the larger picture, I would need to hear more about what your goal is. If your goal is sending traps from Solaris and acting on the in Orion, this should work.