Menu Close

Alerting on SNMP traps in SCOM – Without discovering the SNMP Device

Well, sort of, anyway.  Smile

 

I have written on SNMP monitoring in SCOM a few times:

https://kevinholman.com/2015/02/03/snmp-trap-monitoring-with-scom-2012-r2/

https://kevinholman.com/2015/12/16/how-to-discover-a-windows-computer-as-a-network-device-in-scom-2012/

https://kevinholman.com/2016/04/20/writing-a-custom-class-for-your-network-devices/

 

This one will be a little different.

One of the challenges I have heard many times with SCOM – is that we must discover a network device, in order to monitor or receive SNMP traps from that device.

This can be a big problem for customers, as they often have network devices that only sent traps, but are not query-able via SNMP GET requests.  If we have challenges getting a network device to discover in SCOM, we can’t generate an alert or collect the trap.

 

Let’s make that a little simpler.  This article will demonstrate how we can create a new class for our network devices, discover them from a simple CSV text file, and then monitor them for SNMP traps.

This post will be based on the work of Tatiana Golovina here:  https://blogs.technet.microsoft.com/scpferublog/2013/12/09/snmp-scom-2012-109/ along with feedback from Michael Bullwinkle.

 

The idea is to create a management pack with the following:

1.  A new Resource Pool, that will host our network devices and load balance them.

2.  A Class that will define our SNMP network device and any properties.

3.  A discovery, which is a PowerShell script to discover our network devices.

4.  Rules, to alert on all traps, specific traps from a specific OID, and specific traps where a SNMP varbind contains specific data

 

Therefore – even if you don’t need this functionality – this will be a very good MP example, of discovering objects from a CSV, and having those objects hosted by a resource pool and load balanced by resource pool members!

 

Our class definitions look like the following:

<ClassTypes> <ClassType ID="Demo.SNMPDevice.Class" Accessibility="Public" Abstract="false" Base="System!System.ApplicationComponent" Hosted="false" Singleton="false" Extension="false"> <Property ID="DeviceName" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" /> <Property ID="IP" Type="string" AutoIncrement="false" Key="true" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" /> <Property ID="SNMPCommunity" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" /> <Property ID="Description" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" /> <Property ID="Owner" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" /> </ClassType> <ClassType ID="Demo.SNMPDevice.ResourcePool" Accessibility="Public" Abstract="false" Base="SC!Microsoft.SystemCenter.ManagementServicePool" Hosted="false" Singleton="true" Extension="false" /> </ClassTypes>

 

There is a datasource for the Resource Pool, and a Discovery for that as well, but those aren’t important here.  They just create the pool and load the relationship so the pool will host our devices.

Then – there is a discovery that discovers against the CSV file and creates our instances:

 

image

 

You can override this for Interval, SyncTime, Timeout, and the CSV path you want to discover from:

image

 

My example CSV is very basic – you can add or remove fields you want to discover.  For my example I include the device name, IP, Base64 SNMP Community String, a description, and the Owner.  You may change these as you wish, but you have to change the discovery script as well if you do.

We require a DeviceName, IP Address, and Community String (base64) at a minimum:

image

 

The Base64 Community string is described here:  https://blogs.technet.microsoft.com/brianwren/2009/01/21/snmp-queries/  I have included the one for “public” in my example.

 

This will discover your objects:

image

 

And let you generate alerts when traps are sent to the SCOM Management server that hosts these objects:

 

image

 

I have included three different rule examples:

1.  A rule to alert on ANY trap sent from the device.

2.  A rule to alert on ANY trap sent to the device that comes from a specific OID.

3.  A rule that will filter a specific payload in the trap, such as data in a specific Varbind.

 

You can look at the rule configurations to better understand this method, to start creating your own rules.

 

This MP contains a Resource Pool dedicated for these devices.  You must configure this, as by default it will use Automatic membership, and distribute your network devices across all management servers.  This means each device must send a trap to EACH management server in the pool, because we do not control which management server hosts the device.  For this reason, especially for testing, you may want to set the Pool membership to manual, and limit the management servers.  Many devices are only able to send traps to two IP destinations, so it would be wise to choose two management servers for pool membership – to give high availability and load balancing, or just one management server for simplicity and testing:

 

image

image

 

So with a simple CSV, we can quickly “discover” our network devices, and start getting traps from them really quickly.

 

 

You can download the example management pack and sample CSV file here:

https://gallery.technet.microsoft.com/SCOM-Management-Pack-to-ac659c99

7 Comments

  1. Dane Rafn

    If you were doing this type of SNMP discovery for devices/appliances that are Windows based, would you also need to edit the ic-post-processor.asl file (mentioned in you blog “How to discover a Windows Computer as a Network Device in SCOM 2012”)?

  2. Mohamed Sybulla

    Hi Kevin,

    We have discovered vCenter 6.5 version in SCOM 2016. We added them using both the methods (i meant SCOM discovery and Without discovering the SNMP Device). and udp ports 161 and 162 are also open between source vcenter to SNMP SCOM Receiver server. We could capture the test trap by wireshire running on SCOM SNMP Reciever Management Server from vCenter. But this trap is not captured by SCOM. We already created test trap capturing rule and test trap events capturing rule. All the traps are captured from various devices but from this vCenter it is not capturing. We removed the version line also in the discovery as you suggested.

Leave a Reply

Your email address will not be published. Required fields are marked *