-
Notifications
You must be signed in to change notification settings - Fork 5k
[beatreceiver] - add manager for otel mode #46539
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
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
1cce938
to
dfd1b4f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also address the lint warnings?
I was reading up more the linked issues and I believe the cleanest solution for this problem is to have a package like What do you think? |
Yes that, and we would also need a manager because in future we will implement the otel diagnostics extension. |
@cmacknz I've added a test for checking the |
I created elastic/elastic-agent#10069 to track this so we don't forget about it. TBH I think I'm more on the side of having Following the chain of status reporters is quite complex and I was a reviewer on all the original PRs so I think we need some explanation on the new manager about where to look. |
@belimawr you have changes requested that have been addressed here |
* iniital commit * cleanupt * license * comments * comments * comments * rename * comments and unit test case * go.mod * lint and notice * use existing flag * go.sum * log input test and UnderAgent test * test disabled * stub and cleanup * comment * fixes and comments (cherry picked from commit 4ba000d) # Conflicts: # NOTICE.txt # go.mod # libbeat/management/management.go # x-pack/libbeat/cmd/instance/beat.go
Let's backport to 8.19 to keep the code structure the same |
* iniital commit * cleanupt * license * comments * comments * comments * rename * comments and unit test case * go.mod * lint and notice * use existing flag * go.sum * log input test and UnderAgent test * test disabled * stub and cleanup * comment * fixes and comments (cherry picked from commit 4ba000d) # Conflicts: # NOTICE.txt # go.mod
…46747) * [beatreceiver] - add manager for otel mode (#46539) * iniital commit * cleanupt * license * comments * comments * comments * rename * comments and unit test case * go.mod * lint and notice * use existing flag * go.sum * log input test and UnderAgent test * test disabled * stub and cleanup * comment * fixes and comments (cherry picked from commit 4ba000d) # Conflicts: # NOTICE.txt # go.mod * go.mod and notice * beat_test --------- Co-authored-by: Vihas Makwana <[email protected]> Co-authored-by: Vihas <[email protected]>
…6739) * [beatreceiver] - add manager for otel mode (#46539) * iniital commit * cleanupt * license * comments * comments * comments * rename * comments and unit test case * go.mod * lint and notice * use existing flag * go.sum * log input test and UnderAgent test * test disabled * stub and cleanup * comment * fixes and comments (cherry picked from commit 4ba000d) # Conflicts: # NOTICE.txt # go.mod # libbeat/management/management.go # x-pack/libbeat/cmd/instance/beat.go * merge conflicts * conflicts --------- Co-authored-by: Vihas Makwana <[email protected]> Co-authored-by: Vihas <[email protected]>
Proposed commit message
Add a new manager interface for otel mode. This manager is created if
management.otel.enabled
is set totrue
.We would set this flag true in elastic-agent.
The methods would be implemented later, when the diagnostic extension is implemented.
I am reluctant to reuse the
management.enabled
flag because the flag is used at many places to detect the fleet mode and it might break other things.Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Disruptive User Impact
None, as we're adding a new flag.
Related issues
Testing
If this approach sounds feasible, I'll add integration test cases for
log
input and unit test cases.