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-process-healthchecks.html

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-openmetrics

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