debian-mirror-gitlab/doc/user/project/integrations/generic_alerts.md

70 lines
2.7 KiB
Markdown
Raw Normal View History

2020-05-24 23:13:21 +05:30
---
stage: Monitor
group: Health
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
---
2020-03-13 15:44:24 +05:30
# Generic alerts integration
2019-12-04 20:38:33 +05:30
2020-03-13 15:44:24 +05:30
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13203) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.4.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/issues/42640) to [GitLab Core](https://about.gitlab.com/pricing/) in 12.8.
2019-12-04 20:38:33 +05:30
GitLab can accept alerts from any source via a generic webhook receiver.
When you set up the generic alerts integration, a unique endpoint will
be created which can receive a payload in JSON format, and will in turn
create an issue with the payload in the body of the issue. You can always
[customize the payload](#customizing-the-payload) to your liking.
The entire payload will be posted in the issue discussion as a comment
authored by the GitLab Alert Bot.
## Setting up generic alerts
2019-12-21 20:55:43 +05:30
To set up the generic alerts integration:
2019-12-04 20:38:33 +05:30
2019-12-21 20:55:43 +05:30
1. Navigate to **Settings > Integrations** in a project.
2019-12-26 22:10:19 +05:30
1. Click on **Alerts endpoint**.
2020-04-22 19:07:51 +05:30
1. Toggle the **Active** alert setting. The `URL` and `Authorization Key` for the webhook configuration can be found there.
2019-12-04 20:38:33 +05:30
## Customizing the payload
You can customize the payload by sending the following parameters. All fields are optional:
| Property | Type | Description |
| -------- | ---- | ----------- |
2020-05-24 23:13:21 +05:30
| `title` | String | The title of the incident. Required. |
2019-12-04 20:38:33 +05:30
| `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 will be used. |
| `service` | String | The affected service. |
| `monitoring_tool` | String | The name of the associated monitoring tool. |
2020-03-13 15:44:24 +05:30
| `hosts` | String or Array | One or more hosts, as to where this incident occurred. |
2020-05-24 23:13:21 +05:30
| `severity` | String | The severity of the alert. Must be one of `critical`, `high`, `medium`, `low`, `info`, `unknown`. Default is `critical`. |
TIP: **Payload size:**
Ensure your requests are smaller than the [payload application limits](../../../administration/instance_limits.md#generic-alert-json-payloads).
2019-12-04 20:38:33 +05:30
Example request:
2020-03-13 15:44:24 +05:30
```shell
2019-12-21 20:55:43 +05:30
curl --request POST \
--data '{"title": "Incident title"}' \
2019-12-26 22:10:19 +05:30
--header "Authorization: Bearer <authorization_key>" \
2019-12-21 20:55:43 +05:30
--header "Content-Type: application/json" \
<url>
2019-12-04 20:38:33 +05:30
```
2019-12-26 22:10:19 +05:30
The `<authorization_key>` and `<url>` values can be found when [setting up generic alerts](#setting-up-generic-alerts).
2019-12-04 20:38:33 +05:30
Example payload:
```json
{
"title": "Incident title",
"description": "Short description of the incident",
"start_time": "2019-09-12T06:00:55Z",
"service": "service affected",
"monitoring_tool": "value",
"hosts": "value",
}
```