Monq как зонтик над Zabbix и Prometheus: интеграции, корреляция событий и миграция без остановки мониторинга

Две стратегии: «зонтик навсегда» или полная миграция

Меня зовут Евгений Семёнов, я технический директор ITfresh. Пятнадцать с лишним лет мы обслуживаем IT-инфраструктуру московских компаний размером до пятидесяти рабочих мест, держим собственные серверы в дата-центре МТС и мониторим клиентские площадки централизованно. Исторически — на Zabbix. В двух предыдущих статьях серии я разбирал, что такое Monq Community Edition и как его развернуть. Сегодня — самый частый вопрос, который мы слышим после пилота: «А что делать с Zabbix, который у нас уже пять лет работает?»

Ответ короткий: ничего не ломать. У восьми из десяти наших клиентов Zabbix уже стоит, в нём накоплены сотни триггеров, шаблоны под конкретные ИБП и коммутаторы, привычные графики. Он хорошо делает свою работу — опрашивает железо и ОС. Плохо он делает другое: превращает сырые триггеры в понятную руководителю картину «работает ли 1С». Именно этот разрыв и закрывает зонтик: нижний слой сбора данных остаётся как есть, а сверху появляется система, которая принимает события и метрики из разных источников, хранит их в одном месте и реагирует по единым правилам.

Стратегий две, и выбор между ними — вопрос зрелости инфраструктуры и людей, а не технологий:

Важно понимать, что Monq изначально проектировался под оба сценария — он умеет и собирать данные сам (агенты, пороги, логи), и принимать чужие потоки. В наших внедрениях это почти всегда второй вариант, и дальше я покажу, как он собирается руками.

Что изменилось в редакциях Monq 9 — честная оговорка перед практикой

Прежде чем идти в настройки, обязан уточнить вещь, о которой в обзорах часто молчат. Когда мы начинали серию, условия бесплатной редакции формулировались по лицензионной политике 2024 года: полный функционал до 500 конфигурационных единиц, один обработчик автоматизации, один пользователь. С выходом линейки 9.x (релиз 9.0.0 — 10 октября 2025 года, на момент написания актуальна 9.2.1 от 23 июля 2026-го) вендор перекроил редакции, и картина стала другой.

По актуальной документации модули распределены так:

Почему мы всё равно ставим CE клиентам до 50 рабочих мест? Потому что даже без РСМ одна консоль, в которой рядом лежат триггеры Zabbix, алерты Prometheus, журналы Windows и syslog с коммутаторов, с единым поиском и едиными правилами уведомлений, — это уже другой уровень диагностики по сравнению с пятью открытыми вкладками.

Подключаем Zabbix под зонтик: события, метрики, узлы

Документация Monq описывает три способа дружбы с Zabbix, и мы используем их в такой последовательности.

Шаг 1. Учётная запись и поток данных

На стороне Zabbix создаём отдельную группу пользователей с правами только на чтение нужных групп узлов и заводим в неё техническую учётку для Monq. Никаких «Admin», никакого суперпользователя — принцип минимальных прав здесь не формальность: эта учётка будет жить в конфигурации годами. На стороне Monq создаём поток данных и копируем из его настроек API-ключ — он понадобится дальше.

Шаг 2. События триггеров — через вебхук

В Zabbix заходим в «Оповещения → Способы оповещений», создаём способ типа Webhook. В таблице параметров передаём макросы события — идентификатор, имя, важность, имя узла, статус триггера, — а JavaScript-скрипт способа отправляет POST на публичный API потока:

https://<monq.client.local>/api/public/cl/v1/stream-data?streamKey=<API-ключ>

Дальше — обычное действие Zabbix «при проблеме и при восстановлении отправлять через этот способ пользователю-роботу». Способ работает начиная с Zabbix 5.4, так что даже не самые свежие инсталляции клиентов подключаются без обновления.

Шаг 3. Метрики — через коннектор

Если нужны не только события, но и сами значения (чтобы строить пороги и графики уже в Monq), в Zabbix 6.4 и новее есть механизм коннекторов: «Администрирование → Общие → Коннекторы». URL коннектора — сборщик метрик Monq в формате NDJSON:

https://<monq.client.local>/api/public/mcs/v1/metrics-collector/zabbix/stream-ndjson?streamKey=<API-ключ>

В конфигурации zabbix_server.conf должен быть включён параметр StartConnectors, иначе коннектор молча не заработает — это первое, что проверяем, когда «ничего не приходит». На проде мы держим Zabbix 7.0 LTS (поддержка до середины 2029 года), и коннекторы там штатные.

Шаг 4. Узлы — через опрос API

Третий путь — задание потока данных, которое ходит в Zabbix API под той самой технической учёткой и забирает список узлов и событий. Это «тянущая» схема; она нужна, когда хочется видеть в Monq инвентарь узлов, а не только прилетающие алерты. Оговорка: готовый пакет подключения Zabbix как внешней системы относится к Business-редакции; на CE мы ограничиваемся вебхуком и коннектором, а инвентарь ведём в Zabbix.

Сквозная проверка

Перед тем как отчитаться «подключили», делаем контрольный прогон: на тестовом узле останавливаем службу, смотрим триггер в Zabbix, через несколько секунд — событие в потоке Monq со всеми полями, затем восстановление и закрывающее событие. Если какой-то из трёх шагов не сошёлся — разбираемся сейчас, а не в три часа ночи при реальной аварии.

Подключаем Prometheus и логи

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

Алерты из Alertmanager

Самый быстрый путь — добавить в alertmanager.yml получатель типа webhook, указывающий на тот же публичный API потока Monq, что и у Zabbix (отдельный поток, отдельный ключ):

receivers:
  - name: monq
    webhook_configs:
      - send_resolved: true
        url: 'https://<monq.client.local>/api/public/cl/v1/stream-data?streamKey=<API-ключ>'

route:
  receiver: monq
  group_by: ['alertname', 'instance']

send_resolved: true обязателен: без него Monq увидит открытие проблемы и никогда не увидит её закрытие, а висящие вечно события — верный способ приучить инженера их игнорировать.

Метрики через remote_write

Когда нужны сами временные ряды, Prometheus умеет отправлять их в Monq штатным механизмом удалённой записи — в prometheus.yml добавляется блок remote_write с URL сборщика метрик и заголовком x-smon-stream-key, в котором передаётся ключ потока. Параметры очереди (capacity, max_shards) подбираем под объём: для десятка экспортеров значения по умолчанию подходят, для сотен — считаем отдельно.

Зачем логи в той же системе

Метрика говорит «на терминальном сервере 1С очередь процессора выросла в 16:10». Журнал событий Windows говорит «в 16:08 стартовало задание резервного копирования». Пока эти два факта лежат в разных консолях, связь между ними видит только опытный инженер и только если догадается посмотреть. Когда логи и метрики попадают в одну систему с общим временем и общим поиском — связь видна на экране.

Что мы отдаём в Monq из логов у типового клиента:

• Журналы Windows с терминального сервера и сервера 1С: системный журнал и журнал приложений с фильтром по уровням «Ошибка» и «Предупреждение». Подключение 1С как источника «посмотреть всё подряд» мы не делаем — об этом были грабли в статье про установку.
• Syslog с коммутаторов, маршрутизатора и гипервизора. Monq 9 разбирает RFC 3164 и RFC 5424, так что самописных парсеров не нужно; уровень debug режем на стороне источника.
• Логи почтового сервера и веб-публикации 1С — для них мы используем преобразование логов в метрики: число строк с кодом 5xx за минуту превращается во временной ряд, на который вешается порог.

Хранение логов в Community Edition по объёму и сроку не ограничено лицензией — ограничено только диском. Поэтому сроки хранения мы задаём осознанно: сырые логи 30 дней, агрегаты дольше.

Корреляция и дедупликация: из 200 алертов — один инцидент

Вот сценарий, ради которого зонтики вообще придумали. У клиента два гипервизора, на одном — двенадцать виртуальных машин. Хост теряет питание. Zabbix честно отрабатывает: триггер на сам хост, по три-четыре триггера на каждую ВМ (недоступность агента, ICMP, службы), триггеры на сервисы, которые от этих ВМ зависят. Итого за две минуты — под полсотни уведомлений. Дежурный инженер получает их в Telegram очередью и тратит первые десять минут аварии на то, чтобы понять, что это одна авария, а не пятьдесят.

В Business-редакции Monq это решается штатно: события из потоков попадают в сигналы, правила корреляции склеивают их по связям ресурсно-сервисной модели, и дежурный видит один инцидент с корневой причиной «гипервизор недоступен» и деревом следствий. У одного из наших клиентов (производственная компания, 45 рабочих мест, два хоста, около 30 ВМ) после настройки такой корреляции мы измеряли число уведомлений за сутки до и после. Цифры ниже обезличены, но порядок именно такой:

А что делать на Community Edition, где модуля сигналов нет? Три приёма, которые закрывают большую часть боли без платной лицензии:

1. Зависимости триггеров в самом Zabbix. Механизм старый и недооценённый: триггер «ВМ недоступна» делаем зависимым от триггера «хост недоступен», и Zabbix сам не порождает следствия, пока активна причина. Шторм гасится на источнике, до зонтика.
2. Группировка в Alertmanager. group_by и group_wait склеивают однотипные алерты Prometheus в одно уведомление ещё до отправки в Monq.
3. No-code сценарий в Monq. Бизнес-процесс «при поступлении события с тегом host-down — поставить флаг подавления на 10 минут для событий с тем же именем хоста в поле родителя». Это не настоящая корреляция по модели, а тайм-аут на уведомления, но он снимает 80% шума при падении хоста.

Синтетические проверки поверх интеграций

Метрики говорят «сервер жив». Бухгалтер говорит «1С не открывается». Оба правы: сервер действительно жив, просто веб-публикация отдала ошибку, а служба агента сервера 1С висит, не упав. Между «зелёным Zabbix» и реальной жалобой всегда есть зазор, и закрывают его проверки уровня сервиса — те, что делают то же, что пользователь.

В Monq собственный модуль автотестов и синтетики относится к Enterprise-редакции, поэтому в наших внедрениях на CE синтетику делает Zabbix, а результат уходит под зонтик как обычное событие или метрика:

• Доступность опубликованной базы 1С. Веб-сценарий Zabbix: запрос к адресу публикации, проверка кода ответа и наличия строки в теле. Отдельно — элемент HTTP-агента, меряющий время ответа; порог «больше 3 секунд пять раз подряд» уже говорит о проблемах раньше людей.
• Прохождение тестового письма. Скрипт раз в 15 минут отправляет письмо с внешнего адреса на внутренний и проверяет его появление по IMAP. Время доставки — метрика, отсутствие письма 30 минут — триггер высокой важности.
• Вход на терминальный сервер. Проверка, что порт RDP отвечает и что служба лицензирования удалённых рабочих столов запущена; раз в сутки — тестовый вход сервисной учёткой с записью времени до появления рабочего стола.
• Цепочка сдачи отчётности. Доступность портала оператора отчётности с рабочей станции в офисе и срок действия сертификата электронной подписи (порог — 14 дней до истечения).

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

SLA-отчёты для директора и для нас как подрядчика

Директору бухгалтерской фирмы не нужен график загрузки процессора. Ему нужна одна строка: «Работа в 1С в июле: 99,7%, два инцидента, суммарно 2 часа 10 минут, оба вне отчётного периода». Это и есть смысл зонтика для бизнеса — считать доступность сервисов, а не серверов.

В Business-редакции такие отчёты собираются модулем отчётов по ресурсно-сервисной модели: здоровье сервиса «Работа в 1С» считается из здоровья его компонентов, а отчёт за период формируется по расписанию. На Community Edition модуля отчётов нет, и мы идём другим путём: доступность сервиса определяется результатом синтетической проверки (см. выше), это метрика 0/1, по ней в Monq строится дашборд, а ежемесячную сводку для клиента мы собираем полуавтоматически — выгрузкой значений за период. Менее красиво, зато цифра та же и источник один.

Отдельная история — наш собственный интерес. В договоре аутсорсинга у ITfresh прописаны параметры реакции и доступности, и те же отчёты мы используем как подтверждение выполнения SLA с нашей стороны. Когда спор «у вас всё лежало полдня» разбирается по журналу событий с точностью до минуты, он заканчивается за пять минут, а не за час переписки.

Когда миграция с Zabbix на Monq оправдана полностью

Бывают ситуации, когда зонтик над Zabbix — не решение, а консервация проблемы. Признаки, по которым мы рекомендуем полный переход:

• Zabbix-сервер сам стал наследием: ветка 4.x или 5.0 на ОС, которая не получает обновлений, база MySQL весом в десятки гигабайт без партиционирования, и никто не помнит, как это обновлять.
• Функции дублируются: пороги, уведомления и дашборды уже настроены в Monq, а Zabbix остался только как «сборщик» для пяти хостов.
• Команда дежурных хочет одну консоль и один набор правил вместо двух систем, в каждой из которых надо помнить, где что настроено.

Порядок миграции без слепых зон у нас стандартный:

1. Параллельная работа. Monq получает данные от агентов напрямую, Zabbix продолжает работать. Минимум две недели, включая один отчётный период клиента.
2. Перенос проверок волнами. Сначала доступность и диски, затем службы и приложения, затем специфичные SNMP-проверки. После каждой волны — сверка: каждый триггер Zabbix, который срабатывал за последний квартал, имеет эквивалент в Monq.
3. Вывод старой системы. Сначала отключаем уведомления Zabbix (данные собираются, но молчат), неделю смотрим, что ничего не потеряно, затем гасим сервер и оставляем снимок ВМ на три месяца.

Когда мы не мигрируем: при глубокой кастомизации Zabbix (самописные внешние скрипты, LLD-правила под специфичное оборудование, интеграции с 1С через API Zabbix) и там, где ценность именно в агентном сборе с экзотики — ИБП, климатика, станки с ЧПУ. В этих случаях зонтик — конечная архитектура, а не переходная.

Ограничения Community Edition в интеграционном сценарии

Сведу в одно место, во что упирается бесплатная редакция именно при работе зонтиком, — без маркетинга в обе стороны.

• Один обработчик автоматизации. Все no-code сценарии реагирования на события из всех источников выполняются последовательно. При шторме в полсотни событий сценарий «отправить в Telegram» отработает за секунды, а вот сценарий «подключиться к серверу и собрать диагностику» поставит остальные в очередь. Поэтому сценарии проектируем быстрыми и идемпотентными: уведомил, поставил флаг, вышел. Тяжёлые действия — на стороне источников.
• Нет сигналов и РСМ. Настоящая корреляция по модели зависимостей и расчёт здоровья сервисов — Business. Обходные пути выше (зависимости триггеров, группировка, тайм-ауты подавления) закрывают типовой шторм, но не дают «дерева причин» на экране.
• Нет готовых пакетов подключения внешних систем. Вебхуки, коннектор и remote_write работают как базовый сбор данных; а вот «тянущие» интеграции с инвентаризацией узлов — платная функция.
• Десять пользователей. Для компании до 50 рабочих мест, где в мониторинг смотрят два инженера подрядчика и ИТ-ответственный клиента, — с запасом. Полноценной ролевой модели с тонким разграничением прав в CE нет.
• Ресурсы платформы. Это k3s-кластер с ClickHouse и PostgreSQL внутри, а не лёгкий демон; минимальные требования — 8 ядер с AVX2, 24 ГБ памяти, быстрый SSD. Зонтик над Zabbix на старом сервере не поднимешь.

Вывод для бизнеса до 50 рабочих мест: ограничения CE ощутимы, но обходимы, и экономия в сравнении с Business (от 1,2 млн рублей за on-premise) для такого масштаба решающая. Для сотен узлов, нескольких филиалов и дежурной смены — это уже повод считать платную редакцию, потому что время инженеров, потраченное на ручную корреляцию, стоит дороже лицензии.

Чек-лист внедрения зонтика за 5 рабочих дней

Так выглядит наш типовой план для клиента, у которого уже есть работающий Zabbix и развёрнутая по предыдущей статье платформа Monq CE.

Что должно остаться на руках у заказчика в конце недели: схема источников с адресами и ключами потоков (ключи — в менеджере паролей, не в документе), перечень фильтров и правил подавления с объяснением, зачем каждое, список синтетических проверок с порогами и расписанием, доступ к дашбордам для ИТ-ответственного и руководителя, а также регламент эксплуатации — о нём следующая статья серии.

Если коротко: зонтик над Zabbix — это не «выбросить старое», а «перестать смотреть в пять окон». Community Edition в 2026 году даёт для этого единую консоль событий, метрик и логов с порогами и no-code реакциями; корреляцию и модель сервисов мы добираем приёмами на стороне источников или платной редакцией, когда масштаб того стоит. Нужна помощь — мы такие внедрения делаем регулярно и берём мониторинг на сопровождение вместе со всей инфраструктурой.