В 2026 году развернуть эффективную систему мониторинга для Linux-инфраструктуры в продакшене можно двумя основными путями: используя готовую платформу Zabbix или собрав модульный стек Prometheus + Grafana. Оба решения — мощные open-source инструменты, но их архитектура и философия принципиально различаются, что напряменно влияет на выбор для конкретной задачи. Zabbix предлагает централизованное управление «из коробки», в то время как Prometheus с Grafana дают максимальную гибкость за счет сборки из независимых компонентов.
Это руководство предоставит вам объективное сравнение по ключевым критериям для продакшена и две детальные, проверенные инструкции по установке. Вы сможете быстро запустить сбор критических метрик (CPU, память, диск, сеть), создать наглядные дашборды и настроить алертирование, выбрав решение, которое лучше соответствует архитектуре вашей инфраструктуры и ресурсам команды.
Zabbix или Prometheus + Grafana: объективное сравнение для принятия решения в 2026
Выбор между Zabbix и Prometheus с Grafana — это выбор между двумя разными философиями построения мониторинга. Чтобы принять обоснованное решение, сравним их по ключевым для продакшена критериям: архитектуре, сложности настройки и поддержки, гибкости и масштабируемости.
Архитектура и философия: централизованное управление против модульной гибкости
Архитектурное различие — фундаментально. Zabbix — это классическая монолитная система, построенная по модели «сервер — агенты/прокси — база данных». Сервер Zabbix является единой точкой управления: он опрашивает агентов, установленных на хостах, или собирает данные без агентов через SNMP, ICMP, HTTP. Веб-интерфейс, логика алертинга и хранение данных тесно интегрированы. Это обеспечивает быстрое развертывание готовой системы, но делает кастомизацию отдельных компонентов более сложной.
Prometheus, в свою очередь, работает по модели pull (вытягивания). Автономный сервер Prometheus периодически «скрабирует» (запрашивает) метрики у так называемых экспортеров, например, Node Exporter для метрик ОС. Grafana выступает отдельным, независимым инструментом визуализации, который подключается к Prometheus как к источнику данных. Alertmanager — еще один отдельный компонент для обработки и маршрутизации алертов.
Что выбрать? Zabbix отлично подходит для классической, гетерогенной инфраструктуры с сетевым оборудованием, где важна единая точка управления и готовые шаблоны. Стек Prometheus + Grafana стал де-факто стандартом для мониторинга микросервисных архитектур и Kubernetes, где важны гибкость, мощный язык запросов PromQL и возможность легко интегрировать кастомные экспортеры.
Сложность настройки и поддержки: первоначальные и долгосрочные затраты
Оценка трудозатрат — критический фактор.
Начальная настройка: Zabbix позволяет быстрее получить работающую систему. После установки сервера, базы данных и веб-интерфейса вы сразу получаете доступ к библиотеке готовых шаблонов для мониторинга Linux, сетевых устройств и популярных сервисов. Добавление нового хоста часто сводится к установке агента и привязке шаблона в веб-интерфейсе.
Для Prometheus + Grafana потребуется больше ручных шагов: отдельная установка и настройка Prometheus, Node Exporter на каждом хосте, Grafana, а затем их связывание через конфигурационные файлы (prometheus.yml). Создание эффективных алертов требует понимания PromQL.
Долгосрочная поддержка и масштабирование: Zabbix проще администрировать на начальном и среднем масштабе благодаря централизованному веб-интерфейсу. Для масштабирования на сотни/тысячи хостов потребуется настройка прокси-серверов Zabbix для распределения нагрузки. Архитектура Prometheus изначально горизонтально масштабируема (несколько независимых серверов), но для глобального представления данных потребуются дополнительные инструменты, такие как Thanos или Cortex.
Итог для выбора: Если вам нужна «работающая из коробки» система с минимумом ручной сборки и ваша команда знакома с классическими системами мониторинга — выбирайте Zabbix. Если ваша инфраструктура динамична (контейнеры, микросервисы), а команда готова инвестировать время в изучение и тонкую настройку модульного стека для максимального контроля — ваш выбор Prometheus + Grafana. Для глубокого понимания метрик и их анализа рекомендуем ознакомиться с нашим руководством по ключевым метрикам производительности Linux.
Типичные сценарии мониторинга в 2026: контейнеры, Kubernetes, гибридные облака
Выбор инструмента часто зависит от конкретной задачи. Вот практические рекомендации для распространенных сценариев 2026 года:
Мониторинг микросервисов и Kubernetes: Prometheus + Grafana — бесспорный лидер. Встроенная интеграция с Kubernetes через Service Discovery, мощный PromQL для агрегации метрик подов и нод, а также богатая экосистема экспортеров (cAdvisor, kube-state-metrics) делают этот стек оптимальным для observability в контейнерных средах.
Мониторинг классической инфраструктуры и сетевого оборудования: Zabbix с его готовыми шаблонами для SNMP и централизованным управлением часто выигрывает по скорости внедрения. Единый интерфейс для серверов, коммутаторов и принтеров упрощает жизнь системному администратору.
Гибридные и мультиоблачные среды: Оба решения могут работать, но подходы разные. Prometheus легче масштабировать на несколько независимых кластеров (по прометею на кластер/облако) с последующей федерацией или использованием Thanos для глобальных запросов. Zabbix потребует настройки прокси в каждом сегменте сети для сбора данных и их передачи на центральный сервер.
High availability мониторинг: Для самого стека мониторинга критически важна отказоустойчивость. Prometheus проще развернуть в нескольких экземплярах, собирающих одни и те же цели. Для Zabbix потребуется настройка резервного сервера в режиме standby или кластеризация.
Пошаговая установка и базовая настройка Zabbix для мониторинга Linux-сервера
Предполагаем, что вы используете Ubuntu 24.04 LTS или Rocky Linux 9. Все команды актуальны на апрель 2026 года.
Установка сервера Zabbix и веб-интерфейса
1. Установите репозиторий Zabbix и необходимые пакеты (на примере Ubuntu):
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-1+ubuntu24.04_all.deb
dpkg -i zabbix-release_7.0-1+ubuntu24.04_all.deb
apt update
2. Установите сервер Zabbix, фронтенд и агент, используя PostgreSQL в качестве БД:
apt install -y zabbix-server-pgsql zabbix-frontend-php php8.3-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-agent2
3. Создайте базу данных и пользователя, затем импортируйте начальную схему:
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix
4. Настройте подключение к БД в файле /etc/zabbix/zabbix_server.conf:
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=your_secure_password_here
5. Запустите сервисы и настройте автозагрузку:
systemctl restart zabbix-server zabbix-agent2 nginx php8.3-fpm
systemctl enable zabbix-server zabbix-agent2 nginx php8.3-fpm
6. Откройте веб-браузер и перейдите по адресу http://ваш_сервер/zabbix. Следуйте мастеру начальной настройки веб-интерфейса.
Настройка мониторинга первого хоста: CPU, память, диск, сеть
1. В веб-интерфейсе Zabbix перейдите в Configuration → Hosts и нажмите Create host.
2. Заполните основные параметры: имя хоста, видимое имя и добавьте его в группу (например, «Linux servers»).
3. На вкладке Interfaces добавьте интерфейс типа «Agent» и укажите IP-адрес целевого хоста и порт агента (по умолчанию 10050).
4. На вкладке Templates найдите и свяжите шаблон Template OS Linux by Zabbix agent. Этот шаблон автоматически начнет сбор ключевых метрик: загрузку CPU, использование оперативной и swap-памяти, свободное место на разделах диска, сетевой трафик по интерфейсам, количество запущенных процессов и другую системную телеметрию.
5. Нажмите Add. Через несколько минут перейдите в Monitoring → Latest data, отфильтруйте по имени вашего хоста. Вы увидите список собираемых метрик и их текущие значения. Если данные не появляются, проверьте, что на целевом хосте запущен и настроен Zabbix Agent2, а брандмауэр разрешает соединения на порт 10050.
Развертывание стека мониторинга Prometheus, Node Exporter и Grafana с нуля
Инструкция для Ubuntu 24.04 LTS / Rocky Linux 9. Будем разворачивать компоненты на одном сервере для простоты.
Настройка Prometheus и добавление цели для Node Exporter
1. Установите Prometheus:
wget https://github.com/prometheus/prometheus/releases/download/v2.52.0/prometheus-2.52.0.linux-amd64.tar.gz
tar xvf prometheus-2.52.0.linux-amd64.tar.gz
sudo mv prometheus-2.52.0.linux-amd64 /usr/local/bin/prometheus
sudo useradd --no-create-home --shell /bin/false prometheus
sudo mkdir /etc/prometheus /var/lib/prometheus
2. Создайте основной конфигурационный файл /etc/prometheus/prometheus.yml с учетом best practices 2026 (безопасность, тюнинг):
global:
scrape_interval: 15s
evaluation_interval: 15s
# Настройки безопасности: ограничение одновременных соединений
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
scrape_timeout: 10s
- job_name: 'node_exporter'
static_configs:
- targets: ['localhost:9100']
scrape_timeout: 10s
# Добавление меток для обогащения данных
relabel_configs:
- source_labels: [__address__]
target_label: instance
regex: '([^:]+)(:\d+)?'
replacement: '$1'
3. Установите и запустите Node Exporter для сбора метрик ОС:
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar xvf node_exporter-1.8.0.linux-amd64.tar.gz
sudo mv node_exporter-1.8.0.linux-amd64/node_exporter /usr/local/bin/
sudo useradd --no-create-home --shell /bin/false node_exporter
sudo systemctl enable --now node_exporter
4. Запустите Prometheus и откройте веб-интерфейс по адресу http://ваш_сервер:9090. Перейдите на вкладку Status → Targets. Вы должны увидеть состояние целей (targets) prometheus и node_exporter как UP.
Визуализация метрик: импорт дашборда в Grafana и создание своего
1. Установите Grafana:
sudo apt-get install -y software-properties-common
sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
sudo apt-get update
sudo apt-get install -y grafana
sudo systemctl enable --now grafana-server
2. Откройте веб-интерфейс Grafana по адресу http://ваш_сервер:3000 (логин/пароль по умолчанию: admin/admin).
3. Добавьте источник данных: Configuration → Data sources → Add data source. Выберите Prometheus. В поле URL укажите http://localhost:9090 и нажмите Save & Test.
4. Импортируйте готовый дашборд. Перейдите в Dashboards → Import. В поле Import via grafana.com введите ID 1860 (популярный дашборд «Node Exporter Full»). Выберите источник данных Prometheus и нажмите Import.
Теперь у вас есть комплексный дашборд с графиками по CPU, памяти, дисковому вводу-выводу, сетевому трафику, загрузке системы и другим метрикам. Для создания собственной панели нажмите Add → Visualization, выберите источник данных Prometheus и используйте PromQL для запроса метрик, например: rate(node_cpu_seconds_total{mode="system"}[5m]) для загрузки CPU в системном режиме.
Настройка алертинга: от простых уведомлений до отказоустойчивой конфигурации
Система мониторинга без алертов — просто архив данных. Настроим оповещения в обеих системах, начав с самых востребованных сценариев.
Алерты в Zabbix: триггеры, действия и интеграция с Telegram
1. Создайте триггер. Перейдите в Configuration → Hosts, выберите ваш хост и перейдите на вкладку Triggers → Create trigger.
• Name: «High CPU load on {HOST.NAME}»
• Expression: {Template OS Linux by Zabbix agent:system.cpu.util[,system].avg(5m)}>90
Это выражение сработает, если средняя за 5 минут загрузка CPU в системном режиме превысит 90%.
2. Настройте способ оповещения (медиа-тип). Перейдите в Administration → Media types → Create media type.
• Name: «Telegram»
• Type: Webhook
• В поле Script укажите скрипт, который будет отправлять сообщение через API Telegram-бота. (Для экономии места приведем концепцию: вам потребуется создать бота через @BotFather, получить его токен и chat ID, затем написать скрипт, использующий curl для вызова https://api.telegram.org/bot{token}/sendMessage).
3. Создайте действие. Перейдите в Configuration → Actions, выберите тип «Trigger action» → Create action.
• Настройте условие, при котором действие выполняется (например, для созданного триггера).
• На вкладке Operations добавьте операцию: отправку сообщения созданному пользователю (или группе) через медиа-тип «Telegram».
Alertmanager для Prometheus: правила алертов и маршрутизация
1. Установите и настройте Alertmanager (отдельный компонент).
2. Создайте файл правил алертов для Prometheus, например, /etc/prometheus/rules/node_alerts.yml. Расширим его готовыми правилами для критических метрик 2026:
groups:
- name: node_alerts
rules:
- alert: HighMemoryUsage
expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85
for: 5m
labels:
severity: warning
annotations:
summary: "High memory usage on {{ $labels.instance }}"
description: "Memory usage is above 85% (current value: {{ $value }}%)"
- alert: HighCPUSteal
expr: rate(node_cpu_seconds_total{mode="steal"}[5m]) * 100 > 10
for: 2m
labels:
severity: warning
annotations:
summary: "High CPU steal time on {{ $labels.instance }}"
description: "CPU steal time is above 10% (current: {{ $value }}%). Возможна конкуренция за ресурсы на виртуальном хосте."
- alert: HighDiskIOLatency
expr: rate(node_disk_read_time_seconds_total[5m]) + rate(node_disk_write_time_seconds_total[5m]) > 0.1
for: 3m
labels:
severity: warning
annotations:
summary: "High disk I/O latency on {{ $labels.instance }}"
description: "Суммарная задержка дискового ввода-вывода превышает 100ms."
- alert: NodeOOMKillDetected
expr: increase(node_vmstat_oom_kill[5m]) > 0
labels:
severity: critical
annotations:
summary: "OOM Killer was invoked on {{ $labels.instance }}"
description: "OOM Killer завершил процессы из-за нехватки памяти за последние 5 минут."
- alert: ServiceDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Service {{ $labels.job }} on {{ $labels.instance }} is down"
description: "Цель мониторинга недоступна более 1 минуты."
3. Укажите путь к правилам в prometheus.yml в секции rule_files и перезагрузите конфигурацию Prometheus.
4. Настройте alertmanager.yml для маршрутизации алертов, например, в Slack или email. Alertmanager позволяет группировать алерты по меткам, подавлять уведомления и настраивать повторные отправки. Перед настройкой сложных алертов полезно провести нагрузочное тестирование сервисов, чтобы понимать их нормальное поведение. Методики описаны в нашем руководстве по нагрузочному тестированию серверов.
Как настроить алерты на аномалии?
Помимо пороговых алертов, в 2026 году актуально отслеживание аномалий. В Prometheus для этого можно использовать функции прогнозирования. Пример правила, которое срабатывает, если текущее использование памяти выходит за пределы прогнозируемого диапазона на основе данных за неделю:
- alert: MemoryUsageAnomaly
expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > predict_linear(node_memory_MemAvailable_bytes[1w], 3600) * 1.5
for: 10m
labels:
severity: warning
annotations:
summary: "Anomalous memory usage on {{ $labels.instance }}"
В Zabbix для обнаружения аномалий можно использовать триггерные функции band() (проверка на вхождение в диапазон) или настроить триггер, сравнивающий текущее значение со средним за аналогичный период прошлой недели.
Дальнейшее развитие: масштабирование, кастомные метрики и поддержка в 2026
После успешного запуска базового мониторинга встают вопросы развития системы.
Как добавить мониторинг специфичного оборудования или приложения
Сила обеих систем — в расширяемости.
Для Prometheus используется концепция экспортеров. Например, для мониторинга GPU NVIDIA установите nvidia_gpu_exporter. Для мониторинга кастомного приложения нужно, чтобы оно отдавало метрики в формате Prometheus (обычно по HTTP на путь /metrics). Если приложение этого не умеет, можно написать простой экспортер на Python с использованием библиотеки prometheus_client.
Для Zabbix используйте UserParameter в конфигурации агента (/etc/zabbix/zabbix_agent2.d/*.conf). Он позволяет определить ключ и команду, результат выполнения которой Zabbix будет собирать как метрику. Например:
UserParameter=app.queue.size, /usr/local/bin/check_queue.sh
Для мониторинга состояния сложных распределенных приложений, например, работающих в Kubernetes, принципы остаются теми же, но добавляется специфика оркестратора. Подробнее о подходах к мониторингу в Kubernetes можно узнать из нашего материала о полном цикле создания системы мониторинга.
Масштабирование: Zabbix масштабируется через прокси-серверы, которые берут на себя сбор данных с группы хостов и передают их на основной сервер. Prometheus масштабируется горизонтально — запуском независимых экземпляров для разных сегментов инфраструктуры. Для глобального запроса к данным с нескольких прометеев используются федерация или надстройки вроде Thanos.
Мониторинг состояния самих систем мониторинга (самомониторинг)
Система мониторинга сама является критической инфраструктурой. Обязательно настройте для нее базовый мониторинг.
Для Zabbix: Используйте встроенный шаблон Template App Zabbix Server для мониторинга нагрузки, очереди и работоспособности самого сервера Zabbix. Также отслеживайте свободное место в базе данных и доступность веб-интерфейса.
Для Prometheus: Prometheus по умолчанию экспортирует свои метрики. Отслеживайте метрики prometheus_tsdb_head_samples_appended_total (темп приема образцов), prometheus_target_interval_length_seconds (реальная частота опроса целей) и process_resident_memory_bytes (потребление памяти). Для Grafana следите за метриками grafana_alerting_active_alerts и доступностью веб-интерфейса.
Миграция с Zabbix на Prometheus: пошаговый план и подводные камни
Если вы решили перейти с Zabbix на стек Prometheus, следуйте плану:
1. Параллельный запуск. Разверните Prometheus + Grafana параллельно с существующим Zabbix. Начните с мониторинга тех же ключевых метрик (CPU, память, диск).
2. Перенос критических алертов. Определите 5-10 самых важных алертов в Zabbix и воссоздайте их в Prometheus с помощью PromQL. Проверьте, что они срабатывают на одних и тех же событиях.
3. Обучение команды. Команда должна освоить PromQL и принципы работы Alertmanager. Это ключевое изменение по сравнению с триггерами Zabbix.
4. Перенос дашбордов. Воссоздайте ключевые дашборды в Grafana. Используйте импорт готовых или создавайте с нуля.
5. Поэтапное отключение. После уверенности в работе нового стека начните поэтапно отключать мониторинг сервисов в Zabbix, перенося их в Prometheus. Начните с наименее критичных.
Основные подводные камни: Разная философия сбора данных (pull vs push/query), необходимость переписывания всех кастомных проверок (UserParameters) в экспортеры, иная модель хранения данных (временные ряды в Prometheus vs реляционная БД в Zabbix).
Поддержка в 2026: Регулярно обновляйте компоненты для получения исправлений уязвимостей и новых функций. Настройте резервное копирование критических конфигураций: файлов prometheus.yml, правил алертов, дашбордов Grafana (их можно экспортировать в JSON), а также базы данных Zabbix. Продумайте схему высокой доступности для стека мониторинга, если это необходимо для вашего продакшена.