Fixes term Grafana Alerting (#50404)

This commit is contained in:
brendamuir
2022-06-08 13:35:37 +02:00
committed by GitHub
parent 49dc9da9c1
commit e0e76f0252
36 changed files with 76 additions and 76 deletions
+1 -1
View File
@@ -17,7 +17,7 @@ title: 'Alerting HTTP API '
> **Note:** This topic is relevant for the [legacy dashboard alerts](https://grafana.com/docs/grafana/latest/alerting/old-alerting/) only.
You can find Grafana alerting API specification details [here](https://editor.swagger.io/?url=https://raw.githubusercontent.com/grafana/grafana/main/pkg/services/ngalert/api/tooling/post.json). Also, refer to [Grafana alerting alerts documentation]({{< relref "../../alerting/" >}}) for details on how to create and manage new alerts.
You can find Grafana Alerting API specification details [here](https://editor.swagger.io/?url=https://raw.githubusercontent.com/grafana/grafana/main/pkg/services/ngalert/api/tooling/post.json). Also, refer to [Grafana Alerting alerts documentation]({{< relref "../../alerting/" >}}) for details on how to create and manage new alerts.
You can use the Alerting API to get information about legacy dashboard alerts and their states but this API cannot be used to modify the alert.
To create new alerts or modify them you need to update the dashboard JSON that contains the alerts.
+1 -1
View File
@@ -280,7 +280,7 @@ Content-Length: 97
Deletes an existing folder identified by UID along with all dashboards (and their alerts) stored in the folder. This operation cannot be reverted.
If [Grafana alerting]({{< relref "../../alerting/" >}}) is enabled, you can set an optional query parameter `forceDeleteRules=false` so that requests will fail with 400 (Bad Request) error if the folder contains any Grafana alerts. However, if this parameter is set to `true` then it will delete any Grafana alerts under this folder.
If [Grafana Alerting]({{< relref "../../alerting/" >}}) is enabled, you can set an optional query parameter `forceDeleteRules=false` so that requests will fail with 400 (Bad Request) error if the folder contains any Grafana alerts. However, if this parameter is set to `true` then it will delete any Grafana alerts under this folder.
**Required permissions**
@@ -20,13 +20,13 @@ However, one limitation with these plugins are that they execute on the client-s
We use the term _backend plugin_ to denote that a plugin has a backend component. Still, normally a backend plugin requires frontend components as well. This is for example true for backend data source plugins which normally need configuration and query editor components implemented for the frontend.
Data source plugins can be extended with a backend component. In the future we plan to support additional types and possibly new kinds of plugins, such as [notifiers for Grafana alerting]({{< relref "../../../alerting/notifications/" >}}) and custom authentication to name a few.
Data source plugins can be extended with a backend component. In the future we plan to support additional types and possibly new kinds of plugins, such as [notifiers for Grafana Alerting]({{< relref "../../../alerting/notifications/" >}}) and custom authentication to name a few.
## Use cases for implementing a backend plugin
The following examples gives you an idea of why you'd consider implementing a backend plugin:
- Enable [Grafana alerting]({{< relref "../../../alerting/" >}}) for data sources.
- Enable [Grafana Alerting]({{< relref "../../../alerting/" >}}) for data sources.
- Connect to non-HTTP services that normally can't be connected to from a web browser, e.g. SQL database servers.
- Keep state between users, e.g. query caching for data sources.
- Use custom authentication methods and/or authorization checks that aren't supported in Grafana.