# Nagios

EvoHub receives Nagios notifications through two notification commands that post JSON with `curl`, one for services and one for hosts. A PROBLEM notification opens an EvoHub alert, and the RECOVERY notification resolves it.

## Set it up

:::steps
### Create the integration
In EvoHub, go to **On-Call → Integrations → + Add Integration**, choose **Nagios**, pick an **Escalation Policy** and click **Create Integration**. Copy the **Webhook URL**.
### Add the notification commands
Add the two commands below to `commands.cfg`, with your webhook URL in place of the example. The `$…$` parts are Nagios macros, filled in automatically.
### Use them on the contact
On the contact your hosts and services notify, set the notification commands and options below, then reload Nagios.
:::

Commands:

```text
define command {
  command_name  notify-evohub
  command_line  /usr/bin/curl -s -X POST "https://evohub.io/ingest/nagios?key=YOUR_INTEGRATION_KEY" -H "Content-Type: application/json" -d '{"host":"$HOSTNAME$","service":"$SERVICEDESC$","state":"$SERVICESTATE$","notification_type":"$NOTIFICATIONTYPE$","output":"$SERVICEOUTPUT$"}'
}

define command {
  command_name  notify-evohub-host
  command_line  /usr/bin/curl -s -X POST "https://evohub.io/ingest/nagios?key=YOUR_INTEGRATION_KEY" -H "Content-Type: application/json" -d '{"host":"$HOSTNAME$","service":"","state":"$HOSTSTATE$","notification_type":"$NOTIFICATIONTYPE$","output":"$HOSTOUTPUT$"}'
}
```

Contact settings:

```text
service_notification_commands  notify-evohub
service_notification_options   w,u,c,r
host_notification_commands     notify-evohub-host
host_notification_options      d,u,r
```

Check output goes into the JSON unescaped. EvoHub repairs what that breaks — stray backslashes (Windows paths such as `c:\`), double quotes and line breaks — so such alerts still arrive. Nagios itself strips the characters listed in `illegal_macro_output_chars` (quotes, by default).

## Turn on auto-resolve

Keep the `r` in both notification options. It is what makes Nagios send RECOVERY notifications; without it nothing resolves.

## What EvoHub reads

| EvoHub alert | Taken from |
| --- | --- |
| Title | "`host`/`service` is `state`" for a service, for example "web-01/HTTP is CRITICAL"; "Host `host` is `state`" for a host. |
| Description | `output`, the check output. |
| Labels | `host`, `state` and, for services, `service`. |
| Fingerprint | The host and service together (the host alone for host alerts). |

### Severity

| Nagios state | EvoHub severity |
| --- | --- |
| CRITICAL, DOWN, UNREACHABLE | critical |
| WARNING | medium |
| UNKNOWN | low |
| anything else | medium |

## Resolve and deduplication

- A **PROBLEM** notification opens an alert. A **RECOVERY** notification resolves the open alert for the same host and service.
- **ACKNOWLEDGEMENT**, **FLAPPINGSTART**/**FLAPPINGSTOP** and **DOWNTIMESTART**/**DOWNTIMEEND** notifications are answered with success and change nothing.
- A notification with an empty `notification_type` is treated as a problem, so keep `$NOTIFICATIONTYPE$` in the command — without it, a recovery would open an alert instead of resolving one.
- Because the fingerprint is host plus service, repeated problem notifications are recorded as **Retriggered** on the open alert, and the same service on different hosts opens separate alerts. A service going from WARNING to CRITICAL stays one alert.

## Troubleshooting

- **Nothing arrives**: run the `command_line` by hand with sample values and read EvoHub's answer. `INVALID_KEY` means the key is wrong or the integration is disabled.
- **`INVALID_BODY`**: the body is not a JSON object. Check that the `-d '…'` part was copied whole.
- **Alerts never resolve**: the contact's notification options are missing `r`.

## Related

- [Integrations overview](https://docs.evohub.io/integrations-overview.md)
- [Icinga](https://docs.evohub.io/icinga.md)
- [Escalation policies](https://docs.evohub.io/escalation-policies.md)