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