Uptime Kuma навчила сервер говорити першим

Справжній моніторинг починається не там, де є красивий dashboard, а там, де сервер сам першим подає сигнал. Саме таку роль на моєму VPS отримала Uptime Kuma.

На цьому етапі я зібрав базовий observability loop:

• перевірки HTTP(s) для публічних сервісів
• окремий Ping монітор на сам VPS
• Telegram-сповіщення
• SSL expiry alerts

Які монітори я додав

Мінімальний набір покрив три прикладні сервіси і один базовий мережевий рівень:

• https://dev.bombaworkflows.com
• https://kuma.bombaworkflows.com
• https://portainer.bombaworkflows.com
• VPS Ping

Це важливо, бо HTTP і Ping відповідають на різні питання:

• HTTP каже: "сервіс віддає сторінку або відповідь?"
• Ping каже: "хост взагалі живий у мережі?"

Якщо Ping зелений, а HTTP червоний, проблема вже не в самому VPS, а швидше в nginx, застосунку, SSL або проксі-ланцюжку.

Telegram alerts: найважливіший практичний крок

Dashboard корисний тільки тоді, коли ти на нього дивишся. Telegram корисний тим, що він приходить сам. І це, чесно кажучи, саме той рівень зручності, після якого назад уже не хочеться.

У мене вже був готовий бот, тож я не створював новий. Я просто знайшов chat_id, після чого вніс у Uptime Kuma:

• bot token
• chat ID

і натиснув тест.

Результат був саме той, який і хочеться побачити в таких налаштуваннях: бот прислав тестове повідомлення в Telegram.

Це означає, що канал сповіщень реально працює, а не просто красиво збережений у формі.

Нюанс із getUpdates і webhook

Під час пошуку chat_id в Telegram API легко натрапити на помилку:

{"ok":false,"error_code":409,"description":"Conflict: can't use getUpdates method while webhook is active; use deleteWebhook to delete the webhook first"}

Це не означає, що бот "зламаний". Це означає лише те, що для нього вже активний webhook, і метод getUpdates у цей момент не підходить.

Практичний висновок простий:

• якщо chat_id уже відомий, немає сенсу ламати існуючу інтеграцію
• якщо бот використовується десь ще, треба бути обережним з deleteWebhook

У моєму випадку найкращим рішенням було взяти готовий chat_id і не чіпати діючу схему.

SSL expiry notifications: маленька настройка з великим ефектом

Для dev і kuma я додав також перевірку терміну дії сертифіката. Це одна з тих фіч, які не виглядають вражаюче в перший день, але одного разу рятують від дуже неприємного ранку.

Uptime Kuma показує не лише факт доступності сервісу, а й окремий блок по сертифікату:

• скільки днів залишилось
• дата завершення дії
• дата доменної перевірки

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

Як я перевіряв версію Uptime Kuma

Окремо я навчився перевіряти, що саме запущено в контейнері, а не довіряти тільки UI.

Команди були такими:

docker inspect uptime-kuma --format '{{.Config.Image}}'
docker exec uptime-kuma sh -lc 'node -p "require(\"/app/package.json\").version"'

Це показало:

• який Docker image реально використовується
• яка версія застосунку лежить всередині контейнера

На тому етапі я підтвердив, що спочатку працювала 1.23.17, а потім успішно перейшов на 2.2.1.

Оновлення Uptime Kuma: що важливо перевірити після upgrade

Після оновлення я перевіряв не просто "відкривається чи ні", а цілий ланцюжок:

curl -I http://127.0.0.1:3001
curl -I https://kuma.bombaworkflows.com
docker ps --filter name=uptime-kuma

Результати були правильні для цієї схеми:

• локально контейнер відповідає з 302 Found
• публічний домен теж коректно віддає 302
• контейнер має стан healthy

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

Чому я перевів Uptime Kuma під docker compose

Спочатку сервіс працював нормально, але спосіб керування був занадто ручний. Після переходу на docker compose з'явилось те, чого дуже бракує домашнім VPS на ранніх етапах: передбачуваність.

Поточна схема стала такою:

• compose directory: /home/ubuntu/docker/uptime-kuma
• image: louislam/uptime-kuma:2.2.1
• bind: 127.0.0.1:3001
• volume: uptime-kuma

Перевірка після переведення виглядала так:

docker compose ps
docker inspect uptime-kuma --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}'
docker ps --filter name=uptime-kuma
curl -I http://127.0.0.1:3001
curl -I https://kuma.bombaworkflows.com

Саме цей набір команд уже дає дорослий operational confidence: зрозуміло, де лежить конфіг, що крутиться, який image використовується і чи сервіс реально доступний через nginx.

Чому цей крок важливіший, ніж здається

На папері "налаштував Telegram і кілька моніторів" звучить майже як косметика.

На практиці це означає:

• сервер не мовчить
• проблеми видно по шарах
• є окремий сигнал по мережі
• є окремий сигнал по TLS
• є гарантований канал сповіщення

Тобто інфраструктура переходить зі стану "дивлюсь руками, коли згадаю" у стан "отримую сигнал автоматично".

Висновок

Після цього етапу Uptime Kuma стала не просто ще одним контейнером на сервері, а реальною operational-підсистемою. Вона:

• бачить публічні сервіси
• бачить доступність самого VPS
• ловить ризики по SSL
• відправляє Telegram alerts
• працює в керованому docker compose-стеку

Для маленького навчального сервера це вже дуже сильний рівень. І саме з таких простих, але системних рішень потім і виростає справжня DevOps-практика.