Redfish

Redfish

Plugin: go.d.plugin Module: redfish

Overview

Monitor server hardware through the DMTF Redfish API of a baseboard management controller (BMC). One job covers the health, environmental readings, and inventory of everything behind a single BMC endpoint.

The collector reads these areas. Each component reports its own readings alongside the health and state the BMC publishes for it.

Every system the endpoint exposes appears on this job’s virtual node, or on the collecting Agent when the job has no virtual node.

The collector connects to the Redfish ServiceRoot over HTTP or HTTPS and reads the standard resource types, following links within the same origin. It walks the endpoint once per collection interval, sending several requests at a time up to max_concurrent_requests.

Authentication is set by auth_method:

The only writes it makes are creating and deleting its own Redfish sessions. Everything else is read-only: it changes no setting on the BMC and touches nothing on the systems behind it.

This collector is supported on all platforms.

This collector supports collecting metrics from multiple instances of this integration, including remote instances.

A read-only Redfish account on the BMC. No elevated privileges are needed on the Agent host.

Default Behavior

Auto-Detection

Endpoints are not auto-detected. Configure each BMC as a static or DynCfg job.

Limits

Only standard Redfish properties are collected. Vendor-specific OEM extensions are not.

A reading the endpoint does not return leaves a gap on the chart rather than a zero. Each request must finish within timeout (15 seconds by default) and the whole walk within update_every (60 seconds by default); when a walk runs out of time the collector publishes what it finished and starts fresh at the next interval, so some charts skip that cycle.

Performance Impact

On the Agent host the cost is negligible — HTTP requests and JSON parsing.

On the BMC it scales with how many components the endpoint exposes, since one collection walks every selected resource. The collector sends up to max_concurrent_requests at a time (3 by default, or one when the ServiceRoot declares it cannot serve concurrent requests). BMCs are frequently slow and serialize work internally, so a large chassis can keep the controller busy for much of the interval.

If the BMC struggles, raise update_every, lower max_concurrent_requests, or narrow collect to the areas you need.

Setup

You can configure the redfish collector in two ways:

Important

UI configuration requires paid Netdata Cloud plan.

Prerequisites

Enable and authorize Redfish

Enable the BMC’s Redfish service and create a least-privilege monitoring account that can read the desired systems, chassis, managers, sensors, and storage.

Establish network and TLS trust

Ensure the Netdata Agent can reach the BMC. Prefer HTTPS with a trusted BMC certificate or configure tls_ca. tls_skip_verify is available for legacy/self-signed deployments but permits machine-in-the-middle attacks.

Configuration

Options

The following options apply per Redfish endpoint job. Credentials and private-key fields support Netdata secret references such as ${env:VARIABLE} and ${file:/path}.

via UI

Configure the redfish collector from the Netdata web interface:

1. Go to Nodes.
2. Select the node where you want the redfish data-collection job to run and click the :gear: (Configure this node). That node will run the data collection.
3. The Collectors → Jobs view opens by default.
4. In the Search box, type redfish (or scroll the list) to locate the redfish collector.
5. Click the + next to the redfish collector to add a new job.
6. Fill in the job fields, then click Test to verify the configuration and Submit to save.
   • Test runs the job with the provided settings and shows whether data can be collected.
   • If it fails, an error message appears with details (for example, connection refused, timeout, or command execution errors), so you can adjust and retest.

via File

The configuration file name for this integration is go.d/redfish.conf.

The file format is YAML. Generally, the structure is:

update_every: 1
autodetection_retry: 0
jobs:
  - name: some_name1
  - name: some_name2

You can edit the configuration file using the edit-config script from the Netdata config directory.

cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config go.d/redfish.conf

Examples

Monitor a BMC

Collect hardware readings and health from one Redfish endpoint.

jobs:
  - name: bmc
    url: https://192.0.2.1/redfish/v1/
    username: monitoring
    password: ${file:/etc/netdata/redfish-password}
    tls_ca: /etc/netdata/redfish-ca.pem

Attach to a configured virtual node

Define a virtual node in vnodes.conf, then attach this endpoint job to it.

jobs:
  - name: remote-bmc
    vnode: server-one
    url: https://192.0.2.1/redfish/v1/
    username: monitoring
    password: ${file:/etc/netdata/redfish-password}

Live Data

Inspect one configured endpoint’s latest sensor readings, hardware health, and BMC-retained events, selected with the Instance parameter. Sensors and Hardware show the latest completed collection and do not query the BMC when you open them, so a row can be up to one update_every (60 seconds by default) plus that collection’s duration old; the Observed column is the start time of that collection and is the same for every row. Logs queries the BMC on demand.

Redfish Sensors

Inspect current sensor readings beside the health the BMC reports and an independently derived threshold health, so a crossed limit can be told apart from a fault the BMC has declared. The table holds one row per sensor with its current reading; the average, peak, and threshold values a sensor also publishes are not rows here (they appear on the charts), and power derived from energy is labeled as such. Derived health reads OK when none of that sensor’s own upper and lower limits is active (the BMC may still report other faults), Not applicable when the sensor publishes no limits, and Unavailable when the published limits cannot be used, the reading itself is unavailable, or too few readings have arrived to decide.

Prerequisites

No additional configuration is required.

Parameters

Returns

One row per supported primary reading from the current collection. Missing or invalid values are blank; missing health is Not reported.

Redfish Hardware

Find components needing attention and inspect their identity, configuration and reported condition. Optional columns show CPU counts, memory and storage capacity, firmware release dates and assembly revisions. Component health, aggregate health and collection availability are kept distinct.

Prerequisites

No additional configuration is required.

Parameters

Returns

One row per monitored component or logical resource, including known resources that could not be read. Identity, configuration and version details are optional columns populated when reported by the BMC. Capacity belongs to the individual resource; physical drives and logical volumes must not be added together. Release date describes the firmware or software release, not its installation. Missing or unusable details are blank.

Redfish Logs

Browse events currently retained by one BMC log service in the Logs view. Select the endpoint job and a service linked from its Systems, Managers or Chassis. Refresh reads the log again; BMC rotation or clearing can remove events. This viewer does not store an archive.

Prerequisites

No additional configuration is required.

Parameters

Returns

One row per matching retained entry. Time uses EventTimestamp, then valid Created. Both originals and the time basis remain available in details. Undated entries remain visible as Unavailable after dated rows, with a notice that the time range cannot filter them. Refresh replaces all rows. Failed pages or members fail the request instead of returning a partial log as complete.

Troubleshooting

Diagnostics

Debug Mode

Important: Debug mode is not supported for data collection jobs created via the UI using the Dyncfg feature.

To troubleshoot issues with the redfish collector, run the go.d.plugin with the debug option enabled. The output should give you clues as to why the collector isn’t working.

• Navigate to the plugins.d directory, usually at /usr/libexec/netdata/plugins.d/. If that’s not the case on your system, open netdata.conf and look for the plugins setting under [directories].

  cd /usr/libexec/netdata/plugins.d/
  

• Switch to the netdata user.

  sudo -u netdata -s
  

• Run the go.d.plugin to debug the collector:

  ./go.d.plugin -d -m redfish
  

  To debug a specific job:

  ./go.d.plugin -d -m redfish -j jobName
  

Getting Logs

If you’re encountering problems with the redfish collector, follow these steps to retrieve logs and identify potential issues:

• Run the command specific to your system (systemd, non-systemd, or Docker container).
• Examine the output for any warnings or error messages that might indicate issues. These messages should provide clues about the root cause of the problem.

System with systemd

Use the following command to view logs generated since the last Netdata service restart:

journalctl _SYSTEMD_INVOCATION_ID="$(systemctl show --value --property=InvocationID netdata)" --namespace=netdata --grep redfish

System without systemd

Locate the collector log file, typically at /var/log/netdata/collector.log, and use grep to filter for collector’s name:

grep redfish /var/log/netdata/collector.log

Note: This method shows logs from all restarts. Focus on the latest entries for troubleshooting current issues.

Docker Container

If your Netdata runs in a Docker container named “netdata” (replace if different), use this command:

docker logs netdata 2>&1 | grep redfish

Known Errors

config validation: 'username' and 'password' are required for auth_method "<method>"

When

At job start, with auth_method set to auto, session, or basic.

Cause

Only these three modes send credentials, and both username and password must be set for them. The message also appears the other way round (must be empty for auth_method "none") when credentials are left in place after switching a job to none.

Fix

Set both fields, or switch auth_method to none for an endpoint that takes no credentials. Values may be secret references such as ${file:/etc/netdata/redfish-password} rather than literals.

ServiceRoot has no RedfishVersion

When

At job start or on the first collection, after the URL responded.

Cause

The address answered, but what it returned is not a Redfish ServiceRoot. Usually url points at the BMC’s web UI, a load balancer, or a captive portal rather than at the Redfish service.

Fix

Point url at the service origin or its ServiceRoot path — https://<bmc-address> or https://<bmc-address>/redfish/v1/. Confirm with curl -k https://<bmc-address>/redfish/v1/, which must return JSON containing RedfishVersion.

Redfish endpoint check: Redfish TLS certificate verification failed

When

With an https:// URL and a BMC presenting a self-signed or internally issued certificate, or a certificate issued for a different name than the one in url. During collection the same message appears without the Redfish endpoint check: prefix.

Cause

The Agent host does not trust the certificate authority that signed the BMC’s certificate, or the certificate does not cover the address in url. Most BMCs ship with a self-signed certificate. The collector logs this summary rather than the underlying TLS error text.

Fix

Point tls_ca at the CA bundle that signed the certificate, or install that CA in the Agent host’s trust store; for a name mismatch, use the address the certificate was issued for. tls_skip_verify: true will also connect, but it accepts any certificate and leaves the session open to interception — use it to confirm the diagnosis, not as the permanent setting.

The job starts and passes its check, then collects nothing

When

With auth_method set to auto or session.

Cause

In these modes the configuration test identifies the endpoint without opening a session, so it succeeds before the credentials are ever used. They are validated when collection starts.

Fix

Check the username and password, and that the BMC account may read the systems, chassis, managers, sensors, and storage you expect. auth_method: basic exercises the credentials on every request and fails more visibly while you are diagnosing.

Collection takes as long as, or longer than, the interval

Cause

The endpoint exposes more components than it can serve within update_every. BMCs are frequently slow and many serialize requests internally, so the walk cannot be shortened by concurrency alone. The collector publishes what it finished and starts fresh at the next interval, leaving gaps on some charts.

Fix

Raise update_every, narrow collect to the areas you need, or lower max_concurrent_requests for a controller that degrades under parallel load. Raise timeout only when individual responses genuinely need longer.

A component or reading is missing from the charts

Cause

The collector reads standard Redfish properties only; vendor-specific OEM extensions are skipped. A BMC may also omit a property, or expose it in a shape the standard schemas do not describe. Its area may also be excluded by collect.

Fix

Check collect covers the area first. If it does, report the vendor, model, and firmware version with a sanitized payload from the affected resource so support can be added.