Как работает мониторинг доступности сайтов в 2026 году

Сервис с доступностью 99,99% бывает офлайн менее 53 минут в год. Снижение до 99,9% означает более восьми часов простоя. Мониторинг доступности — это небольшой элемент инфраструктуры, который фиксирует такие минуты сразу, как только они происходят. В этом руководстве объясняется, как он работает, что отслеживать, как часто проверять и какие ошибки превращают полезный инструмент в фоновый шум.

Что на самом деле делает монитор доступности

Монитор доступности работает в небольшом цикле. С сервера, расположенного где-то в публичном интернете, он отправляет запрос на указанный вами целевой адрес. Он записывает ответ, код состояния и время полного обращения. Затем он ждёт заданный интервал и повторяет попытку.

Зонд намеренно располагается за пределами вашей инфраструктуры. Если бы мониторинг проводился изнутри вашей собственной сети, вы не смогли бы обнаружить сбои, которые выглядят нормально изнутри, но не работают для реальных пользователей. В этом и заключается разница между синтетическим мониторингом (внешний зонд) и мониторингом реальных пользователей (телеметрия от реальных посетителей). Большинство команд используют оба подхода. Мониторинг доступности — это синтетическая сторона.

Что на самом деле можно мониторить

Современные инструменты мониторинга доступности охватывают не только HTTP. Девять типов зондов, которые встречаются на рынке, отвечают на немного разные вопросы.

• HTTP возвращает код состояния и время отклика для любого URL.
• Ping (ICMP) проверяет, отвечает ли хост на сетевом уровне.
• SSL показывает, сколько дней осталось до истечения вашего сертификата.
• DNS проверяет, что записи A, AAAA, MX, TXT или NS по-прежнему разрешаются в ожидаемые значения.
• TCP-порт проверяет, прослушивает ли сервис заданный порт или, наоборот, не открылся ли внезапно тот, что должен быть закрыт.
• WHOIS отслеживает срок регистрации вашего доменного имени.
• Blacklist проверяет, не попал ли ваш отправляющий IP в списки Spamhaus, SORBS или аналогичные.
• Heartbeat меняет логику: ваша задача сама пингует монитор, и вы получаете уведомление, когда она перестаёт это делать.

Как часто выполнять проверки

Частота проверок — это компромисс между точностью и шумом. Более высокая частота позволяет ловить короткие сбои, но создаёт больше ложных срабатываний из-за кратковременных сетевых перебоев. Более низкая частота сглаживает шум, но пропускает короткие сбои, которые всё равно засчитываются в ваш бюджет ошибок.

Прагматичное значение по умолчанию: 60 секунд для HTTP и ping важных сервисов, 5 минут для второстепенных страниц, 15 минут для SSL, ежечасно для WHOIS. Опускайтесь до 30 секунд только для сервисов, простой которых измеримо стоит вам денег за каждую минуту. Уход ниже 30 секунд редко улучшает результат и часто приводит к усталости от оповещений.

Маршрутизация оповещений без лишнего шума

Оповещение, которое никто не читает, хуже, чем отсутствие оповещений. Большинству команд достаточно трёх правил.

• По умолчанию отправляйте DOWN в один канал — желательно тот, который ваша команда уже проверяет (Slack, Discord, Telegram или email).
• Используйте пороговое правило: минимум 3 последовательных сбоя перед вызовом дежурного. Один пропущенный чек — шум. Три подряд — сигнал.
• Направляйте критические сервисы в систему оповещения дежурных (PagerDuty, Opsgenie) через подписанный webhook. Всё остальное — в чат. Подтверждайте инциденты, чтобы остановить пейджер, когда за дело уже взялся человек.

Ошибки, которые убивают программы мониторинга доступности

Первая ошибка — мониторинг только главной страницы. Работающая главная страница почти ничего не говорит о процессе оформления заказа или об API, к которому обращается ваше мобильное приложение. Добавьте отдельные HTTP-мониторы для URL, наиболее значимых для выручки или нагрузки на поддержку.

Вторая ошибка — тихое веерное распределение. Каждый монитор пишет во все каналы, затем каждый член команды отключает звук в шумных, а реальный инцидент появляется именно в отключённом канале. Определите один маршрут по умолчанию, направляйте исключения конкретным людям и пересматривайте правила раз в квартал.

Стартовая настройка за 10 минут

Если вы начинаете с нуля, практическая последовательность короткая. Создайте HTTP-монитор для вашего основного URL с интервалом 60 секунд. Создайте SSL-монитор на том же хосте с окном предупреждения 30 дней. Создайте одно правило уведомлений, которое направляет DOWN в чат команды. Добавьте страницу статуса, если у вас есть внешние пользователи, которым важна доступность. Добавьте heartbeat для cron-задач, отвечающих за биллинг, отчёты и резервные копии. Теперь вы уже впереди среднего оператора.