featurecontrol: feature-flag activation is logged at WARN, so a clean start-up emits warnings

What did you do?

Started Alertmanager v0.33.1 with three feature flags that are required for correct operation in our
deployment:

--enable-feature=utf8-strict-mode,auto-gomemlimit,receiver-name-in-metrics

What did you expect to see?

A clean start-up log. Enabling a flag we asked for is an acknowledgement, not a warning.

What did you see instead?

Every one of the three activations is logged at WARN, so a healthy start-up emits three warning
lines and nothing else notable:

{"time":"2026-07-30T11:27:37.086790131Z","level":"WARN","source":"featurecontrol.go:160","msg":"UTF-8 strict mode enabled"}
{"time":"2026-07-30T11:27:37.086818731Z","level":"WARN","source":"featurecontrol.go:163","msg":"Automatically set GOMEMLIMIT to match the Linux container or system memory limit."}
{"time":"2026-07-30T11:27:37.086873731Z","level":"WARN","source":"featurecontrol.go:151","msg":"Experimental receiver name in metrics enabled"}

In featurecontrol/featurecontrol.go at v0.33.1 every branch uses logger.Warn(...)
unconditionally — alert-names-in-metrics, receiver-name-in-metrics, group-key-in-metrics,
classic-mode, utf8-strict-mode, auto-gomemlimit and event-recorder. There is no level
override and no way to reach the same functionality without the line.

Why this matters beyond tidiness

level=WARN is what monitoring and log pipelines are configured to escalate on. A component that
emits warnings on every clean start teaches its operators that its warnings are noise — and the one
warning that matters here is the delivery-failure retry line, which is also the line that leaks the
Telegram bot token (see #5254). Anything that trains a reader to skip Alertmanager's warnings makes
that worse.

Two of the three flags above are not even experimental in effect: auto-gomemlimit is how the Go
heap learns about a container memory limit, and running without it in a limited container is the
worse choice. Announcing the safer configuration as a warning inverts the signal.

Suggested change

Log the activation of a stable, deliberately requested feature at INFO. Keep WARN for the flags
whose message actually carries a caution — the unbounded-cardinality ones
(alert-names-in-metrics, group-key-in-metrics) have a real operational cost and deserve it.

Environment

• Alertmanager version: 0.33.1 (revision=2c8da51e03f3dbbed24f9711ca2d76aab4eef9c5, go1.26.4,
  linux/amd64), image quay.io/prometheus/alertmanager@sha256:9e082985f56f4c8c9f724e18f2288c6708f472e56a5286b8863d080434ea065d
• Configuration: --log.format=json --log.level=info, single replica, --cluster.listen-address=

Start in featurecontrol/featurecontrol.go and review the logger.Warn calls for each feature-flag activation, separating stable requested features from flags whose messages carry an operational caution. Done means stable activations log at INFO while the unbounded-cardinality flags remain at WARN, with clean startup no longer producing warnings for the requested stable flags.