Profiles: Stop passing response headers for Grafana-Pyroscope and parca datasources (#106577)
* Revert "pkgs/tsdb/[grafana-pyroscope-datasource|parca]: Fix use of request headers in responses"
This reverts commit 8bac68e906.
* Profiles: Stop passing request/response headers to the backend
(cherry picked from commit 8fdf86e56f)
(cherry picked from commit 7878815ffc)
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>
* Dependencies: Bump github.com/getkin/kin-openapi from v0.131.0 to v0.132.0
* Dependencies: Bump github.com/openfga/openfga from v1.8.6 to v1.8.12
* Dependencies: Bump golang.org/x to latest
* Dependencies: Unpin and bump github.com/getkin/kin-openapi from v0.126.0 to v0.132.0
* Chore: Update schemas and remove examples
* Chore: Update schemas and remove examples2
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.
