К основному содержимому

Мониторинг сайта: UptimeRobot, Zabbix и системные алерты

VDS / VPS · 20.02.2026 · 4 мин чтения
Иллюстрация к статье «Мониторинг сайта: UptimeRobot, Zabbix и системные алерты»

Каждая минута простоя стоит денег и репутации. Правильный мониторинг позволяет реагировать на проблемы в течение минут, а не часов.

UptimeRobot — бесплатный мониторинг

  1. Зарегистрируйтесь на uptimerobot.com
  2. Add New Monitor → HTTP(s)
  3. URL: https://yourdomain.com
  4. Интервал: 5 минут (бесплатный план)
  5. Оповещение: Email, Telegram, Slack
✅ Бесплатный план UptimeRobot: до 50 мониторов, интервал 5 минут, SMS/email алерты. Для большинства проектов достаточно.

Telegram-алерты с VPS через bash

#!/bin/bash
# /usr/local/bin/check-site.sh
BOT_TOKEN="ВАШ_ТОКЕН"
CHAT_ID="ВАШ_CHAT_ID"
URL="https://yourdomain.com"

HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL")

if [ "$HTTP_CODE" != "200" ]; then
  curl -s "https://api.telegram.org/bot$BOT_TOKEN/sendMessage"     -d "chat_id=$CHAT_ID"     -d "text=🚨 Сайт недоступен! Code: $HTTP_CODE - $(date)"
fi
chmod +x /usr/local/bin/check-site.sh
# Cron каждые 5 минут:
*/5 * * * * /usr/local/bin/check-site.sh

Мониторинг ресурсов сервера

# Установить netdata (красивый дашборд)
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
# Доступен на http://ВАШ_IP:19999

Полезные команды диагностики

htop              # CPU, RAM, процессы
iotop             # Нагрузка на диск
nethogs           # Трафик по процессам
df -h             # Место на диске
free -h           # Использование RAM
ss -tlnp          # Открытые порты

Разбор типичных проблем скрипта проверки

Скрипт шлёт «сайт недоступен», хотя сайт открывается в браузере — частая причина в том, что curl без дополнительных флагов не следует за редиректами и не выставляет заголовок User-Agent, из-за чего некоторые сайты или WAF отдают код 403 или 301 вместо 200.

$ curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com
403

Добавьте -L для следования за редиректами и заголовок User-Agent, имитирующий браузер, если сайт защищён от ботов: curl -s -L -A "Mozilla/5.0" -o /dev/null -w "%{http_code}" https://yourdomain.com. Проверьте итоговую команду вручную из консоли, прежде чем класть её в cron — так вы увидите реальный код ответа, а не только результат работы скрипта.

Telegram-уведомление не приходит, хотя curl к Telegram API выполняется без ошибок — проверьте код ответа самого Telegram, а не только код завершения curl: неверный chat_id или невыполненный /start у бота вернёт JSON с "ok": false, но curl завершится с кодом 0, потому что запрос технически прошёл.

{"ok":false,"error_code":400,"description":"Bad Request: chat not found"}

Сравнение вариантов мониторинга аптайма

ВариантОткуда проверяетсяМинимальный интервал
UptimeRobot (бесплатный план)Внешние сервера сервиса5 минут
Bash-скрипт на самом VPSС того же сервера, что и сайтЛюбой, зависит от cron
Uptime Kuma (self-hosted)С вашего отдельного сервера мониторинга20 секунд
ZabbixС выделенного сервера мониторинга, поддерживает агентовНастраиваемый, вплоть до секунд

Когда мониторинга с одной точки недостаточно

  • Bash-скрипт на самом VPS не заметит, что сервер целиком недоступен — если упал сам сервер, некому запустить проверку и отправить алерт. Нужен внешний сервис вроде UptimeRobot, который проверяет сайт снаружи.
  • Один внешний чекер может дать ложное срабатывание из-за временных проблем у себя в сети — платные планы мониторинга проверяют с нескольких географических точек и шлют алерт только при совпадении отказов.
  • Нужен мониторинг не только HTTP-кода, но и содержимого страницы или времени ответа критического API — простой скрипт на curl проверяет только код ответа, для контроля контента нужны более специализированные проверки.
  • Требуется SLA-отчётность с историей инцидентов за месяцы для клиентов или руководства — бесплатные инструменты обычно хранят историю ограниченный срок, для долгой отчётности нужен платный план или собственная база инцидентов.

Проверка результата

  1. Запустите скрипт вручную и временно остановите Nginx: systemctl stop nginx — должно прийти уведомление в Telegram в течение следующего запуска по cron.
  2. Проверьте, что cron реально выполняет задачу: grep CRON /var/log/syslog | tail должен показывать регулярные записи о запуске скрипта.
  3. Убедитесь, что скрипт не шлёт ложные срабатывания при кратковременных сетевых заминках — добавьте повторную проверку перед алертом, если единичные ложные срабатывания уже случались.
  4. Проверьте, что после восстановления сайта система также присылает уведомление о восстановлении, а не только об аварии — иначе легко забыть, что проблема давно решена.

Для мониторинга ресурсов самого сервера, а не только доступности сайта снаружи, — статья про Netdata. Self-hosted альтернатива UptimeRobot с собственным дашбордом и историей без ограничения по времени разобрана в статье про Uptime Kuma.

Статья помогла?
← Назад в базу знаний Задать вопрос поддержке