Propagate all feature flags to Beat receivers

[belimawr]

What does this PR do?

Preserves the original agent.features subtree in component feature metadata and copies it into generated Beat receiver configs. Removes the separate global FQDN-only propagation path so feature source metadata is authoritative and future Beat-supported flags propagate without translator changes.

Adds coverage for FQDN, log_input_run_as_filestream, aws_s3_v2, unknown future flags, explicit false values, and missing feature metadata.

Why is it important?

The OTel translator previously propagated only FQDN. Other Beat-supported feature flags were dropped, causing Beat receivers to behave differently from the Agent policy.

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

Documentation, default configuration, and new integration coverage are not required; this fixes internal propagation and existing receiver integration coverage exercises these flags.

Disruptive User Impact

None. Configured feature flags now consistently reach OTel Beat receivers.

How to test this PR locally

Run the tests

go test ./pkg/features
go test ./internal/pkg/otel/translate
go vet ./pkg/features ./internal/pkg/otel/translate

Manual test

1. Build and unpack a development Agent package

From the repository root:

mage dev:package
cd build/distributions
tar -xf elastic-agent-9.6.0-SNAPSHOT-linux-x86_64.tar.gz 
cd elastic-agent-9.6.0-SNAPSHOT-linux-x86_64

2. Create a test log and elastic-agent.yml

The policy deliberately configures a legacy log input, forces it to run as a Beat receiver, and enables agent.features.log_input_run_as_filestream.

printf 'manual feature propagation test line %04d\n' {1..200} > /tmp/elastic-agent-feature-test.log

elastic-agent.yml

agent:
  logging:
    level: debug
    to_stderr: true
  features:
    log_input_run_as_filestream:
      enabled: true
  internal:
    runtime:
      default: process
      filebeat:
        log: otel

outputs:
  default:
    type: elasticsearch
    hosts: [http://127.0.0.1:9200]
    username: elastic
    password: changeme

inputs:
  - id: manual-log-receiver
    type: log
    use_output: default
    data_stream:
      namespace: default
    streams:
      - id: manual-log-receiver.generic
        data_stream:
          dataset: generic
        paths:
          - /tmp/elastic-agent-feature-test.log
        allow_deprecated_use: true

agent.grpc:
  port: 5050

3. Start Elastic Agent in standalone mode

sudo ./elastic-agent run -e 2>&1 | tee /tmp/elastic-agent-feature-test-output.log

Connection errors for 127.0.0.1:9200 are expected when Elasticsearch is not running and do not affect this test.

4. Verify that the log input started as Filestream

In another terminal:

grep "running as Filestream" /tmp/elastic-agent-feature-test-output.log | jq '[.log.source, .message]'
grep "Input 'filestream' starting" /tmp/elastic-agent-feature-test-output.log| jq '[.log.source, .message]'

The output should contain a Filebeat receiver log similar to:

[
  "log-default",
  "Log input (deprecated) running as Filestream input"
]
[
  "filestream-monitoring",
  "Input 'filestream' starting"
]
[
  "log-default",
  "Input 'filestream' starting"
]

The standalone policy still declares type: log; seeing input.filestream and Input 'filestream' starting confirms that agent.features.log_input_run_as_filestream.enabled: true reached the generated Beat receiver and was applied. Stop the Agent with Ctrl-C after the assertion succeeds.

Related issues

• Closes Pass all agent.features.* flags to Beat receivers elastic/elastic-agent#15437

  

[github-actions]

TL;DR

The fragment-in-pr check failed because pr-has-fragment is resolving the changelog config for elastic/elastic-agent, while this PR is hosted in belimawr/elastic-agent. The required fragment is already present; rerun after adding the skip-changelog label or run the check with repository ownership/config aligned to the fork.

Remediation

• For this fork PR, add the skip-changelog label to bypass the upstream-only validation, then rerun fragment-in-pr.
• If the workflow is intended to validate fork PRs, make the changelog repository owner/repo resolution use the event repository (or update config.changelog.yaml for the target repository) and rerun the check.

Investigation details

Root Cause

The only failed job is fragments, at check pr-has-fragment. The PR includes changelog/fragments/1783638976-propagate-all-feature-flags-to-beat-receivers.yaml, but the checked-out config.changelog.yaml declares owner: elastic and repo: elastic-agent. The workflow invokes pr-has-fragment --repo elastic-agent 2, so the tool is configured for the upstream repository rather than the PR repository belimawr/elastic-agent.

Evidence

• Workflow: https://github.com/belimawr/elastic-agent/actions/runs/29056937687
• Job/step: fragments / check pr-has-fragment
• Key log excerpt: Error: fragment not present in PR 2 followed by the tool's suggestion to add a fragment or skip-changelog.
• PR file evidence: changelog/fragments/1783638976-propagate-all-feature-flags-to-beat-receivers.yaml is added by PR Propagate all feature flags to Beat receivers #2.
• Configuration evidence: config.changelog.yaml contains owner: elastic and repo: elastic-agent.

Validation

• Not run; this investigation was read-only and the workflow configuration cannot be modified here.

Follow-up

• No previous PR Actions Detective comment was found, so this is a new diagnosis.

---

What is this? | From workflow: PR Actions Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[belimawr]

LGTM

[belimawr]

Closing in favour of elastic#15458