**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)_ |
Adds a new "Allow as recording rules target" toggle to Prometheus datasource configuration that controls whether the datasource can be selected as a target for writing recording rules.
---------
Co-authored-by: ismail simsek <ismailsimsek09@gmail.com>
Co-authored-by: Konrad Lalik <konradlalik@gmail.com>
* Add nanogit package
* Add nanoGit feature flag
* Put logger into nanogit context
* Commit go mod and go sum updates
* Add more stuff around logging
* Nanogit also in extra one
* Add owner to dependency
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.
* capture errors on metrics
* rename seconds to sql_command_duration_milliseconds to match unit that has been captured, and update buckets
* rename sql_command_errors_total to sql_command_count
* Add grafana-build action and workflow
* Fix the --verify flag stalling on tar.gz builds
* Add event sources for main / release branches
* Update CODEOWNERS
* datasources: querier: more robust error handling, and report no error for st
* do not leak error details out
* apply the change to the real file, not just to the test
* 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
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.