[EXTERNAL] Re: Adding new metric definition use case

Matuszczak, Piotr piotr.matuszczak at intel.com
Sat Dec 7 02:44:28 AEDT 2019


Hi all,

Vishwa, it's better idea to discuss the design proposal here. We could get immediate feedback.

Neeraj, the design will be published, but it is not written down yet. I would like to discuss our proposals here. As for the schema, to support the user-defined metrics it will require to be extended. In order to do that I will have to discuss this with the DMTF. It would be good to make new properties part of the standard. We would like to add property for user formula and property for alias of source metric in order to define formula in the most clear and easy way.
As for the feature design proposal, our idea is to provide the following:
- 8 user-defined sensors will be defined in the Redfish tree. When not defined, the sensors won't provide any readings.
- In order for such sensor to provide any readings, user shall provide proper MetricDefinition with source sensors URIs, user-defined formula for calculating result reading from source sensors and MetricDefinition.MetricProperties schema field shall contain URI to one of user-defined sensors. User shall define source sensors, the formula, unit, accuracy etc.
- the user-defined sensors shall be available for the Redfish Telemetry Service under pre-defined URIs (for example: /redfish/v1/Chassis/{ChassisID}/Sensors/UserDefinedSensor0 - /redfish/v1/Chassis/{ChassisID}/Sensors/UserDefinedSensor7), thus user will be able to use this metrics in MetricReports and shall be able to define Triggers for these senors

Please tell us what do you think about our idea.

Regards
Piotr

-----Original Message-----
From: Neeraj Ladkani <neladk at microsoft.com>
Sent: Friday, December 6, 2019 8:37 AM
To: vishwa <vishwa at linux.vnet.ibm.com>; Matuszczak, Piotr <piotr.matuszczak at intel.com>; Paul.Vancil at dell.com
Cc: openbmc at lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz at intel.com>
Subject: RE: [EXTERNAL] Re: Adding new metric definition use case

Yes Piotr,

That would be great. Can you publish your design ?  @Paul, I see 1.1.2 is latest schema for telemetry service. Are there any additions that are being planned for next version?

Neeraj

-----Original Message-----
From: vishwa <vishwa at linux.vnet.ibm.com>
Sent: Thursday, December 5, 2019 10:15 PM
To: Matuszczak, Piotr <piotr.matuszczak at intel.com>; Neeraj Ladkani <neladk at microsoft.com>
Cc: openbmc at lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz at intel.com>
Subject: [EXTERNAL] Re: Adding new metric definition use case

hello Piotr,

Could we use the mailing list for those discussions ?

!! Vishwa !!

On 12/5/19 8:39 PM, Matuszczak, Piotr wrote:
> Hi Neeraj,
>
> I've analyzed your use case with Adrian. It looks like you want to define new, synthesized metric from existing D-Bus sensors. We would like to propose a design to implement user-defined metrics, which are synthesized from other metrics using mathematical formulas defined by the user. Such formula may be provided by the user in runtime, not requiring recompilation of OpenBMC. We can discuss  it during the next Telemetry WG meeting.
>
>
> -----Original Message-----
> From: openbmc <openbmc-bounces+piotr.matuszczak=intel.com at lists.ozlabs.org> On Behalf Of Matuszczak, Piotr
> Sent: Tuesday, December 3, 2019 4:42 PM
> To: Neeraj Ladkani <neladk at microsoft.com>
> Cc: openbmc at lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz at intel.com>
> Subject: RE: Adding new metric definition use case
>
> Hi Neeraj,
>
> There are two cases:
> 1. Sensor is already monitored and you want to define new Metric Definition. It is done on the Redfish level. Also in the case when you want to create calculated metric ("Implementation" property equals "Calculated"). In this case min/max/average can be calculated (as defined by the "CalculationAlgorithm" property).
> 2. You want to create Metric Definition for Synthesized sensor ("Implementation" property equals "Synthesized"). This is the example you shown below. In such case, there is no way to provide BMC the algorithm how the metric shall be synthesized from source metrics. In this case, the calculation algorithm has to be implemented as virtual sensor in the BMC prior to defining the Metric Definition. If you want to be able to create synthesized sensors in runtime, additional design will have to be provided.
>
> Regards
> Piotr
>
> -----Original Message-----
> From: Neeraj Ladkani <neladk at microsoft.com>
> Sent: Tuesday, December 3, 2019 8:40 AM
> To: Matuszczak, Piotr <piotr.matuszczak at intel.com>
> Cc: openbmc at lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz at intel.com>
> Subject: RE: Adding new metric definition use case
>
> Hi Piotr,
>
> The use case is simple that if we want to add new metric definition which is already monitored on DBUS and exposed on redfish , we should be able to configure it without changing BMC code.
>
> For example:
> {
>      "@odata.type": "#MetricDefinition.v1_0_3.MetricDefinition",
>      "Id": "OutletAirflowTemp",
>      "Name": "Definition of Outlet Airflow Temperature",
>      "MetricType": "Numeric",
>      "Implementation": "Synthesized",
>      "PhysicalContext": "Exhaust",
>      "Units": "Cel",
>      "Wildcards": [
>          {
>              "Name": "ChassisID",
>              "Values": [
>                  "1"
>              ]
>          }
>      ],
>      "CalculationParameters": [
>          {
>              "SourceMetric": "/redfish/v1/Chassis/{ChassisID}/Thermal#/Temperatures/2/ReadingCelsius"
>          },
>          {
>              "SourceMetric": "/redfish/v1/Chassis/{ChassisID}/Thermal#/Fans/0/Reading"
>          },
>          {
>              "SourceMetric": "/redfish/v1/Chassis/{ChassisID}/Thermal#/Fans/1/Reading"
>          },
>          {
>              "SourceMetric": "/redfish/v1/Chassis/{ChassisID}/Power#/PowerControl/0/PowerConsumedWatts",
>              "ResultMetric": "/redfish/v1/Chassis/{ChassisID}/Power#/PowerControl/0/PowerMetrics/AverageConsumedWatts"
>          }
>      ],
>      "@odata.id": "/redfish/v1/TelemetryService/MetricDefinitions/OutletAirflowTemp",
>      "@Redfish.Copyright": "Copyright 2014-2019 DMTF. For the full DMTF copyright policy, see https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dmtf.org%2Fabout%2Fpolicies%2Fcopyright&data=02%7C01%7Cneladk%40microsoft.com%7C8fa2ef7c23c04cd5015208d77a13a8b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637112097608671990&sdata=%2BiBekLlqLDCplhGclLS8QsMjz7LJCmaPuhCerwc5QrU%3D&reserved=0."
> }
>
> -----Original Message-----
> From: Matuszczak, Piotr <piotr.matuszczak at intel.com>
> Sent: Thursday, November 28, 2019 3:33 AM
> To: Neeraj Ladkani <neladk at microsoft.com>
> Cc: openbmc at lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz at intel.com>
> Subject: [EXTERNAL] Adding new metric definition use case
>
> Hi Neeraj,
>
>       As we talked recently during the Telemetry WG meeting, you were asking about adding new metric definitions. Please, let me better understand your use case, you have HW sensor present on the board (for example, let it be CPU0 VR temperature), you have already HWmon reading it and exposing it as the sensor on D-Bus. You want to be able to add the new Metric Definition for proper interpretation of sensor's reading and new metric definition shall also modify sensor's D-Bus parameters (Scale and Unit) ? Do I understand it correctly?
>       Monitoring Service does not have to interpret the metric from the sensors, because it is used only for report management.
>
>
> Piotr Matuszczak
> ---------------------------------------------------------------------
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173, 80-298 Gdansk
> KRS 101882
> NIP 957-07-52-316
>



More information about the openbmc mailing list