Мониторинг аптайма — редкая категория, где 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 в силе.
