plan to upstream?

[aqw]

Thanks for creating this tool! Are there any plans to upstream zpool_prometheus the same way that zpool_influxdb has been?

[richardelling]

yes, there are plans, but it is pretty low on the priority list.

To properly implement this as a prometheus service, a C-language web service is needed (reference https://github.com/digitalocean/prometheus-client-c). This brings along a little bit of baggage, but it is mostly license compatible (prometheus-client-c has default dependence on libmicrohttpd, which could be problematic) so the non-technical barriers are relatively low. Using other languages with better web service support is possible, too, with the associated baggage.

The bulk of the pain of upstreaming is in the autoconf and ztest areas.

So it can be done, there are a few people-weeks of effort to make it ready to upstream.

[richardelling]

Alternatively, telegraf can be a prometheus source, so you can run a telegraf instance to use zpool_influxdb and present that as a prometheus metrics endpoint. Not as elegant, but doable.

[aqw]

Thanks for the information and suggestions. :-) We might just take the easy route for now, and deploy a systemd timer to execute zpool_prometheus and direct the output to a file for node_exporter's textfile collector to ingest.

[richardelling]

That will work, too.

Unlike the performance metrics, the bulk of the data collected is configuration and pool status which doesn't change very often. So you can use a coarse sampling interval.

[Jean-Daniel]

yes, there are plans, but it is pretty low on the priority list.

To properly implement this as a prometheus service, a C-language web service is needed (reference https://github.com/digitalocean/prometheus-client-c).

I'm not sure it should be a service. I prefer having a command that merely generate OpenMetrics data, and does not provide a HTTP server, this would make it a reusable foundation to write exporters for OpenZFS.