> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/integrations/inbound-integrations/checkmk/check-mk.md).

# Checkmk Integration (v 1.x)

Send Checkmk 1.x notifications to ilert with the ilert notification plugin, installed on an OMD site.

Checkmk 1.x has no built-in ilert method, so you install the ilert plugin on the Checkmk server and add a notification rule that calls it. A problem opens an alert, an acknowledgment accepts it, and a recovery resolves it. On Checkmk 2.0 or later, use the [built-in method](/integrations/inbound-integrations/checkmk/native.md) instead.

## Requirements

* A Checkmk 1.x site managed with `omd`, and root access to the server. This guide does not cover installs without `omd`; for those, contact <support@ilert.com>.
* Python 2.7.9 or later, which the site provides. Checkmk 1.6 runs Python 2.7 and has no `python3` of its own, so these steps use the files from the plugin's `python2` folder.
* Outbound HTTPS from the Checkmk server to `api.ilert.com`.

These steps were last run against Checkmk Raw Edition 1.6.0p30.

## In ilert: Create a Nagios / Icinga alert source <a href="#create-alarm-source" id="create-alarm-source"></a>

The plugin sends events in Nagios format, so the alert source type is **Nagios / Icinga**, not **checkmk**.

1. Go to **Alerting** → **Alert sources** and click **Create new alert source**.
2. Search for **Nagios**, click the **Nagios / Icinga** tile, and click **Next**.
3. Give your alert source a name, optionally assign teams, and click **Next**.
4. Choose who gets notified: select **Use existing escalation policy** and pick a policy, or **Generate new escalation policy** to start with a basic one that notifies you first. Click **Next**.

   <figure><img src="https://3394882078-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M76ygPnS4HUcFSX8ulm%2Fuploads%2Fgit-blob-8a281bf3931f5a1a531951ce97984d50989dd875%2Falert-source-escalation-step.png?alt=media" alt="The escalation step of the ilert alert source wizard, headed Who should be notified about alerts, with an escalation policy selected and a preview of its escalation rules below."><figcaption><p>Pick an existing escalation policy, or generate a basic one without leaving the wizard.</p></figcaption></figure>
5. Select **Default grouping** and click **Continue setup**. It groups events by the [alert key](#what-each-notification-does-in-ilert) the plugin sets; the other [grouping options](/alerting/configure-alerting/alert-sources.md#event-grouping) are easier to judge once events are arriving.
6. The next page shows more settings, such as notification priority and alert templates. Click **Finish setup** for now; you can change them later.
7. On the final page, ilert shows the integration key for this alert source. Copy it; you will paste it into the notification rule in the next section.

## In Checkmk: Configure the ilert plugin <a href="#configure-ilert-plugin" id="configure-ilert-plugin"></a>

{% stepper %}
{% step %}

### Install the plugin

Run this as root, with `YOUR_SITE` replaced by the name of your site. It puts the plugin in `/usr/local/bin` and the notification script in the site's notifications directory.

```bash
curl -sSLO https://github.com/iLert/ilert-nagios/archive/refs/tags/v1.7.1.tar.gz
tar xzf v1.7.1.tar.gz
cd ilert-nagios-1.7.1/python2
install -m 755 ilert_nagios.py /usr/local/bin/ilert_nagios.py
install -m 755 -o YOUR_SITE -g YOUR_SITE ilert_check_mk.sh /omd/sites/YOUR_SITE/local/share/check_mk/notifications/ilert_check_mk.sh
```

{% endstep %}

{% step %}

### Add the retry job

The plugin keeps an event it could not send in `/tmp/ilert_nagios`. This cron job sends those events every minute. Run it as the site user:

```bash
su - YOUR_SITE
echo '* * * * * /usr/local/bin/ilert_nagios.py -m send' > ~/etc/cron.d/ilert
omd reload crontab
exit
```

{% endstep %}

{% step %}

### Add a notification rule

In Checkmk's web interface, open **Notifications** in the WATO configuration and click **New Rule**.

1. Under **Notification Method**, select **iLert Check\_MK Plugin**, keep **Call with the following parameters:**, and paste the integration key into the field below it.
2. Under **Contact Selection**, clear **All contacts of the notified object**, select **The following users**, and add one user. On a host without contacts, the default creates no notification. One user is enough, because Checkmk sends one notification per recipient.
3. Click **Save**, and activate the pending change.
   {% endstep %}
   {% endstepper %}

## Test the integration <a href="#test" id="test"></a>

{% hint style="warning" %}
This opens a real alert in ilert, and the alert source's escalation policy notifies whoever it names.
{% endhint %}

Open a host in Checkmk, click the hammer icon (**Execute commands on hosts, services and other objects**), and under **Fake check results** enter a message in **Plugin output:**, click **Down**, and confirm. The alert appears under **Alerts** with a summary such as `PROBLEM Host Alert: acme-web-1 is DOWN - Test from Checkmk`.

Under **Fake check results**, click **Up** and confirm. The alert changes to **Resolved**.

## What each notification does in ilert

| Notification type                                                    | What ilert does                                                                                                            |
| -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `PROBLEM`                                                            | Opens an alert and starts its escalation policy. If an alert with the same key is still open, the event goes to that alert |
| `ACKNOWLEDGEMENT`                                                    | Accepts the alert, which stops its escalation. Keep **send notification** on when you acknowledge the problem              |
| `RECOVERY`                                                           | Resolves the alert                                                                                                         |
| Any other type, such as `DOWNTIMESTART`, `FLAPPINGSTART` or `CUSTOM` | Nothing. ilert takes the event and opens no alert                                                                          |

The **alert key** is `HOSTADDRESS` for a host and `HOSTADDRESS-SERVICEDESC` for a service, for example `192.0.2.10-Memory`. With **Default grouping**, events with the same key belong to one alert, so two hosts with the same address share their host alert.

## FAQ <a href="#faq" id="faq"></a>

**What happens if the connection to ilert is interrupted?**

The plugin keeps the event in `/tmp/ilert_nagios` after a network error, an HTTP 429 or a server error, and the retry job sends it within a minute of the connection coming back. Events in that directory are lost if `/tmp` is cleared, for example at a reboot.

**Will alerts in ilert be resolved automatically?**

Yes, as soon as the host or service is UP or OK again in Checkmk.

**Can I send notifications to more than one alert source?**

Yes. Add one notification rule per alert source, each with that alert source's integration key and conditions that select its hosts.

**The plugin does not work. How do I find the issue?**

Look at `~/var/log/notify.log` as the site user. It shows which rules matched and whether the script ran. The plugin itself writes to the system log, such as `/var/log/syslog` or `/var/log/messages`, with the tag `ilert_nagios.py`:

* `HTTP 400 invalid API key` means the key in the rule is wrong, or the alert source's key has been rotated. The plugin deletes an event that ilert rejects, so that notification does not come back.
* `could not send event to iLert` means the server cannot reach `api.ilert.com`. The event waits for the retry job.

The Checkmk documentation describes [the path of a notification](https://docs.checkmk.com/latest/en/notifications.html) and its log files. If you cannot find the cause, contact <support@ilert.com>.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ilert.com/integrations/inbound-integrations/checkmk/check-mk.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
