Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: update request from dev

Requirement

...



Name

Description

1.

Support Redfish v1.0

Supports Redfish version 1.0

 

Make use of REST API and scheme defined in Redfish standard v1.0

2.

0

Support metrics from various type of sensors

 

3.0

Supports filtering the sensor type

 

4.0

out-band monitoring

 

Overview

Configurable list of endpoints

Plugin configuration shall contain list of queries and list of services.

Each query entry shall contain endpoint and list of resources to be collected.

Each service entry shall contain credentials to gain access and list of queries to perform,

3.0 

Configurable mapping of redfish sensors to collectd metrics

There shall be mapping between redfish sensors to collectd sensors as for units and types.

4.0 

OOB monitoring

Collecting telemetry shall be performed over the network.

5.0Supported metrics of redfish v1.0

Metrics shall be supported:

  • Temperature
  • Power
  • Fan


 

Overview

DMTF’s Redfish is a standard API designed to deliver simple and secure management for converged, hybrid IT and the Software Defined Data Center (SDDC). Both human readable and machine capable, Redfish leverages common Internet and web services standards to expose information directly to the modern tool chain. Delivering both in‐band and out‐of‐band manageability, Redfish continues to expand to address customer use cases and technology for a DMTF’s Redfish is a standard API designed to deliver simple and secure management for converged, hybrid IT and the Software Defined Data Center (SDDC). Both human readable and machine capable, Redfish leverages common Internet and web services standards to expose information directly to the modern tool chain. Delivering both in‐band and out‐of‐band manageability, Redfish continues to expand to address customer use cases and technology for a holistic data center management experience.

...

Name

Type

Type Instance

Description

Comment

-

Sensor type

Sensor name

Sensor types and sensor names are not defined and are generated for each sensor individuallydefined via configuration file (They will be auto-generated from payload in next code drops).

Depends to hardware.

 

Plugin configuration

The following configuration options should be supported by redfish collectd plugin:  

Selects sensors to collect information.

Name

Description

Interval

The interval within which to retrieve information about  sensors in seconds

QuerySection defining a query performed on Redfish interface

Endpoint

URI of the REST API Endpoint for accessing the BMC

Resource

Selects single resource or array to collect information.

PropertySelects property from which data is gathered
PluginInstancePlugin instance of collectd metric
TypeType of collectd metric
TypeInstanceType instance of collectd metric
ServiceSection defining service to be sent requests

Sensor

Username

BMC username

Password 

BMC password for the username in question

Address

IP address of the REST API Endpoint for accessing the BMC

Version

Redfish version

Queries

Queries to run

 

Here is an example of the plugin configuration section of collectd.conf file for the python based plugin module:

<Plugin python>

Import "redfish_sensors_plugin"

<Module "redfish_sensors_plugin">

Username "<username>"

Password "<password>"

Interval <poll-interval-seconds>

sensor ["fan:power:thermal"]

Address  "<ipaddress>"

Version  "[v1]"

Verbose false

Debug false

</Module>

</Plugin>

Note :  Plan is to move from python based plugin to C based plugin

Implementation details

To support the redfish based sensor monitoring, the standard redfish interfaces are used as mentioned in the DMTF. Idea is to use as much possible the standard REST API URLs to reach the sensor resources. In order to implement and utilize the redfish interfaces one must understand the concept of resoure maps in DMTF redfish architecture. 

The resource traversing for each elements can happen via well defined resource map. As described in the below diagram, These resource maps can be used directly to depict the REST URL to use GET or POST requests to certain resources. For the purpose of this plugin, the main focus is on the resources below /"redfish/v1/Chassis/<id>".   

Image Removed

Resource Map in Redfish (courtsey : DMTF)

:


Code Block
<Plugin redfish> <Query "fans"> Endpoint "/Chassis[0]/Thermal" <Resource "Fans"> <Property "ReadingRPM"> PluginInstance "chassis-1" Type "rpm" </Property> </Resource> </Query> <Query "temperatures"> Endpoint "/Chassis[0]/Thermal" <Resource "Temperatures"> <Property "ReadingCelsius"> PluginInstance "chassis-1" Type "degrees" </Property> </Resource> </Query> <Query "voltages"> Endpoint "/Chassis[0]/Power" <Resource "Voltages"> <Property "ReadingVolts"> PluginInstance "chassis-1" Type "volts" </Property> </Resource> </Query> <Service "local"> Host "127.0.0.1:5000" User "user" Passwd "passwd" Queries "fans" "voltages" "temperatures" </Service> </Plugin>


Image Added


Implementation details

To support the redfish based sensor monitoring, the standard redfish interfaces are used as mentioned in the DMTF. Idea is to use as much possible the standard REST API URLs to reach the sensor resources. In order to implement and utilize the redfish interfaces one must understand the concept of resource maps in DMTF redfish architecture. 


Image Added


Following  Following redfish REST query outputs the current sensor status of Fan (for "Fan_SYS4_2" with member id 9) and its corresponding metadata. "ReadingRPM" parameters is the main value of concern here which shows the current Fanspeed.

...

Collectd'd standard framework calls are used to read the configurations details and then make a read callback for specified sensors. Once the sensor values are fetched, they are pushed to the cache. Following state diagram gives an idea on how the sensor values are picked.

Image Removed

Collectd redfish State diagram

List of supported sensors

 The  collectd redfish plugin implementation supports the following types of redfish sensors:

...

redfish Sensor type

...

CollectD sensor value type

...

Power

...

voltage

...

Temperature

...

temperature

...

Fan

...

fanspeed

...

idea on how the sensor values are picked.


Image Added

Collectd redfish State diagram

List of supported sensors

 The  collectd redfish plugin implementation supports the following types of redfish sensors:

redfish Sensor type

CollectD sensor value type

Collected Sensor Units

Power

voltage

Volts

Temperature

temperature

Celsius

Fan

fanspeed

RPM

 

Considerations

Configuration Considerations

Deployment Considerations

If your platform does not support BMC – this plugin will be unloaded at initialization time.

 

API/GUI/CLI Considerations

Equivalence Considerations

Security Considerations

Alarms, events, statistics considerations

Not all metrics will be reported as not all types of sensors are supported by redfish plugin.

redfish plugin registers to listen for all type of sensor events received from System Event Log (SEL).

Redundancy Considerations

Performance Considerations

Testing Consideration

The timing interval requirement needs to be taken into consideration when conducting tests.

The Tests should be carried out on a system underload as well as a relatively idle system.

 

Other Considerations

Impact

The following table outlines possible impact(s) the deployment of this deliverable may have on the current system.

 

Ref

System Impact Description

Recommendation / Comments

1

 

 

Key Assumptions

The following assumptions apply to the scope specified in this document.

 

Ref

Assumption

Status

1

 

 

Key Exclusions

The following exclusions apply to the scope discussed in this document.

 

Ref

Exclusion

Status

1

 

 

Key Dependencies

The following table outlines the key dependencies associated with this deliverable.

 

Ref

Dependency

Status

1


 



<Plugin redfish>

  <Query "fans">

    Endpoint "/Chassis[0]/Thermal"

    <Resource "Fans">

      <Property "ReadingRPM">

        PluginInstance "chassis-1"

        Type "rpm"

      </Property>

    </Resource>

  </Query>

  <Query "temperatures">

    Endpoint "/Chassis[0]/Thermal"

    <Resource "Temperatures">

      <Property "ReadingCelsius">

        PluginInstance "chassis-1"

        Type "degrees"

      </Property>

    </Resource>

  </Query>

  <Query "voltages">

    Endpoint "/Chassis[0]/Power"

    <Resource "Voltages">

      <Property "ReadingVolts">

        PluginInstance "chassis-1"

        Type "volts"

      </Property>

    </Resource>

  </Query>

  <Service "local">

    Host "127.0.0.1:5000"

    User "user"

    Passwd "passwd"

    Queries "fans" "voltages" "temperatures"

  </Service>

</Plugin>

 

Considerations

Configuration Considerations

Deployment Considerations

If your platform does not support BMC – this plugin will be unloaded at initialization time.

 

API/GUI/CLI Considerations

Equivalence Considerations

Security Considerations

Alarms, events, statistics considerations

Not all metrics will be reported as not all types of sensors are supported by redfish plugin.

redfish plugin registers to listen for all type of sensor events received from System Event Log (SEL).

Redundancy Considerations

Performance Considerations

Testing Consideration

The timing interval requirement needs to be taken into consideration when conducting tests.

The Tests should be carried out on a system underload as well as a relatively idle system.

 

Other Considerations

Impact

The following table outlines possible impact(s) the deployment of this deliverable may have on the current system.

 

...

Ref

...

System Impact Description

...

Recommendation / Comments

...

1

...

 

...

 

Key Assumptions

The following assumptions apply to the scope specified in this document.

 

...

Ref

...

Assumption

...

Status

...

1

...

 

...

 

Key Exclusions

The following exclusions apply to the scope discussed in this document.

 

Ref

Exclusion

Status

1

 

 

Key Dependencies

The following table outlines the key dependencies associated with this deliverable.

 

...

Ref

...

Dependency

...

Status

...

1

...