Для 300 устройств Zabbix или Prometheus выбирает состав парка

Выбор здесь определяет не число 300, а состав этих 300 устройств и способ работы команды. Если в парке много коммутаторов, маршрутизаторов, ИБП, принтеров и обычных серверов, Zabbix почти всегда запускается быстрее и требует меньше ручной сборки. Если основная нагрузка живет в сервисах, контейнерах и приложениях, которые уже отдают метрики, Prometheus дает более сильный язык запросов и естественнее вписывается в работу через Git.

Я бы не принимал решение по красивому демонстрационному экрану. Оба продукта легко показывают загрузку процессора и доступность узла. Разница обнаруживается позже: когда нужно добавить неизвестную модель коммутатора, убрать лавину сообщений после отказа ядра сети, понять рост хранилища и передать дежурство администратору, который не писал PromQL.

Триста устройств не определяют нагрузку

Само число устройств почти ничего не говорит о размере системы мониторинга. Один сервер с агентом может давать сотню полезных показателей, а коммутатор с сотнями портов после обнаружения интерфейсов создаст гораздо больше элементов или временных рядов. Важны число собираемых показателей, интервал опроса, количество меток, срок хранения и доля недоступных целей, на которых опрос ждет тайм-аута.

Перед выбором разделите парк хотя бы на четыре группы: сетевое оборудование по SNMP, серверные операционные системы, инфраструктурные службы вроде баз данных и гипервизоров, приложения с собственными метриками. Затем для каждой группы запишите способ доступа и владельца. Такая таблица полезнее требования «поддерживать 300 устройств», потому что сразу показывает объем нестандартной работы.

Для SNMP посчитайте не только корпуса, но и обнаруживаемые сущности: физические порты, VLAN, блоки питания, датчики, точки доступа. Не включайте все таблицы MIB только потому, что они доступны. Опрос административно выключенных портов и временных интерфейсов увеличивает хранилище и создает события, которые никто не разбирает. В рекомендациях по шаблонам Zabbix прямо советует применять низкоуровневое обнаружение и фильтровать ненужные сущности. Генератор snmp_exporter тоже поддерживает статические и динамические фильтры индексов. В обоих случаях экономия начинается с модели данных, а не с добавления процессора системе мониторинга.

Для серверов определите, нужны ли только базовые CPU, память, диски и доступность или еще службы, журналы, аппаратные датчики, состояние RAID и прикладные проверки. Prometheus считает каждый уникальный набор меток отдельным временным рядом. Неограниченная метка с идентификатором запроса или пользователя способна создать больше нагрузки, чем весь остальной парк. В Zabbix похожая ошибка возникает, когда низкоуровневое обнаружение создает тысячи элементов и триггеров из изменчивого списка.

Практический расчет начинайте с потока новых значений. Умножьте активные элементы или ряды на частоту сбора, затем проверьте срок хранения и запас диска на пилоте. Теоретический расчет нужен для первого размера виртуальной машины, но фактическое потребление определят шаблоны, метки и изменчивость данных. Сравнивать продукты на пустой установке бессмысленно.

Смешанный парк быстрее заводится в Zabbix

Zabbix удобнее там, где один администратор должен видеть сетевое оборудование и серверы в общей модели хостов. SNMP, ICMP, агентские проверки, IPMI, веб-проверки и многие готовые шаблоны находятся внутри одного продукта. Хост получает интерфейс, к нему привязывают шаблон, а низкоуровневое обнаружение создает элементы, триггеры и графики для найденных портов или файловых систем.

Официальная документация Zabbix по SNMP предлагает готовые шаблоны и предупреждает проверять совместимость с конкретным устройством. Это важная оговорка. Название производителя на шаблоне не гарантирует совпадение OID, индексов и состояний между линейками и версиями прошивки. Я всегда проверяю один экземпляр модели командой snmpwalk, смотрю фактические ответы и только после этого массово привязываю шаблон.

snmpwalk -v3 -l authPriv -u monitor -a SHA256 -A 'AUTH_PASS' \
  -x AES -X 'PRIV_PASS' 192.0.2.15 1.3.6.1.2.1.2.2.1.8

IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: down(2)

Форма вывода сразу отвечает на два вопроса: доступен ли нужный OID и какие индексы реально возвращает устройство. Секреты из примера не кладут в историю оболочки; в рабочей среде используйте защищенный способ передачи учетных данных. Для SNMPv1 и v2c строка community идет без шифрования, поэтому для управляемой сети разумнее SNMPv3 с аутентификацией и шифрованием.

В Prometheus сетевой опрос обычно строят через отдельный snmp_exporter. Prometheus обращается к его HTTP-точке, exporter выполняет SNMP-опрос цели и преобразует индексы в метки. Стандартный модуль if_mib быстро дает статистику интерфейсов, но для фирменных датчиков и таблиц потребуется собрать MIB, описать generator.yml, сгенерировать snmp.yml, выбрать модуль и проверить имена метрик. README проекта прямо говорит, что итоговый snmp.yml не стоит править вручную: изменения вносят в конфигурацию генератора.

Для Linux-серверов Prometheus также требует node_exporter, а для Windows обычно используют отдельный exporter. Это нормальная архитектура, но компоненты нужно установить, обновлять, защищать и инвентаризировать. У Zabbix агент тоже требует развертывания, зато сервер, шаблоны, события и доставка уведомлений образуют один административный контур. При смешанном парке эта цельность сокращает первичную работу.

Prometheus сильнее рядом с приложениями

Prometheus выигрывает, когда приложения и платформы уже публикуют метрики в его формате. Он забирает значения по HTTP, добавляет метки целей и позволяет связывать показатели запросами PromQL. Для команды, которая управляет Kubernetes, сервисами и конфигурацией через Git, этот подход проще развивать и проверять вместе с кодом.

Сильная сторона PromQL видна не на графике CPU, а в вопросах между объектами. Можно посчитать долю ошибок по сервису, исключить тестовую среду, сопоставить скорость запросов с доступными экземплярами и агрегировать результат по команде или региону. В Zabbix вычисляемые элементы и выражения триггеров решают много практических задач, но произвольный анализ многомерных метрик в Prometheus естественнее.

Обнаружение целей тоже отражает происхождение продукта. Prometheus умеет получать цели из Kubernetes, Consul и других поддерживаемых механизмов, а для собственной системы учета есть файловое и HTTP-обнаружение. Официальное руководство по file-based service discovery показывает JSON со списком целей и метками; Prometheus следит за файлом и принимает изменения без перезапуска. Для статичного списка серверов это может показаться лишней работой, но динамическая платформа быстро окупает такую модель.

Преимущество исчезает, если команда использует Prometheus как замену готовой системе наблюдения за коммутаторами. Тогда ей приходится самой собрать exporter, модули SNMP, правила записи, правила тревог, Alertmanager, получателей и интерфейс визуализации. Каждый компонент хорош в своей роли, но количество стыков остается фактом. Три сотни преимущественно сетевых и обычных серверных узлов редко оправдывают эту сборку без другой причины.

Не стоит выбирать Prometheus только потому, что конфигурация хранится в YAML. Файл в Git не становится качественным автоматически. Нужны рецензирование, проверка синтаксиса, тесты правил и понятный процесс выпуска. Prometheus дает promtool test rules для модульной проверки правил тревог. Если команда этим пользуется, она получает воспроизводимость. Если файлы правят прямо на сервере, преимущество перед формами Zabbix почти пропадает.

Первичная настройка считается по нестандартным целям

Срок запуска определяет не установка сервера мониторинга, а число типов целей без подходящего шаблона или exporter. Чистая установка обоих продуктов занимает малую часть проекта. Основное время уходит на доступы, карту владельцев, исключения интерфейсов, пороги, маршруты уведомлений и проверку того, что данные действительно означают заявленное.

Пилот должен включать неудобные устройства, а не только свежий сервер и популярный коммутатор. Возьмите старую модель со странным SNMP, узел через медленный канал, сервер с несколькими дисковыми группами, одну важную базу и приложение с собственными метриками. Если решение справилось с ними, массовое подключение повторяющихся моделей пройдет предсказуемо.

Для честного сравнения выполните одну и ту же последовательность:

1. Подключите по одному экземпляру каждого класса и зафиксируйте все ручные изменения.
2. Настройте одинаковые интервалы, сроки хранения и минимально полезный набор показателей.
3. Смоделируйте потерю узла, заполнение диска, отказ восходящего порта и прекращение поступления данных.
4. Передайте добавление второй цели другому администратору только по вашей инструкции.
5. Обновите шаблон или правило и проверьте, можно ли безопасно откатить изменение.

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

Сравнивайте труд не по числу кликов и строк YAML. Запишите, сколько разных артефактов меняет администратор при добавлении нового типа устройства, где проверяется ошибка и как выглядит откат. У Zabbix сложность часто скрыта в наследовании шаблонов, макросах и прототипах. У Prometheus она видна в relabeling, метках, exporter и маршрутах. Видимая сложность обычно безопаснее скрытой, если команда умеет с ней работать.

Оповещения удобнее в Zabbix, гибче в Alertmanager

Zabbix быстрее дает цельную цепочку от полученного значения до сообщения дежурному. Элемент хранит показатель, триггер вычисляет состояние, действие выбирает получателя и канал, а шаги эскалации повторяют или передают сообщение другой группе. Каналы включают электронную почту, SMS, скрипты и webhook. Все это настраивается и просматривается в одном интерфейсе.

Гибкость Prometheus распределена между правилами тревог и Alertmanager. Prometheus вычисляет выражение, удерживает состояние с помощью for при необходимости и отправляет событие в Alertmanager. Тот группирует, удаляет дубликаты, применяет подавление, выбирает ветку дерева маршрутов и получателя. Метки вроде team, service, site и severity становятся договором между сбором, правилами и доставкой.

На бумаге дерево маршрутов Alertmanager чище множества отдельных действий. На практике оно требует дисциплины именования меток. Если одно правило ставит site=almaty, другое location=almaty, а маршрут ожидает region, уведомления уйдут в корневой получатель. Синтаксис пройдет проверку, но организационная ошибка останется. Поэтому тестируйте не только PromQL, но и примеры событий для каждой ветки маршрутизации.

Типичный сетевой отказ показывает разницу особенно ясно. Пропадает магистральный коммутатор, вслед за ним недоступными становятся десятки серверов, точки доступа и ИБП. Без зависимостей Zabbix создает отдельные проблемы для всех целей. Нужно заранее задать зависимости триггеров, связи сервисов или корреляцию, чтобы дежурный увидел первопричину. В Prometheus все цели получают up=0, затем Alertmanager группирует сообщения по площадке и может подавить дочерние тревоги при активной тревоге на сетевом узле. Но подавление сработает только при совпадающих метках в правиле источника и дочерних событиях.

Официальная документация Alertmanager отдельно объясняет group_wait: короткое ожидание быстрее отправляет первое сообщение, но группа может оказаться неполной и подавляющая тревога не успеет появиться. Длинное ожидание дает корреляции время, но задерживает сигнал. Это не параметр, который стоит копировать из чужого примера. Для потери связи и заполнения диска допустимая задержка различается.

Если оповещения настраивает один системный администратор через интерфейс, Zabbix удобнее обслуживать. Если правила принадлежат командам приложений, проходят review и используют общую таксономию меток, Alertmanager гибче. Ни один продукт сам не исправит плохие пороги. Тревога должна требовать действия, иметь владельца и объяснять, что проверить. Остальные сигналы лучше оставить на панели.

Квалификация администратора меняет итоговую стоимость

Zabbix снижает порог входа, но не отменяет инженерные знания. Администратор должен понимать Linux, сеть, SNMP, базу данных, очередь опроса, кэши, процессы сервера и наследование шаблонов. Графический интерфейс помогает найти объект и увидеть ошибку, однако сложный шаблон с зависимыми элементами и JavaScript-предобработкой уже требует аккуратной отладки.

Для Prometheus нужны Linux, HTTP, модель временных рядов, PromQL, YAML, service discovery, relabeling и эксплуатация exporter. Для надежных уведомлений добавляются Alertmanager, шаблоны сообщений и правила подавления. Если данные уходят в удаленное хранилище, команда получает еще один контур с собственной емкостью и отказами. Такой набор подходит SRE или платформенной команде, но перегружает администратора широкого профиля, который обслуживает еще сеть, учетные записи и резервное копирование.

Разница заметна при передаче дежурства. В Zabbix новый сотрудник может пройти от хоста к последнему значению, триггеру и действию через интерфейс. В Prometheus он должен проследить цель через service discovery, exporter, метки, запрос правила и дерево маршрутов. Этот путь хорошо документируется, но его нужно действительно документировать. Комментарий «все лежит в Git» не объясняет, почему relabeling удаляет метку или какой генератор создал SNMP-модуль.

Оцените зависимость от одного специалиста. Попросите второго администратора без подсказок добавить модель устройства, изменить порог только для одной площадки, поставить обслуживание и объяснить пропавшее уведомление. Если задача останавливается на знании неочевидной команды или экрана, вы нашли эксплуатационный риск. Выбор продукта здесь менее важен, чем исправление инструкции и прав доступа.

Обновления тоже различаются по характеру. В Zabbix приходится согласованно обновлять сервер, интерфейс, схему базы, proxy и агенты с учетом матрицы совместимости. В стеке Prometheus отдельные двоичные файлы можно обновлять независимо, зато совместимость конфигураций и поведение интеграций проверяют по каждому компоненту. Монолит дает меньше движущихся частей, набор компонентов уменьшает область одного обновления. Бесплатной простоты нет.

Для организации без выделенной команды мониторинга я закладываю сопровождение как главный критерий. Система должна пережить отпуск автора, смену подрядчика и замену модели оборудования. Если текущая команда свободно читает PromQL и уже поддерживает exporter, Prometheus не добавит чужой навык. Если таких навыков нет, обучение станет частью стоимости, даже когда лицензия ничего не стоит.

Хранилище нужно считать по данным, а не по бренду

Обе системы поместятся на одном разумно подобранном сервере при аккуратном наборе показателей для 300 устройств, но утверждать конкретный размер без пилота нельзя. Zabbix пишет историю и тренды в реляционную базу данных, а производительность зависит от новых значений в секунду, типов данных, housekeeping, разделения таблиц и настроек кэша. Prometheus хранит временные ряды в локальной TSDB, где объем зависит от числа рядов, интервала, изменчивости меток и срока хранения.

Официальная документация Prometheus предупреждает, что локальное хранилище ограничено масштабом и долговечностью одного узла. Это не означает, что для 300 целей сразу нужна распределенная система. Сначала настройте срок хранения по времени или размеру, следите за самим Prometheus и делайте резервные копии конфигурации. Для долгой истории, общего хранилища нескольких экземпляров или особых требований к доступности рассматривают remote write и совместимое внешнее хранилище, но оно добавляет эксплуатационную работу.

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

Проверьте рост на пилоте по факту. После стабилизации обнаружения снимайте размер данных в одинаковое время несколько дней, отмечайте число активных элементов или рядов и ищите резкие скачки. В Prometheus запрос к внутренним метрикам TSDB покажет число рядов и скорость добавления образцов. В Zabbix внутренние элементы и очередь покажут, успевают ли poller и обработчики принимать значения. Один общий процент CPU ничего не объясняет.

Не используйте высокую доступность как оправдание преждевременной сложности. Сначала определите допустимую потерю истории и время без оповещений. Резервная копия конфигурации не сохраняет метрики, а реплика базы не проверяет доставку webhook. Для системы мониторинга нужен отдельный тест отказа: остановить основной процесс, убедиться в переключении и проверить, что дежурный получил единственное понятное сообщение, а не две копии от обоих узлов.

Сетевое размещение влияет на выбор сильнее интерфейса

Zabbix proxy дает понятный способ собирать данные на удаленной площадке и передавать их центральному серверу. Proxy опрашивает локальные цели, буферизует значения при разрыве связи и уменьшает число разрешенных потоков между сегментами. Для филиалов и изолированных зон это часто весомее удобства панели.

Prometheus обычно размещают рядом с целями или разрешают ему опрашивать HTTP-точки через границы зон. snmp_exporter можно поставить на нескольких центральных машинах, и его документация прямо описывает такой компонент как подобие proxy для SNMP. Но обычные exporter отдают HTTP, поэтому нужно продумать адреса прослушивания, межсетевые экраны, TLS и аутентификацию. Не выставляйте служебные точки в пользовательскую сеть по умолчанию.

SNMP тоже требует отдельной модели угроз. Версии v1 и v2c не шифруют community, а v3 поддерживает аутентификацию и приватность. Создавайте учетную запись только для чтения, ограничивайте адреса источников на оборудовании и храните секреты вне общедоступной конфигурации. Документация snmp_exporter позволяет подставлять имя, пароль и пароль шифрования из переменных окружения при включенном флаге расширения. Это удобнее открытого текста в репозитории, но секрет все равно должен безопасно попасть в процесс.

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

Нарисуйте потоки до установки: сервер или proxy к SNMP, Prometheus к exporter, агент к серверу, система к почте или webhook. Укажите порты, направление, шифрование, владельца правила и поведение при потере WAN. Такой рисунок часто исключает один вариант еще до пилота. Если политика не разрешает центральный HTTP-опрос филиалов, придется размещать сбор ближе к целям независимо от предпочтений команды.

Гибрид оправдан только разными владельцами данных

Использовать Zabbix и Prometheus вместе разумно, когда они решают разные задачи и у каждой есть владелец. Zabbix может следить за сетью, аппаратной частью, доступностью филиалов и обычными серверами. Prometheus при этом собирает прикладные метрики и метрики контейнерной платформы, которыми управляют разработчики или SRE.

Плохой гибрид собирает одинаковые CPU, память и доступность двумя системами «на всякий случай». Он удваивает агенты, правила, панели и уведомления, а при расхождении данных начинается спор о правильном источнике. Разделите ответственность письменно: какой продукт создает тревогу по узлу, где хранится длительная история и кто отвечает за качество меток или шаблона.

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

Гибрид требует двух комплектов резервного копирования, обновления и проверки оповещений. Если в организации один администратор, это сильный аргумент против. Если сетью и платформой управляют разные команды с разными циклами изменений, раздельные инструменты могут уменьшить конфликты. Граница должна совпадать с ответственностью людей, а не с модой на технологию.

Для обычных 300 устройств выбор склоняется к Zabbix

Для парка из сетевого оборудования и серверов под управлением небольшой инфраструктурной команды я выбрал бы Zabbix. Он быстрее покрывает SNMP, агентские данные, обнаружение, триггеры и доставку сообщений без сборки нескольких сервисов. Prometheus выбрал бы при обратной пропорции: мало классического SNMP, много приложений и контейнеров, уже есть exporter, Git-процесс и сотрудники, которые уверенно пишут PromQL.

Сводная логика проста:

• Для множества коммутаторов, ИБП и разнородных серверов выбирайте Zabbix: единая модель хостов, встроенный SNMP и шаблоны сокращают сборку.
• Если преобладают метрики приложений и динамические цели, выбирайте Prometheus: метки, PromQL и service discovery соответствуют задаче.
• Если оповещения ведет администратор через интерфейс, Zabbix собирает триггеры, действия, каналы и эскалации в одном месте.
• Если правила принадлежат командам и проходят review, Prometheus позволяет проверять правила и маршруты как конфигурацию.
• Для филиалов, которые долго живут без WAN, Zabbix с proxy дает штатный локальный сбор и буферизацию.

Цена лицензии не решает вопрос, потому что оба варианта можно начать без платы за сам программный код. Считайте время на новый тип устройства, расследование пропавших данных, обновление компонентов и обучение второго администратора. Через год именно эти операции формируют стоимость.

Если организация одновременно обновляет серверную инфраструктуру, GSE.kz может спроектировать и интегрировать подходящую серверную и инфраструктуру центра обработки данных, не привязывая выбор мониторинга к одному производителю. Само решение все равно следует принять по результатам собственного пилота, потому что модель коммутатора, политика сегментации и навыки смены точнее любой общей таблицы.

Завершите пилот намеренным отказом восходящего порта и передачей задачи другому администратору. Выбирайте систему, в которой он найдет первопричину, получит одно полезное уведомление и сможет объяснить конфигурацию без автора рядом. Для смешанного парка это чаще будет Zabbix; для платформы с готовыми метриками и зрелой SRE-практикой результат может честно оказаться другим.