-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[extension/opamp] Implement ReportsHealth capability #35488
[extension/opamp] Implement ReportsHealth capability #35488
Conversation
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
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.
Is this meant to be a complete implementation of this functionality? The healthcheckv2extension aggregates component status (via the componentstatus.Watcher
interface) and produces a nested representation of collector health. See the "verbose example" here. This representation is structurally similar to the ComponentHealth
message for OpAMP. I think we can extract the status aggregator from the healthcheckv2 extension, use it in the OpAMP extension, and convert AggregateStatus
es into ComponentHealth
messages. I believe work to extract the aggregator is underway as part of: #34692.
Thanks for the input @mwear - this implementation is a rudimentary version of the health report to just indicate whether the agent is up or not (i kept the implementation close to how it is implemented in the supervisor). However, when the component health information from the healthcheckv2 extension becomes available to be used here as well using this here makes a lot of sense - I can also leave this PR as a draft for now and then adapt it to populate the component health map once #34692 has been resolved |
@bacherfl, if this is helpful as is, we can move forward with it so long as we have an issue describing the end result we want. |
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.
One request, but I'm fine getting a basic implementation in since it inches us closer to proper health reporting.
Signed-off-by: Florian Bacher <[email protected]>
# Conflicts: # extension/opampextension/go.mod # extension/opampextension/go.sum
Signed-off-by: Florian Bacher <[email protected]>
Signed-off-by: Florian Bacher <[email protected]>
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.
Looks good to me as a first pass. The next step will be using status reporting.
# Conflicts: # extension/opampextension/go.mod # extension/opampextension/go.sum
I've captured the next step here, which uses component status reporting to improve the health information we report: #35856. |
Description: This PR adds the ReportsHealth capability to the OpAMP extension.
Link to tracking Issue: #35433
Testing: Add unit test to check the configuration being used for the OpAMP client. Also tested manually by running the supervisor and verifying the health messages are received there
Documentation: Describe the new option in the readme