Recording rule fields were not being copied correctly when duplicating an alert rule. This manifests as missing `TargetDataSourceUID` fields from the `Record` part of the rule when rules in a group are re-ordered.
Added some additional tests to ensure we cover the generation of recording rules in tests and fixed the copying logic to ensure all fields are copied correctly.
(cherry picked from commit c73b3ccf6e)
CloudMigrations: Report on prem event with grafana version (#104515)
* grafana version in on prem event report
* store grafana version in cloud migration service
(cherry picked from commit ee99433c65)
Co-authored-by: Dana Axinte <53751979+dana-axinte@users.noreply.github.com>
* Alerting: Resend alerts for states that are missing in the eval results (#105965)
What is this feature?
This PR fixes the MissingSeriesEvalsToResolve behavior when it's set to more than 4 evaluation intervals.
Why do we need this feature?
The MissingSeriesEvalsToResolve setting was not working correctly due to alerts being auto-resolved by Alertmanager after 4 evaluation intervals (via the endsAt field).
Before we had deleteStaleStatesFromCache method that was returning only stale states that had to be resolved. Non-stale states for which the current evaluation does not have a series never had endsAt updated and were never resend to the Alertmanager, so they were automatically resolved after 4 evaluations regardless of the setting.
The new processMissingSeriesStates returns state for each missing series on every evaluation, and resolves the stale ones. This guarantees that alerts without series still alert for the configured number of evaluations.
* Remove FiredAt field
Provisioning: Move OSS provisioning to Run step (#105428)
* Provisioning: Move OSS provisioning to Run step
---------
(cherry picked from commit 1435eedbc4)
Signed-off-by: Maicon Costa <maiconscosta@gmail.com>
Co-authored-by: maicon <maiconscosta@gmail.com>
Run Init Provisioners at Server Initialization (#105080)
* Run Init Provisioners at Server Initialization
---------
(cherry picked from commit 82bbbf1a98)
Signed-off-by: Maicon Costa <maiconscosta@gmail.com>
Co-authored-by: maicon <maiconscosta@gmail.com>
CloudMigrations: Omit autoincremented id for alert snapshots (#106598)
If you tried to migrate alerts from two differente sources/on-prem instances,
the autoincremented numeric id would be the same, and since we were creating
the resource in cloud with that same id (the API accepts it), it would
return an error "conflicting alert rule found" because that id is the primary key on the table.
We simply omit the numeric id now and let the API for the cloud instance generate it.
(cherry picked from commit a1f2693fd8)
Co-authored-by: Matheus Macabu <macabu@users.noreply.github.com>
Alerting: Provisioning API returns 403 on quota exceeded for rule group PUT (#106409)
(cherry picked from commit 1df888c517)
Co-authored-by: Vadim Stepanov <vstpme@gmail.com>
Alerting: Fix group-level labels and query_offset in the import API (#106379)
What is this feature?
Fixes a bug when group-level query_offset and labels parameters are ignored and not saved
Why do we need this feature?
In the import API Prometheus YAML rule definitions are supported:
groups:
- name: group-1
interval: 1m
query_offset: 10m
labels:
severity: "warning"
rules:
- alert: Alert 0 > 0
expr: vector(0) > 0
But applying group-level labels and query_offset is broken and they are not saved right now because during the conversion of the API model to PrometheusRuleGroup they aren't saved to the new structure.
(cherry picked from commit f7a52bc04e)
Alerting: Fix $value type when single data source is queried (#106080)
(cherry picked from commit faeddf334a)
Co-authored-by: Alexander Akhmetov <me@alx.cx>
Alerting: Ensure field validators return the proper type (#104050)
* Ensure field validators return the proper type
This ensures correct error propagation through services up to
the API layer.
* Move error wrapping up to call site
(cherry picked from commit 820c338414)
Co-authored-by: William Wernert <william.wernert@grafana.com>
What is this feature?
Send resolved notifications not only when an alert state becomes stale (series is missing) and transitions from Alerting to Normal, but also from Error, NoData and Recovering.
Why do we need this feature?
Previously, when an alert state became stale or was deleted, it would transition to Normal but wouldn't trigger resolved notifications to the Alertmanager. This meant we relied on the Alertmanager to send resolved notifications when the alert expires. However, if the Alertmanager state is lost, these resolved notifications would never be sent, leaving users with firing alerts in their notification channels. This PR ensures that any transition from a firing state (Alerting, Error, NoData, Recovering) to Normal triggers a resolved notification.
* Remove POST config for Grafana Alertmanager
* Delete auth + test for removed path
* Alerting: Remove check for `alertingApiServer` toggle in UI (#103805)
* Remove check for alertingApiServer in UI
* Update tests to no longer care about alertingApiServer
* Add contact points handlers now that we use alertingApiServer all the time
* Fix test broken from removing camelCase for UIDs
---------
Co-authored-by: Tom Ratcliffe <tom.ratcliffe@grafana.com>
Moustafa Baiou
grafana-delivery-bot[bot]
Stephanie Hingtgen
Alexander Akhmetov
github-actions[bot]
Josh Hunt
Matheus Macabu
Alexander Zobnin
Michael Mandrus
linoman
Artur Wierzbicki
Will Browne
Ryan McKinley
Esteban Beltran
Cory Forseth
Carl Bergquist
ismail simsek
William Wernert
Nick Richmond
Dave Henderson
Marco de Abreu