Мониторинг доступности сайта: инструменты

MAATRIX

Сайт может лежать часами, а вы узнаете об этом от клиента в почте или от коллеги в чате — самый обидный способ обнаружить простой. Инструментов, которые сами следят за доступностью и бьют тревогу раньше пользователей, хватает: от бесплатного скрипта на cron до self-hosted панели и внешних сервисов с готовой сетью точек проверки. Разберём, какой инструмент для какой задачи, что именно он должен проверять и как довести дело до рабочего уведомления в Telegram.

Что вы на самом деле хотите знать

Вопрос «жив ли сайт» на практике распадается на несколько разных проверок, и инструмент мониторинга должен уметь больше одной из них.

Самая базовая проверка — TCP-порт: сервер вообще принимает соединение на 80/443. Она отсеет случай, когда сервер выключен или недоступен по сети, но ничего не скажет о самом сайте. Следующий уровень — HTTP-код ответа: сайт должен отдавать 200, а не 500 или 502. Но и этого мало: PHP-сайт с ошибкой в коде нередко отдаёт 200 и белую страницу с фрагментом стектрейса, WordPress с оборванным подключением к базе показывает «Error establishing a database connection» — тоже с кодом 200, потому что сама страница отрисовалась исправно, просто с текстом ошибки внутри. Формально сайт «работает», по факту — нет.

Отсюда третий, самый надёжный уровень проверки — контент. Инструмент должен не просто дёрнуть URL, а убедиться, что в ответе есть ожидаемый фрагмент текста: название компании в футере, кнопка «Оформить заказ», конкретное слово из главного экрана. Если этого текста нет — считать сайт упавшим, даже если код ответа 200. У Uptime Kuma это тип монитора Keyword, у внешних сервисов вроде UptimeRobot — Keyword Monitoring. Настраивается один раз, а ловит именно те падения, которые проверка по коду ответа пропускает: неудачный деплой, откат к дефолтной странице хостера, поломанный кеш, который отдаёт старую версию с ошибкой.

Отдельно стоит проверка сертификата: TLS истекает не мгновенно, а с предупреждением за несколько дней — и хороший инструмент мониторинга умеет слать алерт заранее, а не в момент, когда браузер уже показывает пользователям предупреждение о небезопасном соединении.

Точка проверки должна быть снаружи

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

Поэтому self-hosted решение вроде Uptime Kuma имеет смысл только на отдельном сервере — не на том, где живут проверяемые сайты. А внешние сервисы мониторинга это требование выполняют автоматически: они физически развёрнуты не у вас, и падение вашей инфраструктуры никак не задевает саму систему проверки.

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

Свой инструмент: Uptime Kuma

Если хочется полного контроля, истории инцидентов и не хочется зависеть от лимитов внешнего сервиса — ставится self-hosted панель. Самый популярный бесплатный вариант — Uptime Kuma, он есть в каталоге готовых приложений MAATRIX, разворачивается одной командой:

docker run -d --restart=unless-stopped -p 3001:3001 \
    -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Подробный разбор установки — с доменом, HTTPS, systemd-вариантом без Docker и первыми мониторами — уже разобран в отдельной статье, повторять здесь смысла нет: как установить и настроить Uptime Kuma на VPS. Там же — как закрыть панель от чужого доступа и настроить бэкап конфигурации.

Из практики: Uptime Kuma закрывает 90% потребностей одного проекта или небольшой команды сайтов — свой интерфейс, история аптайма в процентах, десятки каналов уведомлений, HTTP/TCP/DNS/keyword-мониторы, публичная статус-страница. Минус ровно один, но принципиальный: он видит мир из одной точки — с того сервера, где стоит сам. Если хочется проверять с нескольких географических точек одновременно, self-hosted вариант такого из коробки не даст — нужен либо внешний сервис, либо несколько инстансов Kuma в разных локациях.

Внешние сервисы: UptimeRobot и аналоги

Второй путь — не поднимать ничего у себя, а подключить готовый внешний сервис мониторинга. Самый известный бесплатный вариант — UptimeRobot: регистрация, добавление URL, выбор типа проверки — и сервис уже стучится к сайту с собственной инфраструктуры, независимой от вашей. Бесплатный план у таких сервисов обычно ограничен по числу мониторов и интервалу проверки — точные условия и тарифы меняются, поэтому стоит свериться с актуальной страницей тарифов сервиса, а не ориентироваться на цифры из старых статей.

Кроме UptimeRobot на рынке есть похожие сервисы — Better Stack, Freshping, StatusCake, Pingdom — с разным балансом бесплатных лимитов, числом точек проверки по миру и глубиной интеграций. Общий принцип у всех один: вы не администрируете инфраструктуру мониторинга сами, а покупаете (или получаете бесплатно, в урезанном виде) готовую сеть проверяющих серверов и панель поверх неё.

Плюс подхода — сразу несколько географических точек проверки без лишних телодвижений, что закрывает и вопрос «а видно ли сайт из России», если у сервиса есть нужный регион. Минус — вы зависите от чужой инфраструктуры и её лимитов, а более тонкая настройка (кастомные заголовки запроса, сложная логика проверки, длинная история инцидентов) обычно упирается в платный тариф.

Сравнение подходов

На практике надёжнее всего — не выбирать одно из двух, а совместить: Uptime Kuma на отдельном недорогом VPS как основной, детальный мониторинг с гибкими проверками контента, плюс бесплатный аккаунт во внешнем сервисе как независимый второй контур, который видит вас со стороны и не упадёт вместе с вашей инфраструктурой целиком. Два независимых наблюдателя стоят дешевле одного пропущенного простоя.

Уведомления в Telegram при падении

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

Создайте бота через @BotFather командой /newbot, получите токен вида 123456:ABC-DEF.... Узнайте свой chat_id — проще всего написать боту любое сообщение и запросить обновления через API:

curl "https://api.telegram.org/bot<TOKEN>/getUpdates"

В ответе будет поле chat.id — это и есть нужный идентификатор.

В Uptime Kuma: раздел Settings → Notifications → добавить Telegram, вставить токен и chat_id, привязать уведомление к нужным мониторам. Подробности и частые ошибки при настройке — включая случай, когда уведомления почему-то не приходят при явно рабочем токене — разобраны в отдельной статье: как установить и настроить алерты в Telegram на VPS.

В UptimeRobot: раздел My Settings → Add Alert Contact, тип Telegram, там же авторизация бота через официальный интеграционный бот сервиса — процесс отличается от Kuma, но тоже занимает пару минут.

В обоих случаях важно не ограничиваться уведомлением о падении — включите и уведомление о восстановлении, чтобы не гадать, жива ли проблема прямо сейчас. И не ставьте алерт на первую же неудачную проверку: короткий сетевой всплеск на 10-15 секунд не повод будить вас ночью. Задайте порог в 2-3 неудачные проверки подряд перед тем, как система решит, что сайт действительно упал — это отфильтрует ложные тревоги и оставит только реальные инциденты. О том, как выстроить реакцию на такие алерты уже после того, как они пришли, — в статье мониторинг и алерт при падении сайта.

Частые вопросы