Моніторинг аптайму — рідкісна категорія, де self-hosting переміг начисто: Uptime Kuma дає перевірки HTTP(S), TCP, ping, DNS і keyword, попередження про закінчення сертифікатів, 90+ інтеграцій сповіщень і публічні статус-сторінки з одного контейнера, що простоює на ~256 MB. Помоніторна ціна SaaS-інструментів втрачає сенс у день, коли сервісів у вас більше жменьки. Інженерії залишаються розміщення, ліміти масштабу і що запускати поруч — про це гайд.
Правило нуль: моніторте ззовні
У монітора, що живе всередині інфраструктури, за якою стежить, сліпа пляма розміром із цю інфраструктуру. Якщо Kuma крутиться на тому ж сервері, що й застосунок, мертвий сервер = немає алерту — рівно той сценарій, заради якого моніторинг купувався. Логіка розміщення:
- Інша машина, інший дата-центр, в ідеалі інший провайдер, ніж те, що він перевіряє. VPS за $5–9 в іншому місті — вся ціна питання.
- Хто стежить за стежачим: найдешевша чесна відповідь — другий інстанс Kuma на іншій машині, кожен моніторить URL іншого. Два крихітні сервери, взаємне покриття, все ще дешевше за один SaaS-план.
- Реалізм затримок: перевіряйте звідти, де ваші користувачі. Франкфуртський монітор нічого не каже про досвід американських юзерів — наш мульти-міський сток існує рівно для такого розкиду.
Що Kuma робить добре — і її реальна стеля
Встановлення — справді одна команда (docker run), а набір функцій першого дня покриває потреби 90% команд: інтервали до 20 секунд, ретраї до алерту, вікна обслуговування, попередження про TLS, статус-сторінки на власному домені. Сповіщення дістають усе — від Telegram і Slack до голого SMTP та вебхуків.
Стеля архітектурна: SQLite плюс один Node-процес. На практиці UI та запити історії тупішають після приблизно 100–150 моніторів на коротких інтервалах, кластеризації немає. Чесні відповіді, коли вперлися:
- Діліть за призначенням: інстанс для проду, інстанс для внутрішнього/лаби — вам усе одно веліли запускати два.
- Розтягніть інтервали: більшості сервісів не потрібні 20-секундні перевірки; 60с половинить навантаження без практичної ціни.
- Переростайте свідомо: Gatus (config-as-code, бекенд Postgres) для сотень перевірок у YAML під CI, або повний Prometheus + Alertmanager, коли моніторинг стає роботою команди, а не контейнера.
Аптайм — половина картини: додайте метрики нод
Kuma відповідає «чи живе і як швидко відповідає» — вона не може відповісти «чому зламалося». Пов'язуйте її з шаром метрик на самих машинах:
- Netdata — встановлення однією командою, посекундна гранулярність, блискуче для ретро «що сталося о 03:14». Футпринт за замовчуванням важчий; на маленьких машинах ріжте retention.
- Prometheus node_exporter + Grafana — індустріальний стандарт, якщо ви вже говорите PromQL чи плануєте. Більше збірки, нескінченно композовано.
Комбінація — зовнішня Kuma для симптомів, метрики на машині для причин — ось що реально скорочує інциденти. Забитий диск і прострочений сертифікат, дві найбільш запобіжні причини аварій у малих парках, покриті обидві: Kuma попереджає про сертифікати, метрики нод — про диск.
Шукаєте сервер, який просто працює?
Valebyte VPS — NVMe, підтримка 24/7, розгортання за 60 секунд.
Шпаргалка за розмірами та розміщенням
| Сетап | Залізо | Нотатки |
|---|---|---|
| До ~50 моніторів | 1 vCPU / 1 GB VPS | Kuma + ОС вміщуються із запасом |
| 50–150 моніторів + статус-сторінки | 2 vCPU / 2–4 GB | стежте за латентністю SQLite, тягніть інтервали |
| Сотні перевірок, командні алерти | 4 GB+, дивіться Gatus/Prometheus | config-as-code тут окупається |
Ставте монітор в інший домен відмови, ніж моніторене: інший провайдер або щонайменше інше місто з того ж каталогу. Перевірено 8 липня 2026; лінійка Kuma 2.x зберігає ту саму архітектуру, тож рекомендації щодо SQLite чинні.
