feat: New input plugin for libvirt #11814
Conversation
telegraf-tiger
bot
added
the
feat
p-zak
added
new plugin
plugin/input
reimda
added
the
ready for final review
|
Hi @p-zak, this looks pretty good. Thanks! I have a question about future metric format changes. I assume libvirt's data model doesn't change very often, but if it does, how will it affect the metric format of this plugin? I don't see a hard coded mapping in the code that is like the table in the description so I assume there's a pattern mapping and a change in libvirt would change the metric format. I would like to avoid the situation where a user starts using using telegraf + inputs.libvirt with one version of libvirt, then upgrades libvirt to a version that removes or renames a field. Then telegraf produces metrics of a slightly different format which depending on the outputs being used can cause write errors or query errors downstream. (see the format changes doc) |
|
@reimda I believe that indeed libvirt's data model doesn't change very often (probably that's why most of metrics are in the And that's why there is mapping from source metric (from libvirt) to metrics which are exposed by this plugin. You can find it in I hope that this is the approach you want to achieve? :) |
…for-libvirt # Conflicts: # go.mod
I like how the current mapping code makes the names uniform. The only potential problem I see is that since it is pattern based, if the data from libvirt changes, it will change the metrics telegraf produces. If someone stores the metrics in a database and builds an application or dashboard that queries the database, then when metrics changes it has the potential to break queries and break the downstream application. This is a problem that some other telegraf plugins have. We don't need to prevent it from happening here. I am ok with relying on libvirt's data model not changing often, but maybe we should put something in the docs that lets users know they need to expect changes in the metric format depending on which version of libvirt they use. What do you think? Could you add a note in readme.md? |
plugins/inputs/libvirt/README.md
Outdated
| Below the table containing a list of all metrics | ||
| supported by the libvirt plugin is presented. |
There was a problem hiding this comment.
This might be a good place to put in a note that the metric format could change in the future depending on what statistics libvirt reports.
| Below the table containing a list of all metrics | |
| supported by the libvirt plugin is presented. | |
| See the table below for a list of metrics produced by the plugin. | |
| The exact metric format depends on the statistics libvirt reports, which may vary depending on the version of libvirt on your system. |
There was a problem hiding this comment.
@reimda
Right, changed.
|
Download PR build artifacts for linux_amd64.tar.gz, darwin_amd64.tar.gz, and windows_amd64.zip. 📦 Click here to get additional PR build artifactsArtifact URLs |
|
Thanks Paweł! |
resolves #65
resolves #70
resolves #690
This is a continuation of work being done in following PRs:
cgo)virshbinary and parsed its output)cgo)cgo-freebut immature at that time: https://github.com/digitalocean/go-libvirt which was used to generate XML with metrics which were parsed by code from that PR)This PR uses https://github.com/digitalocean/go-libvirt which became very mature project. It is still
cgo-freeand provides a pure Go interface for interacting with libvirt.The plugin exposes all possible domain statistics which can be gathered from the newest versions of libvirt (>= 7.x.y but it will do its best to expose as much as possible from previous versions).
List of exposed metrics:
And additional statistics: