Сколько RAM нужно для Gatus

MAATRIX

Gatus выбирают за то, что он не просит ни базы данных, ни отдельного фронтенда — весь мониторинг описывается одним YAML-файлом, а статус-страница генерируется автоматически. Но когда доходит до выбора сервера, начинается гадание: production-инструменты вроде Zabbix или Prometheus честно пишут «от 2 ГБ», а по Gatus такой цифры почти нигде нет. Разберёмся, сколько памяти реально нужно бинарнику, от чего зависит рост потребления и какой тариф не станет ни лишним, ни тесным.

Что вообще ест память в Gatus

Gatus — это один Go-бинарник без внешних зависимостей: он сам себе и планировщик, и веб-сервер статус-страницы, и (по желанию) хранилище истории. Память расходуется на четыре вещи:

• Рантайм Go — сборщик мусора и стандартные буферы. Это база, которая присутствует даже при нулевом количестве проверок, и именно она объясняет, почему пустой Gatus всё равно ест не 5 МБ, а заметно больше.
• Конфигурация в памяти — распарсенный YAML со всеми endpoints, условиями (conditions), интервалами и алертами. При сотнях проверок с длинными условиями это уже не копейки.
• Результаты проверок — Gatus по умолчанию хранит в памяти историю последних результатов для отрисовки статус-страницы (полоски uptime, время отклика). Чем больше endpoints и чем длиннее ретеншн истории, тем больше буфер.
• HTTP-клиент на каждую проверку — при HTTP/HTTPS-проверках это TLS-хендшейк, парсинг заголовков и тела ответа (если условие проверяет body). Проверки с regex по большому телу ответа временно поднимают потребление на момент выполнения.

Отдельно стоит хранилище: по умолчанию Gatus держит историю в памяти (in-memory), но можно переключить на SQLite-файл (storage.type: sqlite) — тогда история пишется на диск, а не копится в RAM бесконечно. Для сервера с десятками проверок и длинным ретеншном это меняет картину заметно.

Ориентировочные цифры по количеству проверок

Прежде чем давать числа — важная оговорка: это ориентир по опыту эксплуатации подобных легковесных мониторингов, не результат бенчмарка на конкретной версии Gatus. У вас цифры будут отличаться в зависимости от типов проверок, длины истории и версии бинарника — проверяйте docker stats или systemctl status gatus на своей машине.

Ключевой момент: на сервере с 512 МБ RAM Gatus сам по себе прекрасно живёт даже при 30-50 проверках. Но если это единственное приложение на VPS, память съедает не только Gatus — ещё ОС, systemd, ssh-демон, возможно nginx как reverse proxy перед статус-страницей. Именно поэтому нижняя граница разумного тарифа — 1 ГБ, а не 512 МБ: запас нужен не столько для роста числа проверок, сколько для соседей по памяти.

Как считает память сам Gatus: интервалы и условия

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

Интервал проверки (interval). Чем короче интервал, тем чаще создаются HTTP-клиенты и тем больше конкурентных горутин Go крутится одновременно при большом числе endpoints. Дефолт — 60 секунд, и для 90% сценариев (проверка доступности сайта, API, VPN-эндпоинта) этого достаточно. Ставить 5-10 секунд имеет смысл только для по-настоящему критичных сервисов — и то стоит держать эти проверки в отдельной группе.

Условия (conditions). Простое условие вида:

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

почти не требует памяти сверх базового ответа. А вот условие с regex по телу ответа:

    conditions:
      - "[BODY] == pat(*ok*)"

заставляет Gatus прочитать всё тело ответа в память для каждой проверки. Если это API, отдающий несколько килобайт JSON — не критично. Если по ошибке конфиг проверяет большую HTML-страницу или файл — это регулярный всплеск, который стоит учитывать при выборе тарифа с запасом.

Docker Compose против systemd: разница в оверхеде

Gatus одинаково хорошо работает как в контейнере, так и как systemd-юнит. Разница в оверхеде небольшая, но на серверах с 512 МБ–1 ГБ она заметна.

Docker Compose:

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

volumes:
  gatus-data:

Контейнер добавляет к чистому потреблению Gatus ещё оверхед докер-демона — это общая для всех контейнеров накладная стоимость (обычно порядка 20-40 МБ на сам dockerd и containerd в фоне, плюс изоляция cgroups), которая не растёт линейно с числом контейнеров, но присутствует всегда, если Docker уже установлен на сервере.

systemd-юнит (бинарник без контейнера):

[Unit]
Description=Gatus monitoring
After=network.target

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

[Install]
WantedBy=multi-user.target

Здесь оверхеда практически нет — процесс ест ровно то, что ест сам Gatus. Если на сервере кроме мониторинга ничего не крутится и тариф минимальный (512 МБ – 1 ГБ), systemd-вариант даёт больше запаса. Если на той же машине уже есть Docker ради других сервисов — держать Gatus в общем docker-compose удобнее операционно, разница в памяти не станет решающей.

Хранилище истории: in-memory vs SQLite

По умолчанию Gatus хранит результаты проверок в оперативной памяти, ограничивая их числом (storage.maximum-number-of-results по умолчанию — несколько сотен на endpoint). Это удобно и быстро, но два нюанса стоит знать:

1. При рестарте сервиса вся история uptime обнуляется — статус-страница «забывает» прошлое.
2. При большом числе проверок и высоком лимите результатов in-memory хранилище — это то, что растёт быстрее всего с ростом числа endpoints.

Переключение на SQLite решает оба вопроса:

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

Ценой становится дисковый I/O вместо RAM — для VPS с обычным SSD это не проблема, а для памяти это чистый выигрыш: история переезжает на диск, в RAM остаётся только рабочий кэш последних результатов для рендера страницы. Если планируете держать историю статус-страницы за недели, а не за часы — SQLite обязателен, и тогда даже 1 ГБ тарифа хватит на сотню проверок с запасом.

Типовые конфигурации: сколько проверок реально помещается

Вот три сценария, которые встречаются чаще всего, с расчётом под конкретные тарифы.

Личный проект / небольшая инфраструктура (1 ГБ RAM, 1 vCPU). 10-20 endpoints (сайт, API, пара внутренних сервисов), интервал 60 секунд, in-memory storage, Gatus в Docker вместе с reverse proxy (nginx или Caddy) перед статус-страницей. Итоговая нагрузка — 100-150 МБ суммарно на весь стек, запас больше половины тарифа.

Мониторинг клиентских сайтов агентства (2 ГБ RAM, 2 vCPU). 50-100 endpoints, интервал 30-60 секунд, SQLite-хранилище с ретеншном в несколько недель, уведомления в Telegram/Slack при падении. Здесь уже стоит выделить Gatus отдельный VPS, не совмещая с другими задачами — тогда 2 ГБ дают комфортный запас и на рост числа проверок, и на редкие пики при массовых сбоях у клиентов (когда десятки проверок падают одновременно и генерируют алерты пачкой).

Мониторинг внутренней инфраструктуры компании (2-4 ГБ RAM, 2-4 vCPU). 150-300 endpoints, смешанные HTTP/TCP/DNS/ICMP-проверки, короткие интервалы для критичных сервисов, SQLite с длинным ретеншном, статус-страница за nginx с базовой авторизацией. Здесь запас по CPU становится не менее важным, чем по RAM — при коротких интервалах и сотнях проверок Go-рантайм активнее использует горутины, и слабый vCPU может стать узким местом раньше, чем память.

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