multiple telemetry designs

[Matuszczak, Piotr]

Hi, 

Our design is tailored to support the Redfish Telemetry Service, but it is not limited to it and either, the telemetry configuration and presentation is done via the Redfish. Also, the monitoring service is designed to support Redfish triggers leveraging the Redfish Event Service for sending events. 

If the collectd is to exist independently of Redfish and D-Bus it is possible to use both solutions. I have some questions, though:
1. How the telemetry gathering will be configured by the user, when collectd is used?
2. What is the use case for storing historical readings in the BMC, using non-volatile storage (or did I misunderstood the rrd files)? 

As for merging the two proposals, the common D-Bus API for the telemetry back-end (either collectd or monitoring service) was what I thought about at first. Of course, the back-end will have to support metric report and triggers management, because the bmcweb is only the presentation layer (Redfish Telemetry Service) for the telemetry data. 

Regards
Piotr

-----Original Message-----
From: Brad Bishop [mailto:bradleyb at fuzziesquirrel.com] 
Sent: Friday, October 25, 2019 2:59 PM
To: OpenBMC Maillist <openbmc at lists.ozlabs.org>
Cc: James Feist <james.feist at linux.intel.com>; Matuszczak, Piotr <piotr.matuszczak at intel.com>; Kun Yi <kunyi at google.com>; Justin Thaler <thalerj at linux.vnet.ibm.com>; Mihm, James <james.mihm at intel.com>; Neeraj Ladkani <neladk at microsoft.com>; Shawn McCarney <shawnmm at linux.vnet.ibm.com>
Subject: Re: multiple telemetry designs


> 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