Ingest collector internal telemetry via in-process hooks

[faec]

What does this PR do?

Add a custom telemetry factory and receiver to the OTel collector build to support backwards-compatible ingestion of Collector metrics as ECS metrics that can be viewed in existing Agent dashboards (see #10220 for context on the prometheus-based approach this replaces).

Checklist

• I have read and understood the pull request guidelines of this project.
• 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/fragments using the changelog tool
• I have added an integration test or an E2E test

How to test this PR locally

Running Agent with metrics monitoring enabled and any components using the OTel runtime, you should see collector metric data appear in the metrics.elastic_agent* datastreams.

Related issues

• Closes [beats receivers] Replace OTel collector internal telemetry monitoring with a scalable approach #10220

[elasticmachine]

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

[mergify]

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

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b telemetry-monitoring upstream/telemetry-monitoring
git merge upstream/main
git push upstream telemetry-monitoring

[cmacknz]

In the test failure, the test is logging the wrong error variable. It's logging the one from _, err = fixture.InstallWithoutEnroll(ctx, &installOpts) which is nil and not the one causing the Eventually to fail to succeed.

elastic-agent/testing/integration/ess/restrict_upgrade_deb_test.go

Lines 49 to 58 in c06e8ca

	_, err = fixture.InstallWithoutEnroll(ctx, &installOpts)
	require.NoError(t, err)
	require.Eventuallyf(t, func() bool {
	err = fixture.IsHealthy(ctx)
	return err == nil
	}, 5*time.Minute, time.Second,
	"Elastic-Agent did not report healthy. Agent status error: \"%v\"",
	err,
	)

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: e2acc27

Failed CI Steps

• x86_64:sudo: deb
• arm:sudo: default
• x86_64:sudo: fleet - platform-ingest-elastic-agent-debian-11-1765760468

History

• 💔 Build #32509 failed 8f9a016
• 💔 Build #32507 failed 153d972
• 💔 Build #32476 failed 74b0fa9
• 💔 Build #32420 failed 31e5677
• 💔 Build #32386 failed af2ad82

cc @faec