feat: add win_wmi input plugin

[julesroussel3]

Required for all PRs:

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

resolves #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.

[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:

• Windows Support netdata/netdata#92 (comment)
• Replace WMI with PDH oshi/oshi#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 #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.

[reimda]

I took a quick look at the code and had some thoughts/questions before getting into a close review.

[telegraf-tiger]

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?

[Hipska]

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

[telegraf-tiger]

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.

[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]

Thanks for the nice plugin @julesroussel3! I do have some smaller comments though. Can you please take a look!?

[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.

[Hipska]

All good, just a minor improvement.

[srebhan]

@julesroussel3 I think we are almost there. I have three minor comments for the test and I agree with @Hipska about the example. Can you please fix those so we get that nice plugin in?

[julesroussel3]

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

[telegraf-tiger]

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.

☺️ This pull request doesn't significantly change the Telegraf binary size (less than 1%)

📦 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_arm64.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz	windows_i386.zip
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

[srebhan]

Looks good to me. Thanks for your great work and for keeping this going @julesroussel3!

@powersj as we have quite some changes, please take another look and merge if you are fine with the changes.