Uptime Kuma на сервере: частые ошибки и решения

MAATRIX

Uptime Kuma ставится одной командой — и ломают его тоже одинаково: панель бесконечно «переподключается», мониторы падают все разом в три часа ночи, сертификат просрочен только по мнению Kuma, а после docker compose down -v полугода истории нет. Почти все ошибки Uptime Kuma лежат в четырёх слоях: контейнер, база SQLite, сеть до цели и уведомления. Разбираем по текстам ошибок.

С чего начать: три команды и карта ошибок

Сначала выясните, на каком слое сломалось.

docker inspect uptime-kuma --format '{{.State.Status}} restarts={{.RestartCount}} oom={{.State.OOMKilled}}'
docker logs uptime-kuma --tail 100 --timestamps
docker stats --no-stream uptime-kuma

Вывод running restarts=37 oom=true — не «Kuma глючит», а нехватка памяти. Не поднялся вовсе — проверьте порт: ss -tlnp | grep :3001 и docker ps -a | grep kuma. И различайте, где ошибка: в логе контейнера — сломался сам Kuma, в карточке монитора — то, что он увидел по дороге к цели.

Контейнер, том и база: падения, потери и гигабайты истории

Убит по памяти. Node-процесс Kuma вхолостую занимает 150–220 МБ RSS, на сотне мониторов — 350–500 МБ, плюс Docker и система. На VPS с 512 МБ он попадёт под OOM-killer, причём молча: в панели останется «дырка». Проверка — dmesg -T | grep -i 'killed process': Out of memory: Killed process 1423 (node) total-vm:1180436kB.

Данные исчезли. Всё состояние Kuma — один файл /app/data/kuma.db. Две типовые потери: запуск без -v (база жила в слое контейнера и умерла с ним) и docker compose down -v, где флаг сносит тома, а не только контейнеры. Проверьте том: docker inspect -f '{{json .Mounts}}' uptime-kuma должен показать имя uptime-kuma и путь /app/data. Длинный хэш вместо имени — том анонимный, при пересоздании потеряете.

Тег образа. louislam/uptime-kuma:latest — плохая идея: ветка 2.x при первом старте меняет схему базы, и это односторонняя миграция, назад на 1.x с той же базой нельзя. Пиньте явно: :1 для стабильной 1.23.x, :2 — после бэкапа. Watchtower на latest однажды сделает переход за вас ночью.

SQLite не любит сеть. Том на NFS, CIFS или sshfs даёт SQLITE_BUSY: database is locked либо SQLITE_IOERR: disk I/O error: блокировки SQLite поверх сетевых ФС ненадёжны. Держите /app/data на локальном диске.

База пухнет. Один монитор с интервалом 60 секунд — 1440 записей heartbeat в сутки. Пятьдесят мониторов при хранении 180 дней дают около 13 млн строк: 1,5–3 ГБ и тормоза в интерфейсе. Лечится в Settings → Monitor History: хранение 30–90 дней и кнопка Shrink Database, которая выполняет VACUUM — ему нужно свободное место размером с саму базу.

Бэкап. Копировать живой файл SQLite через cp или tar — способ получить архив с битой базой. Снимайте копию средствами SQLite и забирайте через docker cp: docker exec uptime-kuma sqlite3 /app/data/kuma.db ".backup '/app/data/kuma-bak.db'". Нет sqlite3 — останавливайте контейнер на время архивации. Установка с нуля: Uptime Kuma на VPS по шагам.

Панель не открывается или бесконечно «Reconnecting…»

Страница не грузится совсем. Проверьте с самого сервера: curl -sI http://127.0.0.1:3001 | head -1 и docker port uptime-kuma. Ответ HTTP/1.1 302 Found значит, что Kuma жив и дело в доступе снаружи. Вывод 3001/tcp -> 127.0.0.1:3001 — контейнер слушает только петлю: заходите туннелем ssh -L 3001:127.0.0.1:3001 root@сервер. Молчит и петля — фаервол: ufw allow 3001/tcp.

Отдельная засада: правила ufw не действуют на порты, проброшенные Docker — он пишет свои цепочки в iptables в обход INPUT, и «закрытый» через ufw порт останется открыт миру. Закрытую панель пробрасывайте на 127.0.0.1 и публикуйте через Nginx с TLS.

Панель открылась, но висит Lost connection to the socket server. Reconnecting.... Самая частая ошибка Uptime Kuma за reverse-proxy: интерфейс целиком работает на WebSocket (socket.io), а обычный proxy_pass его не пропускает.

location / {
    proxy_pass http://127.0.0.1:3001;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
}

Без proxy_read_timeout соединение рвётся каждые 60 секунд, и тост вернётся раз в минуту. На Apache нужен a2enmod proxy_wstunnel и ProxyPass /socket.io/ ws://127.0.0.1:3001/socket.io/, за Cloudflare — включённый WebSockets.

Честное ограничение: Uptime Kuma не работает в подкаталоге — example.com/kuma/ не заведётся никакими правилами Nginx, выделяйте поддомен status.example.com.

Забыли пароль. Кнопки восстановления нет, почты тоже. Сброс — скриптом из образа: docker exec -it uptime-kuma node extra/reset-password.js. Потерян и второй фактор — снимайте в базе: sqlite3 /app/data/kuma.db "UPDATE user SET twofa_status = 0 WHERE id = 1;".

Ложные падения: таймауты, IPv6, ICMP и localhost из контейнера

Ложные срабатывания опаснее молчания: на них перестают реагировать и пропускают аварию.

Упали все мониторы разом. Если в 03:00 «легли» тридцать сервисов сразу, а утром всё зелёное — падал не интернет, а сам Kuma. Проверки выполняет один Node-процесс: сто мониторов с интервалом 20 секунд — пять HTTP-запросов в секунду плюс разбор ответов, и на слабом vCPU событийный цикл не успевает — проверки разом уходят в таймаут. Подтверждение: полка около 100% CPU в docker stats. Лечение — интервал 60 секунд для второстепенных мониторов и лишнее ядро.

timeout of 48000ms exceeded. 48 секунд — стандартный Request Timeout монитора, то есть цель реально не ответила. Уменьшать его «чтобы узнавать быстрее» не надо: получите ложные падения на тяжёлых страницах. Правильные ручки — Retries (по умолчанию 0, ставьте 2–3) и Heartbeat Retry Interval: при Retries = 2 падение объявляется после трёх неудач подряд. И проверяйте лёгкий /health, а не главную с половиной каталога.

connect ENETUNREACH 2a02:...:443. У домена есть AAAA-запись, а на сервере IPv6 не настроен. Node с 18-й версии идёт по адресам в порядке ответа DNS и первым пробует IPv6 — браузер сайт при этом открывает. Лечится переменной -e NODE_OPTIONS=--dns-result-order=ipv4first.

connect ECONNREFUSED 127.0.0.1:8080. В мониторе указан http://localhost:8080, но localhost изнутри контейнера — это сам контейнер. Используйте адрес хоста 172.17.0.1, имя сервиса в общей Docker-сети либо флаг --add-host=host.docker.internal:host-gateway.

Ping-монитор молчит. ping: socket: Operation not permitted — контейнеру не дали raw-сокеты: обычный Docker их выдаёт, rootless-режим и Podman нет. Помогает --cap-add=NET_RAW или --sysctl net.ipv4.ping_group_range="0 2147483647". Бывает и что ICMP режет провайдер цели — тогда берите TCP.

Сверить монитор с реальностью можно прямо с сервера: curl -o /dev/null -sS -w '%{http_code} %{time_total}\n' https://ваш-сайт/. Ответ 200 0.412 при красном мониторе значит, что врёт монитор.

Сертификат: монитор ругается, браузер молчит

Расхождение «в браузере зелёный замок, в Kuma ошибка TLS» объясняется одним фактом: браузер дотягивает недостающий промежуточный сертификат по ссылке AIA, Node.js — нет.

• unable to verify the first certificate — цель отдаёт листовой сертификат без промежуточного. В Nginx в ssl_certificate должен стоять fullchain.pem, а не cert.pem. Проверка: openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERT' — должно быть 2 и больше, единица значит обрезанную цепочку.
• Hostname/IP does not match certificate's altnames — мониторите по IP или по домену, которого нет в SAN.
• CERT_HAS_EXPIRED при живом сертификате — время на сервере. Своих часов у контейнера нет, он берёт их у ядра хоста, чинить надо хост: timedatectl set-ntp true. Ухода на пару дней хватает, чтобы просрочка «появилась» у всех целей.
• self-signed certificate in certificate chain — трафик разворачивает MITM-прокси, чужой корень.

Переключатель Ignore TLS/SSL error жалобу закроет, но выключит и пользу проверки: вы больше не узнаете, что сертификат протух. Оставляйте только для внутренних хостов с самоподписанными сертификатами. Предупреждения о скором истечении живут отдельно — Settings → Notifications, блок Certificate Expiry, по умолчанию за 7, 14 и 21 день.

Уведомления: тишина, дубли и шторм

Канал настроен, Test проходит, а реальные падения — мимо. Причин три.

Канал не привязан к монитору. Уведомление живёт отдельно от мониторов: в карточке каждого нужна галочка напротив канала. При создании канала есть чекбоксы Default enabled и Apply on all existing monitors — второй привязывает его ко всем разом. Без них канал молчит.

У контейнера не работает DNS. В логе будет Error: getaddrinfo EAI_AGAIN api.telegram.org. Проверка изнутри: docker exec uptime-kuma getent hosts api.telegram.org. Пусто — пропишите "dns": ["1.1.1.1", "8.8.8.8"] в /etc/docker/daemon.json и перезапустите Docker. Диагностика канала — в статье про алерты в Telegram.

Шторм повторов. Параметр Resend Notification if Down X times по умолчанию 0. Поставите 1 — при часовой аварии получите десятки одинаковых сообщений по каждому монитору. Для плановых работ есть Maintenance: окно обслуживания глушит выбранные мониторы вместо ручного отключения, которое потом забывают вернуть.

И структурное ограничение: Uptime Kuma не может сообщить о собственной смерти. Упал сервер с Kuma — не будет ни алерта, ни отметки в истории, наутро панель покажет ровный зелёный график. Отсюда два правила: не держите Kuma там, за чем он следит, и заведите внешнюю проверку — второй экземпляр в другой локации или монитор типа Push. Дежурств и эскалаций в Kuma нет; логика реагирования — в статье про алерт при падении сайта.

Какой сервер под Uptime Kuma брать в MAATRIX

Kuma почти не считает — он ждёт ответов по сети. Важны стабильность узла, независимость его сети от вашей и память под базу.

Минимум: 1 vCPU, 1 ГБ RAM, 20 ГБ NVMe. Тянет 20–30 мониторов с интервалом 60 секунд. Честное ограничение: 512 МБ — ловушка из раздела про OOM: экономия вернётся ночными провалами. 20 ГБ взяты не с потолка: место под растущую базу heartbeat и под VACUUM, которому нужен её дубль.

Комфортный вариант: 2 vCPU, 4 ГБ RAM, 40–60 ГБ NVMe. Сотня мониторов с интервалом 20–30 секунд, полугодовая история без тормозов, рядом Nginx с TLS и копии базы. Больше двухсот мониторов — наращивайте ядра, а не память.

Локация — Великобритания (Лондон). Мониторинг обязан стоять вне вашей инфраструктуры, иначе падает вместе с ней. Лондон — нейтральная точка с короткими маршрутами и в Европу, и в Россию: RTT Лондон — Москва обычно 40–60 мс, до европейских дата-центров единицы миллисекунд. Проверки идут магистралью, а не через тот же аплинк, что и ваш продакшен, поэтому увиденное Kuma падение будет настоящим. Мониторите американские сервисы — берите US-узел; нужна картина глазами пользователя из Москвы — ставьте пару UK + RU.

Uptime Kuma из каталога apps.maatrix.io разворачивается автоматически при заказе — вставлять команды не нужно. Автоустановка работает на Ubuntu и Debian, адрес панели и учётные данные появятся в личном кабинете, раздел «Доступ». Оплата — картами российских банков, по СБП, криптой или токеном MAAT. Это тоже часть надёжности: сторож не должен отключаться из-за не прошедшего платежа.

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