Grabbing traffic out of SCOM and shipping those alerts over to a ‘manager of managers’ type system for event correlation is a fairly common scenario. Ideally, an integration pack would exist for that other system and two way communication could be established. Unfortunately, that isn’t the case for all and sometimes a different mechanism needs to be used for shipping the traffic.
Enter the SNMP trap. Looking at the available activities, this seems like it should be fairly straight forward:
Get Alert is going set to grab the appropriate alerts. In this case, simply pointed at alerts where CF1 = ‘SendMe’. Now, let’s look at configuring the Send SNMP Trap activity.
NOTE: There is currently a documented bug with the Generic Identifier field in this activity as of when this blog post was written (4/10/2013). KB Here.
Screen One:
Seems ok. Note I typed in 6 for the Generic ID rather than using the […]. That’s due to the bug in the KB above. The Specific ID of 17 is just because I like the number 17. In this case, it is arbitrary and we will be using it to delineate between the different traps when the Generic ID of 6 (Enterprise Specific) is selected.
Now, the Advanced tab:
I’m just trying to ship the name of the alert in a specific varbind. For this case, I just filled in the OID for the varbind with something that looked good. The catch here is the Syntax field:
OID is the default. If you are an SNMP guru, you probably already know which of these that should be selected to ship a string. I, however, am not. So, I am going to give OID a shot and see what we catch on the trap receiver side. I turned on additional activity logging for the runbook in SCOrch and told it to run.
Here are the values we get:
This looks good. Let’s see what we caught on the receiver side using Netmon:
Digging through here, I see Enterprise Specific (6), I see 17 (a number I like) but I do not see anything related to the OID I specified or the name of the alert flagged in SCOM. Let’s try the next data type:
After executing the runbook, here is the result:
Much better. Trying each of the different data types, this is what Netmon was able to see:
Opaque – we can see the data. However, when catching these traps in a different utility I didn’t have as much luck seeing the data.
32 Bit Counter
IP Address – doesn’t show the OID at all
Unsigned 32 bit Integer
32 bit Integer
Time Ticks
Null
For shipping strings inside of SNMP traps, the Octet data type seems like a great place to start.