Calculate memory.working_set.limit.pct for pod and container metricset

[MichaelKatsoulis]

What does this PR do?

This PR calculates and adds memory.working_set.limit.pct for kubernetes pod metricset and memory.workingset.limit.pct for kubernetes container metricset.
The value is calculated as the division of workingset_bytes/memory_limit.

Why is it important?

The fields kubernetes.container.memory.usage.limit.pct and kubernetes.container.memory.usage.node.pct are useful fields that show the total allocated memory for the container/pod divided with either the limit set by user or the node's total memory.

But the total allocated memory also includes buffer and cache bytes which are not actively used and so they are available by other processes. It is useful to provide the workingset_bytes of the container/pod divided with the container's limit as a value that shows the actual usage percentage of a container/pod.

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.

How to test this PR locally

Run metricbeat on Kubernetes with container or pod metricset enabled and watch the values being populated.

Related issues

• Closes https://github.com/elastic/enhancements/issues/13999
• Closes Metricbeat 7.12.1 kubernetes.container.memory.usage.limit.pct is calculated incorrectly #25657

Screenshots

[mergify]

This pull request does not have a backport label. Could you fix it @MichaelKatsoulis? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

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

NOTE: backport-skip has been added to this pull request.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2021-12-21T09:35:35.242+0000

• Duration: 88 min 50 sec

• Commit: 9a10a9d

Test stats 🧪

Test	Results
Failed	0
Passed	9356
Skipped	2421
Total	11777

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[ChrsMark]

Lgtm. I see that we have an "inconsistency" in the naming and it is workinset in container metricset while it is working_set in pod metricset. In any case we cannot do much here without introducing a breaking change 😞 .

@MichaelKatsoulis do you also plan to add it in the package too?

Also @MichaelKatsoulis what do you think about closing #25657 too after this one is merged?

[MichaelKatsoulis]

Lgtm. I see that we have an "inconsistency" in the naming and it is workinset in container metricset while it is working_set in pod metricset. In any case we cannot do much here without introducing a breaking change 😞 .

:(

@MichaelKatsoulis do you also plan to add it in the package too?

I will open a PR for this as well.

Also @MichaelKatsoulis what do you think about closing #25657 too after this one is merged?

Yes I agree.