CHECK_OPENMANAGE(8)

πŸ“¦
version 3.7.12 Β· 3 versions
, in epel 9

✨ NAME ✨

okay bestie, meet check_openmanage(8) β€” the Nagios plugin for checking hardware status on Dell servers running OpenManage. literally its whole job is making sure your Dell server's hardware isn't doing a silent little meltdown πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

check_openmanage [option...]

check_openmanage -H hostname [option...]

πŸ’– DESCRIPTION πŸ’–

So check_openmanage is a plugin for Nagios, and it checks the hardware health of Dell servers running OpenManage Server Administrator (OMSA). It's giving full hardware vibe check: storage subsystem, power supplies, memory modules, temperature probes etc., and it gives an alert if any of those components are faulty or operating outside normal parameters. no cap, it's the friend who notices the weird noise in the walls 🫢

It's designed to be used either locally (using NRPE or similar) or remotely (using SNMP). In either mode, the output is (nearly) the same. Just know that checking the alert log is not supported in SNMP mode, bestie β€” that's the one little boundary.

heads up: alert log checking? not an SNMP-mode thing. do not ask her there πŸ’€

πŸ’… GENERAL OPTIONS πŸ’…

  • -f, --config file β€” Specify a configuration file. For reference on the config file syntax and options, consult the check_openmanage.conf(5) manual page. slay, documentation within documentation ✨
  • -t, --timeout seconds β€” The number of seconds after which the plugin will abort. Default timeout is 30 seconds if the option is not present.
  • -p, --perfdata [argument] β€” Collect performance data. Performance data collected includes temperatures (in Celsius) and fan speeds (in rpm). On systems that support it, power consumption is also collected (in Watts). This option takes one of two arguments, both of which are optional:
    • minimal β€” If minimal is specified as argument, the plugin will use shorter names for the performance data labels, e.g. t0 instead of temp_0_system_board_ambient. This can be used as a workaround in cases where the plugin output needs shortening, for example if the 1024 character limit of NRPE is reached. tiny labels, big relief πŸŽ€
    • multiline β€” If multiline is specified as argument, the plugin will output the performance data on multiple lines, for Nagios 3.x and above.

The default behaviour should be sufficient for most users. lowkey the default is usually the move.

  • --legacy-perfdata β€” With version 3.7.0, performance data output changed. The new format is not compatible with the old format. Users who wish to postpone switching to the new performance data API may set this option. it's giving "keep the old UI, I'm not ready" 😭
  • -w, --warning string | file β€” Override the machine-default temperature warning thresholds. Syntax is:
id1=max[/min],id2=max[/min],...

The following example sets warning limits to max 50C for probe 0, and max 45C and min 10C for probe 1:

check_openmanage -w 0=50,1=45/10

The minimum limit can be omitted, if desired. Most often, you are only interested in setting the maximum thresholds. same, honestly β€” max thresholds are the main character here πŸ”₯

This parameter can be either a string with the limits, or a file containing the limits string. The option can be specified multiple times.

NOTE: This option should only be used to narrow the field of OK temperatures wrt. the OMSA defaults. To expand the field of OK temperatures, increase the OMSA thresholds. See the plugin web page for more information. do not use this to make the OK zone bigger, bestie β€” that's not what she's for 🚨
  • -c, --critical string | file β€” Override the machine-default temperature critical thresholds. Syntax and behaviour is the same as for warning thresholds described above.
  • -F, --fahrenheit β€” Set Fahrenheit as unit for all temperatures. This option will override the --tempunit option, if used simultaneously. Fahrenheit said "I'm the main character now" 🌑️
  • --tempunit unit β€” Set temperature unit. Legal values are:
    • F: Fahrenheit
    • C: Celsius
    • K: Kelvin
    • R: Rankine

Default: C

  • --omreport path β€” Specify full path to omreport, if it is not installed in any of the regular places. Usually this option is only needed on Windows, if omreport is not installed on the C: drive. Windows girlies, this one's for you πŸͺŸ
  • --vdisk-critical β€” Make any alerts concerning virtual disks appear as critical. virtual disk drama gets the critical treatment, periodt πŸ’€
  • -d, --debug β€” Debug output. Will report status on everything, even if status is ok. Blacklisted or unchecked components are ignored (i.e. no output).
NOTE: This option is intended for diagnostics and debugging purposes only. Do not use this option from within Nagios, i.e. in the Nagios config. bestie do NOT leave this on in production, I'm begging πŸ™ˆ
  • -h, --help β€” Display help message and exit.
  • -V, --version β€” Print version info and exit.

🌈 OUTPUT OPTIONS 🌈

  • -o, --ok-info level β€” This option lets you define how much output you want the plugin to give when everything is OK, i.e. the verbosity level. The default value is 0 (one line of output). The output levels are cumulative.
    • 0: Only one line
    • 1: BIOS and firmware info on a separate line
    • 2: Storage controller and enclosure info on separate lines
    • 3: OMSA version on separate line

Default: 0

The reason that OMSA version is separated from the rest is that finding it requires running a really slow omreport command, when the plugin is run locally via NRPE. slow command = separate line, makes sense 🐌

  • -B, --show-blacklist β€” If used together with blacklisting, this option will make the plugin output all blacklistings that are being used. The output will have the correct blacklisting syntax, and will make it easy to maintain control over which blacklistings that are used for each server, as any blacklistings can be viewed from Nagios.

When blacklisting is not used, this option has no effect. no blacklist, no effect β€” she's not doing extra for nothing πŸ’…

  • -i, --info β€” Prefix any alerts with the service tag. putting the service tag first like a little name tag 🏷️
  • -e, --extinfo β€” Display a short summary of system information (model and service tag) in case of an alert.
  • -I, --htmlinfo [code] β€” Using this option will make the servicetag and model name into clickable HTML links in the output. The model name link will point to the official Dell documentation for that model, while the servicetag link will point to a website containing support info for that particular server.

This option takes an optional argument, which should be a country or area code or. If the country code is omitted the servicetag link will still work, but it will not be specific for your country or area. Example for Germany:

check_openmanage --htmlinfo de

If this option is used together with either the --extinfo or --info options, it is particularly useful. Only the most common country codes are supported at this time:

  • Europe, Middle East and Africa (EMEA)
    • at: Austria
    • be: Belgium
    • cz: Czech Republic
    • de: Germany
    • dk: Denmark
    • es: Spain
    • fi: Finland
    • fr: France
    • gr: Greece
    • it: Italy
    • il: Israel
    • me: Middle East
    • no: Norway
    • nl: The Netherlands
    • pl: Poland
    • pt: Portugal
    • ru: Russia
    • se: Sweden
    • uk: United Kingdom
    • za: South Africa
  • America
    • br: Brazil
    • ca: Canada
    • mx: Mexico
    • us: USA
  • Asia / Pacific
    • au: Australia
    • cn: China
    • in: India
    • jp: Japan
  • --postmsg string | file β€” User specified post message. Useful for displaying arbitrary or various system information at the end of alerts. The argument is either a string with the message, or a file containing that string. You can control the format with the following interpreted sequences:
    • %m: System model
    • %s: Service tag
    • %b: BIOS version
    • %d: BIOS release date
    • %o: Operating system name
    • %r: Operating system release
    • %p: Number of physical drives
    • %l: Number of logical drives
    • %n: Line break. Will be a regular line break if run from a TTY, else an HTML line break.
    • %%: A literal %

custom message at the end? cute little sign-off energy πŸŽ€

  • -s, --state β€” Prefix each alert with its corresponding service state (i.e. warning, critical etc.). This is useful in case of several alerts from the same monitored system. label the drama, bestie 🏷️
  • -S, --short-state β€” Same as the --state option above, except that the state is abbreviated to a single letter (W=warning, C=critical etc.). tiny state letters, maximum efficiency ⚑
  • --hide-servicetag β€” This option will replace the servicetag (serial number) in the output with XXXXXXX. Use this option to suppress or censor the servicetag in the plugin output. privacy era activated πŸ•ΆοΈ
  • --linebreak string β€” check_openmanage will sometimes report more than one line, e.g. if there are several alerts. If the script has a TTY, it will use regular linebreaks. If not (which is the case with NRPE) it will use HTML linebreaks. Sometimes it can be useful to control what the plugin uses as a line separator, and this option provides that control.

The argument is the exact string to be used as the line separator. There are two exceptions, i.e. two keywords that translates to the following:

  • REG: Regular linebreaks, i.e. \n.
  • HTML: HTML linebreaks, i.e. <br/>.

This is a rather special option that is normally not needed. The default behaviour should be sufficient for most users. very niche, very demure, very "you'll know if you need it" ✨

✨ SNMP OPTIONS ✨

okay so if you're doing SNMP things, this is your section, bestie πŸ’–

  • -H, --hostname hostname β€” the transport address of the destination SNMP device. Using this option triggers SNMP mode. periodt.
  • -P, --protocol protocol-number β€” SNMP protocol version. This option is optional and expects either of the following:
    • 1: SNMP version 1
    • 2, 2c: SNMP version 2c
    • 3: SNMP version 3

Default: 2c

  • --port port-number β€” SNMP port of the remote (monitored) system. Defaults to the well-known SNMP port 161.
  • -6, --ipv6 β€” this option will cause the plugin to use IPv6. The default is IPv4 if the option is not present.
  • --tcp β€” this option will cause the plugin to use TCP as transport protocol. The default is UDP if the option is not present.
  • --snmp-timeout seconds β€” this option sets the timeout for the SNMP object of the Net::SNMP perl module. Legal values are between 1 and 60 seconds, and the default is 5 seconds if the option is not present. Note that there is one retry (with the same timeout) before the SNMP object times out completely. For an unresponsive SNMP server, you'll see that the plugin times out with an SNMP error after 10 seconds if the 5 second default is used.

This option is usually not needed. The default timeout of 5 seconds is more than sufficient in most cases. 🫢

  • -U, --username securityname β€” [SNMPv3] the User-based Security Model (USM) used by SNMPv3 requires that a securityName be specified. This option is required when using SNMP version 3, and expects a string 1 to 32 octets in length.
  • --authpassword password, --authkey key β€” [SNMPv3] by default a securityLevel of noAuthNoPriv is assumed. If the --authpassword option is specified, the securityLevel becomes authNoPriv. The --authpassword option expects a string which is at least 1 octet in length as argument.

Optionally, instead of the --authpassword option, the --authkey option can be used so that a plain text password does not have to be specified in a script. The --authkey option expects a hexadecimal string produced by localizing the password with the authoritativeEngineID for the specific destination device. The snmpkey utility included with the Net::SNMP distribution can be used to create the hexadecimal string. See snmpkey(1) for more information.

  • --authprotocol algorithm β€” [SNMPv3] two different hash algorithms are defined by SNMPv3 which can be used by the Security Model for authentication. These algorithms are HMAC-MD5-96 β€œMD5” (RFC 1321) and HMAC-SHA-96 β€œSHA-1” (NIST FIPS PUB 180-1). The default algorithm used by the plugin is HMAC-MD5-96. This behavior can be changed by using this option. The option expects either the string md5 or sha to be passed as argument to modify the hash algorithm.
  • --privpassword password, --privkey key β€” [SNMPv3] by specifying the options --privkey or --privpassword, the securityLevel associated with the object becomes authPriv. According to SNMPv3, privacy requires the use of authentication. Therefore, if either of these two options are present and the --authkey or --authpassword arguments are missing, the creation of the object fails. The --privkey and --privpassword options expect the same input as the --authkey and --authpassword options respectively.
  • --privprotocol algorithm β€” [SNMPv3] the User-based Security Model described in RFC 3414 defines a single encryption protocol to be used for privacy. This protocol, CBC-DES β€œDES” (NIST FIPS PUB 46-1), is used by default or if the string des is passed to the --privprotocol option. The Net::SNMP module also supports RFC 3826 which describes the use of CFB128-AES-128 β€œAES” (NIST FIPS PUB 197) in the USM. The AES encryption protocol can be selected by passing aes or aes128 to the --privprotocol option.

One of the following arguments are required: des, aes, aes128, 3des, 3desde

  • --use-get_table β€” this option exists as a workaround when using check_openmanage with SNMPv3 on Windows with net-snmp. Using this option will make check_openmanage use the Net::SNMP function get_table() instead of get_entries() while fetching values via SNMP. The latter is faster and is the default.

🚫 BLACKLISTING 🚫

  • -b, --blacklist string | file β€” blacklist missing and/or failed components, if you do not plan to fix them. The parameter is either the blacklist string, or a file (that may or may not exist) containing the string. The blacklist string contains component names with component IDs separated by slash /. Blacklisted components are left unchecked. πŸ’…
TIP: use the option -d or --debug to get the blacklist ID for devices. The ID is listed in a separate column in the debug output.
NOTE: if blacklisting is in effect, the global health of the system is not checked. 😭

Syntax:

component1=id1[,id2,...]/component2=id1[,id2,...]/...

The ID part can also be all, in which all components of that type is blacklisted.

Example:

check_openmanage -b ps=0/fan=3,5/pdisk=1:0:0:1/ctrl_driver=all

In the example we blacklist powersupply 0, fans 3 and 5, physical disk 1:0:0:1, and warnings about out-of-date drivers for all controllers. Legal component names include:

  • ctrl β€” Storage controller. Note that if a controller is blacklisted, all components on that controller (such as physical and logical drives) are blacklisted as well.
  • ctrl_fw β€” suppress the special warning message about old controller firmware. Use this if you can not or will not upgrade the firmware.
  • ctrl_driver β€” suppress the special warning message about old controller driver. Particularly useful on systems where you can not upgrade the driver.
  • ctrl_stdr β€” suppress the special warning message about old Storport driver on Windows.
  • ctrl_pdisk β€” this blacklisting keyword exists as a possible workaround for physical drives with bad firmware which makes Openmanage choke. It takes the controller number as argument. Use this option to blacklist all physical drives on a specific controller. This blacklisting keyword is only available in local mode, i.e. not with SNMP.
  • pdisk β€” Physical disk.
  • pdisk_cert β€” suppress warning message about non-certified physical disk.
  • pdisk_foreign β€” suppress warning message about foreign physical disk.
  • vdisk β€” Logical drive (virtual disk).
  • bat β€” Controller cache battery.
  • bat_charge β€” ignore warnings related to the controller cache battery charging cycle, which happens approximately every 40-90 days on Dell servers. Note that using this blacklist keyword makes check_openmanage ignore non-critical cache battery errors.
  • conn β€” Connector (channel).
  • encl β€” Storage enclosure.
  • encl_fan β€” Enclosure fan.
  • encl_ps β€” Enclosure power supply.
  • encl_temp β€” Enclosure temperature probe.
  • encl_emm β€” Enclosure management module (EMM).
  • dimm β€” Memory module.
  • fan β€” Chassis fan.
  • ps β€” Power supply.
  • temp β€” Temperature sensor.
  • cpu β€” Processor (CPU).
  • volt β€” Voltage probe.
  • bp β€” System battery.
  • amp β€” Amperage probe (power consumption monitoring).
  • intr β€” Intrusion detection sensor.
  • sd β€” SD card

✨ CHECK CONTROL ✨

  • --no-storage β€” turns off storage checking entirely. It's literally just a glow-up alias for --check storage=0, same energy, shorter name πŸ’…
  • --only keyword β€” bestie, this is the "one thing at a time" girlie option. It makes check_openmanage check and/or report on exactly one class of components, or one warning level. You can specify it once and it expects an argument. Here's the whole menu of arguments and what each one does πŸ‘‡
    • critical β€” print only critical alerts. Any warning alerts get suppressed. 😀
    • warning β€” print only warning alerts. Any critical alerts get suppressed. 🫣
    • chassis β€” check all chassis components and absolutely nothing else.
    • storage β€” only check storage.
    • memory β€” only check memory modules.
    • fans β€” only check fans.
    • power β€” only check power supplies.
    • temp β€” only check temperatures.
    • cpu β€” only check processors.
    • voltage β€” only check voltage probes.
    • batteries β€” only check batteries.
    • amperage β€” only check power usage.
    • intrusion β€” only check chassis intrusion.
    • sdcard β€” only check SD cards.
    • esmhealth β€” only check ESM log overall health, i.e. fill grade.
    • servicetag β€” only check for a sane service tag.
    • esmlog β€” only check the event log (ESM) content.
    • alertlog β€” only check the alert log content.
  • --check string | file β€” okay so this one is your "what should we even look at" dial πŸŽ›οΈ. It lets you adjust which components get checked at all. Heads up though: this is a rougher approach than blacklisting, because blacklisting makes you specify a component id or index and this one does not. The parameter should be either a string containing the adjustments, or a file containing that string. And bestie, no errors are raised if the file does not exist β€” it just vibes quietly into the void πŸ™ˆ

Example:

check_openmanage --check storage=0,intrusion=1

Legal values are described below, along with the default value. Screenshot this πŸ“Έ

  • storage β€” check storage subsystem (controllers, disks etc.). Default: ON
  • memory β€” check memory (dimms). Default: ON
  • fans β€” check chassis fans. Default: ON
  • power β€” check power supplies. Default: ON
  • temp β€” check temperature sensors. Default: ON
  • cpu β€” check CPUs. Default: ON
  • voltage β€” check voltage sensors. Default: ON
  • batteries β€” check system batteries. Default: ON
  • amperage β€” check amperage probes. Default: ON
  • intrusion β€” check chassis intrusion. Default: ON
  • sdcard β€” check SD cards. Default: ON
  • esmhealth β€” check the ESM log health, i.e. fill grade. Default: ON
  • servicetag β€” check that the service tag (serial number) is sane and not empty. Default: ON
  • esmlog β€” check the ESM log content. Default: OFF
  • alertlog β€” check the alert log content. Default: OFF

πŸ” DIAGNOSTICS πŸ”

The option -d or --debug can be specified to display all monitored components. It's giving "show me everything, I want the full lore" ✨


🚦 EXIT STATUS 🚦

If no errors are discovered, a value of 0 (OK) is returned. An exit value of 1 (WARNING) signifies one or more non-critical errors, while 2 (CRITICAL) signifies one or more critical errors.

The exit value 3 (UNKNOWN) is reserved for errors within the script, or errors getting values from Dell OMSA. So if you see a 3, that's not the hardware being dramatic, that's the script or OMSA itself acting up πŸ’€


πŸ’€ BUGS AND LIMITATIONS πŸ’€

Storage info is not collected or checked on very old PowerEdge models and/or old OMSA versions, due to limitations in OMSA. And ngl, the overall support on those models/versions by this plugin is not well tested. So like… proceed with awareness, bestie 🫢


This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. πŸ“œ


🌈 SEE ALSO 🌈


🫢 AUTHORS 🫢

Trond Hasle Amundsen <t.h.amundsen@usit.uio.no> β€” the icon who built all this, we stan πŸ‘‘


And that's the whole page, bestie!! πŸŽ€ This was check_openmanage, version dated 05/20/2023, from the CHECK_OPENMANAGE(8) manual series β€” go forth and monitor those PowerEdges, you absolute legend πŸ’œπŸ¦‹βœ¨
πŸ“¦ where this page comes from