I'd like to propose / offer moving https://github.com/inovex/prometheus-libvirt-exporter to prometheus-community.
Libvirt is likely the most widely used VM hypervisor on Linux.
Be it to run some VMs on a single server or managed by orchestrators the likes of OpenStack (Nova), Proxmox or others.
There are/were other exporters, namely Tinkoff's which was in turn based on Kumina's. Development of all of them has stalled unfortunately, even though https://github.com/prometheus/prometheus/wiki/Default-port-allocations still links to them and e.g. Debian still creates packages (https://packages.debian.org/sid/prometheus-libvirt-exporter).
Apart from the lack of recent development activity, the most important difference is the used library to communicate with libvirt. While @kumina and @Tinkoff use https://github.com/libvirt/libvirt-go, which is a C-library, the proposed prometheus-libvirt-exporter (https://github.com/inovex/prometheus-libvirt-exporter) uses go-libvirt (https://github.com/digitalocean/go-libvirt) native Golang lib (auto-)created by DigitalOcean. This allows the exporter to be much more portable between libvirt versions and distros. There was even some discussion about refactoring (Tinkoff/libvirt-exporter#25), but those efforts never materialised. Additionally the libvirt-go library is now deprecated and has itself been replaced by https://github.com/libvirt/libvirt-go-module.
At @inovex we have been using the prometheus-libvirt-exporter, initially written by @zhangjianweibj for quite a while for our OpenStack environment. But since June 2021 there have been no more commits or releases. And while the exporter already does have support to extract OpenStack Nova metadata from libvirt domain, some changes that were merged (e.g. exporting OpenStack instance flavorName - inovex/prometheus-libvirt-exporter@28296e3) never made it to a binary release.
There were some forks, the most recent / active likely being https://github.com/Ferlab-Ste-Justine/prometheus-libvirt-exporter/ who started to refactor some things. Unfortunately but there were no efforts to update and maintain the exporter outside of individual installations or to become the new default source for it.
We believe having a common and well maintained libvirt-exporter makes sense and went ahead to clean and modernize the existing code:
- Use the official Prometheus exporter toolkit and built-in landing page
- Update all modules to their latest versions
- Update logging to use go-kit
- Update to Go 1.21
- Add CI for build, linting
- Add Dependabot config
- Add releases via goreleaser
- Export arch and machine attributes via info metrics
We also cleaned up the exported metrics, causing breaking changes in https://github.com/inovex/prometheus-libvirt-exporter/releases/tag/v1.4.0):
- Change the label names to follow best practices and be snake-cased (similar to Ferlab-Ste-Justine)
- Move all informational labels to dedicated info metrics to avoid an ever growing list of labels, with more domain metadata being exported.
- Clean up the metric naming (in regards to the subsystems)
All the changes we did are listed here: inovex/prometheus-libvirt-exporter@start_of_fork...v1.4.0
We hope you agree with our reasoning to start yet another fork and that someone from the prometheus-community sponsors this move. Certainly we will continue to contribute to this exporter also under the prometheus-community umbrella.
I'd like to propose / offer moving https://github.com/inovex/prometheus-libvirt-exporter to prometheus-community.
Libvirt is likely the most widely used VM hypervisor on Linux.
Be it to run some VMs on a single server or managed by orchestrators the likes of OpenStack (Nova), Proxmox or others.
There are/were other exporters, namely Tinkoff's which was in turn based on Kumina's. Development of all of them has stalled unfortunately, even though https://github.com/prometheus/prometheus/wiki/Default-port-allocations still links to them and e.g. Debian still creates packages (https://packages.debian.org/sid/prometheus-libvirt-exporter).
Apart from the lack of recent development activity, the most important difference is the used library to communicate with libvirt. While @kumina and @Tinkoff use https://github.com/libvirt/libvirt-go, which is a C-library, the proposed prometheus-libvirt-exporter (https://github.com/inovex/prometheus-libvirt-exporter) uses go-libvirt (https://github.com/digitalocean/go-libvirt) native Golang lib (auto-)created by DigitalOcean. This allows the exporter to be much more portable between libvirt versions and distros. There was even some discussion about refactoring (Tinkoff/libvirt-exporter#25), but those efforts never materialised. Additionally the libvirt-go library is now deprecated and has itself been replaced by https://github.com/libvirt/libvirt-go-module.
At @inovex we have been using the prometheus-libvirt-exporter, initially written by @zhangjianweibj for quite a while for our OpenStack environment. But since June 2021 there have been no more commits or releases. And while the exporter already does have support to extract OpenStack Nova metadata from libvirt domain, some changes that were merged (e.g. exporting OpenStack instance flavorName - inovex/prometheus-libvirt-exporter@28296e3) never made it to a binary release.
There were some forks, the most recent / active likely being https://github.com/Ferlab-Ste-Justine/prometheus-libvirt-exporter/ who started to refactor some things. Unfortunately but there were no efforts to update and maintain the exporter outside of individual installations or to become the new default source for it.
We believe having a common and well maintained libvirt-exporter makes sense and went ahead to clean and modernize the existing code:
We also cleaned up the exported metrics, causing breaking changes in https://github.com/inovex/prometheus-libvirt-exporter/releases/tag/v1.4.0):
All the changes we did are listed here: inovex/prometheus-libvirt-exporter@start_of_fork...v1.4.0
We hope you agree with our reasoning to start yet another fork and that someone from the prometheus-community sponsors this move. Certainly we will continue to contribute to this exporter also under the prometheus-community umbrella.