Custom MIB Poller: Warning/Feature Request

Question

While the burden of configuring snmp properties on all monitored nodes to send SNMP traps to a management server makes the use of centralized polling for SNMP values seem to be a more desirable option than using traps, there is a limitation in the Orion Custom MIB polling implementation that makes traps the more desirable option.  Consider the following scenario as an example:

The HP Insight Management agents for Proliant servers implement the CPQIDA MIB.  To monitor physical drive status in an HP/Compaq drive array, we would monitor the cpqDaPhyDrvStatus object (1.3.6.1.4.1.232.3.2.5.1.1.6).  However (like most health status mibs) this object is arranged in a table with a record for each physical drive in the system.  Therefore, the status of physical drive 0 would require a GET request to the fully-qualified OID 1.3.6.1.4.1.232.3.2.5.1.1.6.0.144, physical drive 1 would require a GET request to OID 1.3.6.1.4.1.232.3.2.5.1.1.6.0.145, etc. etc.  This same table arrangement will likely be found for any object in any MIB (from any vendor) where multiple values might be found, such as temperature probe, memory, fan, processor, battery, or power supply status objects.

It’s easy enough to set up a Custom MIB Poller in Orion using the GetNext method to poll OID 1.3.6.1.4.1.232.3.2.5.1.1.6 (cpqDaPhyDrvStatus).  However, as the first physical drive in the system will always be returned by the GetNext request, the Custom MIB Poller will always return the value for the first physical drive and ignore the rest.  This behavior will occur on any SNMP object that is arranged in a table.  You can get around this issue by using GET requests instead of GetNext requests in the Custom MIB Poller and specifying the fully-qualified OID for each possible configuration.  This may be feasible for something such as power supplies or fans where there are not many possible configuration options, but it is not very feasible for something as variable in configuration as physical or logical drives.

It’d be great if SolarWinds would modify the behavior of the GetNext option in the Custom MIB Poller to actually loop through GetNext requests until the agent returns an error and record each value as a separate instance.  However, until such a feature is implemented, configuring alerts based on incoming SNMP traps is the better option.  Given the example above, we could configure a trap rule in the Orion SNMP Trap receiver to trigger an alert whenever a cpqDaPhyDrvStatusChange trap is received.

kbash · Answer

quote:Originally posted by Mithrilhall

I haven't started using 8.0 yet but there is not option for GetTable?

No GetTable option, just Get or GetNext.  I'm hoping a GetTable or GetNext looping will be in the next minor release.

kbash · Answer

I considered that approach, but we had a number of devices that didn't have a global status object.  Glad to hear you found a workaround without too much trouble.  I'm still working on defining trap to alert rules, but the implementation seems to be pretty robust.

Mithrilhall · Answer

I haven't started using 8.0 yet but there is not option for GetTable?