Мониторинг доступности VPS: настройка алертов

Без мониторинга вы узнаете о проблемах с сервером от недовольных клиентов. Инструменты uptime-мониторинга проверяют доступность каждые 1–5 минут и моментально уведомляют о сбоях.

Бесплатные инструменты

UptimeRobot: настройка за 5 минут

1. Зарегистрируйтесь на uptimerobot.com
2. Add New Monitor → HTTP(s)
3. URL: ваш сайт или IP
4. Monitoring Interval: 5 minutes
5. Alert Contacts: добавьте email и/или Telegram

Локальный мониторинг через скрипт

#!/bin/bash
# /usr/local/bin/check-services.sh

services=("nginx" "mysql" "php8.2-fpm")
BOT_TOKEN="your_telegram_token"
CHAT_ID="your_chat_id"

for service in "${services[@]}"; do
    if ! systemctl is-active --quiet "$service"; then
        msg="ALERT: $service is DOWN on $(hostname)!"
        curl -s "https://api.telegram.org/bot$BOT_TOKEN/sendMessage"             -d "chat_id=$CHAT_ID&text=$msg" > /dev/null
        systemctl restart "$service"
    fi
done

# Добавить в cron (каждые 2 минуты)
*/2 * * * * /usr/local/bin/check-services.sh

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

# Netdata — красивый dashboard в реальном времени
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
# После установки: http://your-vps-ip:19999

Разбор типичных ошибок мониторинга

UptimeRobot показывает Up, а сайт при этом отдаёт ошибку 500 — внешний монитор по умолчанию проверяет только HTTP-код ответа. Если сервер возвращает "200 OK" с пустой страницей ошибки внутри (например, PHP-исключение перехвачено и подставлена заглушка), монитор этого не заметит.

# Проверка кода ответа вручную
curl -o /dev/null -s -w "%{http_code}\n" https://example.com
200

# Но контент внутри — ошибка PHP
curl -s https://example.com | grep -i "fatal error"
Fatal error: Uncaught PDOException in /var/www/app/db.php:12

Решение — настроить в UptimeRobot проверку по ключевому слову (Keyword Monitoring): указать текст, который должен присутствовать на странице при нормальной работе, и монитор пометит сайт как Down, если этого текста нет.

Локальный скрипт перезапускает сервис, но алерт в Telegram не приходит — чаще всего проблема в неверном экранировании амперсанда в URL или в лишних пробелах при переносе строки командой \.

curl: (3) URL using bad/illegal format or missing URL

Это значит, что переменная $msg содержит пробелы и не заключена в кавычки, либо перенос строки после \ добавил невидимый символ. Проверяйте скрипт построчно через bash -x check-services.sh.

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

Когда внешнего мониторинга недостаточно

• Нужно знать причину падения, а не только факт — внешний монитор скажет "сайт недоступен", но не покажет, что закончилась память или диск заполнен на 100%.
• Важна скорость реакции до появления жалоб пользователей — интервал 3–5 минут внешнего сервиса означает, что часть пользователей уже увидит ошибку.
• Сервис работает только во внутренней сети без публичного IP — UptimeRobot и подобные не смогут достучаться до приватного адреса.
• Нужны метрики за длительный период для анализа трендов — бесплатные внешние мониторы обычно хранят историю не больше 1–3 месяцев.
• Нужен контроль не только веб-сервера, но и фоновых задач (cron, очереди) — внешний HTTP-монитор не видит, зависла ли обработка очереди сообщений, для этого нужны отдельные heartbeat-проверки из самого приложения.

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

1. В панели UptimeRobot статус монитора должен смениться на Up в течение первого цикла проверки после настройки.
2. Отключите Nginx вручную (sudo systemctl stop nginx) и убедитесь, что уведомление о падении пришло в течение заявленного интервала.
3. Запустите Nginx обратно и проверьте, что пришло уведомление о восстановлении (Up), а не только о падении.
4. Для локального скрипта проверьте лог: tail -20 /var/log/syslog | grep check-services — там должны быть записи о срабатывании cron.

Для глубокого анализа ресурсов после алерта пригодится Netdata, а для метрик с историей и графиками — Grafana с Prometheus.