Update grafana/alerting to 8eef376f49f8
Includes support for OAuth2 in most notifiers but does not enable that support
yet in FE. Fixes tests related to the change.
* replace PostableUserConfig with GrafanaAlertmanagerConfig to decouple from internal Grafana models
* update alertmanager + tests
* calculate hash of the GrafanaAlertmanagerConfig
* introduce ExtraConfigsCrypto
* delete getLastConfiguration and move all code into method Get
* update legacy store to encrypt ExtraConfigs same way we do in MultiOrgAlertmanager
* update legacy store init
* delete PersistConfig
* remove unnecessary unmarshalling
* add better error
* add tests for legacy store
* add tests that cover extra config validation
* add integration test for conflicting routes
---------
Signed-off-by: Yuri Tseretyan <yuriy.tseretyan@grafana.com>
* Alerting: Fix notification policy conflicts originating from provenance mismatch
Sometimes the provenance field on the notification policy route can mismatch with the actual provenance in the provenance store.
This leads to 409s when trying to update the notification policy via the k8s apis.
We avoid this by ignoring the provenance field when calculating the fingerprint.
Co-authored-by: Matt Jacobson <matthew.jacobson@grafana.com>
* fix tests which validate stability
---------
Co-authored-by: Matt Jacobson <matthew.jacobson@grafana.com>
* automatically rename integration tests to follow the common convention
* name tests differently
* alter column type to bigint
* update another column to bigint
* add another alter
* fix subquery for mysql
Several niche bugs have surfaced as a result of the decrypt code Grafana uses in receivers API being different than what is used to decrypt secrets before sending to remote AM. Example:
- Dingding notifier not abiding by new Patching added to local AM, thus causing missing url errors.
* noop refactor to simplify decryptConfiguration
* Move compat function package
* Use new receiver models to encrypt/decrypt in remote AM
What is this feature?
Implements the POST endpoint for deleting imported Mimir Alertmanager configurations:
POST /api/convert/api/v1/alerts
The API endpoint creates the extra Alertmanager configuration with the provided identifier and matchers.
**What is this feature?**
This PR implements a new Prometheus historian backend that allows Grafana alerting to write alert state history as Prometheus-compatible `ALERTS` metrics to remote Prometheus-compatible data sources.
The metric includes a few additional labels:
* `grafana_alertstate`: Grafana's full alert state, more granular than Prometheus.
* `grafana_rule_uid`: Grafana's alert rule UID.
Grafana states are included in the `grafana_alertstate` label also mapped to Prometheus-compatible `alertstate` values:
| Grafana alert state | `alertstate` | `grafana_alertstate` |
|---------------------|-----------------------|-----------------------|
| `Alerting` | `firing` | `alerting` |
| `Recovering` | `firing` | `recovering` |
| `Pending` | `pending` | `pending` |
| `Error` | `firing` | `error` |
| `NoData` | `firing` | `nodata` |
| `Normal` | _(no metric emitted)_ | _(no metric emitted)_ |
This adds the ability to filter rules with the prometheus compatible api using:
1. `receiver_name` to filter by contact point name
2. `health` to filter by the health status of the rule (one of `ok`, `error`, `nodata`, or `unknown`)
This also ensures that groups with no rules (due to filters) are not returned.
* declare dingding url as secret
patch raw settings before parsing because DingDing's config parser does not know about secrets
* fix integration test
---------
Co-authored-by: Yuri Tseretyan <yuriy.tseretyan@grafana.com>
* Add to available channels
* Export
* Fix bug in deeply nested secrets
BE: Slice re-use bug when traversing deeply.
FE: Only at most one level of nesting was being taken into account
when determining secureFields keys. This change adds a new field on
NotificationChannelOption: secureFieldKey. This is populated on API GET via
transform. This change gives us the option to hardcode secureFieldKey in the
backend and no longer calculate the key via settings topology.
* Update grafana/alerting to 3e20fda3b872
* Prettier
* Linting
* Fix IntegrationConfig test to catch secure field mismatch
What is this feature?
Ensures that resolved notifications are sent when alert states transition from Error to Normal after the configured number of evaluation intervals: Missing series evaluations to resolve.
Why do we need this feature?
Before this change, when an alert was transitioning from Error to Normal, in case when the labels on the new Normal alert instance are the same, Grafana would not send resolved notifications for the Error alert state. The alert would be resolved after a few evaluation intervals automatically in the alertmanager, following the endsAt.
With this change the resolved notification is sent after the configured number of evaluation intervals: Missing series evaluations to resolve.
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.
* Alerting: Optimize prometheus api permission checks
This improves the performance of the Prometheus API by performing the permission checks for rule read permission in a folder upfront, rather than checking permissions for each rule group individually. This reduces the number of permission checks and should speed up the API response time.
* refactor vars
---------
Co-authored-by: Konrad Lalik <konradlalik@gmail.com>