Uptime Kuma: мониторинг своих сервисов и интернета провайдера

Uptime Kuma — это свой «пульт дежурного» для сайтов и сервисов: программа сама проверяет, отвечают ли они, и пишет вам, когда что-то упало. Ставится у себя (VPS, NAS, Home Assistant, Proxmox), без чужого SaaS-кабинета. Ниже — зачем он нужен, как мониторить не только сайт, но и интернет-провайдера при резерве LTE или втором канале, куда слать уведомления и как поставить Kuma на разные системы, включая пошаговую установку на VPS.

Что такое Uptime Kuma

Uptime Kuma — открытый self-hosted монитор доступности. В веб-интерфейсе вы добавляете проверки (мониторы), задаёте интервал и смотрите статус «вверх / вниз», график пинга и историю сбоев. Есть публичные status page для себя или клиентов. Проект: github.com/louislam/uptime-kuma, демо: demo.kuma.pet.

По смыслу это домашний аналог идей вроде UptimeRobot или Pingdom, только данные и правила живут на вашем сервере. Для владельца VPS и self-host стека это удобно рядом с Nextcloud, Vaultwarden, сайтом и умным домом: один экран показывает, что из важного ещё живо.

Что умеет проверять

• HTTP(S) — сайт или API отвечает кодом 200 (или другим ожидаемым).
• Keyword / JSON Query — в ответе есть нужная строка или поле.
• TCP — открыт порт (SSH 22, SMTP 25/465, база, игровой сервер).
• Ping (ICMP) — хост отвечает на ping.
• DNS — запись резолвится как ожидаете.
• Docker — контейнер на том же хосте в нужном состоянии (если Kuma видит Docker socket).
• Push — внешний скрипт сам «отмечается» по URL (удобно для задач, у которых нет входящего порта).
• WebSocket, Steam и др. — узкие сценарии из коробки.

Интервал проверок настраивается; для важных узлов часто ставят 60 секунд, для второстепенных — 5 минут. Слишком частый ping внешнего API чужого сервиса без нужды не делайте — это лишний шум и нагрузка.

Зачем ставить свой монитор

• Узнать о падении сайта или VPN раньше, чем напишут пользователи.
• Отличить «пропал один сервис» от «нет интернета дома».
• Собрать историю простоев без чужой подписки.
• Показать status page семье или команде без доступа в админку.

Если уже думаете про копии данных — монитор не заменяет резервное копирование VPS, но помогает раньше заметить, что пора восстанавливаться.

Мониторинг провайдера и резервного интернета (LTE / второй канал)

У многих дома роутер умеет failover: основной канал (оптика/Ethernet) и запасной (USB LTE-модем, второй провайдер по кабелю, иногда Starlink). Пока запасной канал поднимает выход в сеть, браузер «как будто работает», а вы можете не заметить, что основной провайдер уже лежит часами — пока не кончится лимит LTE или не просядет скорость.

Uptime Kuma здесь полезен, но важно понимать откуда идёт проверка.

Kuma дома, в локальной сети

Если Kuma крутится на NAS / мини-ПК / Home Assistant за роутером и пингует 1.1.1.1 или 8.8.8.8, он отвечает на вопрос: «есть ли сейчас какой-нибудь выход в интернет». При успешном failover на LTE монитор останется зелёным — это не баг, так устроен резерв. Чтобы ловить именно отказ основного канала:

• Добавьте ping/TCP до шлюза основного WAN (IP шлюза провайдера в карточке WAN1) — отдельно от шлюза LTE.
• Если роутер отдаёт метрики (SNMP, API MikroTik/OpenWrt) — можно смотреть статус интерфейса WAN1 через промежуточный экспортёр; в самой Kuma проще начать со шлюзов и внешних IP.
• Проверяйте «свой» внешний IPv4 основного канала (если он статический или через DDNS, привязанный именно к WAN1). После переключения на LTE этот адрес с домашней сети часто уже не пингуется «как раньше» — зависит от схемы роутера.

Kuma на VPS снаружи

Второй полезный контур: экземпляр Kuma на VPS пингует домашний DDNS / белый IP / VPN-endpoint. Тогда вы видите: «дом достучаться из интернета нельзя». Это хорошо ловит полный отвал обоих каналов или поломку проброса портов/WireGuard, но не всегда отличает «упал только основной ISP» от «упал роутер целиком».

Практичная схема «два глаза»

• Дома: мониторы шлюза WAN1, шлюза WAN2/LTE, плюс один внешний ping (интернет вообще есть).
• На VPS: монитор домашнего VPN/DDNS и важных снаружи сервисов (сайт, почта).
• Уведомления с домашнего Kuma — в Telegram; с VPS — туда же или в другой чат «инфра», чтобы не смешивать.

Нюанс: если интернет дома умер полностью, домашняя Kuma может не успеть отправить алерт наружу. Поэтому критичные проверки «сайт / VPN снаружи» лучше дублировать на VPS. Обратное тоже верно: VPS не увидит, что вы уже час сидите на медленном LTE, пока DDNS отвечает.

Куда слать уведомления о сбоях

В настройках Uptime Kuma → Notifications можно добавить один или несколько каналов и привязать их к мониторам. Нативно поддерживаются десятки провайдеров; дополнительно есть Apprise — мост ещё к большому числу служб. Актуальный список — в wiki Notification Methods и в каталоге провайдеров репозитория.

Чаще всего на практике:

• Telegram — бот и chat_id (личный чат или группа).
• Discord / Slack / Google Chat — webhook для команды.
• E-mail (SMTP) — на свой или рабочий ящик.
• Gotify / ntfy — свои push-уведомления на телефон без Google-зависимости.
• Webhook — свой скрипт, Home Assistant, n8n.
• Home Assistant — отдельный провайдер в списке уведомлений Kuma; либо официальная интеграция HA «Uptime Kuma» по API-ключу (с HA 2025.8).
• Apprise — если нужен экзотический канал «в один клик».

Имеет смысл включить два независимых канала (например Telegram + SMTP): если мессенджер молчит, письмо всё равно может дойти. Для «шумных» мониторов настройте задержку/подтверждение сбоя (несколько неудачных проверок подряд), чтобы краткий глюк DNS не разбудил вас среди ночи.

Куда ставится Uptime Kuma

Официально авторы продвигают Docker и установку через Node.js + pm2 на Linux/Windows. Остальное ниже — готовые обёртки сообщества: их удобно брать, но обновления и поддержка зависят от мейнтейнеров аддона/скрипта. Перед установкой смотрите актуальные ссылки в wiki How to Install.

Docker (универсальный путь)

Образ louislam/uptime-kuma:2, порт 3001, том с данными на /app/data. Том должен быть на локальном диске: NFS для data авторы не рекомендуют (риск порчи SQLite).

Home Assistant

У меня Uptime Kuma установлен в Home Assistant — community add-on из репозитория hassio-addons/app-uptime-kuma (раньше addon-uptime-kuma). Добавляете репозиторий hassio-addons в Add-on Store, ставите Uptime Kuma, запускаете и открываете UI с страницы аддона. Так Kuma живёт рядом с автоматизациями на том же мини-ПК/NUC, без отдельного Docker-хоста.

В уведомлениях монитора удобно сразу включить канал HA (Home Assistant) — тогда алерты уходят в вашу умную дом-систему. Минус схемы «Kuma только внутри HA»: если упадёт сам HAOS, вместе с ним может пропасть и монитор. Для «сторожа над HA» лучше держать второй экземпляр на VPS или NAS. Дополнительно в Home Assistant есть официальная интеграция Uptime Kuma: API-ключ из Kuma → сущности мониторов в HA.

Proxmox

В Proxmox VE Helper-Scripts есть готовый LXC-скрипт uptimekuma.sh. На узле Proxmox:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/uptimekuma.sh)"

Скрипт поднимет контейнер с приложением (по умолчанию скромные CPU/RAM). Обновление у helper-скриптов обычно той же командой с -s update — смотрите подсказку в выводе скрипта. Альтернатива: обычный Docker в LXC/VM, как на VPS. База по Proxmox у нас — в материалах про HAOS в Proxmox и другие LXC.

Synology

Готовый пакет Uptime Kuma ставится из Центра пакетов, если подключён репозиторий SynoCommunity. Как добавить источник и пользоваться пакетами без Docker — в статье Synology без Docker: SynoCommunity.

Альтернатива — Container Manager (Docker): проект с образом louislam/uptime-kuma:2, папка данных на volume, порт 3001. Пошаговые неофициальные гайды есть у сообщества (в wiki указан, например, mariushosting). Если публикуете через Reverse Proxy DSM — включите поддержку WebSocket (Kuma без Upgrade/Connection за прокси живёт плохо).

Другие варианты

• Node.js + pm2 без Docker — на Debian/Ubuntu/Windows по wiki.
• Kubernetes Helm, one-click у PaaS — неофициально, на свой риск.
• Пакет для Debian (сообщество) — см. wiki.

Установка Uptime Kuma на VPS (Docker Compose)

Ниже — рабочий минимум на Ubuntu/Debian VPS с Docker. Перед этим имеет смысл базовая гигиена сервера из памятки по безопасности VPS: обновления, SSH-ключи, firewall.

1. Docker и Compose

Если Docker ещё нет — ставьте официальный Docker Engine из репозитория Docker (не пакет docker.io из Ubuntu, если хотите актуальный Engine и Compose plugin). Ниже — шаги из docs.docker.com/engine/install/ubuntu для Ubuntu 22.04 / 24.04. Для Debian те же команды, но URL репозитория linux/debian — см. установку на Debian.

1. Удалите конфликтующие пакеты (если apt напишет, что их нет — это нормально):

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc 2>/dev/null | cut -f1)

2. Добавьте GPG-ключ и apt-репозиторий Docker:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

На Debian замените в командах linux/ubuntu на linux/debian и в Suites используйте $(. /etc/os-release && echo "$VERSION_CODENAME") — как в официальной инструкции.

3. Установите Engine, CLI, containerd и плагины Buildx + Compose v2:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

4. Проверьте, что демон запущен и Compose отвечает:

sudo systemctl status docker
sudo docker run --rm hello-world
sudo docker compose version

Команда hello-world должна скачать тестовый образ и вывести подтверждение. Дальше все команды ниже можно выполнять с sudo (или добавьте пользователя в группу docker по post-install и перелогиньтесь).

Альтернатива для быстрой проверки (не для продакшена): скрипт get.docker.com — Docker сам его не рекомендует на боевых серверах.

2. Каталог и compose-файл

sudo mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma
sudo tee compose.yaml >/dev/null <<'EOF'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data
    environment:
      - TZ=Europe/Moscow
EOF
sudo mkdir -p data
sudo docker compose up -d

Либо скачайте эталонный compose с GitHub:

curl -fsSL -o compose.yaml https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml
sudo docker compose up -d

3. Первый вход

Откройте http://ВАШ_IP:3001, создайте учётную запись администратора. Сразу добавьте монитор на свой сайт (HTTP) и, например, ping 1.1.1.1 для контроля «сети с точки зрения VPS».

4. Firewall

Порт 3001 лучше не светить всему интернету. Варианты:

• закрыть 3001 снаружи и ходить через VPN / SSH-туннель;
• поставить reverse proxy (Caddy/nginx) с HTTPS и паролем/SSO, не забыв заголовки WebSocket;
• ограничить ufw allow from ВАШ_IP to any port 3001.

5. Уведомления Telegram (кратко)

1. Создайте бота у @BotFather, скопируйте токен.
2. Напишите боту / добавьте в группу; узнайте chat_id (через @userinfobot или API getUpdates).
3. В Kuma: Settings → Notifications → Setup Notification → Telegram — вставьте токен и chat_id, Test.
4. В мониторе включите эту нотификацию.

6. Обновление

cd /opt/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

Перед крупным обновлением скопируйте каталог data — там SQLite и настройки. Официальные нюансы миграций — в wiki How to Update.

С чего начать список мониторов

• Сайт и /wp-login.php или health URL — HTTP 200.
• TCP 443 / 80 на VPS.
• VPN endpoint (WireGuard/скрытый порт) — TCP или ping.
• Домашний DDNS с VPS-инстанса Kuma.
• Шлюзы WAN1/WAN2 с домашнего инстанса.
• Свой Gotify/ntfy/Matrix — чтобы знать, что «канал алертов» тоже жив (осторожно с петлями уведомлений).

Частые вопросы

Хватит ли одного Uptime Kuma дома?

Для локальных сервисов и контроля WAN — да. Для «сайт снаружи недоступен» нужен взгляд с VPS или облака: домашний монитор при полном отвале канала может не отправить алерт.

Почему зелёный статус при переходе на LTE?

Потому что проверка внешнего ping идёт уже через запасной канал. Добавьте отдельные мониторы шлюза основного провайдера или смотрите метрики роутера.

Нужен ли белый IP для Kuma?

Нет. Kuma сама ходит исходящими проверками. Белый IP нужен только если вы хотите открыть UI или status page из интернета без VPN — и тогда лучше HTTPS и ограничение доступа.

Чем Kuma не является?

Это не полноценный APM и не замена Prometheus+Grafana для метрик железа (хотя экспорт в Prometheus у Kuma есть). Для «жив ли URL/порт» её обычно достаточно.

Итого: поставьте Uptime Kuma там, где он переживёт типичный сбой (часто — VPS + по желанию второй экземпляр дома), настройте Telegram или ещё один канал, отдельно следите за шлюзом основного провайдера при наличии LTE-резерва — и коротких «тихих» простоев станет заметно меньше.