So here’s my question: I can poll the device during discovery to find out how many nodes the cluster has, is there a way to use this data and pass it along to a script as a var?

$MPElement[Name="IsilonSNMP.Class.IsilonCluster"]/configurednodes$

Any attempt gives me an invalid namespace error.

I’ll think about this over the next day or two in case something comes to mind, but OpsMgr is certainly oriented towards a one to one relationship between IP Address/Comm. string combinations and SNMP agents. As the IP address is the key property of an OpsMgr SNMP Network device, servicing multiple “agents” with a single IP address (with polls or traps) is going to be a challenge. Does the device support Syslog? Perhaps that would be an easier approach if it can be an alternative to SNMP traps (at least by eliminating the community string and including a severity in every message).

As for OpsMgr SNMP resources, there’s a bit of a scarcity of resources, in my opinion. The blogs listed on the blogroll of my site are my typical go to resources for all things OpsMgr, along with the online Authoring Guide, and social.technet.microsoft.com forums. To be honest, in my experience at least, a lot of working with SNMP in OpsMgr sometimes comes down to trial and error. In that regard, I’ve probably tried more than my share of SNMP monitoring approaches with OpsMgr and certainly seen enough errors resulting from those trials, so if you have specific questions about the authoring, I’d be glad to try to assist.

The official documentation is a bit sparse on the topic, but I get the impression that there is a lot of effort going into improving the SNMP capabilities (and documentation of such) of OpsMgr. I spent a lot of time with NetView and more recently have worked with SolarWinds quite a bit. I really appreciate the simplicity and effectiveness of SolarWinds, but the object-oriented architecture of OpsMgr, dynamic discovery capabilities, and incredible flexibility causes me to be a big advocate of using it for SNMP monitoring, particularly in R2 – even if it has a ways to go in the scalability area.

There is an 8 node production cluster with a 3 node lab. Multiple IP addresses… I toyed with that idea and set that as plan C. Plan A is just limited discovery with individually created monitors for each node, etc (almost complete). Plan B was to reuse some of the logic, bind it into classes for discovery and monitor population. I still learning that bit, trying to translate MRTG, RRD, Cacti, Nagios, MOM, Etc into SCOM has been a bit of a leap. Any good reference url’s for further learning?

The more I think about it, it does seem that the easiest way would be Plan C but that brings another issue I was going to address later but might as well toss it on the table as well.. As noted above I have an open issue with Isilon on SNMP trap routing within the cluster. Seems they are attempting to send the trap out a floating “master” SNMP agent that could be on any node using any IP address bound to the node and not routing said packet over the infiniband bus to the attached node with access to the management subnet. Once that issue is resolved I’m going to have to address the data within the packet. They are using an internally created SNMP community string to send the packet (isialert@FQDN-(Node #) example – isialert@cluster-1.domain.int) and the only way to determine what node is having an issue is to look in the pack itself for yet another string. This means I may need to create a “master” SCOM network device to accept all the traps, (ie 8 monitors, 1 for each of the community names that the trap could be coming from per monitored trap def.) do a expression search within the data of the packet to determine the severity of the alert, do another expression search to determine the node having the issue and force all the traps to come from only 1 IP address from the Isilon.