Pass all `agent.features.*` flags to Beat receivers

[belimawr]

Problem

Elastic Agent's OTel translator currently handles Beat receiver feature flags inconsistently.

The translator special-cases agent.features.fqdn.enabled and writes it into the generated Beat receiver config as features.fqdn.enabled. Other feature flags under agent.features.* are not propagated to Beat receivers through the same path, so Beat receiver behavior can diverge from process-managed Beats and from the operator's Agent policy.

This means only fqdn currently gets first-class treatment in generated Beat receiver configs, while other Beat-supported feature flags such as:

• agent.features.log_input_run_as_filestream.enabled
• agent.features.aws_s3_v2.enabled

are excluded from the generated receiver features block unless they are manually present in raw Beat/receiver config.

Current behavior

The OTel translator evaluates the Agent FQDN flag once and injects only that flag into each Beat receiver config:

• FQDN value read from Agent feature state:

  elastic-agent/internal/pkg/otel/translate/otelconfig.go

  Lines 78 to 80 in 77a6589

  	// Evaluate the FQDN feature flag once, so every component in this render sees a consistent
  	// value even if the global flag changes (via a concurrent policy update) while we iterate.
  	fqdnEnabled := features.FQDN()

• Hard-coded Beat receiver features.fqdn.enabled block:

  elastic-agent/internal/pkg/otel/translate/otelconfig.go

  Lines 449 to 454 in 77a6589

  	// propagate the FQDN feature flag into the receiver config
  	sharedConfig["features"] = map[string]any{
  	"fqdn": map[string]any{
  	"enabled": fqdnEnabled,
  	},
  	}

On the Beat side, libbeat/features already knows how to parse more than just fqdn from a Beat config features block. It also parses log_input_run_as_filestream and aws_s3_v2: https://github.com/elastic/beats/blob/af686c255e1f319b47524835f63b06d31365d47b/libbeat/features/features.go#L52-L67

	type cfg struct {
		Features struct {
			FQDN               *conf.C `json:"fqdn" yaml:"fqdn" config:"fqdn"`
			LogRunAsFilestream *conf.C `json:"log_input_run_as_filestream" config:"log_input_run_as_filestream"`
			AwsS3V2            *conf.C `json:"aws_s3_v2" yaml:"aws_s3_v2" config:"aws_s3_v2"`
		} `json:"features" yaml:"features" config:"features"`
	}

	parsedFlags := cfg{}
	if err := c.Unpack(&parsedFlags); err != nil {
		return fmt.Errorf("could not unpack features config: %w", err)
	}

	flags.SetFQDNEnabled(parsedFlags.Features.FQDN.Enabled())
	flags.SetLogInputRunFilestream(parsedFlags.Features.LogRunAsFilestream.Enabled())
	flags.SetAwsS3V2(parsedFlags.Features.AwsS3V2.Enabled())

Because the translator's generated receiver features map currently contains only fqdn, the other Beat-supported flags do not reach OTel Beat receivers when configured as Agent feature flags.

This is different from the intended feature propagation model used by process-managed Beats. proto.Features only has a concrete typed field for fqdn, but it also carries the raw feature configuration in Source:

elastic-agent/pkg/features/features.go

Lines 113 to 119 in 77a6589

	func (f *Flags) AsProto() *proto.Features {
	return &proto.Features{
	Fqdn: &proto.FQDNFeature{
	Enabled: f.FQDN(),
	},
	Source: f.source,
	}

That raw source is intentionally used so new feature flags can be propagated without changing the proto schema every time a flag is added.

The OTel translator should follow the same design intent: do not require a hard-coded typed field for every feature flag, and do not special-case only fqdn.

Desired behavior

All feature flags configured under agent.features.* should be propagated consistently to Beat receivers.

Instead of hard-coding only:

features.fqdn.enabled

the OTel translator should convert the full relevant agent.features.* tree into the Beat receiver features.* tree, preserving feature names and enabled values, for example:

agent:
  features:
    fqdn:
      enabled: true
    log_input_run_as_filestream:
      enabled: true
    aws_s3_v2:
      enabled: true

should produce Beat receiver config equivalent to:

features:
  fqdn:
    enabled: true
  log_input_run_as_filestream:
    enabled: true
  aws_s3_v2:
    enabled: true

Acceptance criteria

• The OTel translator no longer hard-codes only fqdn when building Beat receiver features.
• All supported agent.features.* entries are passed to generated Beat receiver config under features.*.
• Tests cover propagation of multiple feature flags, not only fqdn.
• The implementation avoids creating two competing feature flag propagation mechanisms for Beat receivers.

---

Assisted-by: GPT-5.5
Human reviewed: yes

[infra-vault-gh-plugin-prod]

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

[github-actions]

TL;DR: This is a valid, localized bug. The fix should make proto.Features.Source the single source for Beat receiver feature propagation, but first preserve unknown entries in that source; otherwise simply wiring the translator to it still drops log_input_run_as_filestream and aws_s3_v2.

Recommendation

Update feature parsing to retain the original agent.features subtree, then have the OTel translator copy that subtree to each generated Beat receiver's features block. Remove the translator's global FQDN snapshot and hard-coded features.fqdn.enabled construction. This avoids a second, FQDN-only propagation mechanism and automatically supports future Beat feature flags.

Findings

• internal/pkg/otel/translate/otelconfig.go:78-83 reads only the global features.FQDN() value, and :449-454 creates only features.fqdn.enabled.
• Components already carry Features: featureFlags.AsProto() (pkg/component/component.go:672-683 and 719-730), and pkg/features/features.go:113-119 exposes proto.Features.Source.
• pkg/features/features.go:189-207 currently builds Source by JSON-marshalling the typed cfg; because cfg only declares Agent-owned fields (:56-75), unknown Beat flags are discarded before the translator can use them.
• The merged PR Fix agent.features.fqdn.enabled in otel/translate. #15191 introduced the current FQDN-only path and its tests; issue Add a feature flag to disable injecting the default beat global processors when using the otel runtime #12267 is the related completed work for disabling default Beat processors, not a duplicate of this propagation gap.

Verification

• go test ./pkg/features passes.
• go test ./internal/pkg/otel/translate cannot start in this checkout because the beats submodule is uninitialized (beats/go.mod is missing); this is an environment prerequisite, not a test assertion failure.

Detailed Action Plan

1. In pkg/features/features.go, change Parse/setSource so Source is derived from the original config's agent.features map (using the existing config map/unpack facilities), while retaining typed parsing/defaults for Agent runtime flags. Preserve arbitrary feature names, nested values, and explicit false values. Add a unit test in pkg/features/features_test.go covering fqdn, log_input_run_as_filestream, and aws_s3_v2.
2. In internal/pkg/otel/translate/otelconfig.go, remove the global FQDN read and the fqdnEnabled parameters from getCollectorConfigForComponent and getReceiversConfigForComponent. Extract and clone comp.Features.Source.agent.features into receiver features; do not mutate the protobuf source. Keep features.DefaultProcessors() handling unchanged because it controls generated processors, not receiver feature flags.
3. Update existing receiver/OTel expected configs and replace TestGetReceiversConfigForComponentFQDN (otelconfig_test.go:2776-2839) with a multi-flag test asserting the exact receiver map and no agent nesting. Include a case where typed FQDN and source FQDN differ, proving the translator has one propagation path. Add coverage for a nil/empty source if the helper defines a compatibility fallback.
4. Initialize the repository submodules and run the focused translator tests, then the standard unit/lint targets.

Related Items

Type	Reference	Relevance
Issue	#15437	Current feature propagation gap
PR	#15191	Added the current FQDN-only translator path
Issue	#12267	Related default-processors flag work; resolved by PR #12334
File	pkg/features/features.go:189-207	Current source construction drops undeclared flags
File	internal/pkg/otel/translate/otelconfig.go:449-454	Current hard-coded receiver feature block

---

What is this? | From workflow: Issue Triage

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

[hiSandog]

Using proto.Features.Source as the single source works only if decoding/translation preserves unknown future agent.features.* entries and their scalar types end to end. The translator should strip the agent.features. prefix deliberately, avoid forwarding unrelated namespaces, and define precedence when receiver-local config already sets a feature. Golden tests with known, unknown, false, and nested values across multiple Beat receivers would protect compatibility as new flags are introduced.