Report subcomponent status for beats receivers

[swiatekm]

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 Attributes field. Under the inputs key, 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

• 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. Where relevant, I have used the stresstest.sh script to run them under stress conditions and race detector to verify their stability.
• I have added an entry in ./changelog/fragments using the changelog tool.

Related issues

• Relates https://github.com/elastic/ingest-dev/issues/5742

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b feat/beat-receiver-subcomponent-status upstream/feat/beat-receiver-subcomponent-status
git merge upstream/main
git push upstream feat/beat-receiver-subcomponent-status

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @swiatekm? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[leehinman]

LGTM

[cmacknz]

            "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"
          },

Instead of keeping the control protocol statuses, can we use the healthhcheck extension statuses? e.g. StatusRecoverableError instead of Degraded? This way we don't leak control protocol states into the OTel healthcheck extension.

This would almost certainly be a change required if sub-component status gets standardized upstream anyway.

[swiatekm]

            "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"
          },

Instead of keeping the control protocol statuses, can we use the healthhcheck extension statuses? e.g. StatusRecoverableError instead of Degraded? This way we don't leak control protocol states into the OTel healthcheck extension.

This would almost certainly be a change required if sub-component status gets standardized upstream anyway.

Sure, we can. It's the more idiomatic choice, even if it creates more work for elastic agent to convert it back. I figured that since we'll be changing this again once the upstream convention is in place, I'd just do the most convenient thing for us right now. I don't mind changing it if you think we should be more idiomatic, though.

[swiatekm]

            "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"
          },

Instead of keeping the control protocol statuses, can we use the healthhcheck extension statuses? e.g. StatusRecoverableError instead of Degraded? This way we don't leak control protocol states into the OTel healthcheck extension.
This would almost certainly be a change required if sub-component status gets standardized upstream anyway.

Sure, we can. It's the more idiomatic choice, even if it creates more work for elastic agent to convert it back. I figured that since we'll be changing this again once the upstream convention is in place, I'd just do the most convenient thing for us right now. I don't mind changing it if you think we should be more idiomatic, though.

Done: b31ea4c.