New component: Redfish receiver proposal

[yonatan786]

The purpose and use-cases of the new component

The DMTF Redfish protocol is a standard designed to deliver simple and secure management for converged, hybrid IT and the Software Defined Data Center (SDDC). The Redfish Forum, which is responsible for standard development, consists of industry's leaders like Broadcom Inc., Cisco, Dell Technologies, Hewlett Packard Enterprise, IBM, IEIT SYSTEMS Co Ltd, Intel Corporation, Lenovo, Microsoft Corporation and more.

Redfish improves older standards such as IPMI, SMASH and DASH by exposing a standardized, vendor-agnostic, RESTful API for managing servers, storage, networking & converged infrastructure. It offers a simple, secure and scalable platform management, including firmware updates and configuration management.

Today, Redfish is seeing widespread adoption and deployment by:
• Major server vendors, e.g. Dell EMC, HPE, Lenovo, etc.
• Cloud providers, e.g. Microsoft Azure, Google Cloud, AWS, IBM cloud.
• Open-source solutions
• Standardization organizations
• Etc.

Today, Redfish is being used by NVIDIA in NVIDIA’s clusters for managing hosts and Data Processing Units (DPUs).

Example configuration for the component

All that is required to enable the REDFISH receiver is to include it in the receiver definitions. The protocol can be disabled by simply not specifying it in the list of protocols.

The configuration is divided to 3 parts:

1. global - Encompasses the overall configuration settings for all redfish servers within the redfish collector. It includes parameters that are universally applicable to the entire collection of servers (i.e. collection interval).
2. servers - configuration details are specified on a per-redfish-server basis. This includes essential information required to establish a connection with each individual redfish server (i.e. ip address, port number)
3. collections - The Collection Group abstraction simplifies the configuration by defining groups of sets of property URIs (resources to collect from the Redfish server) that aggregate multiple servers of the same type (e.g. hosts from the same vendor, same devices, etc.).

receivers:
redfishreceiver:
global:
collection_interval: 10s
servers:
- :
hostname:
collections:
-
servers:
- <server name #1>
- <server name #2>
- …
properties:
- /redfish/v1
- …

Telemetry data types supported

Metrics - Metrics - Telemetry will be wrapped into OTLP metrics as list of key-value attribute pair where key is requested URI and value is obtained data

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am a member of the OpenTelemetry organization.
• If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

Alexander Bilkovskii, Yonatan Maman

Sponsor (optional)

No response

Additional context

Following our discussion in the collector SIG meeting on Wednesday (19/6), I am attaching the Redfish Receiver proposal.

[steven-freed]

I can help out with this. I've worked a bit on the Telegraf redfish input plugin. I was surprised when I didn't see an otel redfish receiver. Let me know how I can get involved in the SIG.

[yonatan786]

Hi @steven-freed Thank you for your interest in contributing to the redfish receiver feature. It’s great to hear that you have experience with the Telegraf Redfish input plugin. We share your surprise about the absence of an OpenTelemetry (OTel) Redfish receiver, which is why we have taken the initiative to implement this feature.

Please find the attached presentation detailing our implementation. We would be delighted to receive your reviews and comments on the project. Additionally, if you could sponsor this project (from the oTel side), it would be a tremendous help and greatly appreciated.

Redfish Receiver Proposal.pptx