Zabbix vs Prometheus: что выбрать для мониторинга на малом VDS

Для админа малого VDS мониторинг — это не только графики и алерты, но и дисциплина в расходе ресурсов. Ошибка выбора может стоить лишних 300–500 МБ RAM, гигов на диске и часов на поддержание зоопарка компонентов. В этом обзоре разложим по полочкам Zabbix и Prometheus: архитектуру, модель данных, алерты, требования, эксплуатацию и типичные сценарии. Цель — помочь быстро понять, что поставить на скромный виртуальный сервер, где каждая мегабайта и каждое системное прерывание имеют значение.

Коротко про подходы: две философии

Оба инструмента решают задачи мониторинга, но делают это по-разному.

• Zabbix — классическая монолитная платформа «всё в одном»: сервер, агент(ы), встроенные алерты, веб-интерфейс, автообнаружение, SNMP, прокси, инвентаризация. Данные хранятся в СУБД, триггеры описываются выражениями Zabbix, визуализация встроенная.
• Prometheus — модульная экосистема: сам Prometheus (сбор/хранение метрик), экспортёры (node_exporter и др.), язык запросов PromQL, отдельный Alertmanager для маршрутизации алертов. Визуализация чаще через внешние панели, зато метрики богаче по лейблам.

Если вам нужна коробка «всё сразу» с триггерами и интерфейсом — смотрите на Zabbix. Если хотите гибкие метрики и язык запросов, лёгкий старт и низкий оверхед — Prometheus часто проще.

Архитектура и модель сбора

Zabbix

Поддерживает активный и пассивный режим агента, SNMP-пуллинг, сценарии, ловушку событий. История и тренды хранятся в СУБД. Автодискавери умеет находить хосты/сервисы, низкоуровневое обнаружение (LLD) генерирует элементы и триггеры. Хорошо подходит, когда у вас разнородная инфраструктура (вплоть до сетевого железа) и нужны «готовые» шаблоны.

Prometheus

Использует модель pull: периодически опрашивает цели по HTTP и получает метрики в формате time series с лейблами. Экспортёры превращают внутренние метрики сервисов в понятный Prometheus формат. Для одноразовых пушей есть Pushgateway, но базовая философия — pull. Сильная сторона — PromQL, позволяющий агрегировать, резать по лейблам, вычислять скорости и квантильные оценки.

Ресурсы на малом VDS: RAM, CPU, диск, сеть

На VDS с 1–2 vCPU и 1–2 ГБ RAM важно понимать оверхед.

• Zabbix server с БД и веб-интерфейсом обычно потребует несколько сотен мегабайт памяти. При аккуратной настройке PostgreSQL/MySQL, отключении лишних модулей и ограничении истории можно уложиться примерно в 400–800 МБ RAM под нагрузкой малого стенда (1–3 хоста, десятки–сотни элементов). Диск зависит от глубины истории и трендов; ориентир — от сотен мегабайт до нескольких гигабайт на месяц при умеренной детализации.
• Prometheus с node_exporter на одном хосте зачастую укладывается в 150–300 МБ RAM суммарно. Дисковая ретенция хорошо масштабируется: при ~1–2 тыс. временных рядов и интервале опроса 15 s получите ориентировочно 50–150 МБ в сутки, то есть 1.5–3 ГБ за месяц (с учётом индексов и чанков). Это грубая оценка, но показывает порядок.

Правило большого пальца: если хотите минимум движущихся частей и контроль за диском — Prometheus проще ужимается. Если нужны SNMP, готовые шаблоны, инвентаризация, сложные эскалации — Zabbix даст больше из коробки, но потребует больше RAM/диска.

Метрики и язык запросов

Zabbix: элементы, ключи и триггеры

В Zabbix всё строится вокруг элементов данных (items) и триггеров. Много готовых ключей для агента, есть SNMP OID, сценарии проверки сервисов. Триггеры — логические выражения над историями. Пороговая логика понятна, но когда хочется продвинутой агрегации по лейблам и динамической группировке — становится сложнее.

Prometheus: лейблы и PromQL

Prometheus мыслит метриками с лейблами. Это даёт: динамическую группировку по ролям, окружениям, зонам; вычисление квантилей, скоростей, скользящих средних; сложные селекторы. Для разработчиков и DevOps это часто удобнее, особенно в контейнерных сценариях.

Алерты и маршрутизация

Zabbix

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

Prometheus + Alertmanager

Правила алертов описываются отдельно от сбора метрик, а маршрутизацию, шаблоны уведомлений, подавления и «тихие периоды» ведёт Alertmanager. Сильная сторона — декларативность: чёткие маршруты по лейблам (environment, service, severity), подавления по зависимостям, гибкие шаблоны сообщений. Для малого VDS достаточно пары файлов конфигурации. Подробнее про маршрутизацию и тишину читайте: маршрутизация, тишина и шаблоны Alertmanager.

Визуализация

• Zabbix: встроенные экраны, дашборды, карты зависимостей. Для базового кейса хватит без внешних компонентов.
• Prometheus: встроенный UI минималистичен, реальная визуализация обычно выносится во внешние панели. Это плюс по модульности, но минус по дополнительному сервису, если RAM на VDS совсем мало.

Автообнаружение и инвентаризация

• Zabbix умеет сетевое и низкоуровневое обнаружение (LLD): автоматически создаёт элементы и триггеры для файловых систем, сетевых интерфейсов, процессов. Есть инвентарные поля, отчёты, карты.
• Prometheus полагается на discovery через статический список, файловое SD, DNS SD и лейблы. Для малого VDS чаще достаточно статических таргетов; для динамики контейнеров — автоматизация читабельнее, но сам учёт оборудования — не задача Prometheus.

Хранение и ретенция

На маленьком диске важна ретенция.

• Prometheus: задаёте флаг ретенции (например, 15–30 дней) и каталог хранения. Просто и предсказуемо. Архивация — вручную или через удалённую отправку (remote_write) в долгоживущие хранилища, если понадобится.
• Zabbix: раздельная история и тренды. История детальная (секунды/минуты), тренды агрегированные (часы/дни). Можно тонко настраивать глубину хранения по типам метрик. Диск растёт за счёт СУБД; бэкап — штатными средствами СУБД.

Установка и эксплуатация на малом VDS

Типовой путь для минималистичного стенда (на отдельном небольшом VDS):

• Prometheus: поставить бинарник и node_exporter, создать конфиг, добавить systemd unit. Отдельно поднять Alertmanager. Получится 2–3 сервиса и один каталог данных.
• Zabbix: сервер, агент, БД (PostgreSQL/MySQL), веб-интерфейс. Чуть больше компонентов, зато всё «под одной крышей».

Минимальные примеры конфигураций (для ориентира).

Prometheus: базовый сбор с локального хоста

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['127.0.0.1:9100']

Alertmanager: простая маршрутизация

route:
  receiver: 'default'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h

receivers:
  - name: 'default'
    # Добавьте нужный медиа-канал

Пример правила алерта (Prometheus)

groups:
- name: vds.rules
  rules:
  - alert: HighLoad
    expr: avg_over_time(node_load1[5m]) > on() count without(cpu) (node_cpu_seconds_total{mode="idle"})
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: Высокая нагрузка на CPU
      description: Средняя загрузка за 5 минут превысила число vCPU

Zabbix agent: базовый конфиг

Server=127.0.0.1
ServerActive=127.0.0.1
Hostname=local-vds
Include=/etc/zabbix/zabbix_agentd.d/*.conf

А триггер для классической проверки HTTP в Zabbix можно описать на основе готового ключа проверки TCP/HTTP из шаблонов. Логика порога проста: если сервис недоступен X минут — шлём уведомление и эскалируем.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Безопасность и сеть

• Не экспонируйте служебные порты наружу. Prometheus слушает 9090, node_exporter 9100; Zabbix agent — 10050, сервер — 10051. Разрешайте доступ только из доверенных источников через файрвол.
• Закройте доступ ко всем интерфейсам мониторинга по умолчанию и проксируйте через веб-сервер с аутентификацией и защищённым протоколом и используйте SSL-сертификаты.
• Регулярно обновляйте компоненты и минимизируйте права служб. Для экспортёров достаточно непривилегированных пользователей и read-only доступов там, где это возможно.

Что лучше на малом VDS: разбор сценариев

Один сервер, базовые метрики, минимум оверхеда

Prometheus + node_exporter + Alertmanager. Простой деплой, малый footprint, гибкие алерты. Отлично, если цель — видеть CPU, RAM, диск, сеть, и иметь пару правил уведомлений.

Несколько серверов и сетевое железо, SNMP, готовые шаблоны

Zabbix. Быстрый старт с шаблонами для Linux, сетевого оборудования, сервисов; встроенные триггеры и эскалации. Придётся выделить больше RAM/диска под СУБД и сервер.

Микросервисы, контейнеры, богатые лейблы

Prometheus. Лейблы — ключ к гибкой агрегации по сервисам/версиям/окружениям, минимум ручной работы по описанию порогов, много готовых экспортёров.

Инвентаризация и карты зависимостей

Zabbix. Из коробки даёт инвентарь, карту, автообнаружение, отчёты. Для небольшой инфраструктуры — удобно.

Оценка и планирование ресурсов

• Prometheus: при 1000–2000 временных рядов и интервале 15 s заложите 50–150 МБ/сутки на данные, 150–300 МБ RAM на процесс и буферы. Ретенция 15–30 дней на диске 2–5 ГБ — реалистично.
• Zabbix: на малом стенде планируйте 400–800 МБ RAM под сервер + СУБД + фронт, и 1–5 ГБ диска на месяц истории (зависит от количества элементов, частоты опроса и политики трендов). Сокращайте глубину хранения и частоту там, где это не критично.

Если выбираете конфигурацию сервера под мониторинг, пригодится краткий путеводитель: как выбрать тариф VDS по CPU и RAM.

Эксплуатация и поддержка

• Backup/restore: у Prometheus достаточно бэкапить каталог данных при остановленном процессе или использовать снапшоты. У Zabbix бэкапите СУБД штатными инструментами, отдельно — конфиги и импорт шаблонов.
• Обновления: держите процессы в последних стабильных минорных версиях. На VDS протестируйте обновления на копии, чтобы не словить миграции схемы в неудобный момент.
• Набор метрик: не включайте всё подряд. На маленьком диске каждая новая метрика — это постоянный расход. Начните с системных, добавляйте сервисные точечно.

Антипаттерны на малом VDS

• Ставить все компоненты сразу «на всякий случай». Лишние экспортёры и десятки дашбордов съедят диск и RAM, а толку не добавят.
• Ретенция «на год вперёд». Для оперативного мониторинга 15–30 дней часто достаточно; остальное — в агрегированные тренды или во внешнее хранилище.
• Писать алерты только по абсолютным порогам. Добавляйте временные окна и относительные условия, чтобы снизить шум.

Итог

И Zabbix, и Prometheus отлично решают задачу мониторинга, но при ограниченных ресурсах малого VDS важнее всего простота и предсказуемость. Если вы хотите быстро получить метрики и алерты при минимальной нагрузке — Prometheus обычно выигрывает: поставить, настроить пару файлов, и готово. Если же нужны из коробки шаблоны, SNMP, встроенная инвентаризация и богатая событийная модель — Zabbix оправдывает себя ценой большего потребления ресурсов. Оцените свои приоритеты: какие метрики важны, сколько места есть на диске, как часто вы готовы менять конфиги — и выбирайте инструмент, который проще поддерживать именно вам. Это и будет лучшим решением для мониторинга на малом VDS.