[OTEL] Hide healthcheckv2 from agent status.

[blakerouse]

What does this PR do?

Hides the healthcheckv2 extension from the elastic-agent status output.

Why is it important?

This extension is injected by the elastic-agent so it should not be included in the status as its not created by the user.

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 (covered by unit test)

Disruptive User Impact

The healthcheckv2 will no longer be included in status output.

How to test this PR locally

Run the elastic-agent with OTEL enabled, run elastic-agent status and observe that the healthcheckv2 extension is no longer in the status output.

Related issues

• Closes [OTEL] healthcheckv2extension should be hidden in elastic-agent status output #11714

[elasticmachine]

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

[swiatekm]

You need to check if the extension id is the one we injected. Otherwise, you might delete an extension added by the user.

[blakerouse]

You need to check if the extension id is the one we injected. Otherwise, you might delete an extension added by the user.

@swiatekm Why don't we do this for the other 2 extensions that are hidden?

[pchila]

You need to check if the extension id is the one we injected. Otherwise, you might delete an extension added by the user.

@swiatekm Why don't we do this for the other 2 extensions that are hidden?

I kinda had the same question after seeing @swiatekm comment. Is it because healthcheckv2 can appear in user-provided config and the other 2 cannot ?

Nitpick: I think that the filtering should happen at the boundary with user/other systems when preparing the output (1 level up from where this is but since the other filtered extensions are already here I guess we put the filter here for consistency ?)

[blakerouse]

You need to check if the extension id is the one we injected. Otherwise, you might delete an extension added by the user.

@swiatekm Why don't we do this for the other 2 extensions that are hidden?

I kinda had the same question after seeing @swiatekm comment. Is it because healthcheckv2 can appear in user-provided config and the other 2 cannot ?

Nitpick: I think that the filtering should happen at the boundary with user/other systems when preparing the output (1 level up from where this is but since the other filtered extensions are already here I guess we put the filter here for consistency ?)

There is no limit to a configuration that a user can provide, so I would expect that users can provide that as well. I kept the code consistent with this PR. If its best to filter based on what we inject then we should do that same for all 3.

[swiatekm]

You need to check if the extension id is the one we injected. Otherwise, you might delete an extension added by the user.

@swiatekm Why don't we do this for the other 2 extensions that are hidden?

We don't support using either of those in a collector config, so there's no need. Healthcheckv2 is an upstream component.

Technically, we probably should do it anyway, but I recall it was annoying to do so.

[blakerouse]

@swiatekm That makes sense. I have updated this PR to keep it specifically about the healthcheckv2 extension. It now only removes based on the specific extension ID.

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 86b01d2

Failed CI Steps

• x86_64:sudo: deb - platform-ingest-elastic-agent-debian-13-1762801856

History

• 💔 Build #31772 failed ceb8fda

cc @blakerouse