В какой-то момент любой прод вырастает из уровня «посмотрю сайт глазами, вроде работает». Нужен честный uptime: свои проверки, алерты и история инцидентов. Но тянуть сразу весь стек Prometheus + Alertmanager + Grafana ради пары сайтов и кронов тоже не хочется.
Баланс где-то посередине: лёгкие self‑hosted решения под uptime и healthchecks, которые удобно крутить на обычном VDS. В этой статье разберём три класса таких инструментов:
- Uptime Kuma — GUI‑мониторинг HTTP/TCP/ICMP с уведомлениями;
- Gatus — декларативный uptime в YAML, «для тех, кто любит конфиги»;
- клоны Healthchecks.io — для мониторинга cron‑задач и фоновых воркеров.
Поговорим, где каждый из них уместен, как они вписываются в общую схему мониторинга и как минимальными силами навести порядок в проверках доступности.
Что такое self‑hosted uptime и зачем он нужен, если есть внешние сервисы
Внешние сервисы мониторинга uptime видят ваш сервис «со стороны интернета», а self‑hosted — «изнутри вашей инфраструктуры». Обе точки зрения нужны, но задачи разные.
Внешний uptime отвечает на вопрос «пользователь из мира может зайти на мой сайт?», а self‑hosted — «у меня внутри всё живо и между сервисами нет обрывов?».
Типичные сценарии, где self‑hosted uptime на VDS полезен:
- проверка доступности внутренних сервисов (админки, API, базы, брокеры), которые не должны светиться в интернет;
- проверка backend‑зависимостей изнутри: сайт может быть доступен снаружи, но не может достучаться до базы или платёжного шлюза;
- контроль cron‑задач: бэкапы, импорты, расчёты, очистки — всё, что не видно по HTTP;
- быстрый старт: вы не готовы завязываться на SaaS, хотите максимальный контроль и независимость.
Self‑hosted инструменты для uptime обычно:
- просты в развёртывании (часто один контейнер или бинарь);
- заточены именно под проверки доступности, а не под полноразмерный metrics‑мониторинг;
- хорошо сочетаются с уже существующими стэками (Prometheus, Zabbix и т.д.).
Общий ландшафт: Kuma, Gatus, Healthchecks‑like
Если коротко, то обзор получится такой.
Uptime Kuma
Фокус: визуальный, удобный, «поставил и кликаешь мышкой».
- UI‑ориентированный: всё настраивается из веб‑панели;
- поддержка разных типов мониторов: HTTP(S), TCP, ICMP, DNS, WebSocket и др.;
- много каналов уведомлений: Telegram, e‑mail, Slack, Discord и т.п.;
- простая история инцидентов и наглядные дашборды.
Gatus
Фокус: конфиги в Git и декларативность.
- конфигурация в YAML: описываем эндпоинты, условия и алерты;
- есть веб‑интерфейс, но он вторичен по отношению к конфигам;
- поддерживает HTTP/HTTPS, TCP, DNS, gRPC (через HTTP/JSON‑прокси);
- легко интегрируется в GitOps: MR → ревью → деплой конфигов.
Клоны Healthchecks.io
Фокус: контроль периодических задач.
- каждая задача «пингает» сервис по HTTP, когда успешно отработала;
- если пинга не было в заданный интервал — алерт;
- часто есть поддержка «start / success / fail» пингов и grace‑периодов;
- интеграция с cron и systemd‑таймерами, без агентов.
На практике удобно комбинировать: Kuma или Gatus — для доступности сервисов, Healthchecks‑like — для кронов и воркеров. Всё это отлично размещается на одном VDS, особенно если завернуть в Docker.
Где self‑hosted uptime реально экономит нервы
Ниже несколько типичных кейсов, где такие инструменты быстро окупаются.
«Сайт жив, но корзина не работает»
Снаружи проверяется только главная страница, а внутри никто не мониторит API корзины или оплат. Внешний uptime улыбается, бизнес злится.
Решение: добавить внутренние HTTP‑проверки на те же URL, которые использует фронтенд. В них уже можно проверять не только код ответа, но и наличие конкретных строк в JSON/HTML, время ответа, редиректы.
Сломался cron с бэкапами
Скрипт бэкапа тихо перестал работать — права, путь, квота, что угодно. Логи никто не читает, инцидент всплывает только перед восстановлением.
С Healthchecks‑подобными сервисами каждый запуск бэкапа обязан «постучаться» на URL. Если стука нет — через несколько минут или часов придёт уведомление. Можно заодно мониторить и длительность задания.
Если вы уже задумывались о выносе бэкапов в отдельное хранилище, может быть полезна статья о резервных копиях в S3 с restic и Borg — такие задачи идеально дополняются healthchecks.
Несколько окружений и тестовые стенды
На одном VDS живут dev/stage/prod стенды. Хотелось бы видеть, что именно лежит, и не путаться, когда QA жалуется на «упал стенд».
Uptime Kuma или Gatus позволяют развести проверки по папкам/группам: prod, stage, dev. В Gatus можно ещё и через labels в конфиге делать фильтры.
Uptime Kuma: дружелюбный UI‑мониторинг
Uptime Kuma часто становится первой точкой входа в self‑hosted uptime, потому что:
- быстро ставится (особенно в Docker);
- имеет простой веб‑интерфейс «из коробки»;
- понятен не только DevOps, но и менеджерам и саппорту.
Типы проверок
Основные проверки, которые обычно используют на веб‑проектах:
- HTTP(S) — проверка кода ответа, строк в теле, времени ответа;
- TCP‑порты (например, 5432 для PostgreSQL, 6379 для Redis, 25/587 для SMTP);
- ICMP ping — базовое понимание, жив ли хост и сеть;
- DNS‑запросы — проверка, что DNS‑запись резолвится как надо.
Для сложных систем удобно комбинировать проверки: ping VDS, TCP к базе, HTTP до приложения. Тогда проще локализовать, где именно обрыв.
Алерты и уведомления
Сильная сторона Kuma — много готовых интеграций уведомлений. Обычно первым делом настраивают:
- Telegram‑бота или канал для команды дежурных;
- e‑mail для более «официальных» сообщений;
- внутренний чат (Slack/Discord/Mattermost) — для общего фона.
Гибко настраиваются пороги: сколько провалов подряд считать инцидентом, какие каналы использовать для конкретного монитора, нужно ли уведомлять о восстановлении.
Когда Uptime Kuma — оптимальный выбор
- у вас немного сервисов, и их удобно «кликать мышкой»;
- конфиги в Git не являются строгим требованием;
- вы хотите визуальную доску статусов, понятную саппорту и менеджерам;
- важна скорость запуска и минимум «админщины».
Gatus: uptime как конфигурация
Gatus интересен тем, что ставит в центр конфиг в YAML, а веб‑интерфейс — лишь надстройка над ним. Это хорошо ложится в GitOps‑подход:
Любая новая служба в инфраструктуре — это не только деплой, но и пулл‑реквест с добавлением проверки в Gatus.
Идея Gatus
Каждый сервис описывается блоком в конфиге: что проверять (URL, порт, хост), какие условия считать «здоровыми» и куда слать алерты. Условия могут быть достаточно сложными: статус‑код, время ответа, наличие или отсутствие строк в теле, заголовки и т.д.
Например, для API вы можете сказать: «сервис считается живым, если отвечает 200 за < 500 ms и в JSON есть поле status=ok». Это сильно честнее, чем просто «HTTP 200».
Преимущества конфиг‑подхода
- версионирование: все изменения в мониторинге проходят через Git;
- код‑ревью: коллеги видят, какие проверки добавлены или изменены;
- лёгкий перенос: на новом VDS достаточно забрать репозиторий с конфигами;
- шаблоны: можно стандартизировать проверки по микросервисам.
Для команд, где уже есть привычка хранить всё как код (infra as code, pipelines, Helm‑чарты), Gatus воспринимается естественно.
Где Gatus удобнее Kuma
- много однотипных микросервисов: вы генерите YAML автоматически;
- жёсткий процесс изменений: без Merge Request ничего не меняется;
- нужно хранить «историю логики» проверок вместе с кодом;
- миграции и катастрофы: легко поднять копию в другом месте по тем же конфигам.
Healthchecks‑подобные решения: контроль cron и воркеров
Uptime Kuma и Gatus хороши для постоянных сервисов, которые висят на портах или URL. Но периодические задачи (cron, systemd‑таймеры, очереди) требуют другого подхода.
Логика Healthchecks‑подобных решений:
- для каждой задачи создаётся «чек» с ожидаемым интервалом (например, раз в час);
- скрипт при успешном завершении делает HTTP‑запрос на уникальный URL;
- если сервис не получил пинг в указанный интервал — задача считается «упавшей», и шлётся алерт;
- часто можно отправлять отдельные URL для старта и ошибки, плюс передавать логи в теле запроса.
Почему мониторить cron так важно
Периодические задачи — классический источник «скрытых» проблем:
- их падение не видно из внешнего uptime;
- ошибки могут долго накапливаться (бэкапы, биллинги, отчёты);
- ошибка может быть «тихой» (скрипт завершился, но сделал не то).
Контроль факта запуска и успешного завершения не даёт таким проблемам копиться неделями.
Примеры задач, которым полезен Healthchecks‑подход
- бэкап баз данных и файлов;
- очистка временных файлов и логов;
- регулярный импорт и экспорт данных с внешних систем;
- пересчёт отчётов, витрин, кешей.
Если вы ещё не определились, запускать периодические задачи через cron или systemd‑таймеры, загляните в материал о сравнении cron и systemd‑таймеров — там удобно подобрать формат под мониторинг.
Как комбинировать решения uptime на одном VDS
Частый сценарий для небольших и средних проектов: один не очень нагруженный VDS, на котором крутится всё — от мониторинга до вспомогательных сервисов. Это не идеал с точки зрения разделения ролей, но для старта и небольших бюджетов — вполне рабочий компромисс.
Практическая схема может выглядеть так:
- Uptime Kuma или Gatus слушает локальный порт, доступный только из админской сети или VPN;
- Healthchecks‑подобный сервис также слушает отдельный порт или домен, по которому стучатся cron‑задачи;
- внешний reverse‑proxy (например, Nginx) по доменным именам и путям проксирует запросы к этим сервисам;
- доступ в панели мониторинга ограничивается базовой авторизацией или VPN.
Важно не забыть, что мониторинг тоже сервис, к которому нужен uptime. Минимальный набор проверок, который стоит завести:
- ping и TCP‑порты VDS снаружи;
- HTTP‑проверка самого monitoring‑VDS (если он отдельный);
- healthcheck баз данных, кэшей, очередей;
- healthchecks для ключевых кронов: бэкапы, биллинги, миграции.
Типовые ошибки при внедрении self‑hosted uptime
Ниже — несколько ловушек, в которые команды регулярно попадают.
Нет проверки именно критического пути пользователя
Проверять только главную страницу — мало. Нужно мониторить полный путь, который приносит деньги или важную метрику:
- страницу оформления заказа;
- API авторизации;
- страницу оплаты или callback от платёжного провайдера;
- API ключевого мобильного приложения.
Именно эти точки стоит заводить как отдельные проверки в Kuma или Gatus с более жёсткими SLA.
Алерты без приоритета
Если одинаковыми уведомлениями сыпать про падение тестового стенда и боевой оплаты, команда быстро начнёт игнорировать всё.
Решение — разделять проверки по критичности и для важных сервисов использовать отдельные каналы или уровни важности. Например, в Kuma — отдельная группа мониторов с уведомлениями в другой чат.
Нет дежурств и процессов
Сам по себе uptime не решает проблему, если на алерты никто не реагирует. Даже в небольшой команде полезно:
- определить, кто «первый контакт» по инцидентам в нерабочее время;
- описать минимальный плейбук: куда смотреть в первую очередь, что перезапустить;
- вести короткий журнал инцидентов, чтобы не наступать на те же грабли.
Self‑hosted uptime и «большой» мониторинг
Uptime Kuma, Gatus и Healthchecks‑подобные решения не заменяют полноразмерный мониторинг на уровне метрик (CPU, RAM, latency‑гистограммы, бизнес‑метрики). Они закрывают слой «жив / не жив» и базовую диагностику на уровне доступности.
Здоровая архитектура мониторинга обычно выглядит как слоёный пирог:
- инфраструктурный уровень: метрики серверов и баз;
- сервисный уровень: HTTP/TCP‑healthchecks, проверка зависимостей;
- уровень задач: cron, очереди, фоновые воркеры;
- бизнес‑уровень: заказы, платежи, регистрации.
Инструменты из этой статьи закрывают два средних слоя. Для многих небольших проектов этого уже достаточно, а дальше можно доращивать метрики и лог‑мониторинг по мере роста.
Итоги
Self‑hosted uptime на VDS — это не обязательно огромный стек с десятком компонентов. В большинстве случаев вполне достаточно комбинации из:
- Uptime Kuma или Gatus для постоянных HTTP/TCP/ICMP‑проверок;
- Healthchecks‑подобного сервиса для cron и фоновых задач.
Ключевые мысли:
- следите не только за «сайтом в целом», но и за критическими точками пользовательского пути и внутренними зависимостями;
- внедряйте healthchecks для бэкапов и кронов, это спасает в самые неприятные моменты;
- определите, кто и как реагирует на алерты, иначе любая система мониторинга быстро превратится в фоновой шум.
Дальше можно уже подключать метрики, логирование и трассировки, но честный uptime — это та основа, с которой стоит начать.
