Do not warn on target allocator config load for non-TA Prometheus configs

[musa-asad]

Summary

A plain Prometheus deployment of the CloudWatch Agent (no Target Allocator) logs a misleading WARN ... Could not load config for target allocator from file at startup. No functional impact, but confusing because the user never requested a Target Allocator.

Root cause: createTargetAllocatorManager unconditionally tries to parse the Prometheus config as a prometheusreceiver.Config. A plain config (global:/scrape_configs: at top level) fails strict unmarshal and fires a spurious WARN on every non-TA deployment.

This change gates the warning on whether the config contains a target_allocator: section: warn only when TA config was expected, otherwise log at Debug.

Changes

plugins/inputs/prometheus/target_allocator.go:

• New helper hasTargetAllocatorSection(filename) — checks if config has a target_allocator: key
• Gated the warning: Warn when target_allocator: section present, Debug otherwise

plugins/inputs/prometheus/target_allocator_test.go (new):

• TestCreateTargetAllocatorManager_NoTASection_NoWarn — no Warn for non-TA config
• TestCreateTargetAllocatorManager_MalformedTASection_Warns — genuine TA errors still warn
• TestHasTargetAllocatorSection — helper unit test

Test Output

Before (stock agent image):

level=WARN source=target_allocator.go:97 msg="Could not load config for target allocator from file" filename=/etc/prometheusconfig/prometheus.yaml err="decoding failed due to the following error(s):

'prometheusreceiver.Config' has invalid keys: global, scrape_configs"
level=INFO source=start.go:138 msg="Target Allocator status" enabled=false

WARN grep count            = 1

After (this branch):

level=INFO source=start.go:138 msg="Target Allocator status" enabled=false

WARN grep count            = 0
enabled=false line count   = 1
pod phase                  = Running   restarts=0

Unit tests:

$ CGO_ENABLED=0 go test ./plugins/inputs/prometheus/ -run 'TestCreateTargetAllocatorManager|TestHasTargetAllocatorSection' -count=1 -v
--- PASS: TestCreateTargetAllocatorManager_NoTASection_NoWarn (0.00s)
--- PASS: TestCreateTargetAllocatorManager_MalformedTASection_Warns (0.00s)
--- PASS: TestHasTargetAllocatorSection (0.00s)
PASS
ok  github.com/aws/amazon-cloudwatch-agent/plugins/inputs/prometheus  0.034s

Verified on both Helm and EKS Add-On paths

The same agent binary runs on both paths. Verified the spurious WARN is absent on both:

# Helm path:
$ kubectl logs -n <test-ns-helm> cloudwatch-agent-0 | grep -c 'Could not load config for target allocator'
0

# EKS Add-On path:
$ kubectl logs -n <test-ns-addon> cloudwatch-agent-0 | grep -c 'Could not load config for target allocator'
0

# Both still log the enabled=false status at INFO:
$ kubectl logs -n <test-ns-helm> cloudwatch-agent-0 | grep 'Target Allocator status'
ts=... level=info msg="Target Allocator status" enabled=false

$ kubectl logs -n <test-ns-addon> cloudwatch-agent-0 | grep 'Target Allocator status'
ts=... level=info msg="Target Allocator status" enabled=false

Related

• Fix Target Allocator startup crashes, PrometheusCR watcher, and Prometheus config pod restart amazon-cloudwatch-agent-operator#386 — TA startup crash fix + pod restart on config change