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

Монитор лучше создавать от пользовательского сценария, а не от внутреннего сервера. Спросите: “Если это сломается, кто первым заметит проблему и как он ее опишет?”

Что заполнить

Название: так, как сервис называют в команде или поддержке.
Тип проверки: HTTP, Ping, TCP, heartbeat, DNS, домен, ключевой текст или сценарий, если он доступен в вашем аккаунте.
Цель: URL, домен, IP-адрес, host:port или имя фоновой задачи.
Интервал: как часто запускать проверку. Для первого монитора оставьте значение по умолчанию.
Таймаут: сколько ждать ответа перед ошибкой. Слишком большой таймаут скрывает деградацию.
Порог инцидента: сколько должна длиться проблема перед созданием инцидента.

Не добавляйте сразу все внутренние зависимости. Начните с внешней точки входа: главная страница, /health, публичный API или endpoint, который реально используют клиенты.

Рабочие примеры

Сайт: HTTP-монитор, URL https://example.com, ожидаемый код 200.
API: HTTP-монитор, URL https://api.example.com/health, короткий таймаут.
Фоновая задача: heartbeat-монитор, интервал по расписанию задачи.
База, брокер или SMTP: TCP-монитор с host и port, если сервис доступен извне или через разрешенный allowlist.
Домен: domain-монитор для срока регистрации и статуса домена.
DNS: DNS-монитор для важных A, MX, TXT, NS или CAA записей.

Проверка результата

Откройте созданный монитор.
Найдите последнюю проверку.
Сравните фактический статус с ожидаемым.
При ошибке откройте диагностику и исправьте адрес, код ответа, таймаут или allowlist.
Если проверка успешна, включите оповещения и добавьте монитор на страницу статуса, если он важен для клиентов.

Частые ошибки

Проверять главную страницу, которая зависит от аналитики, виджетов и тяжелого frontend bundle. Для мониторинга лучше отдельный быстрый health endpoint.
Ждать 200, хотя корректный endpoint возвращает 204, 301 или 401.
Создавать монитор на внутренний адрес без allowlist для IP-адресов проверок.
Называть монитор внутренним именем, которое непонятно поддержке и пользователям.