Моніторинг доступності 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.