diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-05-19 18:44:42 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-05-19 18:44:42 +0300 |
commit | 4555e1b21c365ed8303ffb7a3325d773c9b8bf31 (patch) | |
tree | 5423a1c7516cffe36384133ade12572cf709398d /doc/operations/incident_management | |
parent | e570267f2f6b326480d284e0164a6464ba4081bc (diff) |
Add latest changes from gitlab-org/gitlab@13-12-stable-eev13.12.0-rc42
Diffstat (limited to 'doc/operations/incident_management')
-rw-r--r-- | doc/operations/incident_management/alert_notifications.md | 8 | ||||
-rw-r--r-- | doc/operations/incident_management/alerts.md | 14 | ||||
-rw-r--r-- | doc/operations/incident_management/img/alert_detail_added_todo_v13_1.png | bin | 18170 -> 0 bytes | |||
-rw-r--r-- | doc/operations/incident_management/img/alert_details_assignees_v13_1.png | bin | 31091 -> 28017 bytes | |||
-rw-r--r-- | doc/operations/incident_management/img/alert_list_assignees_v13_1.png | bin | 29011 -> 0 bytes | |||
-rw-r--r-- | doc/operations/incident_management/img/alert_todo_assignees_v13_1.png | bin | 10157 -> 0 bytes | |||
-rw-r--r-- | doc/operations/incident_management/incidents.md | 16 | ||||
-rw-r--r-- | doc/operations/incident_management/integrations.md | 23 | ||||
-rw-r--r-- | doc/operations/incident_management/oncall_schedules.md | 7 |
9 files changed, 45 insertions, 23 deletions
diff --git a/doc/operations/incident_management/alert_notifications.md b/doc/operations/incident_management/alert_notifications.md deleted file mode 100644 index 4f46c2bec71..00000000000 --- a/doc/operations/incident_management/alert_notifications.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -redirect_to: 'paging.md' ---- - -This document was moved to [another location](paging.md). - -<!-- This redirect file can be deleted after 2021-04-21 --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/operations/incident_management/alerts.md b/doc/operations/incident_management/alerts.md index 276009ac200..c49684954d9 100644 --- a/doc/operations/incident_management/alerts.md +++ b/doc/operations/incident_management/alerts.md @@ -33,9 +33,10 @@ The alert list displays the following information: - **Event count**: The number of times that an alert has fired. - **Issue**: A link to the incident issue that has been created for the alert. - **Status**: The current status of the alert: - - **Triggered**: No one has begun investigation. + - **Triggered**: Investigation has not started. - **Acknowledged**: Someone is actively investigating the problem. - **Resolved**: No further work is required. + - **Ignored**: No action will be taken on the alert. NOTE: Check out a live example available from the @@ -167,22 +168,19 @@ difficult to track who is investigating and working on it. Assigning alerts ease To assign an alert: -1. To display the list of current alerts, navigate to **Operations > Alerts**: - - ![Alert List View Assignee(s)](img/alert_list_assignees_v13_1.png) +1. To display the list of current alerts, navigate to **Operations > Alerts**. -1. Select your desired alert to display its **Alert Details View**: +1. Select your desired alert to display its details. ![Alert Details View Assignee(s)](img/alert_details_assignees_v13_1.png) 1. If the right sidebar is not expanded, select **{angle-double-right}** **Expand sidebar** to expand it. + 1. In the right sidebar, locate the **Assignee**, and then select **Edit**. From the dropdown menu, select each user you want to assign to the alert. GitLab creates a [to-do item](../../user/todos.md) for each user. - ![Alert Details View Assignee(s)](img/alert_todo_assignees_v13_1.png) - After completing their portion of investigating or fixing the alert, users can unassign themselves from the alert. To remove an assignee, select **Edit** next to the **Assignee** dropdown menu and deselect the user from the list of assignees, or select **Unassigned**. @@ -203,8 +201,6 @@ add a to-do item: Select the **To-Do List** **{todo-done}** in the navigation bar to view your current to-do list. -![Alert Details Added to do](img/alert_detail_added_todo_v13_1.png) - ## Link runbooks to alerts > Runbook URLs [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39315) in GitLab 13.3. diff --git a/doc/operations/incident_management/img/alert_detail_added_todo_v13_1.png b/doc/operations/incident_management/img/alert_detail_added_todo_v13_1.png Binary files differdeleted file mode 100644 index ae874706895..00000000000 --- a/doc/operations/incident_management/img/alert_detail_added_todo_v13_1.png +++ /dev/null diff --git a/doc/operations/incident_management/img/alert_details_assignees_v13_1.png b/doc/operations/incident_management/img/alert_details_assignees_v13_1.png Binary files differindex dab4eac384a..29cdba2c9ab 100644 --- a/doc/operations/incident_management/img/alert_details_assignees_v13_1.png +++ b/doc/operations/incident_management/img/alert_details_assignees_v13_1.png diff --git a/doc/operations/incident_management/img/alert_list_assignees_v13_1.png b/doc/operations/incident_management/img/alert_list_assignees_v13_1.png Binary files differdeleted file mode 100644 index db1e0d8dcb7..00000000000 --- a/doc/operations/incident_management/img/alert_list_assignees_v13_1.png +++ /dev/null diff --git a/doc/operations/incident_management/img/alert_todo_assignees_v13_1.png b/doc/operations/incident_management/img/alert_todo_assignees_v13_1.png Binary files differdeleted file mode 100644 index 637f8be5d25..00000000000 --- a/doc/operations/incident_management/img/alert_todo_assignees_v13_1.png +++ /dev/null diff --git a/doc/operations/incident_management/incidents.md b/doc/operations/incident_management/incidents.md index 078a1a0be08..d09dbd2cb04 100644 --- a/doc/operations/incident_management/incidents.md +++ b/doc/operations/incident_management/incidents.md @@ -267,3 +267,19 @@ any other Markdown text field in GitLab by You can embed both [GitLab-hosted metrics](../metrics/embed.md) and [Grafana metrics](../metrics/embed_grafana.md) in incidents and issue templates. + +### Automatically close incidents via recovery alerts + +> - [Introduced for Prometheus Integrations](https://gitlab.com/gitlab-org/gitlab/-/issues/13401) in GitLab 12.5. +> - [Introduced for HTTP Integrations](https://gitlab.com/gitlab-org/gitlab/-/issues/13402) in GitLab 13.4. + +With Maintainer or higher [permissions](../../user/permissions.md), you can enable + GitLab to close an incident automatically when a **Recovery Alert** is received: + +1. Navigate to **Settings > Operations > Incidents** and expand **Incidents**. +1. Check the **Automatically close associated Incident** checkbox. +1. Click **Save changes**. + +When GitLab receives a **Recovery Alert**, it closes the associated incident. +This action is recorded as a system message on the incident indicating that it +was closed automatically by the GitLab Alert bot. diff --git a/doc/operations/incident_management/integrations.md b/doc/operations/incident_management/integrations.md index c675d995444..07ffb92a000 100644 --- a/doc/operations/incident_management/integrations.md +++ b/doc/operations/incident_management/integrations.md @@ -97,17 +97,17 @@ to configure alerts for this integration. ## Customize the alert payload outside of GitLab -For all integration types, you can customize the payload by sending the following +For HTTP Endpoints without [custom mappings](#map-fields-in-custom-alerts), you can customize the payload by sending the following parameters. All fields are optional. If the incoming alert does not contain a value for the `Title` field, a default value of `New: Alert` will be applied. | Property | Type | Description | | ------------------------- | --------------- | ----------- | -| `title` | String | The title of the incident. | +| `title` | String | The title of the alert.| | `description` | String | A high-level summary of the problem. | -| `start_time` | DateTime | The time of the incident. If none is provided, a timestamp of the issue is used. | -| `end_time` | DateTime | For existing alerts only. When provided, the alert is resolved and the associated incident is closed. | +| `start_time` | DateTime | The time of the alert. If none is provided, a current time is used. | +| `end_time` | DateTime | The resolution time of the alert. If provided, the alert is resolved. | | `service` | String | The affected service. | -| `monitoring_tool` | String | The name of the associated monitoring tool. | +| `monitoring_tool` | String | The name of the associated monitoring tool. | | `hosts` | String or Array | One or more hosts, as to where this incident occurred. | | `severity` | String | The severity of the alert. Case-insensitive. Can be one of: `critical`, `high`, `medium`, `low`, `info`, `unknown`. Defaults to `critical` if missing or value is not in this list. | | `fingerprint` | String or Array | The unique identifier of the alert. This can be used to group occurrences of the same alert. | @@ -168,7 +168,7 @@ alert to confirm your integration works properly. 1. Sign in as a user with Developer or greater [permissions](../../user/permissions.md). 1. Navigate to **Settings > Operations** in your project. 1. Click **Alert integrations** to expand the section. -1. Click the **{settings}** settings icon on the right side of the integration in [the list](#integrations-list). +1. Click the **{settings}** settings icon on the right side of the integration in [the list](#integrations-list). 1. Select the **Send test alert** tab to open it. 1. Enter a test payload in the payload field (valid JSON is required). 1. Click **Send**. @@ -189,6 +189,17 @@ If the existing alert is already `resolved`, GitLab creates a new alert instead. ![Alert Management List](img/alert_list_v13_1.png) +## Recovery alerts + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13402) in GitLab 13.4. + +The alert in GitLab will be automatically resolved when an HTTP Endpoint +receives a payload with the end time of the alert set. For HTTP Endpoints +without [custom mappings](#map-fields-in-custom-alerts), the expected +field is `end_time`. With custom mappings, you can select the expected field. + +You can also configure the associated [incident to be closed automatically](../incident_management/incidents.md#automatically-close-incidents-via-recovery-alerts) when the alert resolves. + ## Link to your Opsgenie Alerts > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in GitLab Premium 13.2. diff --git a/doc/operations/incident_management/oncall_schedules.md b/doc/operations/incident_management/oncall_schedules.md index 87745639c69..695b42f7d1a 100644 --- a/doc/operations/incident_management/oncall_schedules.md +++ b/doc/operations/incident_management/oncall_schedules.md @@ -107,3 +107,10 @@ Hover over any rotation shift participants in the schedule to view their individ When an alert is created in a project, GitLab sends an email to the on-call responder(s) in the on-call schedule for that project. If there is no schedule or no one on-call in that schedule at the time the alert is triggered, no email is sent. + +## Removal or deletion of on-call user + +If an on-call user is removed from the project or group, or their account is deleted, the +confirmation modal displays the list of that user's on-call schedules. If the user's removal or +deletion is confirmed, GitLab recalculates the on-call rotation and sends an email to the project +owners and the rotation's participants. |