multiple telemetry designs

[Neeraj Ladkani]

This is great discussion. can we have a deep dive on this during next telemetry sync up call ?

Neeraj

From: Kun Yi <kunyi at google.com>
Sent: Thursday, October 24, 2019 10:27 AM
To: Shawn McCarney <shawnmm at linux.vnet.ibm.com>
Cc: Brad Bishop <bradleyb at fuzziesquirrel.com>; James Feist <james.feist at linux.intel.com>; piotr.matuszczak at intel.com; thalerj at linux.vnet.ibm.com; OpenBMC Maillist <openbmc at lists.ozlabs.org>; james.mihm at intel.com; Neeraj Ladkani <neladk at microsoft.com>
Subject: Re: multiple telemetry designs



On Thu, Oct 24, 2019 at 10:13 AM Shawn McCarney <shawnmm at linux.vnet.ibm.com<mailto: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/be3dd503/attachment-0001.htm>