Uptime monitoring

Что проверяет uptime monitoring

Uptime monitoring периодически выполняет внешние проверки сервиса и сообщает, доступен ли он из контролируемых точек. Это синтетический срез: система заранее знает, какой запрос или сценарий выполнить и какой результат считать успешным.

В отличие от проверки процесса на сервере, внешняя проверка видит DNS, сетевой маршрут, TLS, CDN, балансировщик и ответ приложения вместе. В отличие от RUM, она не зависит от наличия реальных посетителей и даёт сопоставимые замеры по расписанию.

Типы проверок

• HTTP(S) — статус, время ответа, редиректы, наличие или отсутствие текста.
• TCP / ping — доступность порта или базовой сетевой связности, без доказательства работоспособности приложения.
• TLS / домен — срок действия сертификата, иногда изменения DNS или приближение окончания регистрации.
• Keyword / API — корректность тела ответа, а не только статус 200.
• Transaction / browser checks — многошаговый сценарий в браузере: вход, форма, корзина или другой ключевой путь.

Проверка главной страницы не доказывает работоспособность checkout. Для критичного бизнес-сценария нужна отдельная проверка результата.

Регионы, интервал и подтверждение

Точки наблюдения выбирают по аудитории и сетевым зависимостям. Один регион не различает локальную проблему наблюдателя и общий отказ; несколько регионов помогают увидеть географическую деградацию.

Интервал определяет, как быстро сбой попадёт в замер. Таймаут и повторные подтверждения влияют на ложные тревоги и задержку обнаружения. Полезно различать:

• единичную сетевую ошибку;
• повторяющийся сбой из одной точки;
• подтверждённую недоступность из нескольких точек;
• некорректный ответ приложения при технически успешном соединении.

Пропавший замер — это отсутствие данных, а не доказательство доступности.

Доказательства для диагностики

Оповещение должно содержать не только «down», но и доступные артефакты:

• статус, ошибку и длительность этапов запроса;
• финальный URL и цепочку редиректов;
• фрагмент ответа или скриншот browser check;
• сведения TLS;
• traceroute/MTR для сетевых таймаутов;
• регион, время и идентификатор проверки.

Эти данные ускоряют переход к логам, трассировке и инцидентному runbook. Скриншоты и тела ответов очищаются от персональных данных и секретов.

Uptime как SLI

Внешние проверки могут входить в availability SLI, если заранее определены сценарий, период и правила учёта. Их стоит дополнять успешностью реальных запросов: синтетика может быть зелёной во время проблем у конкретных устройств или сегментов пользователей.

Типовые ошибки

• Проверяется только /health, который не зависит от БД и критичных зависимостей.
• Любой статус 200 считается успехом, включая страницу ошибки.
• Один регион создаёт ложную тревогу из-за локальной сети.
• Browser check хранит реальные пароли и снимает чувствительные данные.
• Алерт не содержит первого диагностического действия.

Связанные инструменты

• Better Stack — внешние проверки, browser transactions и оповещения.
• Uptime Kuma — self-hosted проверки разных типов.
• Gatus — декларативные health checks и статусы.

Связанные материалы

• Alerting — подтверждение и маршрутизация сигнала.
• Real User Monitoring — реальный пользовательский опыт.
• On-call — реакция на подтверждённый сбой.

Материалы и источники

• Better Stack: Uptime monitoring — примеры диагностических данных и transaction checks.
• Google SRE: Monitoring Distributed Systems — black-box monitoring, симптомы и пользовательский срез.
• Playwright: Documentation — браузерная автоматизация для сценарных проверок.