---
title: Uptime monitoring
description: "Внешний мониторинг доступности: HTTP/TCP/SSL-проверки, регионы, transaction checks, false positives и доказательства сбоя."
---

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

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

В отличие от проверки процесса на сервере, внешняя проверка видит DNS, сетевой маршрут, TLS, CDN, балансировщик и ответ приложения вместе. В отличие от [RUM](https://wpcraft.ru/kb/infrastructure/observability/real-user-monitoring.md), она не зависит от наличия реальных посетителей и даёт сопоставимые замеры по расписанию.

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

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

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

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

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

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

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

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

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

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

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

Эти данные ускоряют переход к [логам](https://wpcraft.ru/kb/infrastructure/observability/log-management.md), [трассировке](https://wpcraft.ru/kb/infrastructure/observability/tracing.md) и инцидентному runbook. Скриншоты и тела ответов очищаются от персональных данных и секретов.

## Uptime как SLI

Внешние проверки могут входить в [availability SLI](https://wpcraft.ru/kb/infrastructure/sre/sli-slo-sla.md), если заранее определены сценарий, период и правила учёта. Их стоит дополнять успешностью реальных запросов: синтетика может быть зелёной во время проблем у конкретных устройств или сегментов пользователей.

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

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

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

- [Better Stack](https://wpcraft.ru/kb/infrastructure/tools/better-stack.md) — внешние проверки, browser transactions и оповещения.
- [Uptime Kuma](https://wpcraft.ru/kb/infrastructure/tools/uptime-kuma.md) — self-hosted проверки разных типов.
- [Gatus](https://wpcraft.ru/kb/infrastructure/tools/gatus.md) — декларативные health checks и статусы.

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

- [Alerting](https://wpcraft.ru/kb/infrastructure/observability/alerting.md) — подтверждение и маршрутизация сигнала.
- [Real User Monitoring](https://wpcraft.ru/kb/infrastructure/observability/real-user-monitoring.md) — реальный пользовательский опыт.
- [On-call](https://wpcraft.ru/kb/infrastructure/incidents/on-call.md) — реакция на подтверждённый сбой.

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

- [Better Stack: Uptime monitoring](https://betterstack.com/uptime) — примеры диагностических данных и transaction checks.
- [Google SRE: Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/) — black-box monitoring, симптомы и пользовательский срез.
- [Playwright: Documentation](https://playwright.dev/docs/intro) — браузерная автоматизация для сценарных проверок.