Uptime Kuma — это монитор с открытым исходным кодом для самостоятельного размещения, поддерживающий проверки HTTP(S), TCP, ping, DNS, WebSocket и другие. На отдельном VPS он продолжает проверки, когда ваш продакшен-сервер падает, а не исчезает вместе с ним.
В этой инструкции Uptime Kuma v2 разворачивается на VPS с помощью Docker Compose, порт 3001 остаётся на локальном интерфейсе, HTTPS добавляется через Caddy, оповещения направляются в Telegram, Discord и Slack, а также публикуется страница статуса.
Требования и что вам понадобится
- VPS минимум с 1 vCPU, 1 ГБ ОЗУ и 10 ГБ локального SSD-хранилища
- Ubuntu 24.04 LTS или другой актуальный выпуск Ubuntu, поддерживаемый Docker
- Docker Engine и Docker Compose, установленные на VPS
- Домен или поддомен, направленный на VPS через A-запись (например, status.example.com)
- Доступ по SSH и базовые навыки работы в командной строке
Если Docker ещё не установлен, воспользуйтесь руководством Docker по установке на Ubuntu. Оно устанавливает Docker Engine и плагин Compose, который используется ниже.
Почему VPS для мониторинга должен быть отделён от того, что он проверяет
Продакшен и мониторинг на одном сервере находятся в одном домене отказа. Если этот сервер останавливается, исчезают и приложение, и система, которая должна отправить оповещение.
Улучшить ситуацию помогают две практичные схемы:
- Тот же провайдер, другая локация. Разместите продакшен и мониторинг на разных хостах в разных локациях. Это снижает риск отказа одного сервера или одного дата-центра, но не защищает от любых сетевых аварий или сбоев управляющего слоя на стороне провайдера.
- Совершенно другой провайдер. Размещение монитора у другого провайдера защищает и от аварий, затрагивающих провайдера целиком. Взамен появляется ещё один аккаунт, ещё один счёт и ещё одна операционная поверхность.
У одного экземпляра Uptime Kuma по-прежнему нет внешнего наблюдателя. Добавьте одну внешнюю HTTP(S)-проверку его публичной страницы статуса. Бесплатный тариф UptimeRobot сейчас включает 50 мониторов с интервалом в пять минут. Высокой доступности Uptime Kuma это не даст, но подскажет, когда исчезнет сам монитор.
То же правило действует и для публичных страниц статуса: то, что сообщает вам о сбое, не должно находиться в одном домене отказа с тем, что сбоит.
Разрабатывайте на Linux VPS с root-доступом, NVMe и мощью AMD EPYC.
Посмотреть тарифы LinuxПодбор размера VPS
У Uptime Kuma нет надёжной формулы «количество мониторов к объёму ОЗУ», потому что нагрузка зависит от типа монитора, интервала, настроек повторов и глубины хранения истории. Простые проверки HTTP(S), TCP, ping и DNS легче проверок Browser Engine, которые запускают Chromium.
Для небольшого набора базовых проверок начните с 1 vCPU, 1 ГБ ОЗУ и локального SSD. Следите за реальным потреблением с помощью docker stats uptime-kuma а рост базы данных — с помощью du -sh /opt/uptime-kuma/data. Добавляйте память, когда потребление стабильно высокое, когда контейнер сообщает об OOM kill или когда вы вводите проверки Browser Engine.
Полный образ v2 включает Chromium и встроенную MariaDB; документация по тегам Docker объясняет разницу между образами full и slim.
Разворачиваем Uptime Kuma с помощью Docker Compose
Сохраните этот файл как docker-compose.yml в /opt/uptime-kuma/:
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
ports:
# Bind to localhost only. The reverse proxy will expose it on 443.
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
Три строки заслуживают отдельного внимания:
- image: louislam/uptime-kuma:2 фиксирует мажорную версию. Тег :2 отслеживает стабильную ветку 2.x. Не используйте :latest.
- 127.0.0.1:3001:3001 привязывает контейнер только к localhost. Публичный интернет никогда не должен обращаться к порту 3001 напрямую. TLS-сертификат и публичное имя хоста держит обратный прокси.
- Том с данными хранит базу данных, конфигурацию мониторов и историю. Держите его на локальном хранилище, потому что документация по установке Uptime Kuma предупреждает, что файловые системы без надёжной POSIX-блокировки, включая многие конфигурации NFS, могут повредить SQLite. Остановите стек, прежде чем делать копию на уровне файловой системы.
Запустите и проверьте:
sudo install -d -o "$USER" -g "$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
# Paste the docker-compose.yml file above.
sudo docker compose up -d
sudo docker compose ps
Ожидаемый вывод docker compose ps:
NAME IMAGE STATUS PORTS
uptime-kuma louislam/uptime-kuma:2 Up (healthy) 127.0.0.1:3001->3001/tcp
Чтобы попасть в панель в первый раз, не открывайте порт 3001 в интернет даже ненадолго. Подключитесь через SSH-туннель:
ssh -L 3001:127.0.0.1:3001 [email protected]
Откройте http://localhost:3001 в браузере, создайте учётную запись администратора, задайте надёжный пароль и закройте туннель. Дальше панель будет доступна по HTTPS через обратный прокси.
Если возиться с Compose вручную не нужно, у нас также есть Uptime Kuma в виде приложения в один клик. На текущей странице приложения указана версия v1, поэтому она не совпадает с установкой v2 из этого руководства. Если вам нужна именно v2, используйте ручной путь через Compose.
Обратный прокси и TLS
Не выставляйте Uptime Kuma напрямую. Поставьте перед ним обратный прокси ради TLS, корректной обработки URL и единой публичной точки входа. Есть два пути.
Caddy. Если Caddy ещё не установлен, воспользуйтесь официальной инструкцией по пакетам для Ubuntu. Когда Caddy работает как системная служба, приведённый ниже Caddyfile проксирует запросы к Uptime Kuma на локальном интерфейсе и автоматически выпускает и продлевает сертификат.
Совет: если на VPS для мониторинга крутится только Uptime Kuma, берите Caddy. Caddyfile умещается в три строки, а выпуск и продление сертификата Caddy берёт на себя. Никакого Certbot и отдельного таймера обновления, за которым надо следить в 4 утра.
Сохраните это как /etc/caddy/Caddyfile:
status.example.com {
reverse_proxy 127.0.0.1:3001
}
Перезагрузите конфигурацию Caddy:
sudo systemctl reload caddy
Проверьте:
curl -I https://status.example.com
Вы должны получить успешный ответ 2xx или 3xx с действительным сертификатом. Если соединение не проходит, убедитесь, что A- или AAAA-запись домена указывает на этот VPS, что порты 80 и 443 доступны и что Caddy может занять оба порта. Всё это входит в требования Caddy к автоматическому HTTPS.
Nginx Proxy Manager. Если NPM работает прямо на хосте, добавьте Proxy Host для status.example.com, направьте его на 127.0.0.1, порт 3001, запросите сертификат Let's Encrypt и включите Websockets Support. Если NPM работает в Docker, 127.0.0.1 указывает на сам контейнер NPM. В этом случае подключите NPM и Uptime Kuma к одной сети Docker, а затем направьте proxy host на uptime-kuma, порт 3001.
Маршрутизация оповещений: Telegram, Discord, Slack
Uptime Kuma умеет отправлять одно и то же событие монитора в несколько каналов уведомлений. Настройте каждого провайдера один раз, а затем привяжите к монитору один или несколько каналов в зависимости от того, кому нужно оповещение.
Уведомления настраиваются глобально в разделе Settings > Notifications, а затем назначаются отдельным мониторам. Каждый монитор может отправлять в один или несколько каналов. Одно и то же оповещение может уйти в Telegram дежурному инженеру, в Slack команде и на почту для журнала аудита, и всё это из одного события.
Telegram
- В Telegram напишите @BotFather и выполните /newbot. Выберите имя и username. BotFather пришлёт токен бота. Сохраните его.
- Отправьте новому боту любое сообщение. Затем откройте в браузере https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates. Найдите поле chat.id — это и есть ваш chat ID.
- В Uptime Kuma: Settings > Notifications > Setup Notification > Telegram. Вставьте токен бота и chat ID. Нажмите Тест. Убедитесь, что бот отправляет тестовое оповещение.
- Если тестовое сообщение не приходит, проверьте правильность токена бота и chat ID и убедитесь, что файрвол VPS разрешает исходящие HTTPS-соединения к api.telegram.org.
Discord
- Откройте сервер Discord, куда должны приходить оповещения. Кликните правой кнопкой по нужному каналу, затем Edit Channel > Integrations > Webhooks > New Webhook. Дайте ему имя (например, «Uptime Kuma»), выберите канал и скопируйте URL вебхука.
- В Uptime Kuma: Settings > Notifications > Setup Notification > Discord. Вставьте URL вебхука. При желании задайте имя пользователя и аватар.
- Нажмите Тест. Убедитесь, что вебхук публикует тестовое оповещение в канале.
Slack
- В Slack создайте Incoming Webhook для канала, куда должны приходить оповещения. Slack вернёт URL вебхука вида https://hooks.slack.com/services/T.../B.../....
- В Uptime Kuma: Settings > Notifications > Setup Notification > Slack. Вставьте URL вебхука. При желании настройте иконку и переопределение канала.
- Нажмите Тест.
Когда все тесты проходят, отредактируйте каждый монитор и выберите каналы уведомлений, которые он должен использовать. Настройте Max Retries (максимум повторов) и Retry Interval (интервал между повторами) так, чтобы кратковременный сбой не вызывал оповещение сразу же.
Встроенная страница статуса (и когда её станет мало)
В Uptime Kuma есть публичные страницы статуса с произвольными слагами, группировкой мониторов, собственными доменами, публикациями об инцидентах и сообщениями о плановых работах. Из одного экземпляра можно опубликовать и несколько страниц статуса, для разных сервисов или аудиторий.
Главное её ограничение — коммуникация с клиентами. Посетители пока не могут подписаться на обновления по электронной почте прямо со страницы статуса, а сама публичная страница остаётся частью того же приложения Uptime Kuma, что и панель оператора. Самостоятельная подписка посетителей всё ещё числится как открытый запрос на новую функцию.
Если вам нужны подписки клиентов или система статуса, отделённая от панели мониторинга, одна из альтернатив — Kener. Наш материал о самостоятельно размещаемом стеке мониторинга объясняет, как эти два инструмента можно совмещать.
Частые проблемы
Уведомления молча не доходят, когда файрвол VPS блокирует исходящий HTTPS. Симптом: кнопка Test срабатывает для одних каналов и не срабатывает для других. Решение: убедитесь, что исходящие HTTPS-соединения разрешены и что curl -I https://api.telegram.org с VPS отрабатывает успешно.
Браузер показывает «ERR_TOO_MANY_REDIRECTS» после включения прокси. Поищите дублирующиеся редиректы с HTTP на HTTPS в Caddy, Nginx Proxy Manager или в вышестоящем CDN. Uptime Kuma должен и дальше отдавать HTTP на порту 3001, а TLS терминирует публичный обратный прокси. Если вы включаете доверенные заголовки прокси, текущий путь такой: Settings > Reverse Proxy > HTTP Headers > Trust Proxy.
Контейнер перезапускается каждые несколько минут. Проверьте, не был ли контейнер остановлен из-за нехватки памяти, а затем понаблюдайте за текущим потреблением через docker stats uptime-kuma. Если контейнер убил OOM или память держится у предела VPS, добавьте ОЗУ, уберите тяжёлые проверки или увеличьте их интервалы.
Страница статуса работает на localhost, но не через публичное имя хоста. Убедитесь, что обратный прокси передаёт корневой путь без изменений, сохраняет заголовок Host и поддерживает WebSockets. Uptime Kuma не поддерживает установку в подкаталог, поэтому используйте отдельный домен или поддомен, а не путь вида example.com/uptime-kuma.
Подведём итоги
Uptime Kuma на отдельном VPS даёт вам контроль над проверками, маршрутизацией оповещений и публичной страницей статуса, но вместе с этим на вас ложатся обновления, резервные копии, патчи ОС и внешний наблюдатель за самим монитором. Возьмите VPS в локации, отличной от продакшена, разверните v2 через Docker Compose или воспользуйтесь приложением в один клик, предварительно проверив указанную версию, поставьте впереди Caddy и подключите каналы, за которыми следит ваша команда.
Часто задаваемые вопросы
Сколько оперативной памяти нужно Uptime Kuma?
У Uptime Kuma нет надёжной формулы «мониторы к ОЗУ», потому что потребление зависит от типа монитора, интервала проверки, настроек повторов, глубины хранения истории и использования Browser Engine. Для небольшого набора базовых проверок начните с 1 ГБ ОЗУ и следите за реальным потреблением через docker stats uptime-kuma. Добавьте память, если потребление держится у предела или контейнер убивает OOM.
Стоит ли запускать Uptime Kuma на том же сервере, что и приложение?
Нет. Если инструмент мониторинга и приложение делят один сервер, его отказ выключает их одновременно, и вы теряете оповещения именно тогда, когда они нужнее всего. Запускайте Uptime Kuma на отдельном VPS, лучше в другом дата-центре.
Может ли Uptime Kuma отправлять оповещения в Telegram, Discord и Slack?
Да. Telegram, Discord и Slack входят во встроенные службы уведомлений наряду с электронной почтой, обычными вебхуками, PagerDuty, ntfy, Mattermost и многими другими. Telegram использует токен бота и chat ID, а Discord и Slack — URL вебхуков. К одному монитору можно привязать сразу несколько каналов уведомлений.
Чем Uptime Kuma отличается от UptimeRobot?
Uptime Kuma размещается у вас, поэтому сервер, обновления, резервные копии и маршрутизация оповещений — на вас. Он поддерживает интервалы проверок вплоть до 20 секунд. UptimeRobot — это хостируемый SaaS, и его текущий бесплатный тариф включает 50 мониторов с проверками раз в пять минут. Выбирайте Uptime Kuma, если хотите контроль, и UptimeRobot, если не хотите заниматься сервером мониторинга.
Есть ли у Uptime Kuma публичная страница статуса?
Да. Вы можете выбирать, какие мониторы видны, группировать их, публиковать несколько страниц статуса, привязывать к ним собственные домены и планировать сообщения о работах. Самостоятельной подписки посетителей по email нет, поэтому, если клиентам нужна подписка на обновления, используйте отдельный клиентский инструмент для страниц статуса.
