Beats: Improve collection of process memory metrics in Windows

[jsoriano]

Currently only Private Bytes and Working Set Size is being collected for Windows processes, it can be also interesting to collect Virtual Bytes. Also system.process.memory.share is not being calculated, remaining always as 0.
For more context about this look at this thread: https://discuss.elastic.co/t/virtual-bytes-wrong-counter-in-metricbeat

Thinking on multi-platform support we might want to check what would be an equivalent of these metrics in Windows and Linux.

[martinscholz83]

Here is a good explanation of the differences and why it's a good idea to collect the virtual bytes.

[lachlann562]

We are looking to use metric beat and virtual bytes is a critical metric for our applications. When our system becomes unstable its always due to virtual bytes and not working set/private bytes. Is there any timeline to schedule this enhancement?

[narph]

@jsoriano , indeed the system.process.memory field descriptions do not reflect the actual memory values we retrieve for windows os's.
A PR is opened to fix this https://github.com/elastic/beats/pull/17268.

Regarding adding virtual bytes in the metricset:
system.process.memory.share is not mapped at the moment, in case we want to add virtual bytes or other memory metrics for Windows we might want to use a more Windows appropriate naming.

We are currently using GetProcessMemoryInfo and GlobalMemoryStatusEx win32 apis to retrieve the mapped values, unfortunately they do not contain the virtual bytes, (GlobalMemoryStatusEx will do but only for the current process running).
VirtualQueryEx api could return this value but to get to the total virtual bytes count we need to iterate over all the addressable pages which is not performant enough.
I am afraid that at the moment the only option is to use the windows perfmon metricset and retrieve the virtual bytes using the \Process(*)\Virtual Bytes counter path.

[jsoriano]

Now that @fearful-symmetry has started to work on OS-specific system modules (#17267), it would make more sense to use specific windows metricsets to get these metrics. Maybe we could have a windows.memory metricset that uses perfmon to collect them.