[openstack] about libvirt exporter
Hello. I see that this exporter looks like it collects a lot of information such as projectname, username or flavor of metrics but it looks not popular. It could help us build a very useful dashboard. https://github.com/zhangjianweibj/prometheus-libvirt-exporter I just want to understand some thoughts. Nguyen Huu Khoi
i believe there are 2-3 libvirt exporters but none of them are officially part of the libvirt, Prometheus or openstack projects. the topic of if nova should/cloud have a export has come up in the past. my suggestion at thet time was if we restart and complete the https://specs.openstack.org/openstack/nova-specs/specs/2024.2/approved/per-p... spec which adds a per procoess /health rest endpoint we could extend that with a /metrics or /telemetry endpoint in open metrics/telemetry format https://edgedelta.com/company/blog/opentelemetry-vs-opentracing-vs-openmetri... so that it can provide a promethus scrape endpoint the idea was actually originally raised by john garbut when we first dicssed the healthcheck endpoint at the ptg and we effectively said "yes that could be the direction but lets keep the initial scope small" this work was partly paused because of the eventlet removal work but its something i think we should revisit eventrually perhaps in 2026.2 the reason i bring up eventlet is the current implementation uses the eventlet webserver but i have already consider replacing that with either the stdlib webserver to have 0 depencies or https://github.com/cherrypy/cheroot to align with ironic which already ueses cheroot to host there jsonrpc endpoints if we needed something more performant. in general how the existing libvirt node exporter work are via directly talking to the libvirt api and then parsing the debug metadata we add to the domain xmls to associate the domain metrics with open stack resocues. while the domain xml this is strictly speaking a private debug interface that is subject to change or removal and there for not something that should be relied on for external integrations, it is used by ceilomenter collectd and many other tools and we have not make a backward incompatible change since it was introduced so its more or less reasonable for tools like this to use that info in this way. On 29/09/2025 13:42, Nguyễn Hữu Khôi wrote:
Hello.
I see that this exporter looks like it collects a lot of information such as projectname, username or flavor of metrics but it looks not popular. It could help us build a very useful dashboard.
https://github.com/zhangjianweibj/prometheus-libvirt-exporter
there is also https://github.com/inovex/prometheus-libvirt-exporter which is a fork of it and https://github.com/kumina/libvirt_exporter which is what was packaged by distos like debian in the past https://salsa.debian.org/go-team/packages/prometheus-libvirt-exporter so there have been a couple of competing implementation and no clear winner that im aware of between the 3
I just want to understand some thoughts.
Nguyen Huu Khoi
Hi. Thank you for very useful information. I am looking for 2026.2 for changes. Nguyen Huu Khoi On Mon, Sep 29, 2025, 8:17 PM Sean Mooney <smooney@redhat.com> wrote:
i believe there are 2-3 libvirt exporters but none of them are officially part of the libvirt, Prometheus or openstack projects.
the topic of if nova should/cloud have a export has come up in the past.
my suggestion at thet time was if we restart and complete the
https://specs.openstack.org/openstack/nova-specs/specs/2024.2/approved/per-p...
spec which adds a per procoess /health rest endpoint we could extend that with a /metrics or /telemetry endpoint in open metrics/telemetry format
https://edgedelta.com/company/blog/opentelemetry-vs-opentracing-vs-openmetri...
so that it can provide a promethus scrape endpoint
the idea was actually originally raised by john garbut when we first dicssed the healthcheck endpoint at the ptg and we effectively said "yes that could be the direction but lets keep the initial scope small"
this work was partly paused because of the eventlet removal work but its something i think we should revisit eventrually perhaps in 2026.2
the reason i bring up eventlet is the current implementation uses the eventlet webserver but i have already consider replacing that with either the stdlib webserver to have 0 depencies or https://github.com/cherrypy/cheroot to align with ironic which already ueses cheroot to host there jsonrpc endpoints if we needed something more performant.
in general how the existing libvirt node exporter work are via directly talking to the libvirt api and then parsing the debug metadata we add to the domain xmls to associate the domain metrics with open stack resocues.
while the domain xml this is strictly speaking a private debug interface that is subject to change or removal and there for not something that should be relied on for external integrations, it is used by ceilomenter collectd and many other tools and we have not make a backward incompatible change since it was introduced so its more or less reasonable for tools like this to use that info in this way.
On 29/09/2025 13:42, Nguyễn Hữu Khôi wrote:
Hello.
I see that this exporter looks like it collects a lot of information such as projectname, username or flavor of metrics but it looks not popular. It could help us build a very useful dashboard.
https://github.com/zhangjianweibj/prometheus-libvirt-exporter
there is also https://github.com/inovex/prometheus-libvirt-exporter
which is a fork of it and https://github.com/kumina/libvirt_exporter which is what was packaged by distos like debian in the past
https://salsa.debian.org/go-team/packages/prometheus-libvirt-exporter
so there have been a couple of competing implementation and no clear winner that im aware of between the 3
I just want to understand some thoughts.
Nguyen Huu Khoi
On 9/29/25 3:17 PM, Sean Mooney wrote:
On 29/09/2025 13:42, Nguyễn Hữu Khôi wrote:
Hello.
I see that this exporter looks like it collects a lot of information such as projectname, username or flavor of metrics but it looks not popular. It could help us build a very useful dashboard.
https://github.com/zhangjianweibj/prometheus-libvirt-exporter
there is also https://github.com/inovex/prometheus-libvirt-exporter
which is a fork of it and https://github.com/kumina/libvirt_exporter which is what was packaged by distos like debian in the past
It's actually a fork of https://github.com/zhangjianweibj/prometheus-libvirt-exporter .
https://salsa.debian.org/go-team/packages/prometheus-libvirt-exporter
so there have been a couple of competing implementation and no clear winner that im aware of between the 3
Yes, indeed it's a little sad there is this this diverse landscape. A de-facto standard exporter on top of the libvirt API should be possible. Only after not seeing such an exporter we actually pushed forward with https://github.com/inovex/prometheus-libvirt-exporter . We did so with the intention to create a robust, flexible and portable exporter for most libvirt needs. Also export of OpenStack-specific labels was implemented, best-practices in regards to metric naming and dealing with labels via info-metrics were followed. We also received some issues and PRs already, some even involving Libvirt maintainers: https://github.com/inovex/prometheus-libvirt-exporter/pull/77 After all we intend to maintain and keep this exporter alive - but please send bugs, send patches! But we also more than happily would donate the exporter to the Prometheus Community. See our issue suggesting this: https://github.com/prometheus-community/community/issues/50 Regards Christian
participants (3)
-
Christian Rohmann
-
Nguyễn Hữu Khôi
-
Sean Mooney