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

# OpenSearch Integration

OpenSearch's Alerting plugin can send every triggered monitor straight into ITOC360, where it becomes an alert and follows your on-call routing rules.

Unlike most tools, OpenSearch doesn't have a fixed alert payload — you decide what the webhook sends by writing a short message template. This page gives you that template, so you only need to copy it once.

### Before you start

You'll need:

* OpenSearch 2.0 or later, with the Alerting and Notifications plugins enabled
* A monitor that's already running (this page doesn't cover creating monitors)
* Your ITOC360 OpenSearch webhook URL, which includes your source token

> In OpenSearch 2.0 the old Alerting **Destinations** were replaced by **Notifications → Channels**. If your cluster still shows a Destinations tab, it will simply point you to Notifications.

### Get your webhook URL from ITOC360

1. In ITOC360, open **Integrations** and add a new **OpenSearch** integration.
2. Give it a name that matches the cluster or team it belongs to.
3. Copy the generated webhook URL. It already contains your source token, so treat it like a password.

### Create a notification channel in OpenSearch

Open the main menu and go to **Notifications → Channels**, then click **Create channel**.

<figure><img src="/files/dVzfapUPJyeJmaiXLyk3" alt="" width="563"><figcaption></figcaption></figure>

Fill in the form as follows:

| Field               | Value                                                                                                                             |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Name                | `itoc360`                                                                                                                         |
| Channel type        | Custom webhook                                                                                                                    |
| Method              | POST                                                                                                                              |
| Define endpoints by | Webhook URL                                                                                                                       |
| Webhook URL         | [https://api.itoc360.app/functions/v1/events?token=\<x-itoc-360>](https://api.itoc360.app/functions/v1/events?token=<x-itoc-360>) |
| Webhook header      | `Content-Type` → `application/json`                                                                                               |

<figure><img src="/files/kwBIB61SSvsyWN8Rg1C3" alt="" width="563"><figcaption></figcaption></figure>

Click **Create**. The channel is now available to every monitor in the cluster.

You can use **Send test message** to confirm the endpoint is reachable. Keep in mind that the test message is plain text rather than your template, so ITOC360 won't create an alert from it — it only proves the connection works.

### Add an action to your trigger

Open the monitor you want to forward, click **Edit**, and scroll down to **Triggers**. Expand the trigger you want to use and take note of its **Severity level** — ITOC360 uses that value to set the alert's priority.

<figure><img src="/files/k7W6JjPxUgMVH1xaxHqK" alt="" width="563"><figcaption></figcaption></figure>

Under **Actions**, add an action:

1. Give the action a name.
2. Select the ITOC360 channel you just created.
3. Replace the contents of the **Message** box with the template below.

```
{
  "title": "{{ctx.monitor.name}} - {{ctx.trigger.name}}",
  "description": "{{ctx.monitor.name}} just entered Triggered status.",
  "monitor_name": "{{ctx.monitor.name}}",
  "alert_id": "{{ctx.trigger.id}}",
  "alert_time": "{{ctx.periodStart}}",
  "alert_severity": "{{ctx.trigger.severity}}",
  "status": "ALERT"
}
```

<figure><img src="/files/Ey7fVm687tHwvk6cVcGF" alt="" width="563"><figcaption></figcaption></figure>

Save the monitor. From now on, every time this trigger fires, itoc360 receives an alert.

### Close alerts automatically

OpenSearch doesn't send a notification when a condition stops matching, so recovery needs its own trigger. Add a second trigger to the same monitor:

1. Name it something like `<your-trigger>-resolve`.
2. Invert the trigger condition. If your alert trigger uses `ctx.results[0].hits.total.value > 0`, the recovery trigger uses:

```
ctx.results[0].hits.total.value == 0
```

3. Add an action pointing at the same ITOC360 channel, with this message template:

```
{
  "title": "{{ctx.monitor.name}} - {{ctx.trigger.name}}",
  "description": "{{ctx.monitor.name}} just returned to normal status.",
  "monitor_name": "{{ctx.monitor.name}}",
  "alert_id": "{{ctx.trigger.id}}",
  "alert_time": "{{ctx.periodStart}}",
  "alert_severity": "{{ctx.trigger.severity}}",
  "status": "RESOLVED"
}
```

The only difference from the first template is the `status` field. When ITOC360 receives `RESOLVED`, it closes the open alert for that monitor.

### Priority mapping

OpenSearch severity levels run from 1 to 5, where 1 is the most urgent. itoc360 maps them like this:

| OpenSearch severity | itoc360 priority |
| ------------------- | ---------------- |
| 1 (Highest)         | Critical         |
| 2                   | High             |
| 3                   | Medium           |
| 4                   | Low              |
| 5 (Lowest)          | Low              |

If a payload arrives without a severity, the alert is created with Medium priority.

### Verify the integration

The quickest way to confirm everything works end to end is to let the monitor run once while its condition is met. Within a few seconds you should see a new alert on the ITOC360 **Alerts** page, titled after your monitor and trigger.

If nothing arrives, check the following:

* **The trigger didn't actually fire.** Open the monitor's history — a green bar means the condition was never met, so no action ran.
* **Throttling is enabled on the action.** OpenSearch suppresses repeat notifications while throttling is active.
* **The webhook URL is incomplete.** The token is part of the URL; if it was truncated when pasting, requests are rejected.
* **The message body isn't valid JSON.** OpenSearch sends the message exactly as written, so a missing comma or quote will break the payload.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.itoc360.com/integrations/inbound-integrations/log-management/opensearch-integration.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.