RFC for Telemetry data collection
tomjose
tomjose at linux.vnet.ibm.com
Fri Sep 8 01:20:16 AEST 2017
Hello,
I am working on the issue
(https://github.com/openbmc/openbmc/issues/1957) to design a telemetry
application for the OpenBMC. I would be explaining a rough idea of how
we plan to go about. Please share your thoughts and feedback on this
proposal. This issue would depend on the design evolving out of
following issues, since this app would utilize the capabilities
provided. (https://github.com/openbmc/openbmc/issues/1856,
https://github.com/openbmc/openbmc/issues/2102).
Summary of the requirements that we came across relevant to this discussion.
1) BMC telemetry data (example VRM rail voltages) where the data is
collected at different rates depending on the data and aggregated by the
BMC app (minimum, maximum
and average). Based on the collection timing request(frequency) the
metrics are logged, so that the user can fetch it for analytics.
2) Users should be able to set thresholds for the temperature limits,
and receive alerts. This would allow user to plan the cooling needs.
3) BMC would act as route for the OCC metrics to be send to the user.
The OCC would send down telemetric data to the BMC and BMC should figure
out a way to
alert the user to consume this data.
We would keep the focus of the discussion on the requirement no 1.
This proposal presupposes that all the resources( example VRM rail
voltages, ambient temperature) that the telemetry app is interested in,
should be populated as dbus objects, which can
be queried to read the instantaneous values. phosphor-hwmon application
exposes many of the interested resources.
The idea is to have a yaml based approach, where the policy of the
telemetry app will be expressed. The application would be able to
consume the yaml and initiate the telemetry
data collection. The yaml would express the following:
a) Dbus Info (object, interface, property) associated with the resource.
b) Units associated with the value (celsius) and the associated scaling
factor).
c) Granularity - the time between two measures.
d) Aggregation methods - min,max,avg..etc.
e) Logging policy - frequency for creating an event and alerting the user.
The application would operate based on the policy and log the telemetry
data. The details of logging would evolve as we progress on the related
issue.
Regards,
Tom
More information about the openbmc
mailing list