Sorry if this is a wrong place, I’m a bit of a newbie.
I was just wondering if anyone has or has any idea’s or recommendations on how to monitor HP VSA storage systems latency within Icinga or if it’s possible? Currently We have to log onto the HPE StoreVirtual Management Console and open it’s own performance monitor on the storage management server. It looks just like the normal windows performance monitor, it’s it shame we can’t add the counters it to it. Currently, we can just monitor the ping of the storage systems host names in Icinga.
Yeah I thought that might be the case, thanks for confirming. Was experimenting with SNMP, but my knowledge of it isn’t great and not sure if it’s even possible…
The folder where the HPE StoreVirtual is installed has a folder full of MIB Files, one is called “LEFTHAND-NETWORKS-NSM-STORAGE-MIB.mib” that seems to have the object “storageRaidStatsIoLatencyRead” in it. I added the MIB with the OID on to our Icinga server and created a service for it to use on a test VSA. The Icinga daemon check came up all clear, but getting:
“External command error: Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: LEFTHAND-NETWORKS-NSM-STORAGE-MIB::storageRaidStatsIoLatencyRead”
…on the Dashboard - probably loads of config I’m missing - I just need to read a bit more about SNMP monitoring in Icinga, I’ve seen there’s some documents about it.
Try to execute snmpwalk against your LefthandOS to see what OIDs are available. SNMP agent has to be enabled for each management group (in menu tree Managementgroup, Events, SNMP) with management console.
Hint 2: if OID is incomplete you’ll get the same error message:
/usr/lib/nagios/plugins/check_snmp -H 192.168.1.200 -C read -o .1.3.6.1.4.1.9804.3.1.1.2.12.97.1.57
External command error: Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: iso.3.6.1.4.1.9804.3.1.1.2.12.97.1.57
Great, thanks for you help snmpwalk Roland! It’s a shame storageRaidStatsIoLatencyRead is not valid on VSA’s then, but at least the messages make sense. Oh well, least we tried.
another Hint: copy all MIBs into MIB folder (typical /usr/share/snmp/mibs/ for net-snmp).
If you use parameter -m ALL (or specific MIB name) for tools like snmpwalk (or even some check scripts support this option), you will get human readable output.
The additional number appended to OID usually say that this variable (index) is a SNMP table with dynamic length. If there are multiple measurements (i.e. for each volume/interface/…), you will find each measurement with it’s own index number. Depending on MIB design, you will find other measurements for a specific item by variing the oid (i.e. x.x.x.17.1 delivers input values, x.x.x18.1 output values for same item).
With interfaces and other complex, dynamic item structures it is common to split infos over several tables. There is a table which lists all interfaces by name and it’s MIB index. Measurements are located in other tables, you need to know the index number to query the right interface.