[8.19](backport #48015) Report subcomponent status for beats receivers #48056
+403
−76
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed commit message
Report subcomponent status for beats receivers
Make beats receivers report otel status for their subcomponents - inputs for filebeat and modules for metricbeat.
This is done via the otel status Event
Attributesfield. Under theinputskey, we add a map to the attributes, where input ids are keys, and statuses are values. The status structure is the same as the one used for streams in the control protocol. This is a temporary measure until there's a standard convention for doing this in upstream otel - then we'll switch to that. The purpose of this change is to let elastic-agent report per-stream and per-input status for inputs running in a beat receiver.We currently need to do a hacky workaround to ensure status events are delivered in spite of the component status not changing. This is due to open-telemetry/opentelemetry-collector#14282.
The output of the healthcheckv2 extension with this change looks like the following:
{ "components": { "receiver:metricbeatreceiver/_agent-component/system/metrics-default": { "healthy": true, "status": "StatusRecoverableError", "error": "Error fetching data for metricset system.process: error fetching process list: non fatal error; reporting partial metrics: error fetching PID metrics for 377 processes, most likely a \"permission denied\" error. Enable debug logging to determine the exact cause.", "status_time": "2025-12-10T18:19:53.552220344+01:00", "attributes": { "inputs": { "unique-system-metrics-input-2-cpu": { "error": "", "status": "Running" }, "unique-system-metrics-input-2-process": { "error": "Error fetching data for metricset system.process: error fetching process list: non fatal error; reporting partial metrics: error fetching PID metrics for 377 processes, most likely a \"permission denied\" error. Enable debug logging to determine the exact cause.", "status": "Degraded" }, "unique-system-metrics-input-cpu": { "error": "", "status": "Running" }, "unique-system-metrics-input-process": { "error": "Error fetching data for metricset system.process: non fatal error; reporting partial metrics: error fetching PID metrics for 377 processes, most likely a \"permission denied\" error. Enable debug logging to determine the exact cause.", "status": "Running" } } } } } }Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration filesstresstest.shscript to run them under stress conditions and race detector to verify their stability../changelog/fragmentsusing the changelog tool.Related issues
This is an automatic backport of pull request #48015 done by [Mergify](https://mergify.com).