multiple telemetry designs

[Matuszczak, Piotr]

Hi Brad, 

Thank you for your answers. I believe, that there was some misunderstanding. I've said, that there is PoC implementation, but I've also said, that the code has to be rewritten. Another thing is, that Monitoring Service is relatively simple and I didn't assume that writing our back-end (the Monitoirng Service) will be less work than using collectd. Our main concern was the collectd storage,  performance requirements and Redfish compatibility. 

I will incorporate in my design the proposal to use collectd as an alternative back-end for telemetry. 

Thank you
Piotr

-----Original Message-----
From: Brad Bishop [mailto:bradleyb at fuzziesquirrel.com] 
Sent: Friday, October 25, 2019 7:31 PM
To: Matuszczak, Piotr <piotr.matuszczak at intel.com>
Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>; James Feist <james.feist at linux.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

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