edtanous
commented
1 year ago Per the bug template for questions and features, please direct your questions to the openbmc mailing list: https://lists.ozlabs.org/listinfo/openbmc
Your suggestion for a feature sounds like an excellent addition, and getting it on the mailing list is a lot more likely to find others that share your views and can work on it in tandem. There are certainly a number of designs that are possible to solve your problem (direct dbus->prometheus export, built-in redfish conversion). Those should be first discussed on the mailing list, and once sketched out, you can either start a design doc or start sending patches to help the discussion.
I have not personally heard any direct mention of Prometheus support prior to this request, but am certainly open to the possibilities it could bring. Closing out this bug in leiu of the mailing list.
I would be totally sold if openbmc support zero config Prometheus / OpenTelemetry metrics native scraping endpoint.
Right there is no easy way to do it transparently - need to run converters (i.e. from redfish to prometheus), configure them, setup authentication, maintain metric name and label mappings, etc. While the software to do this is very simple, there is one at https://github.com/intel/telemetry-connectors-for-openbmc-distribution which is just short Python script to do that, it is still a burden to configure, run and maintain.
Are there any plans for Prometheus support? Implementing it does not require any new extra dependencies or libraries compared to already is used.
We could start with something simple like sensors and fans monitoring, then go deeper like system status, power, generic error counters and some more specific ones, and info metadata (i.e. component versions).