Как настроить мониторинг сайтов и API через Uptime Kuma на VPS 

Uptime Kuma — это self-hosted система мониторинга, которую можно развернуть на собственном VPS и использовать для проверки сайтов, API и сетевых сервисов. Она поддерживает HTTP(S), TCP, keyword-проверки, публичные status page и разные способы доставки уведомлений.

В этом руководстве установим Uptime Kuma через Docker, подключим домен и HTTPS, а затем настроим несколько типов мониторинга: обычную HTTP-проверку сайта, проверку доступности TCP-порта и keyword-мониторинг содержимого страницы. Дополнительно создадим публичную страницу статуса и подключим уведомления через универсальный webhook.

В результате получим систему, которая позволит:

• Контролировать доступность сайтов и API;
• Отслеживать время ответа сервисов;
• Проверять открытие TCP-портов;
• Следить за наличием нужного текста на странице;
• Публиковать статусы сервисов на отдельной status page;
• Получать уведомления при сбоях.

В конце отдельно имитируем недоступность одного из сервисов, убедимся, что монитор переходит в состояние Down, и проверим получение реального оповещения. Сам интерфейс Uptime Kuma будет доступен через домен по HTTPS, а прямой доступ к внутреннему порту приложения оставим закрытым.

Как работает мониторинг через Uptime Kuma

Uptime Kuma — это self-hosted система мониторинга, которая работает на собственном сервере и регулярно проверяет доступность внешних сайтов, API и сетевых сервисов.

В отличие от систем вроде Prometheus, которые собирают множество внутренних метрик, Uptime Kuma ориентирован прежде всего на проверку доступности: отвечает ли сайт, открыт ли TCP-порт, содержит ли страница нужный текст и сколько времени занимает ответ.

Это делает его удобным инструментом для простого uptime-мониторинга небольших проектов, API, внутренних сервисов и публичных сайтов.

Что умеет Uptime Kuma

Uptime Kuma поддерживает несколько типов проверок и позволяет настроить отдельные правила для разных сервисов.

С его помощью можно:

• Проверять сайты по HTTP и HTTPS;
• Контролировать доступность API;
• Отслеживать открытые TCP-порты;
• Проверять наличие определенного текста на странице;
• Выполнять DNS- и ping-проверки;
• Отслеживать срок действия TLS-сертификатов;
• Создавать публичные страницы статуса;
• Отправлять уведомления через webhook, email и другие интеграции.

Для каждого монитора можно задать собственный интервал проверки, таймаут, количество повторных попыток и способ уведомления.

Uptime Kuma также сохраняет историю доступности и времени ответа, поэтому в интерфейсе можно увидеть не только текущее состояние сервиса, но и его поведение за предыдущие часы и дни.

Какие типы проверок будем использовать

В рамках руководства настроим три типа мониторинга.

Первый — обычная HTTP(S)-проверка: https://example.com

Uptime Kuma будет регулярно отправлять запрос и считать сервис доступным, если сервер возвращает успешный ответ.

Второй вариант — TCP-проверка. Она позволяет убедиться, что конкретный порт на сервере принимает соединения.

Например:

Host: example.com

Port: 443

Такая проверка полезна, если нужно контролировать не веб-страницу, а доступность конкретного сетевого сервиса.

Третий вариант — keyword-мониторинг. В этом случае Uptime Kuma не просто проверяет HTTP-ответ, но и ищет заданный текст в содержимом страницы.

Например: Keyword: Application is running

Если страница продолжает отвечать, но нужная строка исчезает, монитор может перейти в состояние Down. Это помогает выявлять ситуации, когда веб-сервер формально работает, но приложение уже возвращает неправильную страницу или ошибочный контент.

Как будет устроена схема мониторинга

Uptime Kuma будет работать в Docker-контейнере на отдельном VPS.

Упрощенная схема:

Сам Uptime Kuma внутри VPS будет слушать порт 3001.

Для внешнего доступа к панели настроим Nginx:

В итоговой конфигурации прямой публичный доступ к 3001 использовать не будем. Пользователь будет открывать интерфейс только через домен и HTTPS.

Подготовка VPS

Перед установкой Uptime Kuma подготовим систему и установим Docker. В примере используется Ubuntu.

Обновление системы

Сначала обновим индекс пакетов: sudo apt update

Установим доступные обновления: sudo apt upgrade -y

После этого можно проверить версию системы: lsb_release -a

И доступные ресурсы:

free -h

df -h

Для небольшого количества мониторов Uptime Kuma не требует значительных ресурсов, поэтому отдельного мощного VPS обычно не требуется.

Основные данные приложения будут храниться в Docker volume, поэтому при обновлении или пересоздании контейнера конфигурация и история мониторинга сохранятся.

Установка Docker и Docker Compose

Установим Docker из стандартного репозитория Ubuntu: sudo apt install -y docker.io docker-compose-v2

Запустим Docker и включим автоматический запуск: sudo systemctl enable --now docker

Проверим состояние: sudo systemctl status docker --no-pager

Проверим версии:

docker --version

docker compose version

После этого VPS готов к запуску Uptime Kuma через Docker Compose.

Какие порты понадобятся Uptime Kuma

В процессе настройки будем использовать следующие порты:

Порт 3001 понадобится самому приложению, но в итоговой конфигурации он не должен быть доступен напрямую из интернета.

Снаружи пользователи будут подключаться только к:

а Nginx будет передавать запросы локальному контейнеру.

Почему порт Uptime Kuma не стоит оставлять общедоступным

Uptime Kuma содержит административный интерфейс, список контролируемых сервисов, историю сбоев и настройки уведомлений.

Поэтому оставлять порт 3001 открытым для всего интернета без дополнительного reverse proxy не стоит.

Кроме того, публикация внутреннего порта приложения напрямую усложняет дальнейшую работу с HTTPS и доменом.

Лучше использовать схему: Internet → Nginx :443 → Uptime Kuma :3001

При этом Nginx принимает внешние HTTPS-запросы, а сам контейнер слушает только localhost. Идеальная архитектура - это если сервис вовсе доступен только с внешних адресов администраторов или через туннель, но мы остановимся на упрощённом варианте.

Такой подход уменьшает количество напрямую доступных сервисов и позволяет централизованно управлять TLS-сертификатом.

Теперь развернем сам Uptime Kuma.

Установка Uptime Kuma через Docker

Создание каталога приложения

Создадим отдельный каталог: sudo mkdir -p /opt/uptime-kuma

Перейдем в него: cd /opt/uptime-kuma

Docker Compose-файл и данные приложения будут храниться отдельно от остальных сервисов VPS.

Создание Docker Compose-конфигурации

Создадим файл: sudo nano docker-compose.yml

Добавим конфигурацию:

services:

  uptime-kuma:

    image: louislam/uptime-kuma:1

    container_name: uptime-kuma

    restart: unless-stopped

    ports:

      - "127.0.0.1:3001:3001"

    volumes:

      - uptime-kuma-data:/app/data

volumes:

  uptime-kuma-data:

Здесь важно обратить внимание на строку: 127.0.0.1:3001:3001

Она публикует порт контейнера только на loopback-интерфейсе VPS.

Это означает, что открыть http://PUBLIC_IP:3001 из интернета не получится, но Nginx сможет обращаться к http://127.0.0.1:3001 локально.

Volume:

uptime-kuma-data

будет хранить базу данных, настройки, список мониторов и историю Uptime Kuma независимо от жизненного цикла контейнера.

Запуск контейнера Uptime Kuma

Запустим приложение: sudo docker compose up -d

Docker скачает образ и создаст контейнер.

Проверим список контейнеров: sudo docker ps

В выводе должен появиться uptime-kuma со статусом Up.

При необходимости можно посмотреть логи: sudo docker logs uptime-kuma --tail 50

Проверка состояния контейнера

Проверим контейнер более компактно: sudo docker ps --filter name=uptime-kuma

Ожидаемый результат:

CONTAINER ID   IMAGE                      STATUS

...            louislam/uptime-kuma:1     Up ...

Теперь убедимся, что приложение отвечает локально: curl -I http://127.0.0.1:3001

Проверить локальный bind можно командой: sudo ss -lntp | grep 3001

В выводе должен быть адрес: 127.0.0.1:3001

Это подтверждает, что Uptime Kuma работает в контейнере и уже доступен локально, но его внутренний порт не опубликован напрямую в интернет.

Первоначальная настройка Uptime Kuma

После запуска контейнера можно перейти к первоначальной настройке веб-интерфейса. На этом этапе создадим учетную запись администратора, познакомимся с панелью и зададим базовые параметры, которые понадобятся для дальнейшего мониторинга.

Создание учетной записи администратора

Так как Uptime Kuma пока доступен только локально на 127.0.0.1:3001, для первоначального входа можно временно использовать SSH-туннель или сначала настроить Nginx. В рамках практики удобнее открыть доступ через локальный туннель, а домен и HTTPS подключить позже.

На локальном компьютере выполните: ssh -L 3001:127.0.0.1:3001 -i "C:\Ваш путь к ключу\Название ключа.pem" ubuntu@Ваш_IP

После установления соединения откройте в браузере: http://127.0.0.1:3001

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

Укажите:

Username: admin

Password: надежный пароль

Пароль лучше использовать отличный от SSH, панели облака или других сервисов.

После создания учетной записи откроется основная панель Uptime Kuma.

Обзор панели мониторинга

Главная страница содержит список мониторов и их текущий статус.

Пока список пуст, так как ни одной проверки еще не создано. В дальнейшем здесь будут отображаться состояния:

Up

Down

Pending

Maintenance

Для каждого монитора Uptime Kuma также показывает время ответа, историю событий и процент доступности.

Основные элементы интерфейса:

• Dashboard — список всех мониторов;
• Add New Monitor — создание новой проверки;
• Status Pages — публичные страницы состояния;
• Settings — уведомления и глобальные параметры;
• Maintenance — окна технических работ.

После создания нескольких проверок Dashboard станет основной рабочей страницей для контроля сервисов.

Настройка основных параметров

Перед созданием мониторов можно открыть Settings и проверить базовые параметры.

В первую очередь имеет смысл настроить:

• Часовой пояс;
• Язык интерфейса;
• Формат даты и времени;
• Параметры уведомлений;
• Внешний URL, если он используется в сообщениях.

Если VPS работает в одном часовом поясе, а администратор находится в другом, правильный timezone особенно важен для журналов событий и времени срабатывания уведомлений.

Остальные параметры можно оставить по умолчанию и вернуться к ним после настройки мониторов.

Создание HTTP-проверки сайта

Первым создадим обычный HTTP(S)-монитор. Он будет регулярно отправлять запрос на сайт и контролировать его доступность.

Добавление HTTP(S)-монитора

В Dashboard нажмите: Add New Monitor

В поле Monitor Type выберите: HTTP(s)

Задайте понятное имя, например: Main Website

В поле URL укажите адрес сайта: https://example.com

Uptime Kuma будет выполнять HTTP-запрос и оценивать полученный ответ.

Для обычного сайта можно оставить стандартный метод: GET

Если URL отвечает корректно, после сохранения монитор перейдет в состояние Up.

Настройка интервала и таймаута проверки

Для каждого монитора можно задать собственную частоту проверок.

Например: Heartbeat Interval: 60 seconds

Это означает, что Uptime Kuma будет проверять сайт раз в минуту.

Для тестовой среды можно выбрать более короткий интервал, например: 20 seconds

Это удобно при проверке сбоев, так как не приходится долго ждать смены статуса.

Также можно настроить:

Retries

Timeout

Accepted Status Codes

Например, если сервис считается рабочим только при ответе 200, можно ограничить допустимые коды.

В большинстве обычных сценариев достаточно оставить диапазон успешных HTTP-кодов по умолчанию.

Проверка доступности сайта и времени ответа

После сохранения монитор появится на Dashboard.

Через несколько секунд Uptime Kuma выполнит первый запрос и покажет: Up

Также появится время ответа, например: Response: 120 ms

Чем дольше работает монитор, тем больше данных будет доступно в истории.

Откройте карточку монитора. В ней можно увидеть:

• Текущий статус;
• Response time;
• Uptime percentage;
• Историю heartbeat;
• Последние события.

Однако, одной HTTP-проверки недостаточно для всех сценариев. Иногда нужно проверить доступность конкретного порта или убедиться, что веб-страница содержит ожидаемый текст.

Для этого создадим еще два монитора.

Создание TCP- и keyword-проверок

Проверка доступности TCP-порта

Нажмите Add New Monitor и выберите тип TCP Port.

Назовем монитор: HTTPS TCP

В качестве hostname укажем: example.com

Порт: 443

Интервал можно оставить таким же, как для HTTP-проверки.

После сохранения Uptime Kuma будет пытаться устанавливать TCP-соединение с указанным адресом.

Если порт принимает соединения, монитор отображается как: Up

Такой тип проверки подходит для баз данных, SSH, SMTP и других сетевых сервисов, когда важен сам факт доступности TCP-порта.

Создание keyword-монитора

Теперь создадим проверку содержимого страницы.

Нажмите Add New Monitor и выберите тип HTTP(s) - Keyword.

Название: Website Keyword

URL: https://example.com

В поле Keyword укажите текст, который должен присутствовать на странице.

Например: Example Domain

Uptime Kuma выполнит HTTP-запрос и дополнительно проверит полученное содержимое.

Если сайт отвечает, но нужного текста нет, монитор будет считаться недоступным.

Это полезно в ситуациях, когда веб-сервер возвращает HTTP 200, но вместо нормальной страницы показывает заглушку, ошибку приложения или неправильный контент.

Проверка наличия нужного текста на странице

После сохранения keyword-монитора дождитесь нескольких heartbeat.

Если указанная строка присутствует в ответе, статус станет: Up

В итоге на Dashboard должны одновременно отображаться три проверки:

Такой набор уже покрывает три разных уровня контроля: доступность веб-сервиса по HTTP, открытие сетевого порта и корректность содержимого страницы.

Настройка уведомлений

Одно из главных преимуществ Uptime Kuma — возможность не просто фиксировать сбои в панели, а сразу отправлять уведомление во внешний канал. Это позволяет узнать о проблеме без постоянного просмотра Dashboard.

В рамках руководства используем универсальный webhook. Такой вариант подходит для большинства сценариев, потому что событие можно отправить в собственный сервис, мессенджер, автоматизацию или другой endpoint, который умеет принимать HTTP-запросы.

Выбор способа доставки уведомлений

Uptime Kuma поддерживает разные способы уведомлений. В зависимости от версии и конфигурации можно использовать email, webhook и другие интеграции.

Для универсальной схемы удобнее webhook, потому что он не привязан к конкретному почтовому провайдеру или мессенджеру.

Логика выглядит так:

При изменении состояния монитора Uptime Kuma отправляет HTTP-запрос на заданный URL.

Такой механизм можно использовать как для простого тестового endpoint, так и для собственного обработчика уведомлений.

Настройка универсального webhook

Откройте настройки Uptime Kuma и перейдите в раздел уведомлений.

Создайте новое уведомление и выберите тип: Webhook

Задайте понятное имя, например: Main Webhook

В поле URL укажите endpoint, который будет принимать запросы: https://webhook.example.com/uptime

Для тестирования можно использовать собственный временный webhook endpoint, который показывает входящие HTTP-запросы.

Если endpoint поддерживает POST-запросы с JSON, оставьте соответствующий метод и формат тела запроса.

При необходимости можно дополнительно настроить:

• HTTP headers;
• Authorization;
• Content-Type;
• Собственный JSON body;
• Дополнительные параметры запроса.

Если endpoint требует токен, его лучше передавать через заголовок авторизации, а не добавлять непосредственно в URL.

Привязка уведомления к мониторам

Созданное уведомление само по себе еще не будет использоваться. Его нужно привязать к нужным мониторам.

Откройте, например: Main Website

Перейдите к редактированию и в разделе уведомлений включите: Main Webhook

Аналогично уведомление можно подключить к:

HTTPS TCP

Website Keyword

Если одно уведомление используется для всех проверок, Uptime Kuma сможет сообщать о сбоях каждого из этих сервисов через один webhook.

Для небольшого проекта этого достаточно. В более крупной инфраструктуре можно создавать отдельные каналы уведомлений для разных групп сервисов.

Отправка тестового уведомления

Перед использованием webhook в реальном мониторинге необходимо убедиться, что он работает.

В настройках уведомления используйте функцию тестовой отправки.

Uptime Kuma выполнит запрос на указанный endpoint. Если конфигурация корректна, интерфейс подтвердит успешную отправку.

На стороне webhook также должен появиться реальный входящий запрос от Uptime Kuma.

Тестовая отправка важна, потому что позволяет проверить URL, метод запроса и авторизацию еще до возникновения настоящего сбоя.

Создание публичной Status Page

Uptime Kuma позволяет создать отдельную публичную страницу состояния сервисов. Ее можно использовать для клиентов, сотрудников или пользователей проекта, которым не нужен доступ к административной панели мониторинга.

Status Page отображает только выбранные мониторы и их текущее состояние.

Создание страницы статуса

Откройте раздел Status Pages и создайте новую страницу.

Задайте slug, например: services

Он будет использоваться в URL страницы.

После подключения домена адрес может выглядеть примерно так: https://status.example.com/status/services

Название можно сделать более понятным: Service Status

Добавление мониторов на Status Page

Теперь добавьте на страницу созданные ранее проверки.

Например:

Main Website

HTTPS TCP

Website Keyword

Их можно объединить в одну группу: Production Services

После сохранения Status Page будет отображать состояние каждого выбранного монитора.

Если все сервисы работают нормально, пользователь увидит их в состоянии Operational или аналогичном статусе интерфейса.

При возникновении сбоя соответствующий элемент страницы изменит состояние автоматически.

Настройка названия и описания страницы

Чтобы Status Page была понятна пользователям, добавьте название и краткое описание.

Например: Service Status

Описание: Current availability of websites and API services.

При необходимости можно также изменить:

• Заголовок страницы;
• Отображаемые группы;
• Оформление;
• Порядок мониторов;
• Видимость истории событий.

На публичной странице не следует размещать внутренние адреса, административные URL или другую служебную информацию.

Проверка публичного отображения статусов

После сохранения откройте Status Page в отдельной вкладке браузера.

Убедитесь, что на ней отображаются все выбранные сервисы:

Main Website

HTTPS TCP

Website Keyword

и их актуальное состояние.

На этом этапе все три монитора должны быть доступны.

Публичная страница обновляется на основе тех же проверок, которые выполняет Uptime Kuma, поэтому пользователи получают актуальное состояние сервисов без доступа к административному Dashboard.

Имитация сбоя и проверка оповещений

После настройки мониторинга и webhook необходимо проверить весь сценарий целиком: от возникновения сбоя до получения уведомления.

Для теста лучше использовать контролируемый способ, который можно быстро отменить.

Как безопасно имитировать недоступность сервиса

Не стоит специально останавливать чужой сайт или создавать нагрузку на внешний ресурс. Гораздо безопаснее использовать отдельный тестовый сервис, временно изменить адрес одного из мониторов, заблокировать его ip фаерволом или либо прописать его адрес в файл hosts с заведомо некорректным IP.

Например, для TCP-монитора можно временно указать порт, на котором сервис не работает:

Host: example.com

Port: 65530

Другой вариант — создать дополнительный HTTP-монитор с заведомо недоступным URL: http://127.0.0.1:65530

После сохранения Uptime Kuma начнет выполнять проверки и получит ошибку соединения.

Для ускорения теста можно временно использовать короткий heartbeat interval и небольшое количество retries.

Переход монитора из Up в Down

После нескольких неудачных проверок монитор изменит состояние.

Сначала Uptime Kuma фиксирует ошибочные heartbeat, а затем статус станет: Down

В Dashboard обычно также отображается причина:

Connection refused

Timeout

DNS error

или другой результат неудачной проверки.

На графике истории появится красный участок, соответствующий периоду недоступности.

Это позволяет отличить кратковременную задержку ответа от подтвержденного сбоя.

Получение реального уведомления

После перехода монитора в Down Uptime Kuma активирует привязанное уведомление.

В нашем случае будет выполнен запрос на: Main Webhook

На стороне webhook должен появиться новый входящий запрос уже не тестового, а реального события.

Сообщение будет содержать информацию о мониторе и изменении его состояния.

Такой тест подтверждает работу всей цепочки:

Это важнее простой кнопки Test, потому что показывает, что уведомление действительно связано с монитором и запускается при реальной смене состояния.

Восстановление сервиса после теста

После получения уведомления верните монитор к корректным параметрам.

Например, если для TCP-проверки временно использовался неправильный порт, снова укажите: 443

После следующей успешной проверки монитор вернется в: Up

Uptime Kuma зафиксирует восстановление сервиса и, если это предусмотрено настройкой уведомления, отправит еще одно событие о возвращении в рабочее состояние.

После теста следует убедиться, что Dashboard снова показывает нормальное состояние всех рабочих мониторов.

Таким образом мы проверили не только сам мониторинг, но и полный цикл обработки инцидента: обнаружение сбоя, изменение статуса, отправку уведомления и последующее восстановление.

Подключение домена и HTTPS

После настройки мониторов, уведомлений и Status Page можно открыть Uptime Kuma по отдельному домену. Для этого настроим DNS, установим Nginx как reverse proxy и выпустим TLS-сертификат через Certbot.

В итоговой схеме Uptime Kuma будет по-прежнему работать внутри Docker на локальном порту 3001, а все внешние запросы будут проходить через Nginx.

Создание DNS-записи для Uptime Kuma

Сначала выберите поддомен, который будет использоваться для панели мониторинга.

Например: status.example.com

В DNS-панели домена создайте A-запись:

Type: A

Name: status

Value: 203.0.113.10

Здесь 203.0.113.10 используется как пример публичного IP VPS.

После обновления DNS можно проверить разрешение имени nslookup status.example.com или dig +short status.example.com.

В ответ должен возвращаться IP VPS.

Пока DNS-запись не начнет корректно разрешаться, выпуск TLS-сертификата через Let's Encrypt завершится ошибкой.

Настройка Nginx как reverse proxy

Установим Nginx: sudo apt install -y nginx

Создадим отдельную конфигурацию: sudo nano /etc/nginx/sites-available/uptime-kuma

Добавим:

server {

    listen 80;

    server_name status.example.com;

    location / {

        proxy_pass http://127.0.0.1:3001;

        proxy_http_version 1.1;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection "upgrade";

    }

}

Параметр: proxy_pass http://127.0.0.1:3001;

передает входящие запросы локальному контейнеру Uptime Kuma.

Активируем конфигурацию: sudo ln -s /etc/nginx/sites-available/uptime-kuma /etc/nginx/sites-enabled/uptime-kuma

Проверим синтаксис: sudo nginx -t

При успешной проверке применим изменения: sudo systemctl reload nginx

После этого Uptime Kuma должен открываться по HTTP: http://status.example.com

Выпуск TLS-сертификата через Certbot

Установим Certbot и модуль для Nginx: sudo apt install -y certbot python3-certbot-nginx

Запросим сертификат: sudo certbot --nginx -d status.example.com

Certbot проверит доступность домена, выпустит сертификат Let's Encrypt и обновит конфигурацию Nginx.

После успешного завершения интерфейс станет доступен по: https://status.example.com

Проверим конфигурацию: sudo nginx -t

И состояние Nginx: sudo systemctl status nginx --no-pager

Проверка доступа к Uptime Kuma по HTTPS

Откройте в браузере: https://status.example.com

Должна загрузиться панель Uptime Kuma, а браузер — показать корректное HTTPS-соединение.

Также можно проверить заголовки: curl -I https://status.example.com

В ответ должен возвращаться HTTP-статус сервиса через Nginx.

На этом этапе Uptime Kuma уже доступен по нормальному публичному адресу, а внутренний Docker-порт не используется пользователями напрямую.

Защита Uptime Kuma

После публикации через Nginx важно убедиться, что внешний пользователь не может обойти reverse proxy и открыть Uptime Kuma напрямую по порту 3001.

Закрытие прямого доступа к порту 3001

В Docker Compose мы использовали:

ports:

  - "127.0.0.1:3001:3001"

Это означает, что Docker публикует порт только на loopback-интерфейсе VPS.

Проверим: sudo ss -lntp | grep 3001

Ожидаемый адрес: 127.0.0.1:3001

Если вместо него используется 0.0.0.0:3001 или *:3001 необходимо изменить Docker Compose-конфигурацию и пересоздать контейнер.

После правки:

sudo docker compose down

sudo docker compose up -d

Доступ к панели только через Nginx

После ограничения порта рабочая схема выглядит так:

При этом запрос http://203.0.113.10:3001 не должен открывать интерфейс.

Локально Uptime Kuma продолжит отвечать: curl -I http://127.0.0.1:3001

Это подтверждает, что приложение доступно reverse proxy, но не опубликовано напрямую.

Проверка открытых портов VPS

Посмотрим все слушающие TCP-порты: sudo ss -lntp

Для итоговой конфигурации наружу обычно нужны:

22

80

443

При этом 3001 должен быть привязан только к localhost.

Если используется UFW, можно ограничить внешний доступ:

sudo ufw allow OpenSSH

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw enable

Проверим: sudo ufw status

Отдельно открывать 3001/tcp не требуется.

Обновление контейнера без потери данных

Конфигурация и история Uptime Kuma хранятся в Docker volume: uptime-kuma-data

Поэтому контейнер можно пересоздавать без удаления данных.

Перед обновлением перейдите в каталог проекта: cd /opt/uptime-kuma

Загрузите свежий образ: sudo docker compose pull

Пересоздайте контейнер: sudo docker compose up -d

Проверим: sudo docker ps --filter name=uptime-kuma

Поскольку volume остается тем же, мониторы, пользовательские настройки и история сохраняются.

Перед любым обновлением дополнительно полезно создать резервную копию данных Docker volume и каталога приложения, как вариант - сделать снапшот VPS.

Обслуживание мониторинга

После развертывания основная работа сводится к контролю логов, обновлению контейнера и добавлению новых сервисов по мере необходимости.

Просмотр журналов Docker-контейнера

Если Uptime Kuma работает некорректно, первым делом стоит посмотреть его логи: sudo docker logs uptime-kuma --tail 100

Для просмотра новых сообщений в реальном времени: sudo docker logs -f uptime-kuma

В логах можно увидеть ошибки запуска, сетевые проблемы, ошибки базы данных и другие сообщения приложения.

Состояние контейнера можно проверить: sudo docker ps --filter name=uptime-kuma

Перезапуск Uptime Kuma

Для обычного перезапуска контейнера: sudo docker restart uptime-kuma

Если используется Docker Compose:

cd /opt/uptime-kuma

sudo docker compose restart

После этого проверьте: sudo docker ps

Также локальную доступность: curl -I http://127.0.0.1:3001

Добавление новых сайтов и API

Для нового сервиса обычно достаточно создать отдельный monitor.

Для сайта подойдет: HTTP(s)

Для API можно проверять конкретный endpoint: https://api.example.com/health

Если API должен возвращать определенный текст или JSON-фрагмент, можно использовать keyword-проверку.

Для сетевого сервиса подойдет TCP monitor с указанием hostname и порта.

Чтобы структура Dashboard оставалась понятной, лучше использовать единый принцип именования, например:

Production - Website

Production - API

Production - PostgreSQL

Staging - Website

Так при росте количества мониторов проще ориентироваться в списке и группировать сервисы на Status Page.

Что делать, если монитор показывает ложный Down

Иногда сервис работает нормально, но Uptime Kuma периодически фиксирует Down. Причина не обязательно находится в самом приложении.

Сначала стоит проверить:

• Корректность URL и порта;
• DNS-разрешение;
• HTTP status code;
• Таймаут запроса;
• Количество retries;
• Сетевую доступность с самого VPS (включая фаерволы и другие средства защиты проверяемого сайта);
• TLS-сертификат;
• Наличие keyword для соответствующей проверки.

Например, HTTP-проверку можно повторить непосредственно с VPS: curl -I https://example.com

Для TCP-сервиса: nc -vz example.com 443

Если ручные запросы иногда тоже завершаются таймаутом, проблема находится не в Uptime Kuma, а в соединении или самом проверяемом сервисе.

Если сервис отвечает стабильно, но отдельные heartbeat все равно пропадают, можно увеличить timeout или retries. Однако чрезмерно большие значения использовать не стоит, иначе Uptime Kuma будет слишком долго считать действительно недоступный сервис рабочим.

Для keyword-монитора дополнительно убедитесь, что искомый текст действительно присутствует в HTTP-ответе. Изменение содержимого сайта может привести к Down, даже если сам сервер продолжает возвращать код 200.

Последовательная проверка параметров monitor и ручной запрос с VPS обычно позволяет быстро понять, является ли событие реальным сбоем или ложным срабатыванием.

Заключение

Uptime Kuma позволяет развернуть на собственном VPS удобную систему мониторинга сайтов, API и сетевых сервисов. В отличие от более сложных стеков мониторинга, здесь большая часть настройки выполняется через веб-интерфейс: достаточно создать нужные monitors, задать условия проверки и подключить уведомления.

В рамках руководства мы установили Uptime Kuma через Docker, настроили HTTP-, TCP- и keyword-проверки, создали публичную Status Page и подключили универсальный webhook. После этого отдельно имитировали сбой и убедились, что монитор действительно переходит в состояние Down, а внешний endpoint получает реальное уведомление.

Для публикации интерфейса использовали Nginx как reverse proxy и HTTPS. При этом внутренний порт Uptime Kuma остался привязан к localhost, поэтому пользователям не требуется обращаться к 3001 напрямую. Такой подход соответствует рекомендациям проекта: для безопасной публикации Uptime Kuma удобно использовать reverse proxy, а при проксировании учитывать поддержку WebSocket.

Получившаяся схема подходит для небольших сайтов, API, внутренних сервисов и pet-проектов. По мере роста инфраструктуры в нее можно добавлять новые monitors, отдельные Status Page и дополнительные каналы уведомлений.

FAQ

Можно ли использовать Uptime Kuma без Docker?

Да. Проект можно запускать разными способами, но Docker остается одним из основных и наиболее удобных вариантов установки. Официальная документация отдельно описывает Docker-развертывание и обновление контейнера.

Какие сервисы можно проверять через Uptime Kuma?

Uptime Kuma поддерживает разные типы monitors, включая HTTP(S), TCP и другие проверки. Для типового веб-проекта обычно достаточно HTTP(S)-монитора сайта или API, TCP-проверки нужного порта и дополнительной проверки содержимого страницы.

Зачем использовать keyword-проверку, если сайт уже проверяется по HTTP?

Обычная HTTP-проверка показывает, что сервер ответил допустимым HTTP-кодом. Но это не всегда означает, что приложение работает правильно.

Например, сервер может возвращать код 200, но при этом показывать заглушку или неправильную страницу. Keyword-монитор дополнительно проверяет наличие ожидаемого контента и позволяет заметить такой сценарий сбоя.

Нужно ли открывать порт 3001 в интернет?

Нет, если Uptime Kuma опубликован через reverse proxy. Официальная документация рекомендует использовать Nginx, Apache или другой reverse proxy для безопасной публикации интерфейса. При этом сам порт приложения можно привязать к localhost.

Почему для Nginx нужны заголовки Upgrade и Connection?

Uptime Kuma использует WebSocket, поэтому reverse proxy должен корректно передавать WebSocket-соединения. В официальной документации отдельно отмечается необходимость заголовков Upgrade и Connection.

Можно ли отправлять уведомления не только через webhook?

Да. Uptime Kuma поддерживает множество notification providers. В официальной wiki перечислены встроенные способы уведомлений и интеграции через Apprise; webhook является универсальным вариантом для HTTP POST-интеграций.

Зачем отдельно тестировать реальный Down, если кнопка Test уже работает?

Кнопка Test проверяет только сам канал уведомлений. Она подтверждает, что Uptime Kuma может отправить запрос на webhook, но не проверяет полную цепочку мониторинга.

Имитация сбоя дополнительно подтверждает, что monitor действительно обнаруживает проблему, меняет состояние и после этого активирует привязанное уведомление.

Можно ли создать несколько публичных Status Page?

Да. Status Page является отдельной функцией Uptime Kuma, поэтому можно создавать страницы для разных групп сервисов и показывать на каждой только нужные monitors.

Что произойдет с настройками после пересоздания Docker-контейнера?

Если данные Uptime Kuma вынесены в постоянный Docker volume, пересоздание самого контейнера не должно удалять конфигурацию. Официальная инструкция по обновлению также использует постоянный volume /app/data при удалении старого и запуске нового контейнера.

Список источников

1. Uptime Kuma Wiki — How to Install
2. Uptime Kuma Wiki — Reverse Proxy
3. Uptime Kuma Wiki — Notification Methods
4. Uptime Kuma Wiki — How to Update