[Nagios-users] check_openmanage improvement request

[John Skarbek]

Good Morning,



I've recently deployed the check_openmanage script and it works very
well. Except for hosts that run esxi. Unless I'm doing something
wrong.



I've discovered that Open Manage doesn't broadcast it's OID's through
ESXi like it would if it were a linux or windows host. However I did
find that the iDRAC7 does have similar snmp responses that I'd like to
capture. However when pointing check_openmanage to the drac interface,
I get the message indicating that OMSA must not be installed correctly.
However, looking into the script I found:

my $chassisModelName = '1.3.6.1.4.1.674.10892.1.300.10.1.9.1';



Which does indeed NOT exist. However, a similar OID with the same
information we are looking for is located here:

$chassisModelName = '1.3.6.1.4.1.674.10892.5.1.3.12.0';



After modifying the script a little bit I was able to get past that, but
now check_openamange is complaining, "SNMP ERROR [memory]: The requested
entries are empty or do not exist. "

I presume the entire set of OID's is in a different spot when being
checked through the drac versus the standard windows snmp service. I
would love to assist in enhancing this script, but I'm not sure how I
should start. Let me know who I should contact, or feel free to reach
out to me to assist with this awesome plugin.



Again this is assuming I have my setup configured correctly.



John Skarbek, System Administrator
w [phone] | c [phone] | ***@nextcentury.com
<mailto:***@nextcentury.com>
NEXTCENTURYCORPORATION | m 443.545.3100 | f 443.285.0799 |
www.nextcentury.com <http://www.nextcentury.com/>

[Trond Hasle Amundsen]

I?ve recently deployed the check_openmanage script and it works very well.
Except for hosts that run esxi. Unless I?m doing something wrong.

You're not doing anything wrong. Openmanage, when deployed on ESXi,
doesn't have the necessary capabilities for it to work.

I?ve discovered that Open Manage doesn?t broadcast it?s OID?s through ESXi like
it would if it were a linux or windows host. However I did find that the
iDRAC7 does have similar snmp responses that I?d like to capture. However when
pointing check_openmanage to the drac interface, I get the message indicating
that OMSA must not be installed correctly. However, looking into the script I
my $chassisModelName = '1.3.6.1.4.1.674.10892.1.300.10.1.9.1';
Which does indeed NOT exist. However, a similar OID with the same information
$chassisModelName = '1.3.6.1.4.1.674.10892.5.1.3.12.0';

Actually, the OID is 1.3.6.1.4.1.674.10892.5.4.300.10.1.9.1. I've toyed
around with this a bit, and for the most part you can simply replace
"1.3.6.1.4.1.674.10892.1" with "1.3.6.1.4.1.674.10892.5.4". Same goes for
storage OIDs, to a degree.

After modifying the script a little bit I was able to get past that, but now
check_openamange is complaining, ?SNMP ERROR [memory]: The requested entries
are empty or do not exist. ?
I presume the entire set of OID?s is in a different spot when being checked
through the drac versus the standard windows snmp service. I would love to
assist in enhancing this script, but I?m not sure how I should start. Let me
know who I should contact, or feel free to reach out to me to assist with this
awesome plugin.

I have a modified prealpha version for testing, available in the test
branch in git:

http://git.uio.no/git/?p=check_openmanage.git;a=shortlog;h=refs/heads/test

Note that it's NOT production ready, I have only done some very limited
testing.

I had to simplify some stuff:

* Storage: The storage OIDs from the iDRAC7 are somewhat different,
compared to Openmanage. Some information that the plugin needs is
not available, such as numbered identifiers for components (used in
blacklisting). There are even some OIDs that aren't present in
Openmanage. In short, it's a mess, and the storage bit is very
simplistic. Perhaps the missing info will be added in a later
firmware release, we can only hope.

* ESM health OIDs are missing completely, so ESM health check is
omitted. Same for SD card check.

To use the new feature you have to specify '--idrac', like this:

check_openmanage --idrac -H <idrac-ip>

Test it, break it and tell me what you think :)

I've noticed that neither the rollup-status or component-status for
controllers catches that the controller is actually degraded from
out-of-date firmware. Hopefully it's an anomaly that doesn't apply to
other aspects of controllers, or other components.

Cheers,