public/grafana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Docs: fixes various links (#70384)

Browse Source 
* Docs: fixes various links

* bit more moving

* corrects link

* fixes links

* fixes links from move

* fix links

* fix links

* fixes links

* fixes links

* fix typo

* fixes typo

* fix notif policy link

* fix link
This commit is contained in:
brendamuir
2023-06-20 21:49:57 +02:00
committed by GitHub
parent 13e3308959
commit 701c6b6f07
16 changed files with 25 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/sources/alerting/alerting-rules/_index.md
+2 -2
View File
@@ -33,8 +33,8 @@ Alert rules for an external Grafana Mimir or Loki instance can be edited or dele
**Configure contact points**
For information on how to configure contact points, see [Configure contact points]({{< relref "../manage-notifications/manage-contact-points" >}})
For information on how to configure contact points, see [Configure contact points]({{< relref "./manage-contact-points/_index.md" >}})
**Configure notification policies**
For information on how to configure notification policies, see [Configure notification policies]({{< relref "../manage-notifications/manage-contact-points" >}})
For information on how to configure notification policies, see [Configure notification policies]({{< relref "./create-notification-policy" >}})
docs/sources/alerting/alerting-rules/create-notification-policy.md
+103
View File
@@ -0,0 +1,103 @@
---
aliases:
- ../notifications/
- ../old-alerting/notifications/
- ../unified-alerting/notifications/
description: Notification policies
keywords:
- grafana
- alerting
- guide
- notification policies
- routes
title: Configure notification policies
weight: 420
---
# Configure notification policies
Notification policies determine how alerts are routed to contact points.
Policies have a tree structure, where each policy can have one or more nested policies. Each policy, except for the default policy, can also match specific alert labels.
Each alert is evaluated by the default policy and subsequently by each nested policy.
If the **Continue matching subsequent sibling nodes** option is enabled for a nested policy, then evaluation continues even after one or more matches. A parent policy’s configuration settings and contact point information govern the behavior of an alert that does not match any of the nested policies. A default policy governs any alert that does not match a nested policy.
You can configure Grafana-managed notification policies as well as notification policies for an external Alertmanager data source.
For more information on notification policies, see [fundamentals of Notification Policies]({{< relref "../fundamentals/notification-policies/index.md" >}}).
## Edit default notification policy
{{% admonition type="note" %}}
Before Grafana v8.2, the configuration of the embedded Alertmanager was shared across organizations. Users of Grafana 8.0 and 8.1 are advised to use the new Grafana 8 Alerts only if they have one organization. Otherwise, silences for the Grafana managed alerts will be visible by all organizations.
{{% /admonition %}}
1. In the left-side menu, click **Alerts & IRM** and then **Alerting**.
1. Click **Notification policies**.
1. From the **Choose Alertmanager** dropdown, select an external Alertmanager. By default, the **Grafana Alertmanager** is selected.
1. In the Root policy section, click **Edit**.
1. In **Default contact point**, update the contact point to whom notifications should be sent for rules when alert rules do not match any specific policy.
1. In **Group by**, choose labels to group alerts by. If multiple alerts are matched for this policy, then they are grouped by these labels. A notification is sent per group. If the field is empty (default), then all notifications are sent in a single group. Use a special label `...` to group alerts by all labels (which effectively disables grouping).
1. In **Timing options**, select from the following options:
- **Group wait** Time to wait to buffer alerts of the same group before sending an initial notification. Default is 30 seconds.
- **Group interval** Minimum time interval between two notifications for a group. Default is 5 minutes.
- **Repeat interval** Minimum time interval for re-sending a notification if no new alerts were added to the group. Default is 4 hours.
1. Click **Save** to save your changes.
## Add new nested policy
1. In the left-side menu, click **Alerts & IRM** and then **Alerting**.
1. Click **Notification policies**.
1. From the **Choose Alertmanager** dropdown, select an Alertmanager. By default, the **Grafana Alertmanager** is selected.
1. To add a top level specific policy, go to the Specific routing section and click **+New specific policy**.
1. In the Matching labels section, add one or more rules for matching alert labels.
1. In the **Contact point** dropdown, select the contact point to send notification to if alert matches only this specific policy and not any of the nested policies.
1. Optionally, enable **Continue matching subsequent sibling nodes** to continue matching sibling policies even after the alert matched the current policy. When this option is enabled, you can get more than one notification for one alert.
1. Optionally, enable **Override grouping** to specify the same grouping as the default policy. If this option is not enabled, the default policy grouping is used.
1. Optionally, enable **Override general timings** to override the timing options configured in the group notification policy.
1. Click **Save policy** to save your changes.
## Add nested policy
1. In the left-side menu, click **Alerts & IRM** and then **Alerting**.
1. Click **Notification policies**.
1. Expand the specific policy you want to update.
1. Click **+ Add nested policy**, then add the details using information in [Add new specific policy](#add-new-nested-policy).
1. Click **Save policy** to save your changes.
## Edit specific policy
1. In the left-side menu, click **Alerts & IRM**, and then **Alerting**.
1. Click **Notification policies**.
1. Find the policy you want to edit, then click **Edit**.
1. Make any changes using instructions in [Add new specific policy](#add-new-nested-policy).
1. Click **Save policy**.
## Searching for policies
Grafana allows you to search within the tree of policies by the following:
- **Label matchers**
- **Contact Points**
To search by contact point simply select a contact point from the **Search by contact point** dropdown. The policies that use that contact point will be highlighted in the user interface.
To search by label matchers simply enter a valid matcher in the **Search by matchers** input field. Multiple matchers can be combined with a comma (`,`).
An example of a valid matchers search input is:
`severity=high, region=~EMEA|NASA`
> All matched policies will be **exact** matches, we currently do not support regex-style or partial matching.
## Example
An example of an alert configuration.
- Create a "default" contact point for slack notifications, and set it on the default policy.
- Edit the default policy grouping to group alerts by `cluster`, `namespace` and `severity` so that you get a notification per alert rule and specific kubernetes cluster and namespace.
- Create specific route for alerts coming from the development cluster with an appropriate contact point.
- Create a specific route for alerts with "critical" severity with a more invasive contact point integration, like pager duty notification.
- Create specific routes for particular teams that handle their own on-call rotations.
docs/sources/alerting/alerting-rules/declare-incident-from-alert.md
-48
View File
@@ -1,48 +0,0 @@
---
description: Declare an incident from a firing alert
keywords:
- grafana
- alert rules
- incident
title: Declare incidents from firing alerts
weight: 430
---
# Declare incidents from firing alerts
Declare an incident from a firing alert to streamline your alert to incident workflow.
## Before you begin
- Ensure you have Grafana Incident installed
- You must have a firing alert
## Procedure
To declare an incident from a firing alert, complete the following steps.
1. Navigate to Alerts & Incidents -> Alerting -> Alert rules.
2. From the Alert rules list view, click the firing alert that you want to declare an incident for.
**Note:**
You can also access **Declare Incident** from the alert details page.
3. Click **Declare Incident**.
The **Declare Incident** pop-up opens in the Grafana Incident application.
4. In the **Declare Incident** pop-up, enter what's going on.
**Note**: This field is pre-filled with the name of the alert rule, but you can edit it as required.
The alert rule is also linked to the incident.
5. Select a severity.
6. Add labels, as required.
7. Click **More options** to include a channel prefix and status.
8. Click **Declare Incident**.
## Next steps
View and track the incident in the Grafana Incident application.
For more information, refer to [Grafana Incident documentation.](/docs/grafana-cloud/incident/configure-settings/)
docs/sources/alerting/alerting-rules/manage-contact-points/_index.md
+69
View File
@@ -0,0 +1,69 @@
---
aliases:
- ../../contact-points/create-contact-point/
- ../../contact-points/delete-contact-point/
- ../../contact-points/edit-contact-point/
- ../../contact-points/test-contact-point/
- ../create-contact-point/
description: How to manage your contact points
keywords:
- grafana
- alerting
- guide
- contact point
- templating
title: Configure contact points
weight: 410
---
# Configure contact points
Use contact points to define how your contacts are notified when an alert rule fires. You can create, edit, delete, and test a contact point.
## Add a contact point
Complete the following steps to add a contact point.
1. In the left-side menu, click **Alerts & IRM** and then **Alerting**.
1. Click **Contact points**.
1. From the **Choose Alertmanager** dropdown, select an Alertmanager. By default, **Grafana Alertmanager** is selected.
1. Click **+ Add contact point**.
1. In **Name**, enter a descriptive name for the contact point.
1. From **Integration**, select a type and fill out mandatory fields. For example, if you choose email, enter the email addresses. Or if you choose Slack, enter the Slack channel(s) and users who should be contacted.
1. Some contact point integrations, like email or webhook, have optional settings. In **Optional settings**, specify additional settings for the selected contact point integration.
1. In Notification settings, optionally select **Disable resolved message** if you do not want to be notified when an alert resolves.
1. To add another contact point integration, click **Add contact point integration** and repeat steps 6 through 8.
1. Click **Save contact point** to save your changes.
## Edit a contact point
Complete the following steps to edit a contact point.
1. In the left-side menu, click **Alerts & IRM** and then **Alerting**.
1. Click **Contact points** to view a list of existing contact points.
1. Find the contact point to edit, and then click **Edit** (pen icon).
1. Make any changes and click **Save contact point**.
## Delete a contact point
Complete the following steps to delete a contact point.
1. In the left-side menu, click **Alerts & IRM** and then **Alerting**.
1. Click **Contact points** to view a list of existing contact points.
1. Find the contact point to delete, and then click **Delete** (trash icon).
1. In the confirmation dialog, click **Yes, delete**.
{{% admonition type="note" %}}
You cannot delete contact points that are in use by a notification policy. You will have to either delete the notification policy or update it to use another contact point.
{{% /admonition %}}
## Test a contact point
Complete the following steps to test a contact point.
1. In the left-side menu, click **Alerts & IRM** and then **Alerting**.
1. Click **Contact points** to view a list of existing contact points.
1. Find the contact point to test, then click **Edit** (pen icon). You can also create a new contact point if needed.
1. Click **Test** to open the contact point testing modal.
1. Choose whether to send a predefined test notification or choose custom to add your own custom annotations and labels to include in the notification.
1. Click **Send test notification** to fire the alert.
docs/sources/alerting/alerting-rules/manage-contact-points/configure-integrations.md
+67
View File
@@ -0,0 +1,67 @@
---
description: Configure integrations
keywords:
- Grafana
- alerting
- guide
- notifications
- integrations
- contact points
title: Configure integrations
weight: 100
---
# Configure integrations
Configure integrations in Grafana to select your preferred communication channel for receiving notifications when your alert rules are firing. Each integration has its own configuration options and setup process. In most cases, this involves providing an API key or a Webhook URL.
Once configured, you can use integrations as part of your contact points to receive notifications whenever your alert changes its state. In this section, we'll cover the basic steps to configure your integrations, so you can start receiving real-time alerts and stay on top of your monitoring data.
## List of supported integrations
| Name | Type |
| ----------------------- | ------------------------- |
| DingDing | `dingding` |
| Discord | `discord` |
| Email | `email` |
| Google Hangouts Chat | `googlechat` |
| Hipchat | `hipchat` |
| Kafka | `kafka` |
| Line | `line` |
| Microsoft Teams | `teams` |
| Opsgenie | `opsgenie` |
| [Pagerduty](#pagerduty) | `pagerduty` |
| Prometheus Alertmanager | `prometheus-alertmanager` |
| Pushover | `pushover` |
| Sensu | `sensu` |
| Sensu Go | `sensugo` |
| Slack | `slack` |
| Telegram | `telegram` |
| Threema | `threema` |
| VictorOps | `victorops` |
| Webhook | `webhook` |
### PagerDuty
To set up PagerDuty, provide an integration key.
| Setting | Description |
| --------------- | ------------------------------------------------------ |
| Integration Key | Integration key for PagerDuty |
| Severity | Level for dynamic notifications, default is `critical` |
| Custom Details | Additional details about the event |
The `CustomDetails` field is an object containing arbitrary key-value pairs. The user-defined details are merged with the ones we use by default.
Our default values for `CustomDetails` are:
```go
{
"firing": `{{ template "__text_alert_list" .Alerts.Firing }}`,
"resolved": `{{ template "__text_alert_list" .Alerts.Resolved }}`,
"num_firing": `{{ .Alerts.Firing | len }}`,
"num_resolved": `{{ .Alerts.Resolved | len }}`,
}
```
In case of duplicate keys, the user-defined details overwrite the default ones.
docs/sources/alerting/alerting-rules/view-alert-rules.md
-73
View File
@@ -1,73 +0,0 @@
---
aliases:
- ../unified-alerting/alerting-rules/rule-list/
- ../view-alert-rules/
- rule-list/
description: Manage alerting rules
keywords:
- grafana
- alerting
- guide
- rules
- view
title: View and filter alert rules
weight: 410
---
# View and filter alert rules
The Alerting page lists all existing alert rules. By default, rules are grouped by types of data sources. The Grafana section lists all Grafana managed rules. Alert rules for Prometheus compatible data sources are also listed here. You can view alert rules for Prometheus compatible data sources but you cannot edit them.
The Mimir/Cortex/Loki rules section lists all rules for Mimir, Cortex, or Loki data sources. Cloud alert rules are also listed in this section.
When managing large volumes of alerts, you can use extended alert rule search capabilities to filter on folders, evaluation groups, and rules. Additionally, you can filter alert rules by their properties like labels, state, type, and health.
- [View and filter alert rules](#view-and-filter-alert-rules)
- [View alert rules](#view-alert-rules)
- [Export alert rules](#export-alert-rules)
- [View query definitions for provisioned alerts](#view-query-definitions-for-provisioned-alerts)
- [Grouped view](#grouped-view)
- [State view](#state-view)
- [Filter alert rules](#filter-alert-rules)
## View alert rules
To view alerting details:
1. In the Grafana menu, click the **Alerting** (bell) icon to open the Alerting page. By default, the List view displays.
1. In **View as**, toggle between Grouped or State views by clicking the relevant option. See [Grouped view](#grouped-view) and [State view](#state-view) for more information.
1. Expand the rule row to view the rule labels, annotations, data sources the rule queries, and a list of alert instances resulting from this rule.
{{< figure src="/static/img/docs/alerting/unified/rule-details-8-0.png" max-width="650px" caption="Alerting rule details" >}}
From the Alert list page, you can also make copies of alert rules to help you reuse existing alert rules.
## Export alert rules
Click **Export** to create and tune an alert rule in the UI, then export to YAML or JSON, and use in the provisioning API or files. You can also export an entire rule group to review or use.
**Note:** This is supported in both the UI and provisioning API.
## View query definitions for provisioned alerts
View read-only query definitions for provisioned alerts. Check quickly if your alert rule queries are correct, without diving into your "as-code" repository for rule definitions.
### Grouped view
Grouped view shows Grafana alert rules grouped by folder and Loki or Prometheus alert rules grouped by `namespace` + `group`. This is the default rule list view, intended for managing rules. You can expand each group to view a list of rules in this group. Expand a rule further to view its details. You can also expand action buttons and alerts resulting from the rule to view their details.
{{< figure src="/static/img/docs/alerting/unified/rule-list-group-view-8-0.png" max-width="800px" caption="Alerting grouped view" >}}
### State view
State view shows alert rules grouped by state. Use this view to get an overview of which rules are in what state. Each rule can be expanded to view its details. Action buttons and any alerts generated by this rule, and each alert can be further expanded to view its details.
{{< figure src="/static/img/docs/alerting/unified/rule-list-state-view-8-0.png" max-width="800px" caption="Alerting state view" >}}
## Filter alert rules
To filter alert rules:
- From **Select data sources**, select a data source. You can see alert rules that query the selected data source.
- In the **Search by label**, enter search criteria using label selectors. For example, `environment=production,region=~US|EU,severity!=warning`.
- From **Filter alerts by state**, select an alerting state you want to see. You can see alerting rules that match the state. Rules matching other states are hidden.
docs/sources/alerting/alerting-rules/view-state-health.md
-127
View File
@@ -1,127 +0,0 @@
---
aliases:
- ../fundamentals/state-and-health/
- ../unified-alerting/alerting-rules/state-and-health/
- ../view-state-health/
description: State and Health of alerting rules
keywords:
- grafana
- alert rules
- guide
- state
- health
title: View the state and health of alert rules
weight: 420
---
# View the state and health of alert rules
The state and health of alert rules helps you understand several key status indicators about your alerts.
There are three key components: [alert rule state](#alert-rule-state), [alert instance state](#alert-instance-state), and [alert rule health](#alert-rule-health). Although related, each component conveys subtly different information.
To view the state and health of your alert rules:
1. In the left-side menu, click **Alerts & IRM** and then **Alerting**.
1. Click **Alert rules** to view the list of existing alerts.
1. Click an alert rule to view its state, health, and state history.
## Alert rule state
An alert rule can be in either of the following states:
| State | Description |
| ----------- | ---------------------------------------------------------------------------------------------- |
| **Normal** | None of the time series returned by the evaluation engine is in a `Pending` or `Firing` state. |
| **Pending** | At least one time series returned by the evaluation engine is `Pending`. |
| **Firing** | At least one time series returned by the evaluation engine is `Firing`. |
{{% admonition type="note" %}}
Alerts will transition first to `pending` and then `firing`, thus it will take at least two evaluation cycles before an alert is fired.
{{% /admonition %}}
## Alert instance state
An alert instance can be in either of the following states:
| State | Description |
| ------------ | --------------------------------------------------------------------------------------------- |
| **Normal** | The state of an alert that is neither firing nor pending, everything is working correctly. |
| **Pending** | The state of an alert that has been active for less than the configured threshold duration. |
| **Alerting** | The state of an alert that has been active for longer than the configured threshold duration. |
| **NoData** | No data has been received for the configured time window. |
| **Error** | The error that occurred when attempting to evaluate an alerting rule. |
## Alert rule health
An alert rule can have one the following health statuses:
| State | Description |
| ---------- | ---------------------------------------------------------------------------------- |
| **Ok** | No error when evaluating an alerting rule. |
| **Error** | An error occurred when evaluating an alerting rule. |
| **NoData** | The absence of data in at least one time series returned during a rule evaluation. |
## Special alerts for `NoData` and `Error`
When evaluation of an alerting rule produces state `NoData` or `Error`, Grafana Alerting will generate alert instances that have the following additional labels:
| Label | Description |
| ------------------ | ---------------------------------------------------------------------- |
| **alertname** | Either `DatasourceNoData` or `DatasourceError` depending on the state. |
| **datasource_uid** | The UID of the data source that caused the state. |
You can handle these alerts the same way as regular alerts by adding a silence, route to a contact point, and so on.
## State history view
Use the State history view to get insight into how your alert instances behave over time. View information on when a state change occurred, what the previous state was, the current state, any other alert instances that changed their state at the same time as well as what the query value was that triggered the change.
### Configure the state history view
**Note:** This applies to Open Source only. There is no configuration required if you are using Grafana Cloud.
To enable the state history view, complete the following steps.
1. Ensure you have a Loki instance running to save your history to.
1. Configure the following settings in your Grafana configuration:
a. Enable the Loki backend and Loki remote URL.
b. Enable the three feature toggles for alert state history.
**Example:**
```
[unified_alerting.state_history]
enabled = true
backend = loki
loki_remote_url = http://localhost:3100
[feature_toggles]
enable = alertStateHistoryLokiSecondary, alertStateHistoryLokiPrimary, alertStateHistoryLokiOnly
```
### View state history
To use the State history view, complete the following steps.
1. Navigate to **Alerts&IRM** -> **Alerting** -> **Alert rules**.
1. Click an alert rule.
1. Select **Show state history**.
The State history view opens.
The timeline view at the top displays a timeline of changes for the past hour, so you can track how your alert instances are behaving over time.
The bottom part shows the alert instances, their previous and current state, the value of each part of the expression and a unique set of labels.
Common labels are displayed at the top to make it easier to identify different alert instances.
1. From the timeline view, hover over a time to get an automatic display of all the changes that happened at that particular moment.
These changes are displayed in real time in the timestamp view at the bottom of the page. The timestamp view is a list of all the alert instances that changed state at that point in time. The visualization only displays 12 instances by default.
The value shown for each instance is for each part of the expression that was evaluated.
1. Click the labels to filter and narrow down the results.