feat: add win_wmi input plugin

[julesroussel3]

Required for all PRs:

• [x] Updated associated README.md.
• [x] Wrote appropriate unit tests.
• [x] Pull request title or commits are in conventional commit format

resolves https://github.com/influxdata/telegraf/issues/1857

This PR creates a plugin to obtain metrics from Windows Management Instrumentation (WMI).

This plugin queries Windows Management Instrumentation (WMI) classes on Windows operating systems. An administrator can query and filter for specific properties in any WMI namespace and class. While some system information is already exposed through regular plugins like [[inputs.cpu]] and [[inputs.mem]], this plugin provides ultimate control and flexibility, allowing an administrator to query classes not exposed through other plugins.

Full details of the plugin are available in the README.

[julesroussel3]

Why do the linux-based tests complain with build constraints exclude all Go files in...? Is there a directive missing in some configuration file? (This plugin is Windows-only.)

[powersj]

Hi! Thanks for this PR!

Why do the linux-based tests complain with build constraints exclude all Go files in...? Is there a directive missing in some configuration file? (This plugin is Windows-only.)

The build constraint as-is will only build for Windows, yet the module is always imported with all.go.

To get around this we typically create a win_wmi_notwindows.go file that should look like this. This creates a no-op for the non-windows OSes. I believe adding that should get you going.

[telegraf-tiger[bot]]

Download PR build artifacts for linux_amd64.tar.gz, darwin_amd64.tar.gz, and windows_amd64.zip. Downloads for additional architectures and packages are available below.

:thumbsup: This pull request doesn't change the Telegraf binary size

:package: Click here to get additional PR build artifacts

Artifact URLs

DEB	RPM	TAR GZ	ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_i386.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz
		static_linux_amd64.tar.gz

[julesroussel3]

That worked! Thank you. All tests are passing now.

[reimda]

Hi @julesroussel3, thanks for looking into this.

Does your new plugin gather different data than telegraf's existing inputs/win_perf_counters? That plugin uses Windows's PDH API which seems to grab the same counters as WMI.

I ran into a few mentions that say PDH is a lower level API so it performs better than WMI:

• https://github.com/netdata/netdata/issues/92#issuecomment-619867546
• https://github.com/oshi/oshi/issues/505

[julesroussel3]

Hi @reimda ! Thank you for the question. I’m happy to clarify.

Does your new plugin gather different data than telegraf's existing inputs/win_perf_counters?

It is true that some performance counters are exposed through WMI, and it is true that accessing performance counters directly with the win_perf_counters plugin is optimal. However, WMI provides access to lots of other information which is not available through performance counters.

Configuration and other metadata can be gathered using WMI. For example:

• Using the Win32_ComputerSystem class, the TotalPhysicalMemory, NumberOfProcessors, and NumberOfLogicalProcessors properties can be gathered as metrics, and metadata such as Domain, Manufacturer, and Model can be included as tags. This provides the ability to create rich dashboards which provide administrators a single-pane-of-glass, showing not only resource utilization, but a complete hardware topology.
• Similarly, Win32_PhysicalMemory can be used to inventory the physical memory devices in a computer and their respective sizes.
• Similar to the previous example, properties from the Win32_OperatingSystem class can be used to tag metrics with the version and edition of Windows, allowing the creation of a dashboard which shows how many computers in the environment are running Windows 10 Enterprise versus Professional, Server Standard versus Server DataCenter edition, Server Core versus Server GUI, etc.
• Using classes in the root\mscluster namespace, the name of the cluster to which a node is joined can be gathered, which allows a dashboard to summarize memory and CPU across multiple nodes in a cluster.
• The MBAM_Volume class can be used to summarize the state of disk encryption in a Windows environment.
• The Root\microsoft\sqlserver\ComputerManagement1* namespaces are useful for inventorying the editions and versions of SQL Server installed in a Windows environment.
• The Speed property of MSFT_NetAdapter can be used to determine the negotiated speed and MTU of a network interface.

Furthermore, WMI provides ultimate control. Some of the basic input plug-ins (e.g. cpu, mem) provide abstraction layers to WMI-based data, but do not provide the ultimate flexibility and control that some administrators desire. This plug-in enables an administrator to granularly select each property of a class which they desire to include in their metrics. It's possible that most administrators will choose to use the stock plugins and win_perf_counters, but the lack of a flexible WMI plug-in was a major roadblock in the enterprise environment I support, which is how this plug-in came to be.

[cemremengu]

@julesroussel3 AFAIK (but not sure) you can gather data remotely with WMI so if this plugin also provides that functionality, it will definitely have an edge over existing plugins.

[julesroussel3]

@julesroussel3 AFAIK (but not sure) you can gather data remotely with WMI so if this plugin also provides that functionality, it will definitely have an edge over existing plugins.

@cemremengu That is a good idea for a feature enhancement and is certainly possible. Similar to https://github.com/influxdata/telegraf/pull/11090, for that to work, either the computer object or service account running telegraf would need to have administrative permissions on the remote machine. Unfortunately, when this plug-in was created, remote support wasn't in scope for my requirements.

[telegraf-tiger[bot]]

Hello! I am closing this issue due to inactivity. I hope you were able to resolve your problem, if not please try posting this question in our Community Slack or Community Page. Thank you!

[rismoney]

any way to re-open and get this capability merged?

[julesroussel3]

Apologies, but outside obligations have prevented me from follow-up on the PR review, but this version has been successfully running in a large corporate environment for over a year without issue. If anyone else wants to follow-up with the review, that would be great.

[Hipska]

@julesroussel3 feel free to implement the requested changes and reply to the questions, we will then reopen and review.

[telegraf-tiger[bot]]

Hello! I am closing this issue due to inactivity. I hope you were able to resolve your problem, if not please try posting this question in our Community Slack or Community Page. Thank you!

[rismoney]

inactivity? really?

[rismoney]

Can this get reopened/merged?

[powersj]

If @julesroussel3 has interest in continue working on it sure

[julesroussel3]

I am actively working toward addressing review feedback.

[julesroussel3]

I have clearly botched a rebase while resolving merge conflicts. Any ideas on how to salvage this PR?

[rismoney]

I would make a copy of your git dir (master branch to a diff folder) temporarily.

then what i would do is git remote -v assuming origin is your fork [ https://github.com/julesroussel3/telegraf-win_wmi.git] and upstream is [ https://github.com/influxdata/telegraf.git]

and assuming your changes on your master branch are what you really want in terms of resolved conflict:

git reset --hard origin/master
git rebase upstream/master on each "stop" copy the file you really want back into the vcs [essentially resolve the merge conflict from the copied dir- i'm guessing you already did on your fork] git status will tell you the conflicting file: ie:

CONFLICT (content): Merge conflict in plugins/inputs/win_wmi/win_wmi_test.go

git rebase --continue repeat for all conflicts across your commits - maybe [6-7 times] git push -f origin # this should update your fork with the repaired changes and thereby this PR.

[julesroussel3]

@rismoney Awesome, thanks! Thank worked.

[julesroussel3]

At this point, all conversations are marked resolved and all review points have been addressed. Let me know if any other changes are suggested. Otherwise, it would be great if we could get this merged.

[julesroussel3]

Amazing! Thank you for the thorough review.

[cemremengu]

I have been following this PR from the shadows for a long time, just wanted to thank everyone for the amazing effort!

[rismoney]

merge?

[powersj]

@julesroussel3 any update on this PR? Thanks!

[julesroussel3]

Will try to wrap up by EOW

[julesroussel3]

I believe all of the recent comments have been addressed. The readme linter is complaining, but only about plugin READMEs unrelated to the PR. How do I address that?

[powersj]

I believe all of the recent comments have been addressed.

Thanks I will take a look tomorrow

The readme linter is complaining, but only about plugin READMEs unrelated to the PR. How do I address that?

A rebase on master should have a change that only tests the READMEs that are touched. Otherwise, we can ignore.

[powersj]

Thanks for seeing this through. I'll let Sven take one final look at this.

[srebhan]

@julesroussel3 any updates here? I really would love to see this PR merged...

[julesroussel3]

Hi folks! I made another pass at review comments. Let me know if this is satisfactory for merge.

[julesroussel3]

I've addressed the latest feedback. Let me know what's next.