# Sumo Logic

EvoHub receives Sumo Logic monitor notifications through a **webhook connection**. The same body is used for the alert and the recovery payload; the recovery resolves the EvoHub alert.

## Set it up

:::steps
### Create the integration
In EvoHub, go to **On-Call → Integrations → + Add Integration**, choose **Sumo Logic**, pick an **Escalation Policy** and click **Create Integration**. Copy the **Webhook URL**.
### Create the connection
In Sumo Logic, go to **Monitoring → Connections** (Classic UI: **Manage Data → Monitoring → Connections**), add a connection and choose **Webhook**. Set **URL** to your webhook URL and paste the body below as both the **Alert Payload** and the **Recovery Payload**.
### Use it in monitors
In each monitor, under **Notifications**, add the connection, select the trigger types to send and turn on **Recovery**.
:::

```json
{"id":"{{Id}}","name":"{{Name}}","description":"{{Description}}","trigger_type":"{{TriggerType}}","trigger_value":"{{TriggerValue}}","trigger_condition":"{{TriggerCondition}}","num_results":"{{NumQueryResults}}","query_url":"{{QueryURL}}","alert_url":"{{AlertResponseUrl}}"}
```

Leave a bare `{{ResultsJson}}` out of the body: Sumo Logic inserts it as raw JSON, and the empty result of a recovery would make the body unreadable.

### Monitors with alert grouping

A monitor with **alert grouping** sends one notification per group (per host, say). With the body above all groups share one EvoHub alert, because the alert is identified by the monitor. To get one alert per group, add the grouping field to the body before the closing `}`:

```json
,"group":"{{ResultsJson._sourceHost}}"
```

The alert is then identified by the monitor and the group, and a recovery resolves only its own group's alert. That needs the field in the **Recovery Payload** too: if it comes through empty there, the recovery cannot find the group's alert — leave `group` out and keep one alert per monitor.

## What EvoHub reads

| EvoHub alert | Taken from |
| --- | --- |
| Title | `name` (the monitor name). |
| Description | `description`. |
| Labels | `monitor_id`, `group`, `trigger_type`, `trigger_value`, `trigger_condition`, `num_results`, `query_url`, and `url` (the alert response page). |

### Severity

| Trigger type | EvoHub severity |
| --- | --- |
| Critical | critical |
| Warning | medium |
| Missing Data | low |
| Normal | high |
| ResolvedCritical, ResolvedWarning, ResolvedMissingData | resolves the alert |

## Resolve and deduplication

An alert is identified by the monitor, or by the monitor and the group when the body has one. A repeat while it is open is recorded as **Retriggered**, and the recovery payload resolves it.

## Related

- [Integrations overview](https://docs.evohub.io/integrations-overview.md)
- [Elastic / Kibana](https://docs.evohub.io/elastic-kibana.md)