[META][metricbeat] - Consider using performance counters for windows system metricsets

[VihasMakwana]

While working on #40926, I observed that we can rely on performance counter for many of our system modules. This is a placeholder issue to identify all such modules that can use performance counters and work on a PoC, if we agree on the use case.

Why we should consider performance counters?

• For windows, we rely on APIs such as NtQuerySystemInformation and it has a warning:

  NtQuerySystemInformation may be altered or unavailable in future versions of Windows. Applications should use the alternate functions listed in this topic

  • It might be worth it to consider alternatives
• Currently, for modules such as system.process, there are multiple API calls involved:
  • We first call EnumProcesses to get a list of process ids.
  • Then we loop through all of them call OpenProcess (multiple times per pid).
  • We again have to call NtQuerySystemInformation to get memory/process information.
• Using performance counter would simplify this by a lot.
• While working on unprivileged mode for windows, we observed that system.diskio module wasn't working. There is no workaround for this and it is noted as a "limitation".
  • Performance counters can help resolve this issue. I did some quick unit testing and verified it.

cc: @cmacknz @flexitrev @pierrehilbert

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[cmacknz]

+1 to a PoC. I do not know if there is any historical reason for why did not use performance counters by default. I would guess we ended up here by following the Unix pattern of making syscalls to get things when translating the metricsets to Windows.