Skip to content

Check redfish-sensors

Overview

Checks hardware sensor readings (temperature, voltage, fan speed, power) from the Redfish Chassis collection via the Redfish API. Reads the modern Sensors collection where available and falls back to the legacy Thermal and Power endpoints otherwise, which also supply the fans and power supplies the Sensors collection does not list. Alerts when any sensor reports a non-ok state. Also evaluates fan redundancy status. A Chassis is roughly defined as a physical view of a computer system as seen by a human. A single Chassis resource can house sensors, fans, and other components.

Important Notes:

  • Tested on DELL iDRAC, HPE iLO 6 and DMTF Simulator
  • A check usually completes within a few seconds, but a slow or retried request can exceed the short check timeout monitoring systems use by default (often 10 seconds). Give the check up to 60 seconds.
  • This check runs with both HTTP and HTTPS. It uses GET requests only.
  • No additional Python Redfish modules need to be installed.

Data Collection:

  • Queries /redfish/v1/Chassis to enumerate chassis members
  • For each member, reads the modern Sensors collection to get individual sensor values, thresholds and health status
  • When a chassis exposes no Sensors collection (typical of older BMCs such as iLO4), falls back to the legacy Thermal (temperatures, fans) and Power (voltages, power supplies) endpoints
  • When a chassis has a Sensors collection, adds the fans from the legacy Thermal endpoint if it lists none (HPE iLO 6 lists only temperatures there), and the power supplies from the legacy Power endpoint, whose health the Sensors collection does not carry
  • Follows the Thermal and Power endpoints only where the chassis advertises them. HPE iLO answers both on a storage backplane with the data of the server, so reading them there would report every sensor twice
  • A sensor name that occurs more than once in a chassis is replaced by the sensor's Id, since Dell iDRAC names the sensors of every power supply alike
  • Also queries the Thermal endpoint for fan redundancy information
  • Reads each collection in a single request via the Redfish $expand query where the controller supports it, otherwise falls back to one request per member
  • Uses HTTP Basic authentication if --username and --password are provided
  • Skips sensors and chassis in "Absent" or "Disabled" state. The health of every other one is evaluated, a failed spare power supply included. The thresholds only count for a sensor that is operating ("Enabled", "Quiesced", "Degraded", "Qualified" or no state), since a component in standby, under test, starting or updating reports a reading that says nothing about the running system

Fact Sheet

Fact Value
Check Plugin Download https://github.com/Linuxfabrik/monitoring-plugins/tree/main/check-plugins/redfish-sensors
Nagios/Icinga Check Name check_redfish_sensors
Check Interval Recommendation Every 5 minutes
Can be called without parameters No (--url is required)
Runs on Cross-platform
Compiled for Windows No (runs with Python interpreter)
Uses State File $TEMP/linuxfabrik-monitoring-plugins-redfish.db

Help

usage: redfish-sensors [-h] [-V] [--always-ok] [--brief]
                       [--cache-expire CACHE_EXPIRE] [--ignore IGNORE]
                       [--insecure] [--inventory] [--match MATCH]
                       [--no-insecure] [--no-perfdata] [--no-proxy]
                       [--password PASSWORD] [--proxy PROXY]
                       [--retries RETRIES] [--timeout TIMEOUT] --url URL
                       [--username USERNAME] [--verbose]

Checks hardware sensor readings (temperature, voltage, fan speed, power) from
the Redfish Chassis collection via the Redfish API. Reads the modern Sensors
collection where available and falls back to the legacy Thermal and Power
endpoints otherwise, which also supply the fans and power supplies the Sensors
collection does not list. Alerts when any sensor reports a non-ok state.

options:
  -h, --help            show this help message and exit
  -V, --version         show program's version number and exit
  --always-ok           Always returns OK.
  --brief               Hide items that are OK and show only those in
                        WARN/CRIT state. Alerting is unaffected: all items
                        still drive the overall check state.
  --cache-expire CACHE_EXPIRE
                        The amount of time after which the credential/data
                        cache expires, in minutes. Default: 5
  --ignore IGNORE       Ignore items whose name matches this Python regular
                        expression. Case-sensitive by default; use `(?i)` for
                        case-insensitive matching. Can be specified multiple
                        times.
  --insecure            This option explicitly allows insecure SSL
                        connections.
  --inventory           Output the parsed components as JSON on stdout and
                        exit OK, instead of running a health check. Use this
                        to collect a hardware inventory: the JSON is a single
                        object keyed by component type, so the output of
                        several Redfish checks can be merged into one
                        inventory document with `jq --slurp`. Ignores --brief,
                        --match and --ignore.
  --match MATCH         Only check items whose name matches this Python
                        regular expression. Case-sensitive by default; use
                        `(?i)` for case-insensitive matching. Can be specified
                        multiple times. If both `--match` and `--ignore` are
                        given, an item must match `--match` AND not match
                        `--ignore` to be reported (include first, exclude
                        second).
  --no-insecure         Verify the TLS certificate against the system trust
                        store, overriding the insecure default of this check.
                        Use it once the endpoint presents a publicly trusted
                        certificate, or once its CA has been added to the
                        system trust store.
  --no-perfdata         Suppress the performance data section from the output.
                        The status message and the exit code are unaffected,
                        so alerting keeps working while trending data is
                        dropped.
  --no-proxy            Do not use a proxy, not even one the environment
                        names. Overrides `--proxy`.
  --password PASSWORD   Redfish API password.
  --proxy PROXY         Proxy to reach the target through. The scheme defaults
                        to `http` when omitted. Overrides the proxy the
                        environment names (`http_proxy`, `https_proxy`,
                        `all_proxy`) together with the exceptions it lists in
                        `no_proxy`, and is itself overridden by `--no-proxy`.
                        Without either parameter the environment applies.
                        Credentials belong into the environment variable
                        rather than here, because a command-line argument is
                        visible to every user on the host. Example:
                        `--proxy=http://proxy.example.com:3128`.
  --retries RETRIES     Number of extra attempts if a request to the Redfish
                        API fails, before the check gives up. Helps against an
                        occasionally slow or flaky management controller.
                        Default: 3
  --timeout TIMEOUT     Network timeout in seconds. Default: 8 (seconds)
  --url URL             Redfish API URL.
  --username USERNAME   Redfish API username.
  --verbose             Makes this plugin verbose during the operation. Useful
                        for debugging and seeing what is going on under the
                        hood. For this check that also appends every Redfish
                        response it evaluated to its output, ready to be
                        attached to a bug report, and writes a trace of every
                        Redfish request, with timings, to linuxfabrik-
                        monitoring-plugins-redfish-trace.log below the
                        temporary directory. Unlike this check's output, the
                        trace survives a check that the monitoring server
                        terminates for exceeding its timeout, which is what
                        makes it useful against a slow management controller.
                        Passwords and session tokens are kept out of both. The
                        output grows with the responses, so keep this switched
                        on in a service definition only while chasing a
                        problem.

Documentation:
https://linuxfabrik.github.io/monitoring-plugins/check-plugins/redfish-sensors/

Usage Examples

./redfish-sensors --url=https://bmc --username=redfish-monitoring --password='linuxfabrik'

Output:

Everything is ok. Checked sensors on 1 member.

Member: Contoso 3500RX, Power: On, LED: Lit, SKU: 8675309, SerNo: 437XR1138R2, PartNumber: 224071-J23

Sensor                             ! Location    ! Reading ! Unit ! Value ! State
-----------------------------------+-------------+---------+------+-------+------
Ambient Temperature                ! Room        ! 22.5    ! Cel  ! [OK]  ! [OK]
CPU #1 Fan Speed                   ! CPU         ! 80      ! %    ! [OK]  ! [OK]
CPU #1 Temperature                 ! CPU         ! 37      ! Cel  ! [OK]  ! [OK]
DIMM #1 Temperature                ! Memory      ! 44      ! Cel  ! [OK]  ! [OK]
Power Supply #1 Input Power        ! PowerSupply ! 374     ! W    ! [OK]  ! [OK]

Redundancy            ! Mode ! State
----------------------+------+-------
BaseBoard System Fans ! N+m  ! [OK]

States

  • OK if all sensors are healthy and within their thresholds.
  • WARN if a sensor health or health rollup state is "Warning".
  • WARN if a sensor value exceeds the Redfish caution or critical threshold (UpperCaution, LowerCaution, UpperCritical, LowerCritical; the legacy UpperThresholdNonCritical, LowerThresholdNonCritical, UpperThresholdCritical, LowerThresholdCritical). Redfish defines a critical reading as above the normal range but not yet fatal, which is why HPE iLO labels this threshold "Caution".
  • WARN if a sensor value exceeds a user-defined threshold (UpperCautionUser, LowerCautionUser, UpperCriticalUser, LowerCriticalUser). A user-defined threshold of 0 counts as not set, since HPE iLO 6 reports 0 for a threshold nobody configured.
  • CRIT if a sensor health or health rollup state is "Critical".
  • CRIT if a sensor value exceeds the Redfish fatal threshold (UpperFatal, LowerFatal; the legacy UpperThresholdFatal, LowerThresholdFatal), which HPE iLO labels "Critical".
  • --always-ok suppresses all alerts and always returns OK.

Perfdata / Metrics

Depends on your hardware. Each sensor reading (from the modern Sensors collection or, in the legacy fallback, from the Thermal and Power endpoints) is reported as a separate metric. Where several chassis carry a sensor of the same name, as the blades of an enclosure do, the chassis id goes in front of those metric names, for example Blade1_CPU_CPU_Temp.

Name Type Description
[\<chassis-id>]\<location>\<sensor-name> Number Sensor reading. Examples: Chassis_Chassis_Fan_1, CPU_CPU_1_Temperature, Intake_01-Inlet_Ambient, Blade1_CPU_CPU_Temp

For Maintainers

You don't need a physical server with a real BMC (the management controller that serves the Redfish API, e.g. HPE iLO or Dell iDRAC) to develop or test this plugin. The official DMTF Redfish mockup server serves a static, read-only Redfish tree (including the modern Sensors collection as well as the legacy Thermal and Power endpoints) over plain HTTP, which is exactly what this GET-only plugin needs.

Run the mockup server and point the plugin at it, from the repository root:

podman run \
    --detach --rm \
    --name lfmp-redfish-mock \
    --publish 5000:8000 \
    docker.io/dmtf/redfish-mockup-server:latest
sleep 3
check-plugins/redfish-sensors/redfish-sensors --url=http://127.0.0.1:5000 --no-proxy
podman stop lfmp-redfish-mock

Use http://127.0.0.1:5000 rather than http://localhost:5000, because localhost may resolve to IPv6 (::1) while the published container port is bound to IPv4.

The fixtures under unit-test/stdout/ are the output of --verbose runs, one file per scenario, with a ### GET <path> block for every Redfish response the plugin evaluated. The test suite replays them instead of calling a controller, so the output a user attaches to a bug report becomes a new scenario as it is, whatever the number of members. To simulate a fault, copy a scenario and edit a sensor's Status.Health, or push a reading past its critical threshold. The offline test suite is run with ./run from the unit-test directory.

Credits, License