Integrate perflib_exporter into windows_exporter

[jkroepke]

Hi,

writing this issue at this time seems like perflib_exporter has some lacks of maintenance. It includes the maintenance of outdated dependencies and other bugs seen as issue or PR.

The author of the library confirms that he is not longer using windows in production.
leoluk/perflib_exporter#25

I would like to ask if it make sense to merge the perflib_exporter into the windows_exporter to reduce the amount of unmaintained libraries. Since windows_exporter mostly depends on WMI metrics, it could be benefit of this.

[jkroepke]

@breed808 also let me know, if you need some assistance for maintenance. I'm already a member of the prometheus-community group.

[breed808]

I'm open to assisting in the maintenance of perflib_exporter. Dependency management with Dependabot has been simple since it was introduced for windows_exporter.

Bugs would be harder for me to assist with; I don't currently use either exporter in a production/business environment

Do you envision perflib_exporter being added into the windows_exporter project as a separate Go package, or kept in a separate project?

[jkroepke]

Bugs would be harder for me to assist with; I don't currently use either exporter in a production/business environment

At least, we plan to use windows_exporter as part of Grafana Agent for VM monitoring + Kubernetes monitoring (windows nodes).

I also recently add a helm chart for windows_exporter on the prometheus-community/helm-charts repository.

I would see the perflib_exporter as part of the windows_exporter project as a separate Go package.
Alternative we cloud craft a new go package with code fragments from perflib_exporter to create a lightweight version of perflib_exporter that may only works with the windows_exporter and optimized it. I would personally not support use-cases outside windows_exporter for the perflib_exporter package.

[breed808]

Sound good. I believe the MIT license applied to the Perflib exporter would allow us to copy the code into the windows_exporter project, so long as we include the copyright and permission notice.

I'd like to avoid a situation where both the perflib_exporter and the windows_exporter projects maintain separate copies of the perflib_exporter code.
@leoluk what are your thoughts on the potential migration discussed here?

[jkroepke]

An alternative would be the package from datadog agent, which is Apache 2.0 licenced.

/~https://github.com/DataDog/datadog-agent/tree/main/pkg/util/winutil/pdhutil

[jkroepke]

I open #1241 as example where I copy only a essential subset of the code which is required for windows_export. I also remove the HelpText queries, since they are not manadory for windows_exporter.

[leoluk]

Very much in favor of this - neither me nor my company have any Windows Server environments. The library is much better off being maintained actively as part of windows_exporter, I'm glad to see it is still useful!

I archived /~https://github.com/leoluk/perflib_exporter and pointed users to windows_exporter instead.