Adding new metric definition use case

Adding new metric definition use case

[Matuszczak, Piotr]

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

Re: Adding new metric definition use case

[vishwa]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

hello,

I am just curious if the minutes are captured somewhere. The last I see 
is: "*Minutes of meeting : 08/06/19 @ 10:00 PM IST"*

Wiki: 
https://github.com/openbmc/openbmc/wiki/Platform-telemetry-and-health-monitoring-Work-Group

!! Vishwa !!

On 11/28/19 5:03 PM, Matuszczak, Piotr wrote:
> 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
>

[-- Attachment #2: Type: text/html, Size: 1896 bytes --]

RE: Adding new metric definition use case

[Neeraj Ladkani]

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 http://www.dmtf.org/about/policies/copyright."
}

-----Original Message-----
From: Matuszczak, Piotr <piotr.matuszczak@intel.com> 
Sent: Thursday, November 28, 2019 3:33 AM
To: Neeraj Ladkani <neladk@microsoft.com>
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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

RE: Adding new metric definition use case

[Matuszczak, Piotr]

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@microsoft.com> 
Sent: Tuesday, December 3, 2019 8:40 AM
To: Matuszczak, Piotr <piotr.matuszczak@intel.com>
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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 http://www.dmtf.org/about/policies/copyright."
}

-----Original Message-----
From: Matuszczak, Piotr <piotr.matuszczak@intel.com> 
Sent: Thursday, November 28, 2019 3:33 AM
To: Neeraj Ladkani <neladk@microsoft.com>
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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

RE: Adding new metric definition use case

[Matuszczak, Piotr]

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@lists.ozlabs.org> On Behalf Of Matuszczak, Piotr
Sent: Tuesday, December 3, 2019 4:42 PM
To: Neeraj Ladkani <neladk@microsoft.com>
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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@microsoft.com> 
Sent: Tuesday, December 3, 2019 8:40 AM
To: Matuszczak, Piotr <piotr.matuszczak@intel.com>
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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 http://www.dmtf.org/about/policies/copyright."
}

-----Original Message-----
From: Matuszczak, Piotr <piotr.matuszczak@intel.com> 
Sent: Thursday, November 28, 2019 3:33 AM
To: Neeraj Ladkani <neladk@microsoft.com>
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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

Re: Adding new metric definition use case

[vishwa]

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@lists.ozlabs.org> On Behalf Of Matuszczak, Piotr
> Sent: Tuesday, December 3, 2019 4:42 PM
> To: Neeraj Ladkani <neladk@microsoft.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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@microsoft.com>
> Sent: Tuesday, December 3, 2019 8:40 AM
> To: Matuszczak, Piotr <piotr.matuszczak@intel.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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 http://www.dmtf.org/about/policies/copyright."
> }
>
> -----Original Message-----
> From: Matuszczak, Piotr <piotr.matuszczak@intel.com>
> Sent: Thursday, November 28, 2019 3:33 AM
> To: Neeraj Ladkani <neladk@microsoft.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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
>

RE: [EXTERNAL] Re: Adding new metric definition use case

[Neeraj Ladkani]

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@linux.vnet.ibm.com> 
Sent: Thursday, December 5, 2019 10:15 PM
To: Matuszczak, Piotr <piotr.matuszczak@intel.com>; Neeraj Ladkani <neladk@microsoft.com>
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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@lists.ozlabs.org> On Behalf Of Matuszczak, Piotr
> Sent: Tuesday, December 3, 2019 4:42 PM
> To: Neeraj Ladkani <neladk@microsoft.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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@microsoft.com>
> Sent: Tuesday, December 3, 2019 8:40 AM
> To: Matuszczak, Piotr <piotr.matuszczak@intel.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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&amp;data=02%7C01%7Cneladk%40microsoft.com%7C8fa2ef7c23c04cd5015208d77a13a8b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637112097608671990&amp;sdata=%2BiBekLlqLDCplhGclLS8QsMjz7LJCmaPuhCerwc5QrU%3D&amp;reserved=0."
> }
>
> -----Original Message-----
> From: Matuszczak, Piotr <piotr.matuszczak@intel.com>
> Sent: Thursday, November 28, 2019 3:33 AM
> To: Neeraj Ladkani <neladk@microsoft.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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
>

RE: [EXTERNAL] Re: Adding new metric definition use case

[Matuszczak, Piotr]

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@microsoft.com>
Sent: Friday, December 6, 2019 8:37 AM
To: vishwa <vishwa@linux.vnet.ibm.com>; Matuszczak, Piotr <piotr.matuszczak@intel.com>; Paul.Vancil@dell.com
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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@linux.vnet.ibm.com>
Sent: Thursday, December 5, 2019 10:15 PM
To: Matuszczak, Piotr <piotr.matuszczak@intel.com>; Neeraj Ladkani <neladk@microsoft.com>
Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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@lists.ozlabs.org> On Behalf Of Matuszczak, Piotr
> Sent: Tuesday, December 3, 2019 4:42 PM
> To: Neeraj Ladkani <neladk@microsoft.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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@microsoft.com>
> Sent: Tuesday, December 3, 2019 8:40 AM
> To: Matuszczak, Piotr <piotr.matuszczak@intel.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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&amp;data=02%7C01%7Cneladk%40microsoft.com%7C8fa2ef7c23c04cd5015208d77a13a8b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637112097608671990&amp;sdata=%2BiBekLlqLDCplhGclLS8QsMjz7LJCmaPuhCerwc5QrU%3D&amp;reserved=0."
> }
>
> -----Original Message-----
> From: Matuszczak, Piotr <piotr.matuszczak@intel.com>
> Sent: Thursday, November 28, 2019 3:33 AM
> To: Neeraj Ladkani <neladk@microsoft.com>
> Cc: openbmc@lists.ozlabs.org; Ambrozewicz, Adrian <adrian.ambrozewicz@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
>