Update elastic-agent-system-metrics to v0.8.1

[belimawr]

Proposed commit message

Update elastic-agent-system-metrics to v0.8.1 to enable collecting
memory and CPU metrics from privileged process on Windows.

Fix python test to ensure the cmdLine is found in at least one
process instead of them all because we cannot fetch the cmdLine from
privileged process on Windows.

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.

Author's Checklist

• Update elastic-agent-system-metrics to the fixed version (PR: Fix CmdLine generation and caching elastic-agent-system-metrics#107)

How to test this PR locally

1. Install Elastic-Agent with Elastic-Defend integration enabled
2. Run Metricbeat (from this PR) as administrator with process metrics enabled
3. Ensure events from elastic-endpoint.exe contain CPU and memory metrics.

Related issues

• Closes Metricbeat fails to get information for protected processes under Windows #17314

## Use cases

Screenshots

## Logs

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @belimawr? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[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: 2023-11-15T09:18:15.946+0000

• Duration: 178 min 26 sec

Test stats 🧪

Test	Results
Failed	0
Passed	28172
Skipped	1882
Total	30054

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the 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!)

[belimawr]

@fearful-symmetry, could you do a sanity check on this last change? I believe it is ok to change, but I'd like a second opinion before merging.

[fearful-symmetry]

It looks like the assertTrue() line was just moved out of the loop block to check for the cmdline globally? That seems fine, but wouldn't it require the last event to set found_cmdline |= "cmdline" in process in order to pass? Maybe a counter that needs to be > 1 would work?

[belimawr]

It looks like the assertTrue() line was just moved out of the loop block to check for the cmdline globally?

Yes, that was my intent because it already does an OR operation on itself. Being honest I was very confused by the assertTrue() being inside the loop and having found_cmdline |= "cmdline" in process.

beats/metricbeat/module/system/test_system.py

Lines 421 to 427 in bab5bb4

	found_cmdline = False
	for evt in output:
	process = evt["system"]["process"]
	# Not all process will have 'cmdline' due to permission issues,
	# especially on Windows. Therefore we ensure at least some of
	# them will have it.
	found_cmdline |= "cmdline" in process

but wouldn't it require the last event to set found_cmdline |= "cmdline" in process in order to pass?

That's an OR operator, so as long as "cmdline" in process returns True at least once, then found_cmdline will always be True.