Allow metricbeat to dynamically identify the number of cores instead of using runtime.NumCPU()

[marc-gr]

Describe the enhancement:

Currently metricbeat uses runtime.NumCPU() to grab the number of cores: https://github.com/elastic/beats/blob/master/metricbeat/module/system/cpu/data.go#L100

This has some limitations, since there are a bunch of situations where the reported number does not match the actual number of cores:

• You modified the number of cores without restarting (either because you are using an hypervisor that allows hot addition or you enabled them at runtime)
• You have some offline or disabled cores
• You run the process with a more restrictive affinity (using taskset)
• or you have isolated CPUs in the system

Describe a specific use case for the enhancement or feature:

If any of the above situations happen, we still want to report the real number of cores. A similar change was done for auditbeat here

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[fearful-symmetry]

Agreed, we need to do this differently, the sooner the better. Both lscpu and auditbeat pull from /sys/devices/system/cpu on linux, which is the way to go. Not sure about other platforms.

[botelastic]

Hi!
We just realized that we haven't looked into this issue in a while. We're sorry!

We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1.
Thank you for your contribution!

[fearful-symmetry]

Closing, as we now no longer use the runtime libs for CPU info, and we're now actually looking at os-reported CPU config.