Активные мониторы

В отличие от heartbeat-а, где «звонит» сам ваш сервис, активный монитор работает наоборот: serverless-функция Notifly сама раз в N секунд проверяет заданный ресурс. Если заданное число попыток подряд завершилось ошибкой — приходит alert; когда связь возвращается — приходит recovery.

Поддерживается 27 типов проверок — от простого HTTP-GET до lightweight protocol-handshake для почтовых, баз данных, очередей и сетевых сервисов, DNS-резолва и проверки TLS-сертификатов.

Базовые проверки:

`kind`	Что проверяет	Формат `target`
`http`	`GET <url>`, ожидаем `2xx` (или `expectedStatus`)	`https://example.com/health`
`tcp`	TCP-handshake — порт открыт	`host:port`
`ssl`	TLS-сертификат: цепочка доверия и имя хоста валидны, до истечения больше `certMinDays` дней (по умолчанию 14)	`example.com` или `example.com:8443`
`tls`	TCP+TLS handshake (TLS 1.2+, с проверкой сертификата); `expectedStatus` = минимальный запас по сроку сертификата в днях, `0` — проверять только handshake	`host:port`
`dns`	Резолв имени системным или указанным резолвером	`example.com` или `example.com@8.8.8.8:53`

Протокол-handshake (target — host:port; у sip, ntp, snmp порт можно опустить):

`kind`	Что проверяет
`smtp`	TCP, читаем баннер `220` (или сразу шлём `EHLO`), ждём `250`, `QUIT`
`imap`	TCP, ждём `* OK ...`, шлём `a LOGOUT`
`pop3`	TCP, ждём `+OK ...`, шлём `QUIT`
`ssh`	TCP, читаем баннер `SSH-...`
`ftp`	TCP, ждём баннер `220`, шлём `QUIT`
`redis`	TCP, шлём `PING`, ждём `+PONG` (ответ `-NOAUTH` тоже считается «жив»)
`postgres`	TCP, шлём `StartupMessage`, ждём `R`/`E`/`N`
`mysql`	TCP, читаем handshake-пакет (protocol_version=10)
`mongodb`	TCP, шлём `hello` (OP_MSG), ждём ответ
`memcached`	TCP, шлём `version`, ждём `VERSION ...`
`clickhouse`	TCP, нативный протокол: Client Hello
`cassandra`	TCP, CQL `OPTIONS`, ждём `SUPPORTED`
`zookeeper`	TCP, команда `ruok`
`mqtt`	TCP, `CONNECT` (MQTT 3.1.1), ждём `CONNACK`
`kafka`	TCP, запрос `ApiVersions`
`amqp`	TCP, заголовок AMQP 0-9-1, ждём `Connection.Start` (RabbitMQ и др.)
`nats`	TCP, ждём баннер `INFO ...`
`ldap`	TCP, анонимный `SearchRequest` root DSE, ждём ответ
`rdp`	TCP, шлём X.224 Connection Request, ждём ответ
`sip`	UDP, `OPTIONS` (по умолчанию порт `:5060`)
`ntp`	UDP, NTP-запрос (по умолчанию порт `:123`)
`snmp`	UDP, SNMPv1 GetRequest (по умолчанию порт `:161`)

Протокольные проверки не авторизуются в сервисе — они подтверждают, что сервер жив и отвечает на своём протоколе.

Как это работает

каждую минуту:   timer-trigger → notifly-monitor
                 └─▶ забрать мониторы, у которых подошло next_check_at (кроме paused)
                     └─▶ проверка с timeoutSec
                         ├─ успех → status=up, failCount=0
                         │           если был "down" и alert уходил → recovery (если задан текст)
                         └─ ошибка → failCount++
                                     < consecutiveFails → status=degraded
                                     ≥ consecutiveFails → status=down; alert, если ещё не отправлен

Проверка — отдельная функция notifly-monitor, её раз в минуту запускает таймер-триггер. Если просроченных мониторов больше, чем помещается в один вызов, работа раздаётся дополнительным вызовам.
Уведомление — обычное сообщение Notifly в канал, выбранный при создании монитора. Оно доходит до всех ваших устройств (web, Android, iOS, desktop), как любая другая push-нотификация, и дальше эскалируется по настройкам доставки канала.
История — каждая проверка пишется в историю (агрегаты по минутам, часам и дням и лог последних проверок) — см. REST endpoints.

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

События

Поскольку общение инициирует сам Notifly, есть два явных события:

Событие	Когда отправляется	Текст
Потеря связи (alert)	После `consecutiveFails` неудач подряд, один раз на падение. К тексту добавляется техническая ошибка в скобках (например, `(connection refused)`)	`alertTitle` + `alertMessage`
Восстановление связи (recovery)	При первой успешной проверке после `down` — только если задан `recoveryMessage` и о падении действительно был отправлен alert	`recoveryTitle` + `recoveryMessage`

Оба сообщения уходят с приоритетом alertPriority.

Повторного alert-спама не будет: отправив alert, монитор запоминает момент в поле alertedAt и, пока остаётся в down, новых сообщений не шлёт — проверки продолжаются с обычным интервалом и просто фиксируют статус. Исключение — re-arm: если вы через PUT /monitor/:id меняете параметры проверки (kind, target, интервал, таймаут, expectedStatus, certMinDays, consecutiveFails), отметка alertedAt сбрасывается и монитор проверяется сразу; если цель всё ещё недоступна, придёт свежий alert. Правка названия, текстов и приоритета таймер не сбивает и re-arm не делает.

Что ещё влияет на уведомления:

Прочитано = стоп досылки. Пока alert не прочитан, его может досылать эскалация канала (email, SMS, звонок, мессенджеры, вебхуки). Отметка «прочитано» — в приложении или по ссылке из письма/Telegram — останавливает досылку по остальным методам.
Тихие часы владельца канала подавляют эскалацию во внешние каналы для сообщений с приоритетом ниже порога breakthroughPriority (по умолчанию 8). Чтобы alert будил ночью, задайте alertPriority не ниже порога.
Окна обслуживания: в окне проверки идут и пишутся в историю, но alert откладывается — если после окна цель всё ещё лежит, первая же проверка его отправит. Если монитор упал и поднялся внутри окна, не придёт ни alert, ни recovery.
Статус-страница канала: переход в down открывает авто-инцидент на публичной странице, восстановление — закрывает.

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

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

Откройте app.notifly.ru → Мониторинг → Мониторы.
Нажмите «Создать» — откроется мастер «Что вы хотите проверять?». Для протокольного монитора выберите карточку «Сервис на хосте/порту жив» (затем протокол из списка) или «SSL-сертификат не истекает». Остальные карточки ведут к специализированным мониторам и heartbeat-у.
Заполните:
- Название — для отображения, например «Прод-сайт» или «Postgres-реплика».
- Канал — через какой канал слать уведомление (свой или расшаренный вам с правом отправки).
- Тип проверки — один из 27 kind (см. таблицы выше).
- Цель — формат зависит от типа: URL, host:port, хост или DNS-имя.
- Период (сек) — между проверками (минимум 30, максимум 86400).
- Таймаут (сек) — сколько ждать ответа в одной попытке (по умолчанию 10, максимум 30).
- Подряд неудач — сколько подряд неудачных проверок до alert (по умолчанию 1, максимум 20; типично 2–3, чтобы не реагировать на единичные сетевые джиттеры).
- Ожидаемый HTTP-код (только http) — 0 означает «любой 2xx», иначе явный код (например, 200).
- Алёрт за N дней до истечения сертификата (только tls) — 0 = проверять только handshake; 30 = alert, если сертификату осталось меньше 30 дней.
- Предупреждать за N дней до истечения (только ssl) — 1–365, по умолчанию 14.
- Текст alert / recovery — что прилетит в push. Recovery включается флажком «Уведомлять о восстановлении».
Кнопка «Тест» выполняет одну проверку прямо из диалога — без сохранения монитора.

Через REST API

# HTTP-проверка
curl -X POST "$NOTIFLY_URL/monitor" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <api-token>" \
     -d '{
       "appid": 12345,
       "name": "Прод-сайт",
       "kind": "http",
       "target": "https://example.com/health",
       "intervalSec": 60,
       "timeoutSec": 10,
       "expectedStatus": 0,
       "consecutiveFails": 2,
       "alertTitle": "Прод-сайт недоступен",
       "alertMessage": "Сайт недоступен!",
       "alertPriority": 9,
       "recoveryMessage": "Сайт снова отвечает."
     }'

# TCP-проверка
curl -X POST "$NOTIFLY_URL/monitor" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <api-token>" \
     -d '{
       "appid": 12345,
       "name": "Postgres-реплика",
       "kind": "tcp",
       "target": "db-replica.example.com:5432",
       "intervalSec": 60,
       "timeoutSec": 5,
       "consecutiveFails": 3,
       "alertMessage": "Реплика не принимает соединения.",
       "recoveryMessage": "Реплика снова доступна."
     }'

# SSL — валидность сертификата и alert за 21 день до истечения
curl -X POST "$NOTIFLY_URL/monitor" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <api-token>" \
     -d '{
       "appid": 12345,
       "name": "SSL prod",
       "kind": "ssl",
       "target": "example.com",
       "intervalSec": 3600,
       "certMinDays": 21,
       "alertMessage": "Сертификат example.com невалиден или скоро истекает!"
     }'

# DNS — проверка резолва через указанный сервер
curl -X POST "$NOTIFLY_URL/monitor" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <api-token>" \
     -d '{
       "appid": 12345,
       "name": "DNS prod-зоны",
       "kind": "dns",
       "target": "example.com@8.8.8.8:53",
       "intervalSec": 300,
       "timeoutSec": 5,
       "alertMessage": "DNS-зона example.com не резолвится через 8.8.8.8"
     }'

Поля тела запроса:

Поле	Обязательное	Описание
`appid`	да	ID канала для уведомлений; при `PUT` не меняется
`name`	да	1–200 символов
`kind`	да	тип проверки (см. таблицы выше)
`target`	да	цель в формате своего `kind`
`intervalSec`	да	30–86400
`timeoutSec`		1–30, по умолчанию 10
`consecutiveFails`		1–20, по умолчанию 1
`expectedStatus`		`http`: `0` или код 100–599; `tls`: минимальный запас сертификата в днях
`certMinDays`		только `ssl`: 1–365, по умолчанию 14
`alertMessage`	да	1–2000 символов
`alertTitle`		заголовок alert-сообщения
`alertPriority`		0–10, приоритет alert и recovery
`recoveryTitle`, `recoveryMessage`		заголовок и текст recovery; пустой `recoveryMessage` — recovery не шлётся

В ответе — объект монитора с вычисляемыми полями status, failCount, lastCheckAt, lastError, nextCheckAt, alertedAt.

Примеры по типам

Характерные комбинации kind + target для частых задач:

{ "kind": "smtp",     "target": "mx.example.com:587"     } // SMTP отвечает на EHLO
{ "kind": "imap",     "target": "imap.example.com:143"   } // IMAP жив (plain)
{ "kind": "pop3",     "target": "pop3.example.com:110"   } // POP3 жив
{ "kind": "ssh",      "target": "jump.example.com:22"    } // SSH-баннер
{ "kind": "redis",    "target": "redis.example.com:6379" } // Redis отвечает на PING
{ "kind": "postgres", "target": "pg.example.com:5432"    } // PostgreSQL принимает соединения
{ "kind": "mysql",    "target": "db.example.com:3306"    } // MySQL шлёт handshake
{ "kind": "ntp",      "target": "ntp.example.com"        } // NTP по UDP, порт 123 по умолчанию
{ "kind": "tls",      "target": "smtps.example.com:465", "expectedStatus": 14 } // TLS на порту 465 жив, сертификату ≥ 14 дней
{ "kind": "ssl",      "target": "example.com", "certMinDays": 30 } // сертификат валиден и не истечёт в ближайшие 30 дней

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

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

Создай монитор для https://api.example.com/health, проверять каждые 30 секунд, алёрт после 3 подряд неудач с текстом «API лежит», recovery «API снова работает».

Доступные MCP-инструменты: list_monitors, create_monitor, update_monitor, delete_monitor, pause_monitor, resume_monitor, test_monitor.

REST endpoints

Метод	Путь	Описание
`GET`	`/monitor`	Список мониторов пользователя
`POST`	`/monitor`	Создать
`PUT`	`/monitor/:id`	Обновить настройки (нельзя сменить `appid`)
`DELETE`	`/monitor/:id`	Удалить
`POST`	`/monitor/:id/pause`	Приостановить (проверки не выполняются)
`POST`	`/monitor/:id/resume`	Возобновить: статус `pending`, проверка — сразу
`POST`	`/monitor/test`	Разовая проверка (dry-run) без создания монитора — возвращает `ok`, `durationMs`, `details`, `error`
`GET`	`/monitor-history/:kind/:id`	Агрегаты проверок по бакетам; параметры `bucket` (`1m`/`1h`/`1d`, по умолчанию `1h`), `from`, `to` (unix-секунды)
`GET`	`/monitor-history/:kind/:id/log`	Последние проверки (лог хранится 7 дней); параметр `limit` (по умолчанию 50, максимум 200)

Все endpoints требуют API-токен или токен устройства — логин-пара на них не принимается. API-токену для изменяющих операций (POST/PUT/DELETE, а также pause/resume) нужен доступ write; для чтения (GET-списки, история) и для POST /monitor/test достаточно read. Если токен ограничен каналами, он видит и меняет только мониторы этих каналов.

Эндпоинт POST /monitor/test принимает { "kind", "target", "timeoutSec", "expectedStatus", "certMinDays" } (таймаут — до 60 секунд, по умолчанию 10) и выполняет одну проверку прямо сейчас, ничего не сохраняя — удобно проверить доступность цели до создания монитора:

curl -X POST "$NOTIFLY_URL/monitor/test" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <api-token>" \
     -d '{ "kind": "tcp", "target": "db.example.com:5432", "timeoutSec": 5 }'
# → {"ok":true,"durationMs":42,"details":"Connected to db.example.com:5432"}

Недоступная цель возвращает 200 с "ok": false и текстом ошибки в error.

История доступна для любого вида мониторинга: в :kind подставляется вид сущности — monitor (эта страница), http_monitor, content_monitor, port_monitor, workflow_monitor, browser_workflow_monitor или heartbeat, в :id — ID монитора. По умолчанию история отдаёт последние 24 часа для 1m, 7 дней для 1h и 30 дней для 1d. Каждый бакет содержит bucketTs, checksCount, successCount, failCount, sumDurationMs/minDurationMs/maxDurationMs и lastStatus; запись лога — ts, success, durationMs, error.

Другие типы мониторов

Описанный выше /monitor — это «лёгкие» протокол-проверки (HTTP-GET, TCP- и protocol-handshake, DNS, TLS/SSL). Для более сложных сценариев у Notifly есть специализированные мониторы со своими настройками, лимитами таймаута и отдельными REST API:

HTTP-мониторы — полноценные запросы с методом, заголовками, телом, проверкой кода/контента и времени ответа (таймаут до 30 с).
Контент-мониторы — следят за изменением содержимого страницы или значения в JSON API, таймаут до 60 с.
Порт-мониторы — проверка набора портов хоста (таймаут до 10 с).
Сканирование портов — обнаружение открытых портов хоста.
Workflow-мониторы — цепочки HTTP-шагов с извлечением значений и проверками (таймаут до 60 с).
Browser-workflow — сценарии в реальном браузере (клики, ввод, проверки на странице), таймаут до 120 с.

Смежные возможности мониторинга:

Метрики — приём числовых метрик и алёрты по пороговым значениям.
Проверка домена — подтверждение владения хостом.
Heartbeat — обратный сценарий: сервис сам периодически «звонит» Notifly, а alert приходит при пропущенном пинге.
Окна обслуживания — плановые работы без ложных алертов.
Статус-страницы — публичный статус и аптайм мониторов канала.

Ограничения

Минимальный период: 30 секунд.
Максимальный период: 24 часа (для редких проверок выгоднее использовать heartbeat).
Каждая проверка — событие в дневной квоте тарифа (Free — 1000 событий в сутки, см. Квоты и тарифы). Монитор с периодом 60 секунд тратит 1440 событий в сутки. Когда квота исчерпана, проверки откладываются до 00:05 МСК следующего дня, а вам приходит одно уведомление о квоте.
Проверки идут из Yandex Cloud, поэтому цель должна быть доступна из публичного интернета; приватные, loopback и link-local адреса запрещены.
Протокольные проверки (smtp/imap/pop3/redis/…) выполняются без TLS — для шифрованных портов используйте kind: "tls" или kind: "ssl".
Проверки срока регистрации домена (WHOIS/RDAP) нет — ssl следит только за сертификатом.