Як налаштувати Uptime Kuma на VPS

Uptime Kuma — це монітор з відкритим кодом для самостійного розміщення, який підтримує перевірки HTTP(S), TCP, ping, DNS, WebSocket та інші. На окремому VPS він продовжує перевірки, коли ваш продакшен-сервер падає, а не зникає разом із ним.

Ця інструкція розгортає Uptime Kuma v2 на VPS за допомогою Docker Compose, залишає порт 3001 на локальному інтерфейсі, додає HTTPS через Caddy, надсилає сповіщення в Telegram, Discord і Slack та публікує сторінку статусу.

Вимоги та що вам знадобиться

• VPS щонайменше з 1 vCPU, 1 ГБ ОЗП і 10 ГБ локального SSD-сховища
• Ubuntu 24.04 LTS або інший актуальний випуск Ubuntu, який підтримує Docker
• Docker Engine і Docker Compose, встановлені на VPS
• Домен або субдомен, спрямований на VPS через A-запис (наприклад, status.example.com)
• Доступ через SSH і базові навички роботи в командному рядку

Якщо Docker ще не встановлено, скористайтеся посібником Docker зі встановлення на Ubuntu. Він встановлює Docker Engine і плагін Compose, який використовується нижче.

Чому VPS для моніторингу має бути відокремлений від того, що він перевіряє

Продакшен і моніторинг на одному сервері мають спільний домен відмови. Якщо цей сервер зупиняється, зникають і застосунок, і система, що має надіслати сповіщення.

Покращити це допомагають дві практичні схеми:

1. Той самий провайдер, інша локація. Розмістіть продакшен і моніторинг на окремих хостах у різних локаціях. Це зменшує вразливість до відмови одного сервера чи одного дата-центру, але не захищає від будь-яких мережевих аварій або збоїв керуючого рівня в межах усього провайдера.
2. Цілком інший провайдер. Розміщення монітора в іншого провайдера захищає й від аварій, що зачіпають провайдера цілком. Платою за це є ще один обліковий запис, ще один рахунок і ще одна операційна поверхня.

Один екземпляр Uptime Kuma усе одно не має зовнішнього спостерігача. Додайте одну зовнішню HTTP(S)-перевірку його публічної сторінки статусу. Безкоштовний тариф UptimeRobot наразі містить 50 моніторів з інтервалом у п'ять хвилин. Високої доступності Uptime Kuma це не дасть, але повідомить, коли зникне сам монітор.

Те саме правило стосується публічних сторінок статусу: те, що повідомляє вам про збій, не повинно бути в одному домені відмови з тим, що збоїть.

Підбір розміру VPS

В Uptime Kuma немає надійної формули «кількість моніторів до обсягу ОЗП», бо навантаження залежить від типу монітора, інтервалу, налаштувань повторів і глибини зберігання історії. Прості перевірки HTTP(S), TCP, ping і DNS легші за перевірки Browser Engine, які запускають Chromium.

Для невеликого набору базових перевірок почніть з 1 vCPU, 1 ГБ ОЗП і локального SSD. Стежте за реальним споживанням за допомогою docker stats uptime-kuma а зростання бази даних — за допомогою du -sh /opt/uptime-kuma/data. Додавайте пам'ять, коли споживання стабільно високе, коли контейнер повідомляє про OOM kill або коли ви додаєте перевірки Browser Engine.

Повний образ v2 містить Chromium і вбудовану MariaDB; документація щодо тегів Docker пояснює різницю між образами full і slim.

Розгортання Uptime Kuma за допомогою Docker Compose

Збережіть цей файл як docker-compose.yml у /opt/uptime-kuma/:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      # Bind to localhost only. The reverse proxy will expose it on 443.
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data

Три рядки варті окремої уваги:

• image: louislam/uptime-kuma:2 фіксує мажорну версію. Тег :2 відстежує стабільну гілку 2.x. Не використовуйте :latest.
• 127.0.0.1:3001:3001 прив'язує контейнер лише до localhost. Публічний інтернет ніколи не повинен звертатися до порту 3001 напряму. TLS-сертифікат і публічне ім'я хоста тримає зворотний проксі.
• Том із даними містить базу даних, конфігурацію моніторів та історію. Тримайте його на локальному сховищі, бо документація зі встановлення Uptime Kuma попереджає, що файлові системи без надійного POSIX-блокування, зокрема багато конфігурацій NFS, можуть пошкодити SQLite. Зупиніть стек, перш ніж робити копію на рівні файлової системи.

Запустіть і перевірте:

sudo install -d -o "$USER" -g "$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
# Paste the docker-compose.yml file above.
sudo docker compose up -d
sudo docker compose ps

Очікуваний вивід docker compose ps:

NAME          IMAGE                       STATUS                   PORTS
uptime-kuma   louislam/uptime-kuma:2      Up (healthy)             127.0.0.1:3001->3001/tcp

Щоб уперше зайти в панель, не відкривайте порт 3001 в інтернет навіть ненадовго. Скористайтеся SSH-тунелем:

ssh -L 3001:127.0.0.1:3001 [email protected]

Відкрийте http://localhost:3001 у браузері, створіть обліковий запис адміністратора, задайте надійний пароль і закрийте тунель. Відтепер панель доступна через HTTPS за допомогою зворотного проксі.

Якщо ручний Compose вам не потрібен, у нас також є Uptime Kuma у вигляді застосунку в один клік. На поточній сторінці застосунку вказано v1, тож вона не збігається з налаштуванням v2 із цього посібника. Якщо вам потрібна саме v2, скористайтеся ручним шляхом через Compose.

Зворотний проксі та TLS

Не виставляйте Uptime Kuma напряму. Поставте перед ним зворотний проксі заради TLS, коректної обробки URL і єдиної публічної точки входу. Є два шляхи.

Caddy. Якщо Caddy ще не встановлено, скористайтеся офіційною інструкцією щодо пакета для Ubuntu. Коли Caddy працює як служба на хості, наведений нижче Caddyfile проксіює запити до Uptime Kuma на локальному інтерфейсі й автоматично випускає та поновлює сертифікат.

Порада: якщо на VPS для моніторингу крутиться лише Uptime Kuma, беріть Caddy. Caddyfile вміщується в три рядки, а випуск і поновлення сертифіката Caddy бере на себе. Жодного Certbot і жодного окремого таймера оновлення, який доводиться глядіти о 4 ранку.

Збережіть це як /etc/caddy/Caddyfile:

status.example.com {
    reverse_proxy 127.0.0.1:3001
}

Перезавантажте конфігурацію Caddy:

sudo systemctl reload caddy

Перевірте:

curl -I https://status.example.com

Ви маєте отримати успішну відповідь 2xx або 3xx із чинним сертифікатом. Якщо з'єднання не вдається, переконайтеся, що A- або AAAA-запис домену вказує на цей VPS, що порти 80 і 443 доступні та що Caddy може зайняти обидва. Усе це входить до вимог Caddy до автоматичного HTTPS.

Nginx Proxy Manager. Якщо NPM працює безпосередньо на хості, додайте Proxy Host для status.example.com, спрямуйте його на 127.0.0.1, порт 3001, запросіть сертифікат Let's Encrypt і увімкніть Websockets Support. Якщо NPM працює в Docker, 127.0.0.1 вказує на сам контейнер NPM. Тоді підключіть NPM та Uptime Kuma до однієї мережі Docker, а потім спрямуйте proxy host на uptime-kuma, порт 3001.

Маршрутизація сповіщень: Telegram, Discord, Slack

Uptime Kuma може надсилати одну й ту саму подію монітора в кілька каналів сповіщень. Налаштуйте кожного провайдера один раз, а потім прив'яжіть до монітора один чи кілька каналів залежно від того, кому потрібне сповіщення.

Сповіщення налаштовуються глобально в розділі Settings > Notifications, а потім призначаються окремим моніторам. Кожен монітор може надсилати в один або кілька каналів. Те саме сповіщення може піти в Telegram черговому інженерові, у Slack команді та на пошту для журналу аудиту, і все це з однієї події.

Telegram

1. У Telegram напишіть @BotFather і виконайте /newbot. Оберіть ім'я та username. BotFather надішле токен бота. Збережіть його.
2. Надішліть новому боту будь-яке повідомлення. Потім відкрийте в браузері https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates. Знайдіть поле chat.id — це і є ваш chat ID.
3. В Uptime Kuma: Settings > Notifications > Setup Notification > Telegram. Вставте токен бота і chat ID. Натисніть Тест. Переконайтеся, що бот надсилає тестове сповіщення.
4. Якщо тестове повідомлення не приходить, перевірте правильність токена бота і chat ID та переконайтеся, що фаєрвол VPS дозволяє вихідні HTTPS-з'єднання до api.telegram.org.

Discord

1. Відкрийте сервер Discord, куди мають надходити сповіщення. Клацніть правою кнопкою на потрібному каналі, потім Edit Channel > Integrations > Webhooks > New Webhook. Дайте йому назву (наприклад, «Uptime Kuma»), виберіть канал і скопіюйте URL вебхука.
2. В Uptime Kuma: Settings > Notifications > Setup Notification > Discord. Вставте URL вебхука. За бажанням задайте ім'я користувача та аватар.
3. Натисніть Тест. Переконайтеся, що вебхук публікує тестове сповіщення в каналі.

Slack

1. У Slack створіть Incoming Webhook для каналу, куди мають надходити сповіщення. Slack поверне URL вебхука виду https://hooks.slack.com/services/T.../B.../....
2. В Uptime Kuma: Settings > Notifications > Setup Notification > Slack. Вставте URL вебхука. За бажанням налаштуйте піктограму та перевизначення каналу.
3. Натисніть Тест.

Коли всі тести проходять, відредагуйте кожен монітор і виберіть канали сповіщень, які він має використовувати. Налаштуйте Max Retries (максимум повторів) та Retry Interval (інтервал між повторами) так, щоб короткочасний збій не спричиняв сповіщення одразу.

Вбудована сторінка статусу (і коли її стане замало)

Uptime Kuma містить публічні сторінки статусу з власними слагами, згрупованими моніторами, власними доменами, дописами про інциденти та повідомленнями про планові роботи. З одного екземпляра можна опублікувати й кілька сторінок статусу для різних сервісів чи аудиторій.

Більше обмеження стосується комунікації з клієнтами. Відвідувачі поки що не можуть підписатися на оновлення електронною поштою просто зі сторінки статусу, а сама публічна сторінка лишається частиною того самого застосунку Uptime Kuma, що й панель оператора. Самостійна підписка відвідувачів досі значиться як відкритий запит на функцію.

Якщо вам потрібні підписки клієнтів або система статусу, відокремлена від панелі моніторингу, однією з альтернатив є Kener. Наш матеріал про самостійно розміщений стек моніторингу пояснює, як поєднати ці два інструменти.

ЧИТАЙ

Налаштування стека моніторингу Grafana + Prometheus на вашому VPS (посібник із Docker Compose)

Типові проблеми

Сповіщення мовчки не спрацьовують, коли фаєрвол VPS блокує вихідний HTTPS. Симптом: кнопка Test працює для одних каналів і не працює для інших. Розв'язання: переконайтеся, що вихідні HTTPS-з'єднання дозволені й що curl -I https://api.telegram.org з VPS виконується успішно.

Браузер показує «ERR_TOO_MANY_REDIRECTS» після ввімкнення проксі. Пошукайте дубльовані переспрямування з HTTP на HTTPS у Caddy, Nginx Proxy Manager або у вищому CDN. Uptime Kuma має й далі віддавати HTTP на порту 3001, а TLS завершує публічний зворотний проксі. Якщо ви вмикаєте довірені заголовки проксі, поточний шлях такий: Settings > Reverse Proxy > HTTP Headers > Trust Proxy.

Контейнер перезапускається кожні кілька хвилин. Перевірте, чи не було контейнер зупинено через брак пам'яті, а потім поспостерігайте за поточним споживанням через docker stats uptime-kuma. Якщо контейнер убив OOM або пам'ять тримається біля межі VPS, додайте ОЗП, приберіть важкі перевірки або збільште їхні інтервали.

Сторінка статусу працює на localhost, але не через публічне ім'я хоста. Переконайтеся, що зворотний проксі передає кореневий шлях без змін, зберігає заголовок Host і підтримує WebSockets. Uptime Kuma не підтримує встановлення в підкаталозі, тож використовуйте окремий домен або субдомен, а не шлях на кшталт example.com/uptime-kuma.

Підсумок

Uptime Kuma на окремому VPS дає вам контроль над перевірками, маршрутизацією сповіщень і публічною сторінкою статусу, але разом з тим на вас лягають оновлення, резервні копії, патчі ОС і зовнішній наглядач за самим монітором. Візьміть VPS у локації, відмінній від продакшену, розгорніть v2 через Docker Compose або скористайтеся застосунком в один клік, попередньо перевіривши вказану версію, поставте попереду Caddy та підключіть канали, за якими справді стежить ваша команда.

Часті запитання

Скільки оперативної пам'яті потрібно Uptime Kuma?

В Uptime Kuma немає надійної формули «монітори до ОЗП», бо споживання залежить від типу монітора, інтервалу перевірки, налаштувань повторів, глибини зберігання історії та використання Browser Engine. Для невеликого набору базових перевірок почніть з 1 ГБ ОЗП і стежте за реальним споживанням через docker stats uptime-kuma. Додайте пам'яті, якщо споживання тримається біля межі або контейнер убиває OOM.

Чи варто запускати Uptime Kuma на тому самому сервері, що й застосунок?

Ні. Якщо інструмент моніторингу та застосунок ділять один сервер, його відмова вимикає обидва одночасно, і ви втрачаєте сповіщення саме тоді, коли вони найпотрібніші. Запускайте Uptime Kuma на окремому VPS, бажано в іншому дата-центрі.

Чи може Uptime Kuma надсилати сповіщення в Telegram, Discord і Slack?

Так. Telegram, Discord і Slack входять до вбудованих служб сповіщень поряд з електронною поштою, звичайними вебхуками, PagerDuty, ntfy, Mattermost та багатьма іншими. Telegram використовує токен бота і chat ID, а Discord і Slack — URL вебхуків. До одного монітора можна прив'язати кілька каналів сповіщень.

Чим Uptime Kuma відрізняється від UptimeRobot?

Uptime Kuma ви розміщуєте самі, тож сервер, оновлення, резервні копії й маршрутизація сповіщень — ваша турбота. Він підтримує інтервали перевірок аж до 20 секунд. UptimeRobot — це хостований SaaS, і його поточний безкоштовний тариф містить 50 моніторів із перевірками раз на п'ять хвилин. Обирайте Uptime Kuma, якщо хочете контролю, або UptimeRobot, якщо не хочете обслуговувати сервер моніторингу.

Чи має Uptime Kuma публічну сторінку статусу?

Так. Ви можете обирати, які монітори видно, групувати їх, публікувати кілька сторінок статусу, прив'язувати до них власні домени та планувати повідомлення про роботи. Самостійної підписки відвідувачів електронною поштою немає, тож якщо клієнтам потрібна підписка на оновлення, скористайтеся окремим клієнтським інструментом для сторінок статусу.