# LibreNMS

EvoHub receives LibreNMS alerts through an alert transport of type **API**. A rule that fires opens an EvoHub alert; its recovery resolves it.

## Set it up

:::steps
### Create the integration
In EvoHub, go to **On-Call → Integrations → + Add Integration**, choose **LibreNMS**, pick an **Escalation Policy** and click **Create Integration**. Copy the **Webhook URL**.
### Create the transport
In LibreNMS, go to **Alerts → Alert Transports → Create alert transport** and choose the type **API**. Set **API Method** to `POST`, **API URL** to your webhook URL, **Headers** to `Content-Type=application/json`, and paste the body below on one line.
### Test it
Click **Test**. LibreNMS sends its test alert; EvoHub answers with success and opens no alert.
### Use it in rules
Attach the transport to your alert rules (or make it a default transport) and keep **Recovery alerts** on in each rule. Without it LibreNMS never tells EvoHub the alert has cleared.
:::

```json
{"title":"{{ $title }}","rule":"{{ $name }}","rule_id":"{{ $rule_id }}","alert_id":"{{ $alert_id }}","device_id":"{{ $device_id }}","hostname":"{{ $hostname }}","sysName":"{{ $sysName }}","ip":"{{ $ip }}","os":"{{ $os }}","location":"{{ $location }}","severity":"{{ $severity }}","state":"{{ $state }}","timestamp":"{{ $timestamp }}"}
```

> [!NOTE]
> LibreNMS puts values into the body without escaping them. EvoHub copes with line breaks inside values, but a double quote inside a value breaks the JSON and the delivery is refused. That is why the template leaves out free-text variables such as `$msg`. The same fields also work with **Send as form**.

## What EvoHub reads

| EvoHub alert | Taken from |
| --- | --- |
| Title | `title`, or the rule name and host name. |
| Description | The rule and the device (host name, sysName, IP). |
| Labels | `hostname`, `sysName`, `ip`, `os`, `location`, `rule`, `rule_id`, `device_id`, `severity`, `state`, `timestamp`. |

### Severity

| LibreNMS severity | EvoHub severity |
| --- | --- |
| critical | critical |
| warning | medium |

## Resolve and deduplication

An alert is identified by the rule and the device. States *active*, *worse*, *better* and *changed* open the alert or are recorded as **Retriggered** on it; *recovered* (state `0`) resolves it. Acknowledging the alert in LibreNMS (state `2`) changes nothing in EvoHub.

## Related

- [Integrations overview](https://docs-dev.evohub.io/integrations-overview.md)
- [ManageEngine OpManager](https://docs-dev.evohub.io/manageengine-opmanager.md)