HTTP-мониторы (расширенные)

«Лёгкий» тип http в активных мониторах делает только GET <url> и сверяет статус-код с 2xx (или expectedStatus). Этого достаточно для простого health-check-а, но не покрывает случаи вроде «дёрни POST /api/login с JSON-телом и заголовком Authorization, а потом проверь, что в ответе пришёл "status":"ok" и код 200».

HTTP-монитор — это отдельная сущность со своим REST API, которая умеет:

произвольный метод — GET, POST, PUT, PATCH, DELETE, HEAD;
произвольные заголовки (headers) — JSON-объект {"Header": "Value"};
тело запроса (body) — для POST/PUT/PATCH;
фильтрацию ответа — по статус-коду, диапазону кодов, подстроке/regex в body, значению по JSONPath и максимальному времени ответа;
два режима реакции — алёртить «на совпадение» или «на несовпадение» фильтров.

Всё остальное (период, таймаут, число неудач подряд, тексты alert/recovery, паузы) работает так же, как у обычных мониторов.

Поля монитора

Поле	Тип	Обязательно	Описание
`appid`	number	да	ID канала, в который слать уведомления
`name`	string	да	Название монитора, 1–200 символов
`method`	string	да	`GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD` (регистр не важен)
`url`	string	да	Валидный `http(s)` URL
`headers`	string	нет	JSON-объект заголовков: `{"Authorization": "Bearer ..."}`
`body`	string	нет	Тело запроса (для `POST`/`PUT`/`PATCH`)
`intervalSec`	number	да	Период между проверками, 30–86400 секунд
`timeoutSec`	number	нет	Таймаут одной попытки, по умолчанию 10, максимум 30
`filterMode`	string	да	`alert_on_match` или `alert_on_mismatch` (см. ниже)
`filters`	string	да	JSON-массив фильтров (см. Фильтры ответа)
`consecutiveFails`	number	нет	Сколько подряд неудач до alert, по умолчанию 1, максимум 20
`alertMessage`	string	да	Текст уведомления при срабатывании, 1–2000 символов
`alertTitle`	string	нет	Заголовок уведомления
`alertPriority`	number	нет	Приоритет push, 0–10
`recoveryTitle`	string	нет	Заголовок recovery-сообщения
`recoveryMessage`	string	нет	Текст при возврате в норму (если пусто — recovery не шлётся)

Фильтры ответа

filters — это JSON-массив объектов. Каждый объект описывает условие, которому должен соответствовать ответ. Можно комбинировать несколько проверок в одном фильтре. Доступные поля фильтра:

Поле фильтра	Тип	Что проверяет
`statusCode`	number	Точный HTTP-код (`0` = не проверять)
`statusCodeMin` / `statusCodeMax`	number	Диапазон кодов `[min, max]` включительно (`0,0` = не проверять)
`bodyContains`	string	Подстрока, которую должен содержать body
`bodyRegex`	string	Регулярное выражение (синтаксис Go) для body
`jsonPath`	string	Путь в JSON-ответе, например `$.status` или `data.0.id`
`jsonPathValue`	string	Ожидаемое значение по `jsonPath` (сравнение строковое)
`maxDurationMs`	number	Максимально допустимое время ответа в мс (`0` = не проверять)

Режим фильтрации (`filterMode`)

alert_on_mismatch — описываете, как выглядит нормальный ответ. Если фактический ответ не совпал с фильтрами — уходит alert. Это «whitelist»-логика и самый частый сценарий.
alert_on_match — описываете проблемный ответ. Если фактический ответ совпал с фильтром — уходит alert. Удобно ловить конкретные ошибки.

// filterMode = "alert_on_mismatch":
// норма — код 200 и в JSON {"status":"ok"}; иначе алёрт.
[
  { "statusCode": 200, "jsonPath": "$.status", "jsonPathValue": "ok" }
]

// filterMode = "alert_on_match":
// алёртим, если в body встретилось слово maintenance ИЛИ код в 5xx.
[
  { "bodyContains": "maintenance" },
  { "statusCodeMin": 500, "statusCodeMax": 599 }
]

// норма — отвечает быстрее 800 мс и код 2xx (filterMode = "alert_on_mismatch"):
[
  { "statusCodeMin": 200, "statusCodeMax": 299, "maxDurationMs": 800 }
]

Состояния и события

HTTP-монитор использует те же статусы, что и обычные мониторы: pending (создан, проверок ещё не было), up, degraded (есть сбои, но порог consecutiveFails ещё не достигнут), down (alert отправлен) и paused.

Событие	Когда	Текст
Alert	После `consecutiveFails` подряд срабатываний фильтра (по логике `filterMode`), только при первом переходе в `down`. К сообщению добавляется техническая информация (последний код, превью body, ошибка)	`alertMessage`
Recovery	При первой успешной проверке после `down`, только если задан `recoveryMessage`	`recoveryMessage`

Пока монитор в down, повторных alert-ов не будет — проверки продолжаются и просто фиксируют статус.

Тестовый запрос

Перед созданием монитора можно выполнить разовый запрос и посмотреть ответ — ничего не сохраняя. POST /http-monitor/test принимает method, url, headers, body, timeoutSec и возвращает statusCode, bodyPreview (первые 2048 символов), headers (JSON заголовков ответа), durationMs и error (если запрос упал).

curl -X POST "$NOTIFLY_URL/http-monitor/test" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <client-token>" \
     -d '{
       "method": "POST",
       "url": "https://api.example.com/login",
       "headers": "{\"Content-Type\": \"application/json\"}",
       "body": "{\"user\":\"probe\",\"pass\":\"...\"}",
       "timeoutSec": 10
     }'
# → {"statusCode":200,"bodyPreview":"{\"status\":\"ok\"}","headers":"{...}","durationMs":134}

Создание монитора

Через админку

Откройте app.notifly.ru → Мониторы → HTTP.
Укажите название, канал, метод, URL, при необходимости — заголовки и тело.
Настройте период, таймаут, число неудач подряд.
Опишите фильтры ответа и выберите режим (alert_on_match / alert_on_mismatch).
Задайте тексты alert и recovery.

Через REST API

curl -X POST "$NOTIFLY_URL/http-monitor" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <client-token>" \
     -d '{
       "appid": 12345,
       "name": "API login health",
       "method": "POST",
       "url": "https://api.example.com/login",
       "headers": "{\"Content-Type\": \"application/json\"}",
       "body": "{\"user\":\"probe\",\"pass\":\"...\"}",
       "intervalSec": 60,
       "timeoutSec": 10,
       "filterMode": "alert_on_mismatch",
       "filters": "[{\"statusCode\":200,\"jsonPath\":\"$.status\",\"jsonPathValue\":\"ok\"}]",
       "consecutiveFails": 2,
       "alertMessage": "Логин-эндпоинт не отвечает как надо!",
       "alertPriority": 9,
       "recoveryMessage": "Логин снова работает."
     }'

Поля headers, body и filters передаются строками (JSON внутри JSON), поэтому в curl-примерах их содержимое экранируется.

Через MCP (для AI-ассистента)

Если настроен MCP-сервер Notifly (см. MCP), достаточно описать задачу словами:

Заведи HTTP-монитор: POST на https://api.example.com/login с JSON-телом, проверяй каждую минуту, что код 200 и в ответе status=ok, алёрт после 2 неудач подряд.

REST API

Метод	Путь	Описание
`GET`	`/http-monitor`	Список HTTP-мониторов пользователя
`POST`	`/http-monitor`	Создать
`POST`	`/http-monitor/test`	Разовый тестовый запрос (без сохранения)
`PUT`	`/http-monitor/:id`	Обновить настройки (нельзя сменить `appid`)
`DELETE`	`/http-monitor/:id`	Удалить
`POST`	`/http-monitor/:id/pause`	Приостановить проверки
`POST`	`/http-monitor/:id/resume`	Возобновить

Создание, изменение, удаление, пауза и возобновление требуют клиентский (или MCP) токен с правом записи. POST /http-monitor/test доступен без привязки к конкретному монитору.

Смежные мониторы

Активные мониторы — «лёгкие» проверки (HTTP-GET, TCP, DNS, TLS-expiry).
Контент-мониторы — отслеживание изменения содержимого страницы.
Workflow-мониторы — цепочки HTTP-шагов с извлечением значений.
Browser-workflow — сценарии в реальном браузере.