Gatus на Ubuntu 24.04: пошаговая установка

MAATRIX

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

Что такое Gatus и когда он лучше Uptime Kuma

Gatus — открытый проект на Go (репозиторий TwiN/gatus), который проверяет доступность эндпоинтов по расписанию и превращает результаты в статус-страницу. Ключевая идея — декларативность: вся конфигурация, включая условия успеха проверки, живёт в одном config.yaml. Никакой отдельной СУБД для базовой работы не требуется — данные о статусах можно хранить в памяти или в SQLite-файле.

Чем Gatus отличается от соседей по нише:

Если вам нужен именно uptime-мониторинг «работает / не работает» с публичной статус-страницей и без отдельной базы — Gatus закрывает вопрос за 15 минут. Если нужны графики нагрузки CPU и сложные триггеры — это уже задача для Prometheus с Grafana или Zabbix. А если хочется кликать мышкой, а не писать YAML — присмотритесь к Uptime Kuma.

Проверки Gatus умеют работать с HTTP(S), TCP-портами, DNS-записями, ICMP (ping), а также напрямую подключаться к PostgreSQL, MySQL, Redis, RabbitMQ и другим сервисам — то есть можно проверять не только «сайт отвечает», но и «база принимает соединения» или «до истечения SSL-сертификата осталось больше недели».

Устанавливаем Gatus на Ubuntu 24.04

Ставить будем как системный сервис — отдельным пользователем, бинарником в /usr/local/bin и юнитом systemd. Это надёжнее, чем разово запущенный процесс в screen/tmux, и переживает перезагрузку сервера.

Создайте системного пользователя без домашней директории и без прав на shell:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin gatus
sudo mkdir -p /etc/gatus /var/lib/gatus
sudo chown gatus:gatus /var/lib/gatus

Скачайте актуальный релиз с GitHub. Точное имя архива в релизах Gatus иногда меняется между версиями, поэтому надёжнее не хардкодить версию, а спросить у GitHub API прямую ссылку на архив под вашу архитектуру:

ARCH=$(dpkg --print-architecture)   # amd64 или arm64
mkdir -p /tmp/gatus-install && cd /tmp/gatus-install

DOWNLOAD_URL=$(curl -s https://api.github.com/repos/TwiN/gatus/releases/latest \
  | grep "browser_download_url" \
  | grep "linux" \
  | grep "${ARCH}" \
  | grep -v ".sha256" \
  | head -n1 \
  | cut -d '"' -f4)

echo "Ссылка на релиз: $DOWNLOAD_URL"
curl -L -o gatus.tar.gz "$DOWNLOAD_URL"
tar -xzf gatus.tar.gz

После распаковки бинарник может лежать как в корне архива, так и во вложенной папке — проверьте, где он оказался: find /tmp/gatus-install -type f -name "gatus".

Установите бинарник и проверьте версию:

sudo install -m 755 /tmp/gatus-install/gatus /usr/local/bin/gatus
gatus --version
rm -rf /tmp/gatus-install

Если бинарник не запускается с ошибкой прав — проверьте, что архив действительно был собран под вашу архитектуру (uname -m для сверки: x86_64 соответствует amd64, aarch64 — arm64).

Пишем config.yaml: первые проверки сайта, SSH и Postgres

Создайте конфиг в /etc/gatus/config.yaml. Начнём с малого набора: HTTP-проверка сайта, TCP-проверка SSH-порта и проверка подключения к PostgreSQL.

web:
  address: 127.0.0.1
  port: 8080

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

ui:
  title: "Статус сервисов | MAATRIX"
  header: "Статус наших сервисов"
  link: "https://example.com"

endpoints:
  - name: "Сайт"
    group: "production"
    url: "https://example.com"
    interval: 30s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 800"
      - "[CERTIFICATE_EXPIRATION] > 168h"

  - name: "SSH"
    group: "production"
    url: "tcp://example.com:22"
    interval: 60s
    conditions:
      - "[CONNECTED] == true"

  - name: "PostgreSQL"
    group: "production"
    url: "postgres://gatus_check:пароль@127.0.0.1:5432/postgres?sslmode=disable"
    interval: 60s
    conditions:
      - "[CONNECTED] == true"

Обратите внимание на web.address: 127.0.0.1 — веб-интерфейс Gatus по умолчанию слушает 8080 порт и не предполагает публичный доступ без прокси. Вешать его напрямую на 0.0.0.0 без reverse-proxy и SSL перед ним — плохая идея, ниже разберём правильный вариант.

Условия (conditions) — сердце Gatus. Каждое условие — простое сравнение, все они должны выполниться, чтобы проверка считалась успешной. Полезные плейсхолдеры:

• [STATUS] — HTTP-код ответа;
• [RESPONSE_TIME] — время ответа в миллисекундах;
• [BODY] — тело ответа, можно искать подстроку через [BODY] == pat(*ok*);
• [CONNECTED] — для TCP/DNS/DB-проверок: удалось ли подключиться;
• [CERTIFICATE_EXPIRATION] — сколько времени осталось до истечения SSL-сертификата.

Для проверки PostgreSQL создайте отдельного read-only пользователя, а не используйте боевые учётные данные:

CREATE USER gatus_check WITH PASSWORD 'сложный_пароль';
GRANT CONNECT ON DATABASE postgres TO gatus_check;

Пароли в config.yaml лучше не хранить открытым текстом на боевом сервере — вынесите их в переменные окружения через синтаксис ${VAR}, который Gatus поддерживает, и подставляйте их через systemd EnvironmentFile (см. следующий раздел).

Проверьте синтаксис конфига до запуска сервиса:

sudo -u gatus GATUS_CONFIG_PATH=/etc/gatus/config.yaml /usr/local/bin/gatus &
# смотрим на вывод в консоли, затем Ctrl+C

Если в логе нет ошибок парсинга YAML и видно Now listening on 127.0.0.1:8080 — конфиг рабочий, переходим к systemd.

Systemd-юнит, автозапуск и постоянное хранилище

Создайте файл переменных окружения для секретов отдельно от конфига:

sudo tee /etc/gatus/gatus.env > /dev/null <<'EOF'
PG_CHECK_PASSWORD=сложный_пароль
EOF
sudo chmod 600 /etc/gatus/gatus.env
sudo chown gatus:gatus /etc/gatus/gatus.env

В config.yaml подставьте ${PG_CHECK_PASSWORD} вместо пароля в открытом виде. Теперь юнит:

sudo tee /etc/systemd/system/gatus.service > /dev/null <<'EOF'
[Unit]
Description=Gatus - automated service health dashboard
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=gatus
Group=gatus
EnvironmentFile=/etc/gatus/gatus.env
Environment=GATUS_CONFIG_PATH=/etc/gatus/config.yaml
ExecStart=/usr/local/bin/gatus
WorkingDirectory=/var/lib/gatus
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/var/lib/gatus
PrivateTmp=true

[Install]
WantedBy=multi-user.target
EOF

Запустите и добавьте в автозагрузку:

sudo systemctl daemon-reload
sudo systemctl enable --now gatus
sudo systemctl status gatus

Логи смотрите через sudo journalctl -u gatus -f.

Хранилище sqlite в /var/lib/gatus/data.db сохраняет историю статусов между перезапусками сервиса — без него после каждого рестарта график «аптайма» на статус-странице обнулялся бы. Для нагруженных инсталляций с десятками эндпоинтов Gatus также умеет писать в PostgreSQL — это уместно, если вы уже держите отдельную БД для мониторинга и хотите единое хранилище для нескольких инстансов Gatus.

Публикуем статус-страницу через Nginx и HTTPS

Gatus слушает только localhost — снаружи его закрывает nginx с TLS. Если у вас ещё не настроен reverse proxy на сервере, сначала пройдите установку nginx как reverse proxy, а сертификат для домена статус-страницы проще всего получить через Caddy с авто-SSL — либо вручную через certbot, если reverse proxy уже на nginx.

Конфиг виртуального хоста для nginx (сертификаты — через certbot, домен замените на свой):

server {
    listen 80;
    server_name status.example.com;
    return 301 https://$host$request_uri;
}

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;
    }
}

Если статус-страница должна быть видна только вам и команде, а не всем клиентам — закройте её базовой авторизацией на уровне nginx:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd operator

И добавьте в блок location:

auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;

Публичная статус-страница (без basic auth) обычно нужна, если вы показываете клиентам доступность вашего SaaS или API — Gatus рисует её автоматически из тех же эндпоинтов, отдельно верстать ничего не нужно. Если вы уже сравнивали разные решения для статус-страниц — обзор инструментов мониторинга доступности сайта поможет понять, где Gatus вписывается среди аналогов.

Алерты в Telegram при падении

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

Создайте бота через @BotFather в Telegram, сохраните токен. Затем узнайте свой chat ID — напишите боту любое сообщение и выполните curl -s "https://api.telegram.org/bot<ТОКЕН>/getUpdates" | grep -o '"chat":{"id":[0-9-]*'.

Добавьте в config.yaml секцию alerting и привяжите алерт к нужным эндпоинтам:

alerting:
  telegram:
    token: "${TELEGRAM_BOT_TOKEN}"
    id: "${TELEGRAM_CHAT_ID}"
    default-alert:
      enabled: true
      failure-threshold: 3
      success-threshold: 2
      send-on-resolved: true

endpoints:
  - name: "Сайт"
    url: "https://example.com"
    interval: 30s
    conditions:
      - "[STATUS] == 200"
    alerts:
      - type: telegram

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

Токен и chat ID вынесите в /etc/gatus/gatus.env рядом с паролем от базы — так секреты не окажутся в git, если вы (как и стоит) держите config.yaml под версионным контролем.

Кроме Telegram Gatus поддерживает Slack, Discord, PagerDuty, Opsgenie, email через SMTP и универсальный webhook — если у вас уже есть система дежурств, скорее всего для неё найдётся готовый интеграционный тип, а не только вебхук общего назначения.

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