Кожна хвилина простою коштує грошей і репутації. Правильний моніторинг дозволяє реагувати на проблеми протягом хвилин, а не годин.
UptimeRobot — безкоштовний моніторинг
- Зареєструйтеся на uptimerobot.com
- Add New Monitor → HTTP(s)
- URL:
https://yourdomain.com - Інтервал: 5 хвилин (безкоштовний план)
- Сповіщення: Email, Telegram, Slack
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-звітність з історією інцидентів за місяці для клієнтів чи керівництва — безкоштовні інструменти зазвичай зберігають історію обмежений термін, для тривалої звітності потрібен платний план або власна база інцидентів.
Перевірка результату
- Запустіть скрипт вручну і тимчасово зупиніть Nginx:
systemctl stop nginx— має прийти сповіщення в Telegram протягом наступного запуску за cron. - Перевірте, що cron справді виконує задачу:
grep CRON /var/log/syslog | tailмає показувати регулярні записи про запуск скрипту. - Переконайтесь, що скрипт не шле хибні спрацювання при короткочасних мережевих затримках — додайте повторну перевірку перед алертом, якщо поодинокі хибні спрацювання вже траплялися.
- Перевірте, що після відновлення сайту система також надсилає сповіщення про відновлення, а не лише про аварію — інакше легко забути, що проблему давно вирішено.
Для моніторингу ресурсів самого сервера, а не лише доступності сайту ззовні, — стаття про Netdata. Self-hosted альтернатива UptimeRobot із власним дашбордом розібрана в статті про Uptime Kuma.