check_openmanage weirdness
Greg Etling
getling at stern.nyu.edu
Thu May 20 16:53:11 CEST 2010
Trond, thanks for your quick reply. Unfortunately it does appear we have
a disconnect between OMSA and SNMP:
>Does omreport report anything on storage? Try:
>
> omreport storage controller
>
C:\Documents and Settings\Administrator>omreport storage controller
Controller PERC 6/i Integrated (Embedded)
Controllers
ID : 0
Status : Non-Critical
Name : PERC 6/i Integrated
Slot ID : Embedded
State : Degraded
Firmware Version : 6.0.3-0002
Minimum Required Firmware Version : 6.2.0-0012
Driver Version : 2.14.00.32
Minimum Required Driver Version : 2.23.00.32
Storport Driver Version : 5.2.3790.3959
Minimum Required Storport Driver Version : 5.2.3790.4173
Number of Connectors : 2
Rebuild Rate : 30%
BGI Rate : 30%
Check Consistency Rate : 30%
Reconstruct Rate : 30%
Alarm State : Not Applicable
Cluster Mode : Not Applicable
SCSI Initiator ID : Not Applicable
Cache Memory Size : 256 MB
Patrol Read Mode : Auto
Patrol Read State : Stopped
Patrol Read Rate : 30%
Patrol Read Iterations : 82
Abort check consistency on error : Not Applicable
Allow Revertible Hot Spare and Replace Member : Not Applicable
Auto replace member on predictive failure : Not Applicable
Load balance : Not Applicable
Security Capable : Not Applicable
Security Key Present : Not Applicable
Redundant Path view : Not Applicable
>If that works, try getting the same information via SNMP:
>
> snmpwalk -v2c -c <community> <hostname>
>1.3.6.1.4.1.674.10893.1.20.130.1
>
[root at nagios ~]# snmpwalk -v2c -c ***** testserver
1.3.6.1.4.1.674.10893.1.20.130.1
SNMPv2-SMI::enterprises.674.10893.1.20.130.1 = No Such Object available
on this agent at this OID
It appears to only have data under the 1.3.6.1.4.1.674.10892 and
1.3.6.1.4.1.674.10899 trees. Thoughts?
Greg
Greg Etling <getling at stern.nyu.edu> writes:
> > I have just started implementing some check_openmanage checks on my
> > servers, and have run into some odd behavior with the combination of
> > Windows 2003, OM 6.2 and the SNMP check. It appears that this
> > combination is having issues with the drive/controller reporting.
> > Initially things worked fine under OM 5.4, until the SNMP service
would
> > die (other than that, Mrs. Lincoln...) - so i upgraded to OM 6.2,
when I
> > observed the following behaviour.
> >
> > When the check is run without any blacklisting, the plugin reports
that
> > there is a global status WARNING, but all components are OK - the
> > WARNING is coming from out of date Firmware/Driver versions as
listed below:
> >
> > ------
> > Firmware/Driver Information for Controller PERC 6/i Integrated
> > Firmware Version 6.0.3-0002
> > Minimum Required Firmware Version 6.2.0-0012
> > Driver Version 2.14.00.32
> > Minimum Required Driver Version 2.23.00.32
> > Storport Driver Version 5.2.3790.3959
> > Minimum Required Storport Driver Version 5.2.3790.4173
> > ------
> >
> > Now when run in debug mode, I noticed that it had no information about
> > the drives at all (note the beta version - same output as plugin
v3.5.7):
[snip]
This is the key to this problem. There are warnings associated with the
storage subsystem, but that information is not available via SNMP for
some reason. The global status of the server inherits these warnings,
however, so the plugin reports this as some unknown error.
Does omreport report anything on storage? Try:
omreport storage controller
If that works, try getting the same information via SNMP:
snmpwalk -v2c -c <community> <hostname> 1.3.6.1.4.1.674.10893.1.20.130.1
Usually the problem is that the storage components of OMSA is not
installed, in which case neither command will work.
> > And the Status as reported to Nagios believes that there are no disks
> > whatsoever on the server:
> > ------
> > OK - System: 'PowerEdge 2950', SN: 'XXXXXXX', hardware working fine, 0
> > logical drives, 0 physical drives
> > ------
Yes, that is the normal behaviour when the plugin doesn't find any
storage components. The plugin can't report this as a problem, since
it's OK for a server not to have storage reported by OMSA (which only
reports on supported storage), or any storage at all for that matter
(diskless servers).
> > This has been replicated on several identical systems.
> >
> > I'm a bit stumped as to where the problem lies. Please let me know if
> > you need further information from me.
You should check your OMSA install. The storage parts of it was probably
not installed. It may also be that there is something wrong with the
OMSA+SNMP integration, which prevents storage information from being
presented. That would be trickier to debug.
Cheers,
-- Trond H. Amundsen <t.h.amundsen at usit.uio.no> Center for Information
Technology Services, University of Oslo ------------------------------
------------------------------------------------------------------------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
More information about the Users
mailing list