multiple telemetry designs

[Kun Yi]

On Thu, Oct 24, 2019 at 10:13 AM Shawn McCarney <shawnmm at linux.vnet.ibm.com>
wrote:

> I've reviewed both designs, although I cannot say I understand them both
> in depth.
>
> With that disclaimer, here is my 2 cents:
>
> * Both proposals are thoughtful with a lot work put into them.
>
> * bmcweb has a lot of a sensor code that is quite complex that is
> dependent on the current D-Bus sensors and associations.  It would
> require a lot of work and re-testing to ensure a different interface to
> sensor data doesn't break current systems.  The code would be even more
> complex if it had to support two different sensor data interfaces.
>
> * There are sensor readings that cannot be collected by reading files in
> the file system.  Some are collected by direct I2C reads or other
> methods.  If my surface understanding of collectd is correct, plug-ins
> would need to be written to handle these "non-file" sensors.
>
> * For the reasons above, I'd prefer to see D-Bus continue to be the
> "public API" to sensor data.  D-Bus is the central data sharing
> repository on the OpenBMC.  How the sensor data gets on D-Bus is
> implementation detail and can vary by system and by project.  It can be
> obtained by hwmon, collectd, and many other ways.  As long as it is
> published on D-Bus, other applications (like bmcweb) can easily consume it.
>
> * It sounds like the RRD format would be an efficient way to store
> sensor data.  I do worry about the space and CPU required to store
> telemetry data.  The OpenBMC stack is going to be used on some big
> servers, and they are going to have a large number of sensors.
>
> * 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?
>
> Thanks,
>
> Shawn
>
>
(author of the collectd/RRD based design here)
First of all, I have been silent on the mailing list for a while, without
any progress on collectd. There are some fires that I need to put out
first, unfortunately :(

I have discussed with Piotr in the telemetry meeting. Basically we'd like
to rephrase it as this: Piotr's design doesn't prevent future extension
such as using collectd/rrdtool as a backend to provide telemetry data, and
I reviewed the Redfish API that the design would provide, which LGTM.
Therefore I +1'ed Piotr's design, given that there is already concrete work
behind it, and collectd didn't work for his requirements.

To be able to merge the designs, either Bmcweb can use RRD library or
collectd/librrd can talk D-Bus, which is some work but not insurmountable.
Piotr maybe you want to call that out explicitly in your design doc?

Regards,
Kun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191024/100f2314/attachment.htm>