Integrate collectd with OpenBMC

[Kun Yi]

hi Brad,

We are making some progress toward two things that we'd like to push upstream:
1. An C++ wrapper for RRD "-- librrdplus"
2. An IPMI OEM handler -- "rrd-ipmi-blobs"

Would you please help create these two repositories?

On Mon, Jul 22, 2019 at 9:30 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> On Thu, Jun 27, 2019 at 10:51:03PM -0700, Kun Yi wrote:
> >Hello there,
> >
> >In the context of reporting BMC performance metrics, my intern Gabriel
> >(cc'ed here) and I have started looking at integrating collectd as a
> >metrics collection tool on OpenBMC. We have got it running, which is
> >trivial, but the next question is how to report the data.
> >
> >We have thought about it and thinks implementing a D-Bus interface to be
> >the most flexible approach. At first, we could implement a snapshot
> >(instantaneos read) interface. It would then be fairly straightforward to
> >add them as Redfish/IPMI sensors.
>
> Just curious in what situations DBus was required?  In the design I
> thought you had applications going right to librrd - where did that fall
> down?

Originally we did envision a D-Bus based data pipeline, but after
researching we think a
file based approach is going to be as flexible and more efficient.
Currently we don't see
D-Bus as strictly needed in the collection path. It *might* be useful
to have a few tunable
knobs exposed through D-Bus, but again it can just be a build-time configuration
for now.

>
> >
> >There are two ways to do this:
> >1. Implement as a collectd "D-Bus" plugin [1]. Collectd supports writing
> >custom plugins which are C files calling the internal plugin APIs. Could
> >probably use sdbus to implement.
> >
> >+ could potentially be upstreamed to collectd
> >- the code probably will live in a downstream fork first, and if it doesn't
> >end up upstream, maintaining could become an issue since collectd plugin
> >API is not guaranteed stable
> >- C
> >
> >2. Implement as an interposer daemon that translates between one of the
> >formats that collectd supports (unix socket, plaintext, RRDTool..) to D-Bus
> >
> >+ project could be purely OpenBMC
> >+ can use sdbusplus
> >- another daemon
> >
> >Any advice on this? Currently we are leaning towards the first approach,
> >but do you agree the D-Bus plugin is general enough to be of interest to
> >the upstream collectd community?
> >
> >I can definitely reach out to the collectd group but just want to ask here
> >first :)
> >
> >[1] Collectd plugins:
> >https://collectd.org/wiki/index.php/Plugin_architecture
> >--
> >Regards,
> >Kun



-- 
Regards,
Kun