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

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

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

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

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

Протокол-handshake (target всегда host:port):

kind	Что проверяет
smtp	TCP, читаем баннер 220, шлём EHLO/QUIT
imap	TCP, ждём * OK ..., шлём a LOGOUT
pop3	TCP, ждём +OK ..., шлём QUIT
ssh	TCP, читаем баннер SSH-...
ftp	TCP, ждём баннер 220, шлём QUIT
redis	TCP, шлём PING, ждём +PONG
postgres	TCP, шлём StartupMessage, ждём R/E/N
mysql	TCP, читаем handshake-пакет (protocol_version=10)
mongodb	TCP, шлём hello (OP_MSG), ждём ответ
memcached	TCP-проверка memcached
clickhouse	TCP-проверка ClickHouse
cassandra	TCP-проверка Cassandra
zookeeper	TCP-проверка ZooKeeper
mqtt	TCP-проверка брокера MQTT
kafka	TCP-проверка Kafka
amqp	TCP-проверка AMQP / RabbitMQ
nats	TCP, ждём баннер INFO ...
ldap	TCP, шлём SearchRequest, ждём ответ
rdp	TCP, шлём X.224 Connection Request, ждём ответ
sip	UDP, OPTIONS (по умолчанию порт :5060)
ntp	UDP, NTP-запрос (по умолчанию порт :123)
snmp	UDP, SNMPv1 GetRequest (по умолчанию порт :161)

Все TLS-варианты выполняются поверх обычного TCP (без StartTLS), поэтому для шифрованных портов указывайте уже-шифрованный порт (smtp → :465, imap → :993, pop3 → :995, redis → :6380 и т.п.). Для проверки самого факта работы TCP — используйте kind: "tcp".

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

каждую минуту:   timer-trigger → notifly-monitor
                 └─▶ SELECT WHERE next_check_at <= now AND status != "paused"
                     └─▶ HTTP GET / TCP Dial с timeoutSec
                         ├─ успех → status=up, fail_count=0
                         │           если был "down" и есть recoveryMessage → recovery
                         └─ ошибка → fail_count++; если ≥ consecutiveFails и не "down":
                                     отправить alert, status=down

• Хранение — таблица monitors в YDB Serverless, индекс по next_check_at.
• Проверка — отдельная Cloud Function notifly-monitor, запускается таймер- триггером Yandex Cloud (cron * * * * ? * — раз в минуту).
• Уведомление — обычное сообщение Notifly, приходит через выбранное при создании монитора канал и доходит до всех ваших клиентов (web, Android, desktop), как любая другая push-нотификация.

События

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

Событие	Когда отправляется	Текст
Потеря связи (alert)	После consecutiveFails подряд неудач, только при первом переходе в down. К сообщению добавляется техническая ошибка (например, dial tcp: connect: connection refused)	alertMessage
Восстановление связи (recovery)	При первой успешной проверке после состояния down, только если задан recoveryMessage	recoveryMessage

Повторного alert-спама не будет: пока монитор в down, новых сообщений не шлётся, проверки продолжаются с обычным интервалом и просто фиксируют статус.

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

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

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

Лимит таймаута зависит от типа монитора

Для обычного /monitor потолок таймаута — 30 секунд (по умолчанию 10). У специализированных мониторов лимиты другие: HTTP — 30, порт — 10, контент — 60, workflow — 60, browser — 120 секунд. Каждый описан на своей странице (см. Другие типы мониторов).

Через REST API

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

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

# TLS — алёрт за 30 дней до истечения сертификата
curl -X POST "$NOTIFLY_URL/monitor" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <client-token>" \
     -d '{
       "appid": 12345,
       "name": "SSL prod",
       "kind": "tls",
       "target": "example.com:443",
       "intervalSec": 3600,
       "timeoutSec": 10,
       "expectedStatus": 30,
       "alertMessage": "Сертификат example.com истекает менее чем через 30 дней!"
     }'

# DNS — проверка резолва через указанный сервер
curl -X POST "$NOTIFLY_URL/monitor" \
     -H "Content-Type: application/json" \
     -H "X-Notifly-Key: <client-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"
     }'

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

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

{ "kind": "smtp",     "target": "mx.example.com:25"      } // SMTP-MX отвечает
{ "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": "tls",      "target": "smtps.example.com:465", "expectedStatus": 14 } // SSL-сертификат жив и не истечёт в ближайшие 14 дней

Через 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.

REST endpoints

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

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

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

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

Историю можно смотреть для любого типа монитора, подставив kind (например http, tcp, dns) и id монитора.

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

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

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

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

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

Почему YDB, а не S3

См. ту же аргументацию для heartbeat: индексированный точечный запрос по next_check_at дешевле и быстрее, чем перечисление S3-объектов.

Ограничения

• Минимальный период: 30 секунд (чтобы не перегружать YDB).
• Максимальный период: 24 часа (для редких проверок выгоднее использовать heartbeat).
• Один вызов notifly-monitor обрабатывает до 150 просроченных мониторов (cron срабатывает раз в минуту, проверки идут параллельно, по умолчанию до 100 одновременно; если просроченных больше — функция до-вызывает сама себя).
• Запросы идут из Yandex Cloud, поэтому целевой ресурс должен быть доступен из публичного интернета (или из приватной сети YC, если функция в нужной VPC).
• Все протокол-специфичные проверки (smtp/imap/pop3/…) выполняются без StartTLS — для шифрованного варианта используйте уже-шифрованный порт (:465, :993, :995, :6380) с kind: "tls" или kind: "tcp".