До основного вмісту

Моніторинг сайту: 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.

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці