Add receiver/integration (and where available, channel) as structured log fields on notification failures

What

When a notification send fails, the dispatcher logs:

level=ERROR source=dispatch.go msg="Notify for alerts failed" component=dispatcher aggrGroup="..." num_alerts=1 err="<receiver>/<integration>[0]: notify retry canceled due to unrecoverable error after 1 attempts: channel \"CXXXXXXXX\": unexpected status code 429: {\"ok\":false,\"error\":\"ratelimited\"}"

The receiver name, integration type, and (for integrations that surface it, e.g. Slack) the target channel are all present — but only concatenated into the free-text err string. The only structured fields are component, aggrGroup, num_alerts, and err.

Why

Operators aggregating these logs (Loki, ELK, etc.) can't group or alert by receiver / integration / channel without regex-parsing err, which is brittle across error shapes.

This matters specifically for Slack rate-limiting: Slack's chat.postMessage limit is 1 message/sec per channel, so 429s are inherently channel-scoped. Diagnosing "which channel / receiver is being rate-limited" is the exact question operators need to answer, and today it requires parsing the error string. A structured receiver (and, where the notifier exposes it, channel) field would make this a first-class group-by.

The RetryStage already holds the integration and receiver name at the point of failure (in notify.go, where the stage is constructed via NewRetryStage(integration, groupName, …)), so receiver and integration are available to attach to the logger with no new plumbing. Channel is integration-specific and lives inside the wrapped notifier error, so it's a softer ask — but receiver/integration alone would cover most of the need.

Proposal

Attach receiver and integration as structured fields on the failure log in dispatch.go (and/or notify.go's retry logging), e.g.:

logger := d.logger.With("aggrGroup", ag.GroupKey(), "num_alerts", len(alerts), "receiver", ..., "integration", ..., "err", err)

Optionally, integrations that already extract a channel/target could surface it as a structured field on their own error path.

Happy to open a PR if the maintainers are open to the approach.

Read dispatch.go and notify.go, starting at the failure logging and the NewRetryStage(integration, groupName, …) construction. Trace how receiver and integration are available at the failure point, and inspect whether any notifier errors expose a channel. Done means notification failures include receiver and integration as structured fields, with channel surfaced only where already available.