<div dir="ltr">Hello there,<br clear="all"><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>There are two ways to do this:</div><div>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.</div><div><br></div><div>+ could potentially be upstreamed to collectd</div><div>- 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</div><div>- C</div><div><br></div><div>2. Implement as an interposer daemon that translates between one of the formats that collectd supports (unix socket, plaintext, RRDTool..) to D-Bus</div><div><br></div><div>+ project could be purely OpenBMC<br></div><div>+ can use sdbusplus</div><div>- another daemon</div><div><br></div><div>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?</div><div><br></div><div>I can definitely reach out to the collectd group but just want to ask here first :)</div><div><br></div><div>[1] Collectd plugins: <a href="https://collectd.org/wiki/index.php/Plugin_architecture">https://collectd.org/wiki/index.php/Plugin_architecture</a></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Regards,<div>Kun</div></div></div></div>