This commit fixes an issue in alerting where NoDataFound is false
when using the AND operator to compare two conditions in an alert
rule and one of the conditions has no data.
(cherry picked from commit d6ed5d295e)
* do not suppress NoData state
* extract conversion of state to postable alert + tests
* create a special alert instance if nodata
* use NoData when converting from Keep Last State instead of Alerting
* add silence during migration if NoData is mapped to KeepLastState.
(cherry picked from commit 610643a668)
Co-authored-by: Yuriy Tseretyan <yuriy.tseretyan@grafana.com>
* test kvstore in intregration tests with different databases
* escape 'key' in delete query
* export quote and use it in kvstore
(cherry picked from commit d1aefa1792)
Co-authored-by: Jean-Philippe Quéméner <JohnnyQQQQ@users.noreply.github.com>
* Alerting: Validate contact point configuration during migration to Unified Alerting (#40717)
* 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.
(cherry picked from commit 74fb491b6a)
* Alerting: Remove invalid Slack URL as we migrate notification channels (#40344)
* 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>
(cherry picked from commit 2448123a65)
* fix tests
Co-authored-by: gotjosh <josue@grafana.com>
Co-authored-by: Yuriy Tseretyan <yuriy.tseretyan@grafana.com>
* Alerting: Fixes a bug when trying to sync broken alertmanager config (#40338)
* Alerting: Fixes a bug when trying to sync broken alertmanager config
Broken alertmanager configuration has the potential to be introduced as part of a migration e.g. due to incompatible data between what grafana accepts and what the Alertmanager expects. When this happens, we expect an eventually consistent behaviour where we'll keep trying to apply the configuration until it works.
As part of change in https://github.com/grafana/grafana/pull/39237 we introduced a regression that modified this behaviour and instead tried to create a new Alertmanager for that organization everytime, which eventually ended up in a panic due to a duplicate metrics being registered.
This PR fixes that and introduces a test to catch further regressions.
* Remove disable orgs
(cherry picked from commit 48d73cb148)
* remove decryptFn that is not known in 8.2 branch
Co-authored-by: gotjosh <josue@grafana.com>
Co-authored-by: Yuriy Tseretyan <yuriy.tseretyan@grafana.com>
Remove validation for labels to be accepted in the Alertmanager, This helps with datasources that produce non-compatible labels.
Adds an "object_matchers" to alert manager routers so we can support labels names with extended characters beyond prometheus/openmetrics. It only does this for the internal Grafana managed Alert Manager.
This requires a change to alert manager, so for now we use grafana/alertmanager which is a slight fork, with the intention of going back to upstream.
The frontend handles the migration of "matchers" -> "object_matchers" when the route is edited and saved. Once this is done, downgrades will not work old versions will not recognize the "object_matchers".
Co-authored-by: Kyle Brandt <kyle@grafana.com>
Co-authored-by: Nathan Rodman <nathanrodman@gmail.com>
(cherry picked from commit 6572017ec7)
cleanup
Co-authored-by: gotjosh <josue@grafana.com>
* Extract search users to a new service
* Fix wire provider
* Fix common_test and remove RouteRegister
* Remove old endpoints
* Fix test
* Add indexes to dashboards and orgs tables
* Fix lint
(cherry picked from commit 02702eb82d)
* keep existing unified alert rules untouched
* move silences and other alertmanager files to the organization directory (only if it is a single organization deployment)
* assign the existing notification settings and routes to the first organization
* create default notification settings for each organization in the case of multi org deployment
(cherry picked from commit 5d0d7dcb3a)
Co-authored-by: Yuriy Tseretyan <yuriy.tseretyan@grafana.com>
* Add method GetAllLatestAlertmanagerConfiguration to DBStore
* add method ApplyConfig to AlertManager
* update multiorg alert manager to load all alertmanager configs at once
(cherry picked from commit 1910d85ae0)
Co-authored-by: Yuriy Tseretyan <yuriy.tseretyan@grafana.com>
An user within Grafana has a completely different meaning. Multi-tenancy is done via Organizations as a top-level concept.
(cherry picked from commit 35e5bfce40)
Co-authored-by: gotjosh <josue@grafana.com>
* pass url parameters through context.Context
* fix url param names without colon prefix
* change context params to vars
* replace url vars in tests using new api
* rename vars to params
* add some comments
* rename seturlvars to seturlparams
* Chore: GetDashboardQuery should be dispatched using DispatchCtx
* Fix after merge
* Changes after review
* Various fixes
* Use GetDashboardCtx function instead of GetDashboard
* Alerting: Refactor & fix unified alerting metrics structure
Fixes and refactors the metrics structure we have for the ngalert service. Now, each component has its own metric struct that includes the JUST the metrics it uses. Additionally, I have fixed the configuration metrics and added new metrics to determine if we have discovered and started all the necessary configurations of an instance.
This allows us to alert on `grafana_alerting_discovered_configurations - grafana_alerting_active_configurations != 0` to know whether an alertmanager instance did not start successfully.