Два разных подхода к одной задаче

Zabbix и связка Prometheus + Grafana + Alertmanager решают одну и ту же задачу — сбор метрик и алертинг — но исходят из противоположных архитектурных философий. Путаница в выборе обычно происходит именно потому, что это не конкурирующие продукты одного класса, а два разных подхода к мониторингу.

Zabbix — цельная, самодостаточная платформа. Сервер, СУБД, веб-интерфейс, система алертинга и агенты — всё в одном продукте, заточенном под традиционную инфраструктуру: стойки серверов, коммутаторы, IPMI-контроллеры, разнородный сетевой парк.

Prometheus-стек — набор специализированных инструментов. Prometheus собирает метрики и хранит их во встроенной time-series базе, Grafana рисует дашборды, Alertmanager занимается маршрутизацией алертов. Изначально спроектирован под динамическую, контейнеризированную инфраструктуру — Kubernetes и микросервисы.

Архитектурные различия

Zabbix работает по модели клиент-сервер: центральный сервер опрашивает агентов (или принимает от них данные), обрабатывает триггеры, пишет всё в реляционную БД (PostgreSQL, MySQL, Oracle, IBM DB2 или SQLite). Zabbix-прокси позволяют распределить сбор данных по нескольким локациям, но архитектурно это всё равно одна центральная база — просто с буферизацией на местах.

Prometheus работает по pull-модели: сам ходит по HTTP-эндпоинтам (экспортёрам) и забирает метрики по расписанию. Хранит данные во встроенной TSDB, но только 15 дней по умолчанию — для более длительного хранения нужны Thanos, Cortex или Mimir, каждый со своей архитектурой (сайдкары, object storage, компакторы). Визуализация и алертинг — отдельные компоненты (Grafana, Alertmanager).

Модульность Prometheus — это одновременно и сила, и цена: можно взять ровно те компоненты, что нужны, но каждый из них разворачивается, настраивается и обслуживается отдельно.

Где выигрывает каждый

Zabbix сильнее в: - SNMP-мониторинге и сетевом оборудовании — сотни готовых шаблонов под конкретных вендоров - Гетерогенной инфраструктуре: серверы, свитчи, IPMI, принтеры, ИБП — всё через единый интерфейс - Готовом решении "из коробки" — не нужно собирать стек из нескольких продуктов - Встроенной эскалации оповещений с гибкими правилами (кому, когда, как долго ждать реакции)

Prometheus + Grafana + Alertmanager сильнее в: - Kubernetes и микросервисах — service discovery из коробки находит новые поды и сервисы автоматически - PromQL — мощный язык запросов для агрегации и анализа временных рядов - Гибкости визуализации — Grafana де-факто отраслевой стандарт дашбордов, подключается не только к Prometheus, но и к Elasticsearch, Loki, CloudWatch и десяткам других источников - Экосистеме — огромное количество готовых экспортёров под что угодно (базы данных, очереди, кэши, сами приложения через client-библиотеки)

Версии 2026 года — что изменилось

Zabbix 7.x заметно прокачал историю с высокой доступностью (HA) — раньше это было слабым местом по сравнению с распределённой природой Prometheus.

Prometheus 3.x добавил нативную поддержку OpenTelemetry — раньше для интеграции с OTel-экосистемой нужны были дополнительные конвертеры, теперь Prometheus принимает OTLP-метрики напрямую.

Оба продукта в 2026 году активно развиваются, так что выбор — это по-прежнему вопрос архитектурного соответствия задаче, а не того, какой проект "жив", а какой умирает.

Сравнение по практическим параметрам

Параметр Zabbix 7.x Prometheus 3.x + Grafana + Alertmanager
Модель сбора данных Push/pull (агент или SNMP-polling) Pull (scrape по HTTP)
Хранилище Реляционная БД (PostgreSQL/MySQL/др.) Встроенная TSDB, 15 дней по умолчанию
Долгосрочное хранение Встроено (настройки trends) Нужны Thanos/Cortex/Mimir отдельно
Визуализация Встроенный веб-интерфейс, карты сети Grafana — гибче, но отдельный компонент
Алертинг Встроенный, с эскалациями Alertmanager — маршрутизация, группировка, silence
Лучше всего для Сети, SNMP, статичная инфраструктура Kubernetes, микросервисы, динамичная инфра
Установка Один продукт, но требует БД Модульно: 3+ отдельных сервиса
Лицензия GPL Apache 2.0 (Prometheus), AGPLv3 (Grafana)

Практический пример — минимальный Prometheus-стек

# docker-compose.yml
services:
  prometheus:
    image: prom/prometheus:v3.0.0
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
    ports:
      - "9090:9090"

  alertmanager:
    image: prom/alertmanager:latest
    container_name: alertmanager
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: "смени-меня"

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    ports:
      - "9100:9100"

volumes:
  prometheus-data:
  grafana-data:

Минимальный prometheus.yml:

global:
  scrape_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

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

После запуска: Prometheus на порту 9090, Alertmanager на 9093, Grafana на 3000 — там нужно добавить Prometheus как data source и либо собрать дашборд руками, либо импортировать готовый (например, "Node Exporter Full", id 1860 на grafana.com).

Гибридный вариант

Некоторые команды используют Zabbix как источник данных для Grafana — Zabbix отвечает за сбор и хранение, Grafana даёт более гибкую визуализацию поверх. Это разумный компромисс, если инфраструктура уже на Zabbix, но команде не хватает гибкости встроенных дашбордов.

Что выбрать

Zabbix стоит взять, если: - Инфраструктура преимущественно статична: серверы, сеть, редко меняющийся состав хостов - Нужен явный SNMP-мониторинг сетевого оборудования - Важно получить готовое решение без сборки стека из нескольких продуктов - В команде нет отдельного человека, который будет поддерживать Prometheus+Grafana+Alertmanager как три независимых сервиса

Prometheus-стек стоит взять, если: - Инфраструктура — Kubernetes или активно скейлящиеся контейнеры - Команда готова писать PromQL и YAML-конфиги - Нужна гибкая визуализация с множеством источников данных, не только метрик с серверов - Есть ресурс поддерживать несколько компонентов вместо одного

Итог

Это не вопрос "что лучше" — это вопрос соответствия архитектуре. Zabbix проектировался для мира стоек и коммутаторов, Prometheus — для мира подов и сервисов. Если инфраструктура смешанная (что бывает часто: часть на голом железе, часть в Kubernetes), не редкость и комбинация обоих — Zabbix для сетевого оборудования и легаси-серверов, Prometheus-стек для контейнеризированной части.