Post by fhomps on Nov 20, 2024 13:38:25 GMT
Hi,
I have a use case for retrieving sensor values from a BMC at relatively high frequencies (>10Hz) over Redfish. Speed of acquisition is not a big concern, but precision is: I need frequent, precisely timestamped values, but getting them 5 seconds late is acceptable.
From what I understand, the telemetry service is made for this purpose: timestamped values of a sensor can be aggregated to a report, then the report can be gathered every so often by the client.
However, I need some clarifications on how this should be implemented.
Taking the example of a MetricReport defined over a single metric (e.g. a sensor's value), I see two possible interpretations of the whitepaper & specs:
1. In the absence of a collection function, MetricReports accumulate metric values
A MetricReport with:
- no CollectionFunction
- a CollectionTimeScope set to Point
- a MetricReportDefinitionType set to Periodic (with a Schedule of every 5 seconds)
would accumulate data points every time the metric value changes.
Essentially, a report with no collection function keeps a history of the values of a specific property in the Redfish arborescence, which the client wants to monitor precisely. The BMC temporarily stores metric values, then publishes all of them in a report, every 5 seconds.
I find this behavior intuitive: no collection function means no processing of the data, so we keep all of it and let the user sort it out.
It is also ideal for my use case. Reports can be easily pushed to the client via the EventService, or pulled regularly if preferred (via MetricReportDefinitionType OnRequest). In either case, the client only gets reports on new values of the metric they hadn't seen before, which is a win on performance and complexity.
2. In the absence of a collection function, MetricReports keep only the current (last) metric value
The previously described MetricReport would be generated every 5 seconds, containing a single value, timestamped with the time it appeared on the redfish arborescence.
This seems to be what OpenBMC implementors had in mind, as I observe this behavior on the latest versions of their TelemetryService.
Under this interpretation, to achieve the desired use case, one would need a MetricReport with:
- a MetricReportDefinitionType set to OnChange, meaning a new, full report would be created every time the sensor updates
- ReportUpdates set to AppendWrapsWhenFull or AppendStopsWhenFull, so that the newly created report keeps the historic values present in the previous one.
I find this less intuitive: discarding all values over a timeframe except the last one is a form of processing; thus, it should be a specific CollectionFunction.
It is also much heavier on the implementation side: a whole new report has to be published on the web server every update. Right now on OpenBMC, all reports force MetricReportDefinitionType=Overwrite, so I cannot test this, but watching sensors at >10Hz will probably be unattainable (due to the very dbus-heavy architecture between telemetry service and bmcweb).
Which of these two is the correct interpretation of the spec?
My apologies if I missed something obvious in the specs / whitepapers / forums, but this has been stumping me for a while. Any help is appreciated.
