multiple telemetry designs

[Brad Bishop]

> On Oct 24, 2019, at 1:13 PM, Shawn McCarney <shawnmm at linux.vnet.ibm.com> wrote:
> 
> * Could the two proposals be merged, with D-Bus providing the public API to the data?  Maybe something like the following?  1) Continue to store current sensor values on D-Bus using the existing architecture.  Sensor values come from a variety of sources.  2) An application obtains current sensor values from D-Bus and stores them with timestamps in RRD to provide efficient history/telemetry.  3) A new D-Bus interface/method is created to obtain the history/telemetry data.  4) bmcweb uses the current D-Bus interfaces for the Sensor URIs (as it does today) and uses the new D-Bus interface/method for Telemetry URIs?

I think there is room for a merged/split design.  There are two use cases to consider though while we formulate that.

1 - I want to expose sensor data with collectd (collectd-binary).
2 - I want to expose sensor data with bmcweb (Redfish).

I would suggest that for #1, dbus be avoided and go right to the source of the data, whatever that may be.  That would be more performant and it avoids dependencies on OpenBMC software which means collectd plugins that are written would have a chance at being accepted in upstream collectd.  This would be irrespective of how #2 is designed and implemented.

I don’t think I need #1 though.  Does anyone plan on doing #1 on their BMC?  When I originally suggested collectd, it was because I thought:

1 - collectd is a preexisting implementation of the proposed custom monitoring service...

therefore

2 - it would save effort and be a smaller maintenance burden to use pre-existing software rather than writing it from scratch.

It is certainly possible though that collectd can’t be made to fit the bill or I am imagining more of an overlap between the custom monitoring service and a collectd based one than there really is.

thx - brad