[Metricbeat] Windows Module add wmi metricset

[herrBez]

Proposed commit message

[Metricbeat][Windows] Add experimental wmi metricset

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Disruptive User Impact

This PR does not have impact to existing use-cases

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Move WMI metric capture from Logstash to metric beats #29072
• Collect SMART data with metricbeat #8614
• [External] [Feature] Metricbeat Support/Migration eskibars/wmibeat#4

Use cases

As a windows user I want to leverage WMI (and in particular WQL, SQL for WMI) to extract detailed system information and metrics.

Screenshots

Logs

[botelastic]

This pull request doesn't have a Team:<team> label.

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @herrBez? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit

[mergify]

backport-8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label and remove the backport-8.x label.

[strawgate]

One of the challenges with running arbitrary WMI queries is that WMI queries can be extremely slow and certain WMI queries can actually result in changes to the system -- have we considered whether or how we might provide timeout functionality for running WMI queries?

[herrBez]

Hi, good points! Thank you for the comment :).

One of the challenges with running arbitrary WMI queries is that WMI queries can be extremely slow and certain WMI queries can actually result in changes to the system -- have we considered whether or how we might provide timeout functionality for running WMI queries?

About the timing issues: I don't see a parameter in the library to stop a query after X seconds (I would need to understand if the underlying library/WMI have a similar mechanism). Maybe by leveraging an ExecAsyncQuery (there is no "exposed" method for this) we can stop after a timeout. Similarly to what is done here: https://github.com/microsoft/wmi/blob/v0.25.0/pkg/wmiinstance/WmiEventSink_test.go#L66. Not sure it's actually stopping the underlying query after some time.

About the "can actually result in changes to the system": with the current implementation we can only build queries of type SELECT * FROM Class WHERE .... This should prevent changes to the system, right?

[strawgate]

A WMI query does whatever the underlying WMI provider decides it should do. This means a developer can create a WMI provider which upon a Select * from MyCustomProvider, performs a change to the system.

A common bad actor example is the win32_product provider. When queried, the win32_product provider verifies the integrity of all installed MSI packages on the system. For any products where integrity cannot be verified it performs a repair install of the MSI.

You have to read quite a bit of documentation to land on this fact:

The Win32_Product class enables you to enumerate the software installed on a computer, provided the software was installed by using the Windows Installer.

...

Warning  Win32_Product is not query optimized. Queries such as "select * from Win32_Product where (name like 'Sniffer%')" require WMI to use the MSI provider to enumerate all of the installed products and then parse the full list sequentially to handle the “where” clause. This process also initiates a consistency check of packages installed, verifying and repairing the install. With an account with only user privileges, as the user account may not have access to quite a few locations, may cause delay in application launch and an event 11708 stating an installation failure. For more information, see [KB Article 794524](https://support.microsoft.com/kb/974524).

This means a simple select name from Win32_Product where (name like 'Google Chrome%') can take upwards of an hour to complete and can result in significant changes to the underlying system.