* Alerting: Improve legacy migration to include send reminder & frequency
Legacy channel frequency is migrated to the channel's migrated route's
repeat interval if send reminder is true. If send reminder is false, we
pseudo-disable the repeat interval by setting it to a large value (1y).
If there were no default channels, the root notification policy is still
created with the default 4h repeat interval.
* Alerting: Improve notification policies created during migration
Previously, migrated legacy alerts were connected to notification policies through
a `rule_uid` label in a 1:1 fashion. While this correctly mimicked pre-migration routing,
it didn't create a notification policy structure that is easy to view/modify. In addition,
having one policy per migrated alert is, in some ways, counter to the recommended approach of
Unified Alerting.
This change replaces `rule_uid`-based migrated notification policies with a private
label called `__contacts__`. This label stores a list of double quoted strings containing the names of
all contact points an AlertRule should route to (based on legacy notification channels). Finally,
one notification policy is created per contact point with each matching AlertRules via regex on this
`__contacts__` label.
The result is a simpler, clearer, and easier to modify notification policy structure, with the
added benefit that you can see which contact points an AlertRule is being routed to from the
AlertRule creation page.
* Alerting: Update default route groupBy to [grafana_folder, alertname]
Default group by for new routes and migrations is now [grafana_folder, alertname]
* Alerting: Create fewer contact points on migration
Previously a new contact point was created for every unique combination
of channels attached to any legacy alert. This was very hard to maintain,
requiring modifications in every generated contact point.
This change deduplicates the generated contact points to a more
reasonable state. There should now only be one contact point per legacy
channel, and we attached multiple contact points to a route by nesting
them. The sole exception to this is if there were multiple default
legacy channels, in which case we create a redundant contact point
containing all of them used only in the root policy. This allows for a
much simpler notification policy structure.
Co-authored-by: gotjosh <josue.abreu@gmail.com>
* Alerting: Validate contact point configuration during the migration
This minimises the chances of generating broken configuration as part of the migration. Originally, we wanted to generate it and not produce a hard stop in Grafana but this strategy has the chance to avoid delivering notifications for our users.
We now think it's better to hard stop the migration and let the user take care of resolving the configuration manually.
* Alerting: Remove invalid Slack URL as we migrate notification channels
Grafana will accept any type of utf8 valid string as the Slack URL and will simply fail as we try to deliver the notification of the channel. The Alertmanager will fail to apply a configuration if the URL of the Slack Receiver is invalid.
This change takes that into account by removing the URL for the receiver as we migrate notification channels that do not pass the url validation. As we assume the notification was not being delivered to being with.
* Add a log line when we modify the channel
Co-authored-by: Yuriy Tseretyan <yuriy.tseretyan@grafana.com>
