Uptime Kuma: мониторинг сайта и сервера — настройка

MAATRIX

Развернуть Uptime Kuma — пять минут, а настроить так, чтобы он ловил аварии и не будил на ровном месте, — отдельная работа. Разница между «мониторинг стоит» и «мониторинг работает» прячется в типах проверок, интервалах, retries и окнах обслуживания. Ниже — настройка мониторинга сайта и сервера по полям формы: что ставить и какие цифры считать.

Что Uptime Kuma проверяет, а что нет

Kuma смотрит на сервис снаружи и отвечает на вопрос «работает или нет». Метрик он не собирает: графика процессора и триггера «load average выше 5 пять минут подряд» здесь не будет — это Netdata или Prometheus с Grafana. Зато типов проверок два десятка, и половина настройки — выбрать правильный.

Про версии: 1.23.x — стабильная ветка, 2.x добавила SNMP, RabbitMQ, Manual и внешнюю базу MariaDB. Тег образа фиксируйте номером, а не latest; сама установка разобрана отдельно.

Монитор сайта: коды ответов, Keyword и Json Query

Простой HTTP-монитор проверяет только код ответа из поля Accepted Status Codes (по умолчанию 200-299). Этого мало: WordPress с упавшей базой отдаёт 200 и белую страницу, Nginx с заглушкой — 200 и «Идут работы». Берите тип HTTP(s) - Keyword.

Слово выбирайте из динамической части страницы: цену товара или название последней статьи. Текст шапки и футера бесполезен — заглушка и кэш его сохраняют. Когда слова нет, монитор пишет keyword ... not found и уходит в DOWN. Галка Invert Keyword переворачивает логику: падение объявляется, если слово *есть*, — так ловят «Ошибка соединения с базой данных».

Честное ограничение: Kuma ищет в сыром теле ответа, и если страница рисуется JavaScript, вашего слова в HTML не будет. Выхода два: проверять API-эндпоинт этой страницы либо тип Real Browser, который поднимает Chromium и съедает 400–700 МБ памяти на проверку.

Для API удобнее Json Query. Пусть /healthz отдаёт:

{"status":"ok","db":"up","queue":17,"version":"2.4.1"}

В поле Json Query пишете status, в Expected Value — ok. Jsonata умеет и условия: queue < 100 вернёт true, и монитор упадёт, когда очередь распухнет. Один запрос заменяет три — но /healthz обязан реально ходить в базу, а не отдавать заглушку.

Если бот-защита отвечает Request failed with status code 403, User-Agent подменяется в поле Headers, но правильнее внести IP мониторинга в allowlist WAF. Сообщения монитора читаются буквально:

Последняя строка стоит пояснения: браузеры достраивают неполную цепочку из кэша и молчат, а Kuma честно ругается — у части мобильных клиентов сайт не открывается. Соблазн поставить Ignore TLS/SSL error велик, но вместе с ошибкой вы выключите контроль срока: уведомление об истечении сертификата перестанет приходить.

Интервал, retries и таймаут: через сколько вы узнаете о падении

Скорость реакции определяют четыре поля: Heartbeat Interval (период проверок), Retries (сколько раз перепроверить перед вердиктом), Heartbeat Retry Interval (пауза между ними, по умолчанию 60 с) и Request Timeout (48 с — 80% минутного интервала). Худшее время до уведомления: интервал + Retries × Heartbeat Retry Interval.

Крайности одинаково плохи. Retries: 0 превращает любой сетевой чих в тревогу, и через неделю на них перестают смотреть. Retries: 5 при retry interval 60 с даёт пять минут, когда вы ничего не знаете. Два-три повтора — компромисс почти для всего. Таймаут держите меньше интервала: 48 секунд при интервале 30 — это очередь проверок, наезжающая сама на себя.

Resend Notification if Down X times consecutively отвечает за повторы: 0 — одно сообщение на аварию, 10 — напоминание раз в десять минут. Срок сертификата задаётся глобально: Settings → Notifications → Certificate Expiry, пороги 7, 14 и 21 день.

Мониторинг сервера: порты, DNS, Docker и push-мониторы

Сайт — половина задачи; за самим сервером Kuma следит иначе.

TCP Port подтверждает лишь то, что кто-то принял соединение: Postgres держит порт открытым и при too many connections. Берите тип PostgreSQL со строкой postgres://kuma:пароль@10.8.0.5:5432/postgres — он выполнит реальный запрос. Пользователя заведите без прав на данные и ходите по WireGuard: выставлять 5432 в интернет — плохая сделка.

Ping упирается в ICMP: его режут многие сети и почти все CDN, и монитор будет вечно красным. DNS ловит смену NS, угон домена и забытое продление; резолвер 1.1.1.1, тип записи A. Docker Container требует сокета /var/run/docker.sock, проброшенного в контейнер и заведённого в Settings → Docker Hosts, — а доступ к сокету равносилен root на хосте.

Push — единственный способ следить за тем, что внутри машины. Kuma даёт URL, который сервер дёргает по расписанию; не дёрнул — падение. Диск, память, результат бэкапа и живость cron ложатся сюда идеально.

#!/bin/bash
# /usr/local/bin/kuma-disk.sh
PUSH="https://kuma.example.com/api/push/mS7fK2pQx"
USED=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$USED" -lt 85 ]; then
  curl -fsS -m 10 --retry 2 "$PUSH?status=up&msg=disk-${USED}%25&ping=$USED" >/dev/null
else
  curl -fsS -m 10 --retry 2 "$PUSH?status=down&msg=disk-${USED}%25" >/dev/null
fi

Расписание кладём в /etc/cron.d/kuma: * * * * * root /usr/local/bin/kuma-disk.sh. Две детали, из-за которых curl прячут в скрипт, а не пишут прямо в crontab. Первая: cron трактует % как перевод строки, и незаэкранированный процент в URL молча ломает команду. Вторая: значение ping= Kuma рисует на графике — передав туда занятость диска, вы получаете график заполнения раздела.

Heartbeat Interval ставят с запасом: cron ходит раз в минуту — задайте 120 секунд, тогда пропущенный запуск не поднимет тревогу. Для суточного бэкапа curl дописывают в конец скрипта через && и ставят интервал 26 часов.

Группы, теги и окна обслуживания

На двадцатом мониторе список превращается в кашу, а первая авария сервера шлёт десять сообщений подряд.

Группы. Тип Group создаёт родителя для проверок одного проекта; группа падает, если упал любой вложенный монитор. Отсюда приём против шторма: уведомления вешаются только на группу, дочерние мониторы остаются немыми и служат для диагностики. Одно сообщение вместо десяти — но и подробностей меньше. Зависимостей, как в Zabbix, у Kuma нет: иначе алерты не подавить.

Теги (Settings → Tags) держите в двух-трёх измерениях: env:prod, client:acme — по ним фильтруется список и собираются статус-страницы. Привязка уведомлений: в диалоге создания канала есть две галки, экономящие полчаса кликов, — Default enabled (канал цепляется ко всем новым мониторам) и Apply on all existing monitors. Без них пара мониторов останется немой: ровно те, о которых вы вспомните в аварию.

Окна обслуживания. Раздел Maintenance, стратегия Cron Expression, выражение 0 3 * * *, длительность 30 минут — и ночной бэкап перестаёт быть аварией, а на статус-странице висит «Under maintenance». Ловушка в поле Timezone: по умолчанию там серверная зона, а контейнер почти всегда живёт в UTC, и окно откроется в 06:00 по Москве, когда работы уже закончились. Выберите Europe/Moscow в форме окна или стартуйте контейнер с -e TZ=Europe/Moscow; проверка — docker exec uptime-kuma date.

Домен, статус-страница и хранение истории

Панель на голом IP с портом 3001 — это пароль администратора, летящий открытым текстом. Заводите домен и TLS, но помните: Kuma общается с браузером по WebSocket, и без апгрейда соединения интерфейс покажет Lost connection to the socket server. Reconnecting...

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 86400;
}

Порт 3001 закрывается наружу — ufw allow 443/tcp, ufw deny 3001/tcp, а контейнер публикуется как -p 127.0.0.1:3001:3001. В профиле включите 2FA: Kuma умеет TOTP из коробки.

Статус-страница создаётся в Status Pages и живёт по адресу /status/<slug>. Ограничение: отдаёт её тот же сервер, что и мониторинг, — умрёт он, умрёт и она (разбор статус-страницы).

История. Settings → Monitor History, поле «Keep monitor history data for X days», по умолчанию 180. Объём считается заранее: 25 мониторов с интервалом 60 секунд дают 36 000 записей в сутки, за 180 дней — около 6,5 млн строк и 0,7–1 ГБ базы. Фактический размер: docker exec uptime-kuma ls -lh /app/data/kuma.db. Сократили срок — нажмите Shrink Database, иначе SQLite не отдаст место. Когда мониторов сотни, в ветке 2.x базу выносят наружу переменными UPTIME_KUMA_DB_TYPE=mariadb и UPTIME_KUMA_DB_HOSTNAME.

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

Kuma почти ничего не потребляет: в простое 120–200 МБ RSS, полсотни мониторов доводят его до 300 МБ, процессор загружен долями процента — сотня проверок с интервалом 60 секунд это меньше двух запросов в секунду. Замер у себя: docker stats --no-stream uptime-kuma.

Честно про нижнюю границу: гигабайта хватает ровно до мониторов Real Browser. Каждая такая проверка поднимает Chromium на 400–700 МБ, и OOM-killer гасит не браузер, а процесс Kuma — мониторинг умирает молча и именно тогда, когда нужен. Нужны такие проверки — планка 4 ГБ.

Правило важнее любых гигабайт: Uptime Kuma не должен стоять на сервере, за которым следит. Упадёт машина — вместе с сайтом пропадёт и сторож, уведомление не уйдёт. Отдельный дешёвый VPS в другой сети закрывает вопрос.

Локация — Великобритания, Лондон. Внешняя точка наблюдения: 8–15 мс до крупных европейских узлов, 40–55 мс до Москвы, около 75 мс до Нью-Йорка — трасса короткая и стабильная, ложных таймаутов из-за маршрута почти не бывает. Франция даёт ту же картину для ЕС; RU нужна, если важно видеть сайт глазами клиента из России; US — если под наблюдением зарубежные API и ИИ-сервисы.

Uptime Kuma есть в каталоге apps.maatrix.io — при заказе сервера он разворачивается автоматически, вставлять команды руками не нужно. Автоустановка работает на Ubuntu и Debian, берите Ubuntu 24.04 LTS; доступы появятся в личном кабинете, в разделе «Доступ». Первые три действия после входа: включить 2FA, привязать домен с TLS, создать канал уведомлений с галкой Default enabled. Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна даже для лондонской площадки. Начать можно с минимального тарифа — память добавляется позже без переезда.

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