Как отслеживать доступность сайта и получать алерты
Практика4 минРедакция Innovialabs
Коротко
Подключите внешний uptime-сервис, который проверяет сайт из нескольких регионов каждые 1–5 минут, шлёт алерт в Telegram или на почту после 2–3 неудачных проверок подряд и публикует страницу статуса для клиентов.
Короткий ответ
Доступность сайта нужно проверять снаружи, а не с того же сервера, где он работает. Если сервер упал, мониторинг на нём упадёт вместе с ним и никого не предупредит. Поэтому используют внешние uptime-чекеры: они раз в несколько минут отправляют запрос на ваш сайт из разных точек мира и сообщают, если ответа нет или он неправильный.
Минимальная рабочая схема:
- проверка главной страницы и одной важной страницы (например, оформления заказа или API);
- интервал 1–5 минут;
- алерт в Telegram и на почту ответственного;
- публичная страница статуса для клиентов.
Какие бывают проверки
| Тип проверки | Что проверяет | Когда нужна |
|---|---|---|
| HTTP(S) | Код ответа (200, 301 и т.д.) | Всегда, базовый минимум |
| Ключевое слово | Есть ли на странице нужный текст | Когда сайт может отдавать 200 с пустой или ошибочной страницей |
| Ping / TCP-порт | Отвечает ли сервер или конкретный порт | Для серверов, баз данных, почты |
| SSL | Срок действия сертификата | Чтобы не пропустить истечение |
| Домен | Срок регистрации домена | Чтобы домен не «отвалился» внезапно |
| Heartbeat (cron) | Что фоновая задача отчиталась вовремя | Бэкапы, рассылки, синхронизации |
Проверка по ключевому слову часто полезнее простой HTTP-проверки: сайт может отвечать кодом 200, но показывать страницу ошибки базы данных.
Как выбрать сервис
Простых внешних сервисов много: UptimeRobot, Better Stack, Pingdom, Freshping, Uptime Kuma (open source, ставится на свой сервер). Сравнивайте их не по названию, а по критериям:
- Минимальный интервал проверок на нужном вам тарифе.
- Количество регионов, из которых идут проверки. Подтверждение из нескольких точек снижает ложные тревоги.
- Каналы уведомлений: Telegram, email, SMS, звонок, webhook.
- Страница статуса: есть ли, можно ли подключить свой поддомен.
- История и отчёты по доступности за месяц.
Если вы ставите self-hosted решение вроде Uptime Kuma, размещайте его на другом сервере и у другого провайдера, чем основной сайт.
Настройка интервалов и алертов
Интервал. Для коммерческого сайта разумно 1–3 минуты, для внутренних сервисов — 5 минут. Слишком частые проверки не дают реальной пользы и иногда создают лишнюю нагрузку.
Подтверждение сбоя. Отправляйте алерт не после первой неудачи, а после 2–3 подряд или после подтверждения из нескольких регионов. Иначе кратковременные сетевые сбои будут будить вас по ночам, и команда начнёт игнорировать уведомления.
Таймаут. Задайте разумное время ожидания ответа. Если страница грузится очень долго, для пользователя это почти то же самое, что недоступность.
Telegram-алерты. Большинство сервисов умеют слать уведомления в Telegram напрямую или через бота. Удобная схема:
- Создайте отдельный чат или канал для алертов.
- Добавьте туда бота сервиса мониторинга (или своего бота через webhook).
- Включите уведомления и о падении, и о восстановлении.
Email оставьте как резервный канал: если что-то не так с Telegram, письмо всё равно дойдёт.
Если сервис поддерживает только webhook, сообщение в Telegram можно отправить запросом к Bot API:
curl -s "https://api.telegram.org/bot<TOKEN>/sendMessage" \
-d chat_id=<CHAT_ID> \
-d text="Сайт example.com недоступен"
Публичная страница статуса
Страница статуса снижает поток вопросов в поддержку во время сбоя: клиенты видят, что вы знаете о проблеме и работаете над ней.
Что на ней должно быть:
- список компонентов (сайт, API, личный кабинет, оплата);
- текущий статус каждого;
- история инцидентов с короткими пояснениями;
- плановые работы, объявленные заранее.
Размещайте её на поддомене вроде status.example.com и на внешней платформе, а не на том же сервере. Иначе при сбое пропадёт и сайт, и страница о сбое.
Частые ошибки
- Мониторинг стоит на том же сервере, что и сайт.
- Проверяется только главная страница, а ломается оформление заказа.
- Алерты уходят одному человеку, который в отпуске.
- Нет уведомлений о восстановлении — непонятно, когда проблема ушла.
- Не отслеживаются сроки SSL-сертификата и домена.