-
Notifications
You must be signed in to change notification settings - Fork 177
[8.19] (backport #8737) Move beat receiver component logic to the otel manager #8990
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* Add initial otel component manager implementation * Update coordinator to use the new manager * Move logging to the coordinator * Add more tests * Don't use a real otel manager in tests * Move the logic to the otel manager * Ignore the test collector binary * Rename some dangling attributes back * Comment out temporarily unused code * Restore manager e2e test * Fix import order * Write synthetic status updates directly into the external channel * Update collector config and components in one call * Rename the mutex in the otel manager * Discard intermediate statuses * Emit component updates in a single batch * Undo timeout increase in test (cherry picked from commit 503421f) # Conflicts: # internal/pkg/agent/application/coordinator/coordinator.go # internal/pkg/agent/application/coordinator/coordinator_unit_test.go
Cherry-pick of 503421f has failed:
To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
|
NOTE: This is an alternative implementation of #8529, which adds the new functionality to the existing Otel manager, instead of creating a new object for it.
What does this PR do?
Move beat receiver component logic to the otel manager.
This logic consists of two tasks conceptually:
Up until now, the logic for these was haphazardly spread across the agent coordinator. This PR moves all of it into the OtelManager, which can now run both raw otel collector configurations and agent components in a single otel collector instance.
The OtelManager now encapsulates all the logic involved in interfacing between the agent coordinator and the otel collector. In the near future, it will also take on additional responsibilities, like generating diagnostics for components it runs.
The only new logic this PR introduces lives in the new manager's main loop, and has to do with how updates and configurations are moved around. The rest is either existing logic moved to a new location, and new tests for that old logic.
Why is it important?
Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files[ ] I have added an entry in./changelog/fragments
using the changelog tool[ ] I have added an integration test or an E2E testRelated issues
This is an automatic backport of pull request #8737 done by [Mergify](https://mergify.com).