Fixes term Grafana Alerting (#50404)
This commit is contained in:
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user