Instead of installing an agent has querying the hosts via WinRM/CIM been considered.

[SynFinAck]

From a support standpoint, one of the biggest issues we have with reporting software is the agent. Some do perfectly well and have no issues because they clean up after themselves and their code is solid for the most part. However, there are those agents that take way too much CPU RAM or Disk I/O to accomplish the task. Making the support engineer pull out even more hair..

My suggestion would be to allow another method of collecting data. In powershell and even .NET there is a push to adopt a more standard way of remote querying standard information across servers and appliances the Result was the Common Information Model (CIM) Microsoft is migrating away from WMI because it's old, deprecated, and not very secure. Powershell 7 doesn't even support WMI anymore. So while it exists now it is definitely not going to be here in the future.. CIM seems to be the way to go or some Combination of CIM/OIM

By default most WMI classes have been ported or translated from WMI to CIM (though not all). However via CIM you could make a local wmi query to the class that wasn't created (if necessary)

Even better much of the Data that is returned from CIM is formatted much better.. No need to translate datetime's or anything. From a powershell standpoint CIM is a very secure way to pull information from a server.

Most calls to a Win32_ can simply be queried using CIM instead. Here is an idea of the classes that are available

PS C:\> $classes = (Get-CimClass|Where-Object {$_.CimClassName.StartsWith('Win32')}).CimClassName
>> $classes |Select-Object -First 5
Win32_DeviceChangeEvent
Win32_SystemConfigurationChangeEvent
Win32_VolumeChangeEvent
Win32_SystemTrace
Win32_ProcessTrace

Also, this will save you the need to do a lot of string parsing, since Powershell will handle all of the serializing for you.

[breed808]

Apologies for the delayed response to this, I've been away from the project for a few weeks and this question has required some time to consider an answer.

I don't think remote queries would necessarily be a bad idea, but there's a few items to consider:

1. windows_exporter is currently designed with local queries as the sole method of metric collection. While implementation of remote queries is possible, it would require a not-insignificant rewrite of the exporter.

2. Much of your comment addresses the deprecation of WMI as a metric source. This exporter has already moved away from WMI where possible, replacing WMI queries with other sources (Perflib, native APIs, etc).

3. Each of our existing metrics sources would need to support remote queries. For example, if our API calls can only be run locally, an agent would still be required.

I don't mean to throw up roadblocks in the form of these points, but further discussion and identification of alternatives would be required before working on a remote implementation. Perhaps implementing a separate exporter for remote calls is an option? Or addressing existing issues with the agent?

[github-actions[bot]]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.