Uptime Kuma: панель мониторинга за 5 минут

Когда серверов становится больше одного, а сервисов — больше трёх, ты перестаёшь успевать проверять их вручную. Я до последнего надеялся, что смогу держать в голове, какие сайты упали, а какие нет. Спойлер: не смог.

Uptime Kuma — это тулза, которая просто пингует твои сервисы и рисует зелёные или красные лампочки на дашборде. Ставится за три минуты через Docker.

Вот мой docker-compose.yml:

version: '3'
services:
  uptime-kuma:
    image: louislam/uptime-kuma
    container_name: uptime-kuma
    ports:
      - "3001:3001"
    volumes:
      - ./uptime-kuma-data:/app/data
    restart: unless-stopped

Запустил docker-compose up -d, открыл порт 3001, прошёл начальную настройку. Всё. Первый монитор добавил за 30 секунд: URL, интервал проверки 60 секунд, таймаут 10 секунд.

Kuma умеет проверять не только HTTP, но и ping, TCP-порты, и даже искать ключевое слово в ответе. Я, например, проверяю что WordPress жив — ищу строку «wp-json» в теле страницы.

Уведомления прикрутил через Telegram-бота. Теперь если сервер лёг — приходит сообщение с названием монитора и кодом ошибки. Весной у меня nginx упал в три ночи, Kuma дёрнул меня, я поднял за пять минут. Без него узнал бы утром, что полсайта недоступно половину ночи.

Сделал статус-страницу на status.mysurik.ru. Отдал ссылку паре клиентов, теперь они сами видят, всё ли работает, и не дёргают меня по пустякам.

Из практических моментов: на слабых VPS иногда бывают ложные срабатывания — сервис жив, но отвечает чуть дольше обычного, Kuma считает что всё пропало. Лечится увеличением таймаута до 10 секунд и включением Retries = 2. После этого ложных тревог почти не было.

Ещё удобная штука — группы мониторов. Я разбил всё на группы: Web, Database, Docker, System. Группа подсвечивается красным, если хотя бы один монитор в ней упал. Смотришь на дашборд и сразу видишь, где копать.

Метрики хранятся в SQLite, за месяц набралось около 50 МБ. uptime за месяц у меня держится на уровне 99.5–99.7%. Без Kuma я бы вообще не знал этих цифр.

В общем, штука полезная. Не требует выделенного сервера, не жрёт ресурсы, настраивается за пять минут. Из коробки — тёмная тема, куча иконок, поддержка многоязычности. Я жалею только что не поставил её раньше.

Расскажу подробнее, как я пришёл к Uptime Kuma и как он устроен изнутри. Потому что короткая версия не передаёт того, сколько сомнений и граблей стояло за этими «пятью минутами настройки».

Начну с того, почему я вообще задумался о мониторинге. У меня на сервере крутится не один сайт, а несколько сервисов: WordPress-блог, аналитика Plausible, очередь уведомлений, пара домашних штук, которые торчат наружу через reverse proxy. Когда их стало больше трёх, я поймал себя на том, что каждый день вручную открываю все адреса и проверяю, что они отвечают. Это отнимало минут десять-пятнадцать, и при этом я всё равно пропустил момент, когда один из сервисов лежал полдня из-за упавшего диска. Именно тогда я решил, что мониторинг — это не роскошь, а необходимость.

Почему именно Uptime Kuma, а не что-то другое. Вариантов было несколько: Uptime Robot, HetrixTools, мониторинг в панели хостинга, самописный cron-скрипт. Uptime Robot мне не подходил, потому что бесплатный тариф ограничен и я хочу, чтобы данные были у меня, а не у третьей стороны. Самописный скрипт я почти написал — но потом понял, что мне придётся самому пилить и уведомления, и статус-страницу, и историю аптайма. Это неделя работы ради того, что Kuma даёт из коробки за три минуты. Выбор был очевиден.

Теперь про сам Docker Compose поподробнее. Я не стал ограничиваться минимальным вариантом — добавил параметры, которые сильно облегчают жизнь. Во-первых, я вынес данные в именованный том или в папку рядом — важно, чтобы при пересоздании контейнера данные мониторов не пропадали. Во-вторых, я ограничил память контейнера через deploy.resources, чтобы Kuma не съел всё на слабом VPS. В-третьих, я поставил restart: unless-stopped, чтобы контейнер поднимался сам после перезагрузки сервера. Кто забывает про restart — тот потом ловит «всё было хорошо, пока сервер не перезагрузили».

Отдельная тема — это reverse proxy и HTTPS. Я не хочу открывать порт 3001 наружу напрямую, это некрасиво и небезопасно. Поэтому я завернул Kuma за свой nginx: создал поддомен status.mysurik.ru, выпустил сертификат Let’s Encrypt и проксировал запросы с 443 на внутренний 3001. Теперь статус-страница доступна по нормальному https-адресу, без цифровых портов в URL. Если ты не уверен в конфигурации nginx для проксирования — обязательно добавь headers для WebSocket, потому что Kuma использует вебсокеты для обновления дашборда в реальном времени.

Про уведомления стоит рассказать отдельно. Я упоминал Telegram, но там есть нюанс. Uptime Kuma поддерживает десятки каналов: Telegram, Email, Discord, Slack, Pushover, и так далее. Я настроил два канала сразу: Telegram — для себя, потому что я почти всегда в телефоне в мессенджере, и Email — для дублирования, на случай, если упадёт именно сеть или Telegram. Важный совет: не полагайся на один канал уведомлений. Если у тебя упал весь сервер, то и бот, который живёт на этом сервере, тоже не пошлёт сообщение. Поэтому второй канал должен быть внешним.

Теперь про типы мониторов — тут я немного глубже копнул. HTTP(S) — это самая базовая проверка, но есть и более интересные. Heartbeat — если у тебя есть скрипт или устройство, которое периодически должно что-то делать, Kuma может следить, что «сердцебиение» приходит вовремя. Я так слежу за своим бэкап-скриптом: он шлёт heartbeat раз в сутки, и если он не пришёл — значит, бэкап упал, и я узнаю об этом сразу, а не через неделю. Ping и TCP-проверки пригодятся для домашней лаборатории. Мне очень зашла проверка ключевого слова в ответе — это не просто «сайт отвечает», а «сайт отвечает правильно». Если WordPress выдал белую страницу смерти, но HTTP-код 200 — обычный монитор скажет «всё ок», а Kuma с проверкой на wp-json поймёт, что что-то не так.

Про статус-страницу ещё пара слов. Она нужна не только клиентам — я сам часто смотрю на неё с телефона, когда кто-то спрашивает «а у тебя всё работает?». Вместо того чтобы лезть в консоль, я открываю статус-страницу и вижу всё состояние сразу. Kuma позволяет настраивать оформление: свои цвета, логотип, описание. Моя страница на status.mysurik.ru выглядит аккуратно и минималистично. Тёмная тема — она же есть и на дашборде, и на публичной странице, — это плюс для тех, кто много работает вечером.

Про производительность и ресурсы. Kuma на моём VPS жрёт около 80–120 МБ памяти, что для всегда работающего мониторинга очень мало. SQLite-база растёт не так быстро, как кажется: я отключил хранение логов ответов для неважных мониторов (можно настроить retention), и теперь база стабильно держится в разумных пределах. Для сравнения — полноценный Grafana + Prometheus съест в десять раз больше ресурсов и требует настройки экспортеров. Если тебе не нужны сложные графики и алертинг на каждый чих — Uptime Kuma это идеальный баланс.

Про ложные срабатывания я уже упоминал вкратце, но добавлю важное. На дешёвых VPS часто бывает, что метрики или сборщик забирает CPU, и ответ сервиса задерживается. Если у тебя стоит жёсткий таймаут в 5 секунд, Kuma начнёт слать тревоги на пустом месте, и ты перестанешь им доверять. Мой рецепт: таймаут 10 секунд, две ретраи, и — что самое главное — период «тишины» после тревоги. Если сервис упал и поднялся за минуту, я не хочу получать семь сообщений. Период тишины в 10–15 минут решает эту проблему.

Ещё я узнал, что Kuma умеет делать резервное копирование своих настроек. Это не автоматическая функция, но в разделе настроек есть кнопка экспорта конфигурации. Я после настройки всех мониторов один раз выгрузил бэкап и храню его у себя. Если что-то случится с контейнером — восстановлю настройки за минуту, не вспоминая, какие мониторы и с какими интервалами были.

Про обновления. Проект развивается быстро, выходят новые версии с исправлениями. Обновление через Docker тривиально: docker compose pull && docker compose up -d. Я обновляю Kuma примерно раз в месяц, проблем ни разу не было. Единственное — перед обновлением делаю дамп SQLite-базы, на всякий случай.

И последнее про мой рабочий процесс. Сейчас у меня мониторинг выглядит так: каждый сервис проверяется раз в минуту, история аптайма хранится за 90 дней, на дашборде я вижу общую картину, при проблеме приходит уведомление в Telegram и на почту, а публичная статус-страница показывает клиентам, что всё в порядке. Я стал спокойнее: не надо держать в голове список сервисов и проверять их вручную. И, что немаловажно, цифры аптайма теперь у меня есть — 99.5–99.7% в среднем за месяц, и это подтверждено историей, а не ощущениями.

Если ты только начинаешь с мониторинга — начни именно с Uptime Kuma. Он прощает ошибки, ставится за пять минут, не требует отдельного сервера и даёт 90% пользы за 10% усилий. Когда вырастешь — перейдёшь на что-то серьёзнее, если вообще понадобится. Я пока остаюсь на Kuma и не жалею.

И пару слов о том, как Kuma вписался в мой общий стек. Раньше я следил за серверами вразнобой: что-то в панели хостинга, что-то вручную, что-то вообще никак. Теперь всё сведено в одну точку. Дашборд Kuma я держу открытым на втором мониторе — и это приятная замена десятку вкладок с разными панелями. Если у тебя, как у меня, сервисы разбросаны по нескольким машинам — Kuma спокойно мониторит их все с одной точки, ему необязательно жить на той же машине. Это сильно упрощает картину.

И ещё: не бойся экспериментировать с настройками. Я первое время боялся что-то поменять и сломать, а потом просто начал пробовать — и оказалось, что почти всё меняется на лету, без перезапуска. Kuma в этом смысле очень дружелюбен: можно потыкать, посмотреть, как реагируют мониторы, и ничего не откатить. Так и осваивается.