Uptime Kuma: self-hosted моніторинг серверів та сайтів

Uptime Kuma: моніторинг серверів та сайтів

Uptime Kuma — self-hosted open-source альтернатива UptimeRobot з красивим інтерфейсом, сповіщеннями в Telegram і підтримкою моніторів HTTP, TCP, DNS, Docker та інших.

Встановлення через Docker

docker run -d   --name uptime-kuma   -p 3001:3001   -v uptime-kuma:/app/data   --restart unless-stopped   louislam/uptime-kuma:latest

Відкрийте http://your-server:3001 для первинного налаштування.

Docker Compose

version: '3.8'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    ports:
      - "3001:3001"
    volumes:
      - ./uptime-kuma-data:/app/data
    restart: unless-stopped

Nginx Reverse Proxy + SSL

server {
    listen 443 ssl;
    server_name status.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/status.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/status.yourdomain.com/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
        proxy_set_header   Host $host;
    }
}

Налаштування моніторів

• HTTP(S) — перевірка сайту, очікуваний статус 200, keyword match
• TCP Port — перевірка доступності порту (MySQL 3306, SSH 22)
• DNS — моніторинг DNS-записів
• Docker Container — стан контейнера
• Ping — ICMP-перевірка доступності

Сповіщення в Telegram

У налаштуваннях додайте Notification → Telegram:

Bot Token: 123456:ABCdefGHIjklMNO
Chat ID: -1001234567890  # для групи

# Отримати Chat ID:
curl "https://api.telegram.org/bot{TOKEN}/getUpdates"

Status Page (публічна сторінка)

Uptime Kuma підтримує створення красивих публічних Status Page — показуйте стан сервісів клієнтам без доступу до панелі адміністратора.

Розбір реальних помилок

Три ситуації закривають майже всі звернення під час першого налаштування Uptime Kuma: права на volume, неправильний Chat ID у Telegram і самопідписаний сертифікат у внутрішнього сервісу. Усі три легко відтворити і так само легко усунути, якщо розуміти першопричину, а не просто перезапускати контейнер.

База даних недоступна для запису

Error: EACCES: permission denied, open '/app/data/kuma.db'

Контейнер Uptime Kuma працює від непривілейованого користувача всередині образу, а змонтована директорія ./uptime-kuma-data на хості належить root. Виправляється командою chown -R 1000:1000 ./uptime-kuma-data — дізнатися реальний UID процесу всередині контейнера можна через docker exec uptime-kuma id.

Telegram не доставляє сповіщення

Error: Bad Request: chat not found

Chat ID вказано неправильно — часта причина в тому, що для груп Telegram використовує від'ємні ID (наприклад, -1001234567890), а супергрупи починаються з -100. Якщо бот не є учасником групи або заблокований користувачем у приватних повідомленнях — помилка буде та сама.

Uptime Kuma проти UptimeRobot і Healthchecks.io

Коли Uptime Kuma не підходить

• Потрібен моніторинг з кількох географічних регіонів одночасно — self-hosted інсталяція перевіряє лише з одного VPS, і локальний збій мережі дасть хибну тривогу.
• Клієнтам важливий незалежний сторонній звіт про доступність — self-hosted сторінка статусу не вважається нейтральним доказом у SLA-суперечках.
• Потрібні складні ланцюги ескалації чергувань (on-call rotation) — тут чесніше підійде PagerDuty або Opsgenie.
• Планується кілька тисяч моніторів — SQLite за замовчуванням не розрахований на таке навантаження без додаткового налаштування.
• Потрібна довга історія метрик для SLA-звітності за роки — Uptime Kuma зберігає агрегати обмежений термін.

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

# Контейнер піднятий і слухає порт
docker ps | grep uptime-kuma
curl -I http://localhost:3001

# API статусу конкретного монітора (публічний, якщо увімкнена Status Page)
curl https://status.yourdomain.com/api/status-page/heartbeat/default

# Логи контейнера при дивній поведінці
docker logs uptime-kuma --tail 50

Порожня відповідь на curl -I або код, відмінний від 200/301, означає, що nginx reverse proxy не достукався до контейнера — перевірте, що proxy_pass вказує на правильний порт і що контейнер взагалі запущений. Після первинної перевірки варто налаштувати сам сервер моніторингу за чек-листом зі статті про налаштування хмарного сервера, а резервні копії бази Uptime Kuma зручно ганяти через rclone.