docs/designs/bmc-health-monitor.md

11 means to make sure the BMC is working correctly. User can get required metrics
12 data as per configurations instantly. Set of monitored metrics may include CPU
25 3. Metric staging. When metrics are collected, they will be ready to be read
29 4. Data transfer, where the consumer program obtains the metrics from the BMC by
31 5. The consumer program may take certain actions based on the metrics collected.
38 differences between sensors and metrics:
40 1. Sensor data originate from hardware, while most metrics may be obtained
42    metrics on all kinds of BMCs than sensors on BMCs, and we might not need the
44    most health metrics.
45 2. Most sensors are instantaneous readings, while metrics might accumulate over
46    time, such as “uptime”. For those metrics, we might want to do calculations
48 3. Metrics can represent device attributes which don't change, for example,
51 4. Metrics are expressed in native units such as bytes for memory. Sensors
56 metrics data.
66 - A daemon to periodically collect various health metrics and expose them on
70 - Capability to configure health monitoring for wide variety of metrics, such as
82 consumer is obtained, it should be able to obtain the health metrics from the
153 [Metrics Dbus interfaces](https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/64914).
157 | xyz.openbmc_project.Metric.Value     | Interface to represent value for Metrics.                 …
158 | xyz.openbmc_project.Metric.Reset     | Interface to reset persistent Metrics counters.           …
178 Servers for Metrics Data
214 variety of metrics from various sources and provides mechanisms to store them in
215 different ways. For exposing these metrics to DBus, a Collectd C plugin can be
220 - Off the shelf tool with support for lot of metrics.
228   around exposing the metrics on Dbus which will also be needed for Collectd
236 Extend Metrics Dbus interface for -
248 The proposed design changes the DBus interface from Sensors to Metrics, so