One of the more asked questions regarding Operations Manager network monitoring is: how can I “certify” my own generic devices? As you may know Operations Manager distinguishes network device3s in two broad families: certified and generic. Certified devices are, basically, “known” devices for which specific monitors and rules have been defined, generic devices are “unknown” so only the standard port monitoring and snmp and icmp availability is implemented. For example for generic devices CPU usage is not collected and as a direct consequence they’re not displayed ion the top 10 CPU devices in network summary dashboard. Just to be clear there are cases where even certified devices do not expose CPU usage via SNMP, in this case event certified ones are not present in such dashboard.
To my knowledge at the time of this writing the differences between generic and certified devices are:
generics don’t have vendor and model (it can be easily added, most vendor publish the device model in SNMP)
generics don’t have CPU and memory monitoring, thus you don’t have the device in the top 10 cpu usage devices in the generic dashboard. (If the device exposes the CPU counter it can be easily added.)
generics don’t have the discovery of sensors and fans. Currently this is not a significant difference since they’re not monitored in any case. Adding this can be challenging depending on how they’re exposed in SNMP. The snmp modules in OpsMgr are not engineered for discovery scenarios and heterogeneous table management can be tricky, but I will present a couple of solutions for it.
generics don’t have trap based discovery, this can be a curse rather than a benefit. (see https://nocentdocent.wordpress.com/2013/03/26/network-discovery-reference-sysctr-scom/)
From the previous list you can correctly conclude that discovery works for all devices (certified and generic). If the device implements RFC standards for SNMP port monitoring then all the ports are discovered and when applicable connected to other managed devices (network or computer), this means all the tricky work needed for creating the network topology and understanding the links between devices is done regardless of certified or generic status for the device.
Returning to the original question “how can I certify my own generic devices?”, the answer is: no you cannot certify your own generic devices, but you can bring them on par with certified ones if they expose the management capabilities via SNMP.
To add some more details, which devices are certified and which are generic is defined in the network discovery module, this happens to be code Microsoft licensed from EMC under the SMARTS agreement, the configuration of this code is not documented and it is not supported to bring in any mod. This means your devices will remain GENERIC in console even if they can be better monitored than certified ones. Actually a device can be forced to CERTIFIED via a custom discovery rule, but this property will be overwritten every time the network discovery runs and, in my opinion, will just add confusion. Certified or Generic is the OpsMgr certification level so leave it alone and let’s focus on monitoring.
This is the first in a serie of articles on SNMP device monitoring, I don’t know how many of them yet, and I don’t know where the code will be posted, there are several possibilities here: I can use technet gallery, I can open a codeplex project or I can just publish the snippets without the full sourcecode. I can even consider, with some help, to merge the xSNMP modules and integrate them for OpsMgr 2012. It really depends on the community feedback I will get.
This first chapter will set the basics, the references and the table of contents for future chapters.
Table of contents
Chapter 1 – Creating SNMP monitoring Management Packs for System Center 2012 Operations Manager (this article)
Chapter 2 – Discovery: identifying the device.
Chapter 4 – Device components discovery.
The basic process for adding a new device is all around knowingly how the device responds to SNMP queries; this is typically documented in vendor published or standard MIB files. Without this first step there’s nothing that can be done. Once we get there it’s pretty straightforward to use the SNMP modules of Operations Manager 2012 to broaden the manageability of the devices. This typically implies performing a targeted discovery to uniquely identify the device, this is normally achieved via the sysObjectID of the device. Once we can uniquely identify the device we can target all the further monitors and rules to our specific device type.
1. Get the device SNMP tree
2. Get a unique identifier for the device, this typically is the sysObjectID
3. Define a new class for the device inherited from System.Network.node
4. Write a discovery rule to identify the device (remember the first discovery is performed in any case by the OpsMgr standard modules)
5. Target any further discovery, rule or monitor to the device class
To obtain the full device SNMP tree you need tools to perform queries and have a graphical representation of MIB files. The following is my short list:
MIB Browser: Manage Engine http://www.manageengine.com/free-tools.html
SNMP Query Utilities and SNMP extensions: http://sharpsnmplib.codeplex.com/
SNMP Simulator: http://snmpsim.sourceforge.net/
Jalasoft Xian SNMP Simulator: http://www.jalasoft.com/xian/snmpsimulator/see and a good howto guide for the tool here http://blogs.technet.com/b/kevinholman/archive/2013/05/29/simulate-monitoring-of-network-devices-with-jalasoft.aspx
vNext mib2mp a commercial solution to automatically build Operations Manager management pack starting from MIB files: http://www.mib2mp.com
The OpsMgr module types and classes
The key management packs for network monitoring are:
· System.SNMP.Library – defines basic SNMP types and data sources
· System.NetworkManagement.Library – defines all the classes for certified devices and advanced data sources
· System.NetworkManagement.Monitoring – defines actual monitoring for certified devices
You can find the documentation for relevant modules on MSDN (see references) but the above management pack are really useful to understand how network monitoring works and to get samples to build your own code.
Since we’re going to write our own management packs for specific devices, it’s fundamental to remember which are the base classes that we need to inherit from. For network management we have two base classes:
· System.NetworkManagement.Node – this is the actual device, our device class will inherit from Node
· System.NetworkManagement.LogicalDevice – this is a generic device component (such as processor, or fan) we can use this to model our device, in several cases we have more specialized classes such as System.NetworkManagement.Processor or System.NetworkManagement.Memory that can be used for specific and standard components
While the base properties of the Node class are already discovered for us, remember the first discovery is up to OpsMgr standard modules (we’re just going to implement a specialized discovery), the LogicalDevice class has a couple of key properties:
– Key – it must be unique within the hosting device, the network monitor standard is <abbreviation>-<device address>/<index> (MEM-172.31.1.1/1). When possibile we will instead use the component OID so it can be direclty used in rules and monitors.
– Index – it’s the device Index in the SNMP tree, useful when there is more than one component of that type per device to build the full SNMP OID. We’ll see plenty of such examples in code.
Resources and references
MIB Catalog: http://www.ndt-inc.com/SNMP/MIBsByRFC.html
SNMP Event Wizard in OpsMgr on http://technet.microsoft.com/en-us/library/hh563870.aspx
SNMP Modules reference on MSDNhttp://msdn.microsoft.com/en-us/library/jj130169.aspx
This posting is provided “AS IS” with no warranties, and confers no rights.