|
|
Post by redfisher on Sept 6, 2023 12:31:16 GMT
Hi,
I have setup streaming telemetry on a redfish implementation. I am getting the metric report like shown below:
{
"MetricId": "Thermal_readings",
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/4",
"MetricValue": "39.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricId": "Thermal_readings",
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/5",
"MetricValue": "37.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricId": "Thermal_readings",
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/6",
"MetricValue": "37.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
I am not able to map the temperature reading to the sensors that generated this data as the MetricProperty is like above. I was thinking it should be something like below:
{
"MetricId": "Thermal_readings",
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/Sensorname", << replaced the sensor id with its name
"MetricValue": "37.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
Is this the right approach? Without the sensor name field - the data above is pretty much useless on the receiver side as we will not be able to map the data to its source sensor. Same story with Power readings etc.
|
|
|
|
Post by mraineri on Sept 6, 2023 13:22:59 GMT
"MetricProperty" will point you to where in the model you can find the source of data. So, using a sensor name would not resolve to anything. Keep in mind, the format of "MetricProperty" is a URI with RFC6901 JSON Pointer. For example, deconstructing the value "/redfish/v1/Chassis/System/Thermal#/Temperatures/4" would equate to...
- Go to "/redfish/v1/Chassis/System/Thermal"
- Step into the "Temperatures" property found in the root of the response
- Go to index 4 of the array
Early on, we anticipated that data collectors would already have a mapping of the different metric property values to a label or something more useful to them. However, we did add an additional "Context" property that can be included to give the sort of hint you're looking for. That would be the starting place to look, but unfortunately it doesn't seem like the service you have supports that property. |
|
|
|
Post by redfisher on Sept 6, 2023 15:55:59 GMT
The issue with Context field is that it can be set per subscription and not per metric reading. I noticed that there is a MetricId field that can be user configured but again that becomes an issue when setting up the subscriptions as the subscribing entity needs to know which sensor number maps to what value and this mapping can change from system to system!
One solution for this can be for the redfish metric report definition to provide the ability to stream the fields of interest to the consumer:
Example curl output:
"@odata.context": "/redfish/v1/$metadata#Thermal.v1_3_0.Temperature",
"@odata.id": "/redfish/v1/Chassis/System/Thermal#/Temperatures/34",
"@odata.type": "#Thermal.v1_3_0.Temperature",
"LowerThresholdCritical": 0.0,
"MaxReadingRangeTemp": 127.0,
"MemberId": "34",
"MinReadingRangeTemp": -128.0,
"Name": "SSD 1 TEMP",
"ReadingCelsius": 32.0,
"Status": {
"Health": "OK",
"State": "Enabled"
},
"UpperThresholdCritical": 80.0
}
As a redfish telemetry subscriber, I want to be able to choose the fields of interest to me in my subscription like the Name field, the ReadingCelsius field and the report should only include those two values for all the Thermal sensors on the device. Is this possible? If so, please share some curl examples for me to try.
|
|
|
|
Post by mraineri on Sept 6, 2023 19:41:15 GMT
"Context" is metric reports are not per subscription like with typical event notifications. This context is per metric value in a metric report. For example, this is what it could look like for your usage:
{
"MetricId": "Thermal_readings",
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/4",
"MetricValue": "39.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00",
"Context": "CPU 1 Temperature"
},
{
"MetricId": "Thermal_readings",
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/5",
"MetricValue": "37.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00",
"Context": "DIMM 1 Temperature"
},
{
"MetricId": "Thermal_readings",
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/6",
"MetricValue": "37.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00",
"Context": "DIMM 2 Temperature"
},
Beyond this, we don't have what you're looking for in the model at this time. The design pattern for the existing model was to minimize the amount of static data returned and to map the desired metrics to generic "MetricValues". I can raise this with others internally to discuss further though.
|
|
|
|
Post by redfisher on Sept 6, 2023 20:29:29 GMT
Please discuss with others and let me know if anything is needed from my side.
|
|
|
|
Post by redfisher on Sept 14, 2023 15:30:05 GMT
Hi, The context field per metric you mentioned above - is that user configured or does the redfish implementation populate that field with the sensor name?
|
|
|
|
Post by mraineri on Sept 14, 2023 15:34:14 GMT
It would be up to the Redfish implementation to populate that information. Generally I would expect it to be a sensor name in the case of a sensor reading, but it could be other things depending on the specific metric in question.
|
|
|
|
Post by redfisher on Sept 14, 2023 15:45:42 GMT
Do you have a pointer to this info on a redfish telemetry spec that I can share with the vendor?
|
|
|
|
Post by mraineri on Sept 14, 2023 16:11:40 GMT
Sorry, I'm looking at the Context property again and I'm misremember the discussions we had a while ago. You're right; Context in MetricReport is the same as what you'd provide in the POST to the subscription collection, meaning there's nothing else to go on in the MetricReport body...
Sorry for the confusion.
|
|
|
|
Post by mraineri on Sept 14, 2023 16:14:47 GMT
And I'm still raising this as something we need to discuss further internally.
|
|
|
|
Post by redfisher on Sept 14, 2023 16:21:06 GMT
No issues. So, how do we get the ability to add fields of interest for the subscriber into a redfish telemetry metric report? Need to add this to the redfish MetricReport spec?
|
|
|
|
Post by mraineri on Sept 14, 2023 16:38:34 GMT
Yes, we'd likely need to add a new property to the MetricReport schema for this usage, unless others have differing ideas during discussions.
|
|
|
|
Post by redfisher on Oct 24, 2023 19:37:09 GMT
Also, how would I create a telemetry metric report where I am requesting some other fields than the numerical ones?
Example curl output from above:
"@odata.context": "/redfish/v1/$metadata#Thermal.v1_3_0.Temperature",
"@odata.id": "/redfish/v1/Chassis/System/Thermal#/Temperatures/34",
"@odata.type": "#Thermal.v1_3_0.Temperature",
"LowerThresholdCritical": 0.0,
"MaxReadingRangeTemp": 127.0,
"MemberId": "34",
"MinReadingRangeTemp": -128.0,
"Name": "SSD 1 TEMP",
"ReadingCelsius": 32.0,
"Status": {
"Health": "OK",
"State": "Enabled"
},
"UpperThresholdCritical": 80.0
}
How would I create a metric report that will stream the fields ReadingCelsius and the Name field? Is there a way to stream the status.health fields?
|
|
|
|
Post by mraineri on Oct 25, 2023 1:29:42 GMT
There are two ways of doing this, and I'll show all three properties at once since the distinction is to add/remove array members.
First is the direct way using definitions solely in MetricReportDefinition. When configuring the MetricReportDefinition resource, you'd specify MetricProperties to point to the different properties you want in your metric report and also specify any wildcards in the URIs for the properties in the Wildcards property. In the example below, it's pointing to the three properties (ReadingCelsius, Name, and Status/Health inside the Temperatures arrays in the Thermal resource) and allowing for two different wildcards.
{
"Wildcards": [
{
"Name": "ChassidId",
"Values": [
"0"
]
},
{
"Name": "TemperatureId",
"Values": [
"4",
"5",
"6"
]
}
],
"MetricProperties": [
"/redfish/v1/Chassis/{ChassidId}/Thermal#/Temperatures/{TemperatureId}/ReadingCelsius",
"/redfish/v1/Chassis/{ChassidId}/Thermal#/Temperatures/{TemperatureId}/Name",
"/redfish/v1/Chassis/{ChassidId}/Thermal#/Temperatures/{TemperatureId}/Status/Health"
],
<Other MetricReportDefinition properties>
}
The other way is to use existing MetricDefinition resources that point to the same properties listed above (and likely with the same wildcards). In this case, there would be three different MetricDefinition resources (since each of these properties have different underlying types. For example, this could be the MetricDefinition resource for the health.
{
"@odata.id": "/redfish/v1/TelemetryService/MetricDefinitions/TemperatureHealth",
"@odata.type": "#MetricDefinition.v1_3_2.MetricDefinition",
"Id": "TemperatureHealth",
"Name": "Health for temperature objects",
"MetricType": "Discrete",
"Wildcards": [
{
"Name": "ChassidId",
"Values": [
"0"
]
},
{
"Name": "TemperatureId",
"Values": [
"4",
"5",
"6"
]
}
],
"MetricProperties": [
"/redfish/v1/Chassis/{ChassidId}/Thermal#/Temperatures/{TemperatureId}/Status/Health"
]
}
Then, you'd have a MetricReportDefinition that references the three MetricDefinition resources, like this (no need to call out MetricProperties directly since those are part of the MetricDefinition resources):
{
"Metrics": [
{
"MetricId": "TemperatureHealth"
},
{
"MetricId": "TemperatureName"
},
{
"MetricId": "TemperatureReading"
}
],
<Other MetricReportDefinition properties>
}
Both methods should form a metric report that looks something like this:
{
"MetricValues": [
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/4/ReadingCelsius",
"MetricValue": "39.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/5/ReadingCelsius",
"MetricValue": "37.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/6/ReadingCelsius",
"MetricValue": "37.000000",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/4/Name",
"MetricValue": "SSD Temp",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/5/Name",
"MetricValue": "CPU 1 Temp",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/6/Name",
"MetricValue": "DIMM 1 Temp",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/4/Status/Health",
"MetricValue": "OK",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/5/Status/Health",
"MetricValue": "OK",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
},
{
"MetricProperty": "/redfish/v1/Chassis/System/Thermal#/Temperatures/6/Status/Health",
"MetricValue": "OK",
"Timestamp": "2023-09-06T12:22:36.443+00:00"
}
]
}
|
|
