multiple telemetry designs

[Brad Bishop]

Hi Piotr

> On Oct 25, 2019, at 11:08 AM, Matuszczak, Piotr <piotr.matuszczak at intel.com> wrote:
> 
> 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. 

I wasn’t trying to suggest that your design was inflexible.  I apologize if that seemed to be the case.

> 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?

-OEM extension to any management protocol
-ssh + collectd config file
-no configuration (baked into the image - think per-system images deployed to 10000 systems).

but I’m just blasting ideas - I don’t have any need for running the collectd network output plugin.

> 2. What is the use case for storing historical readings in the BMC, using non-volatile storage (or did I misunderstood the rrd files)? 

Clients can have have transient disconnects and not miss any sensor readings.

> 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. 

That makes sense.  And I assume you believe that it is more work to use collectd as that back-end than writing one from scratch?  I guess at this point it is a little moot - from the other thread it sounds like you have the code mostly done already anyway...

thx - brad