Как установить и настроить Gatus на VPS

MAATRIX

Когда сайт или API падает ночью, вы обычно узнаёте об этом последним — от клиента в чате поддержки. Uptime Kuma и Zabbix решают эту проблему, но тянут за собой веб-интерфейс, базу данных и лишние настройки, если нужно просто следить за десятком эндпоинтов. Gatus — компактная альтернатива: весь мониторинг описывается одним YAML-файлом, а сам сервис отдаёт готовую статус-страницу и шлёт алерты без танцев с бубном. Разберём, как поставить его на VPS, настроить проверки и вывести статус-страницу наружу.

Что такое Gatus и когда он нужен

Gatus — это открытый инструмент мониторинга на Go (проект TwiN/gatus), который периодически стучится в ваши эндпоинты — по HTTP, TCP, DNS, ICMP или через выполнение shell-команды — и проверяет ответ по условиям вроде [STATUS] == 200 или [RESPONSE_TIME] < 300. Результат хранится в памяти или в SQLite/PostgreSQL, а сверху крутится веб-интерфейс со статус-страницей — той самой, где зелёные и красные квадратики показывают историю доступности за последние часы.

Он не заменяет полноценный APM или Prometheus с десятками экспортёров, зато отлично закрывает типовую задачу: «я хочу знать, что сайт лежит, раньше, чем это заметят пользователи». Плюсы для VPS-эксплуатации:

• конфиг — один YAML-файл, который удобно хранить в git и раскатывать через CI;
• бинарник весит около 20 МБ, Docker-образ — тоже компактный, отдельная база не обязательна;
• встроенная генерация статус-страницы без сторонних плагинов;
• алерты сразу «из коробки» — Telegram, Slack, Discord, PagerDuty, email, вебхуки, ntfy.

Если вам нужен агентский мониторинг ресурсов (CPU, RAM, диск) — это не к Gatus, для этого лучше подойдёт связка Grafana и Prometheus или отдельный агент на самом сервере. Gatus решает именно blackbox-задачу: «отвечает ли сервис снаружи так, как должен».

Установка на VPS: бинарник, systemd, Docker

Проще всего запускать Gatus в Docker — так вы избегаете ручного управления зависимостями и обновлениями. Docker на сервере должен быть установлен заранее — процесс стандартный для любого свежего дистрибутива.

Минимальный docker-compose.yml:

services:
  gatus:
    image: twinproduction/gatus:latest
    container_name: gatus
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./config:/config
      - gatus-data:/data
    environment:
      - GATUS_CONFIG_PATH=/config

volumes:
  gatus-data:

Порт намеренно проброшен только на 127.0.0.1 — наружу статус-страницу отдаём через reverse proxy с SSL, об этом ниже. Создайте каталог config, положите туда config.yaml (пример — в следующем разделе) и поднимите контейнер:

mkdir -p gatus/config
cd gatus
docker compose up -d
docker compose logs -f gatus

Если предпочитаете нативный бинарник без Docker — скачайте актуальный релиз со страницы проекта на GitHub под вашу архитектуру, распакуйте в /usr/local/bin/gatus и опишите systemd-юнит:

# /etc/systemd/system/gatus.service
[Unit]
Description=Gatus uptime monitoring
After=network.target

[Service]
Type=simple
User=gatus
WorkingDirectory=/etc/gatus
ExecStart=/usr/local/bin/gatus
Restart=on-failure
RestartSec=5
Environment=GATUS_CONFIG_PATH=/etc/gatus/config.yaml

[Install]
WantedBy=multi-user.target

useradd -r -s /usr/sbin/nologin gatus
mkdir -p /etc/gatus && chown gatus:gatus /etc/gatus
systemctl daemon-reload
systemctl enable --now gatus

Для продакшена Docker-вариант обычно удобнее — проще обновлять образ (docker compose pull && docker compose up -d) и не нужно вручную следить за релизами бинарника.

Базовый конфиг: первые проверки

Всё поведение Gatus описывается в config.yaml. Начните с самого простого — проверки доступности сайта:

endpoints:
  - name: main-site
    url: "https://example.com"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 800"

interval — как часто дёргать эндпоинт, conditions — список условий, которые обязаны выполниться все сразу, иначе проверка считается упавшей. Доступные плейсхолдеры: [STATUS], [RESPONSE_TIME] (в миллисекундах), [BODY], [IP], [CONNECTED], [CERTIFICATE_EXPIRATION] и другие — полный список удобнее смотреть в README проекта, он периодически пополняется.

Полезная деталь: [RESPONSE_TIME] < 800 — это ориентир, не жёсткое правило физики. Реальный приемлемый порог зависит от вашего сервиса и локации VPS относительно пользователей — для API внутри одного дата-центра 800 мс может быть уже тревожным сигналом, а для сайта с внешним CDN — нормой. Настройте пороги под свою реальность, а не копируйте чужие цифры вслепую.

Перезапуск контейнера (или systemd-сервиса) подхватывает изменения конфига; Gatus также умеет отслеживать файл и перечитывать его на лету при web.write-timeout и включённом hot-reload — но для стабильности на проде проще перезапускать явно после правки.

Виды проверок: HTTP, TCP, DNS, ICMP, TLS

Gatus проверяет не только «жив ли HTTP», но и низкоуровневые вещи. Несколько практических примеров.

TCP-проверка (например, что порт SSH или база данных отвечают):

endpoints:
  - name: postgres-tcp
    url: "tcp://10.0.0.5:5432"
    interval: 30s
    conditions:
      - "[CONNECTED] == true"

DNS-проверка (резолвится ли домен и отдаётся ли ожидаемая запись) — удобно после переезда на новый DNS или смены хостинга:

endpoints:
  - name: domain-a-record
    url: "https://example.com"
    dns:
      query-name: "example.com"
      query-type: "A"
    conditions:
      - "[BODY] == 203.0.113.10"

ICMP-пинг для проверки, что хост в сети вообще отвечает:

endpoints:
  - name: server-ping
    url: "icmp://203.0.113.10"
    interval: 30s
    conditions:
      - "[CONNECTED] == true"

Отдельно стоит включить проверку срока действия TLS-сертификата — это дешёвая страховка от «сайт упал, потому что забыли продлить Let's Encrypt»:

    conditions:
      - "[STATUS] == 200"
      - "[CERTIFICATE_EXPIRATION] > 240h"

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

Для проверок, которые не сводятся к запросу (например, «воркер обработал очередь за последний час»), есть тип type: dns для DNS и произвольные HTTP-эндпоинты health-check внутри вашего приложения — Gatus просто дёргает URL, а логику «здоров ли сервис» вы описываете в самом приложении.

Публикация статус-страницы через reverse proxy

По умолчанию Gatus слушает 8080 и отдаёт статус-страницу на /. Наружу лучше не светить порт напрямую — заведите домен вида status.example.com и проксируйте через Nginx или Caddy с TLS.

Вариант с Nginx (подробный разбор reverse proxy — в статье Nginx как reverse proxy на VPS):

server {
    listen 443 ssl http2;
    server_name status.example.com;

    ssl_certificate     /etc/letsencrypt/live/status.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/status.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

Вариант с Caddy проще — TLS выпускается автоматически без ручной настройки certbot:

status.example.com {
    reverse_proxy 127.0.0.1:8080
}

Если статус-страница не должна быть публичной (внутренний дашборд для команды), включите базовую авторизацию прямо в Gatus, без правки конфига nginx:

security:
  basic:
    username: "ops"
    password-bcrypt-base64: "JDJhJDEwJC..."  # bcrypt-хеш пароля, base64

Bcrypt-хеш пароля можно сгенерировать одной командой:

htpasswd -nbBC 10 "" "ваш-пароль" | tr -d ':\n' | sed 's/^\$2y/\$2a/' | base64

Также в блоке ui: можно задать заголовок страницы, логотип и favicon:

ui:
  title: "Статус сервисов — Example"
  header: "Example Inc. — статус"
  logo: "https://example.com/logo.png"

Не забудьте открыть 443/80 в файрволе, если ещё не сделали — быстрый чек-лист есть в статье про UFW на VPS.

Алерты: Telegram, Slack, история и хранилище

Мониторинг без уведомлений — это просто красивая страница, на которую никто не смотрит в 3 часа ночи. Настройка Telegram-алертов:

alerting:
  telegram:
    token: "123456789:AA...ваш-токен-бота"
    id: "-1001234567890"  # chat_id канала или группы
    default-alert:
      failure-threshold: 3
      success-threshold: 2
      send-on-resolved: true
      description: "Сервис недоступен"

failure-threshold: 3 означает, что алерт уйдёт только после трёх подряд неудачных проверок — это отсекает случайные сетевые всплески и не превращает канал в мусорку. send-on-resolved: true пришлёт отдельное сообщение, когда сервис снова заработал — без этого вы будете гадать, восстановилось ли всё само. Как создать бота и получить chat_id, подробно описано в статье алерты в Telegram на VPS.

Дальше в каждом эндпоинте достаточно подключить нужный тип алерта:

endpoints:
  - name: main-site
    url: "https://example.com"
    interval: 60s
    conditions:
      - "[STATUS] == 200"
    alerts:
      - type: telegram

Slack и Discord настраиваются аналогично — через свои вебхуки в секции alerting. По умолчанию история проверок хранится в памяти и теряется при перезапуске контейнера. Для сохранения истории между рестартами используйте SQLite или PostgreSQL:

storage:
  type: sqlite
  path: /data/gatus.db

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

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