Monq Community Edition 9.0: честный разбор бесплатного российского «зонтичного» мониторинга для компаний до 50 рабочих мест

Зачем малому бизнесу зонтичный мониторинг, если уже есть Zabbix

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

Начну с боли. У типового нашего клиента на 30–50 рабочих мест в хозяйстве уже есть зоопарк наблюдательных инструментов: Zabbix следит за серверами и сетью, у гипервизора своя панель, у системы резервного копирования своя консоль, 1С пишет технологический журнал, почтовый сервер — свои логи. Каждый инструмент по отдельности работает. Но когда в разгар рабочего дня «падает 1С», происходит одно и то же: бухгалтерия звонит директору, директор звонит нам, инженер открывает четыре окна и начинает собирать картину по кусочкам. Директор в это время слышит «мы смотрим» — худший ответ из возможных. А хочет он услышать: «Сервис „1С:Бухгалтерия" недоступен 12 минут, причина — закончилось место на диске SQL-сервера, устраняем, прогноз — 20 минут».

Разница между этими двумя ответами — это и есть зонтичный мониторинг. Он не заменяет Zabbix и панели, а собирает их сигналы в единую модель здоровья бизнес-сервисов. Не «CPU на srv-sql01 — 92%», а «сервис „Бухгалтерия" — жёлтый, потому что деградировала СУБД». Один экран здоровья ИТ вместо десяти админских панелей — так я объясняю это директорам, и это объяснение работает безотказно: директору не нужны сорок графиков загрузки процессора, ему нужен светофор «работает / не работает / скоро сломается».

Что такое Monq и почему это не ещё один Zabbix

Monq — российская платформа класса AIOps/observability, то, что на рынке называют «зонтичным мониторингом». Ключевое отличие от классических систем: Monq не столько собирает метрики сам (хотя умеет и это), сколько принимает потоки событий, метрик и логов из уже работающих источников — Zabbix, Prometheus, гипервизоров, журналов приложений — и строит поверх них ресурсно-сервисную модель, сокращённо РСМ.

РСМ — центральное понятие, без которого Monq не понять. Это граф зависимостей: физический диск входит в сервер, сервер несёт СУБД, на СУБД живёт база 1С, база 1С — часть бизнес-сервиса «Бухгалтерия». Каждый узел графа имеет вычисляемое состояние здоровья, и деградация нижнего уровня распространяется вверх по связям. Сыплется диск — платформа сама подсвечивает, какие сервисы под ударом, ещё до того, как позвонили пользователи. Вокруг РСМ построено остальное: корреляция и дедупликация событий (сто однотипных алертов от одного сбоя схлопываются в один инцидент), расчёт SLA по сервисам, low-code автоматизация реакций — от перезапуска службы до уведомления в Telegram.

Второй важный для нас момент — происхождение. Monq — российская разработка, и это тот случай, когда «российская» означает не переклеенный шильдик: русский интерфейс и русская документация здесь первичны, а не переведены по остаточному принципу. Платформа включена в реестр российского ПО (reestr.digital.gov.ru), что для части наших клиентов — не абстракция, а условие работы: госконтракты и медицинские организации регулярно требуют реестровый софт, и на этом требовании отваливаются многие западные и даже открытые альтернативы.

Про версии. Крупный релиз 9.0 вышел 10 октября 2025 года, и именно он сделал платформу интересной для сегмента малого бизнеса; сейчас вендор уже выпустил 9.2.0 (10 июля 2026 года), поэтому в статье я говорю о поколении 9.x в целом, отмечая, что именно принёс релиз 9.0.

Community Edition 9.0: что дают бесплатно и где подвох

Теперь к главному вопросу: что именно бесплатно. Monq Community Edition — это не демка с урезанным ядром и не тридцатидневный trial. Это полнофункциональная self-hosted платформа с ограничениями по масштабу, а не по сроку. Перечислю условия так, как мы их зафиксировали для себя на 20 августа 2026 года:

• До 500 активных конфигурационных единиц (КЕ) в ресурсно-сервисной модели. Считаются только активные КЕ — число неактивных не ограничено.
• Один пользователь и одна рабочая группа. Это, пожалуй, самое чувствительное ограничение бесплатной редакции: штатно работать в системе может один пользователь. Про то, кому это мешает, а кому нет, скажу отдельно в разделе о минусах.
• Один параллельный обработчик автоматизации. Сценарии low-code выполняются в один поток — про это ограничение подробно скажу в разделе о минусах.
• Сбор и хранение логов и метрик без ограничения срока. При оформлении ключа выбирается вариант лицензии по объёму логов: 50 ГБ в сутки или безлимит.
• Ключ — через личный кабинет на monq.ru, для активации требуется доменное имя (по «голому» IP инстанс не активировать).

Часть возможностей коммерческих редакций в CE недоступна: расширенная ролевая модель с разграничением прав между несколькими администраторами (в CE — тот самый один пользователь), Intelligent Ops и мониторинг приложений (APM). Для сценария «один экран здоровья ИТ для компании до 50 РМ», который ведёт один ответственный инженер или аутсорсер, эти модули не критичны — но ограничение по пользователям надо трезво примерить на свою команду ещё до внедрения.

Считаем КЕ на живом примере

Лимит «500 активных КЕ» звучит абстрактно, пока не переложишь его на реальную инфраструктуру. КЕ — это учётная единица в РСМ: сервер, виртуальная машина, служба, база данных, сетевое устройство, бизнес-сервис. Возьмём типовую компанию на 50 рабочих мест из нашей практики:

Запас до лимита — двух-трёхкратный, и это при том, что мы завели в модель все 50 рабочих станций, что делаем далеко не всегда: часто достаточно мониторить терминальный сервер, а судьба конкретного офисного ПК на здоровье бизнес-сервисов не влияет. Правило гигиены такое: активной КЕ должно быть только то, что участвует в расчёте здоровья сервисов; тестовые виртуалки, выведенное из эксплуатации железо и прочий музей — либо неактивные КЕ (они бесплатны в любом количестве), либо вообще не в модели. Реально упереться в 500 КЕ можно в трёх случаях: несколько филиалов с полноценной инфраструктурой в каждом, сотни IoT-датчиков или СКУД/видеонаблюдение, заведённые поштучно, и привычка тащить в РСМ всё подряд «на всякий случай». Первые два случая — это уже не профиль «до 50 РМ», а третий лечится дисциплиной моделирования.

Архитектура и функциональные блоки 9.0 глазами эксплуатанта

Разберу платформу по блокам — не по маркетинговой брошюре, а в порядке, в котором с ними сталкивается эксплуатирующий инженер.

Сбор данных. Monq принимает метрики и логи как собственными средствами, так и из внешних систем. В релизе 9.0 появился инфраструктурный мониторинг с правилами по CMDB-фильтрам: одно правило вида «всем виртуальным машинам с меткой prod проверять доступность и диски» автоматически распространяется на множество динамических объектов — не нужно, как в классических системах, руками цеплять шаблон к каждому новому хосту. Туда же — MetricBridge, механизм преобразования логов в метрики: из журнала веб-сервера можно получить метрику количества ошибок в минуту и повесить на неё порог. Заявленная производительность конвейера — до ~1,4 ТБ логов в сутки на инстанс; для сегмента до 50 РМ это на порядки больше любой реальной нагрузки, то есть в потолок производительности такой клиент не упрётся никогда.

Обработка событий. Потоки событий из всех источников проходят корреляцию и дедупликацию. По данным вендора, шум алертов снижается до 5–10% исходного объёма — и по нашему опыту с алертами Zabbix это похоже на правду: когда падает гипервизор, вместо тридцати писем о недоступности каждой виртуалки дежурный видит один инцидент с корнем «хост недоступен». Уставший от спама инженер, который перестал читать почту мониторинга, — реальная угроза надёжности, и дедупликация лечит именно её.

РСМ и здоровье сервисов. Про модель я уже рассказал; добавлю механику. Влияние распространяется снизу вверх: деградация диска меняет здоровье СУБД, СУБД — здоровье сервиса «Бухгалтерия». На выходе — экраны здоровья и карты сервисов, которые в 9.0 заметно ускорили (обновление карт построено на pub/sub, состояние меняется на глазах, без перезагрузки страницы). Именно этот экран мы выводим директору: строчки «Бухгалтерия», «Почта», «Файлы», «Интернет» и светофор напротив каждой.

SLA и отчёты. Раз у сервиса есть вычисляемое здоровье, доступность считается автоматически. Отчёт «сервис 1С в августе был доступен 99,7% рабочего времени, два инцидента, суммарно 74 минуты» — это то, что аутсорсер показывает клиенту, а ИТ-директор — генеральному. Мы такие отчёты раньше собирали руками из Zabbix, теперь они собираются сами.

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

Под капотом. Monq — это k3s (лёгкий Kubernetes) и набор микросервисов: PostgreSQL, ClickHouse, ArangoDB, Redis, RabbitMQ, Consul. Наружу инстансу нужны только порты 22 и 443. Для эксплуатанта это означает две вещи: платформа современная и масштабируемая — и платформа тяжёлая. Об этом следующий раздел.

Чего Monq CE НЕ сделает — честный список

Обзор без раздела о недостатках — это реклама. Вот что нужно понимать до внедрения, а не после.

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

Ему нужна полноценная виртуальная машина, и немаленькая. Минимальные требования single-node инсталляции: x64-процессор с поддержкой SSE4.2 и AVX2, от 8 ядер, от 24 ГБ оперативной памяти, SSD от 60 ГБ с производительностью от 700 IOPS, ОС Debian 12. Это Kubernetes-стек с шестью подсистемами хранения и обмена, а не лёгкий демон на 50 МБ памяти, как сервер Zabbix. Для наших клиентов это обычно виртуалка на собственном гипервизоре или VPS — ресурсы посильные, но «поставлю на старый системник под столом» здесь не сработает. Требование AVX2, кстати, отсекает совсем древнее железо — проверяйте процессор до начала работ.

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

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

Часть возможностей — только в платных редакциях. Расширенная ролевая модель, Intelligent Ops, мониторинг приложений (APM) — этого в CE нет. Если нужен полноценный APM или гибкое разграничение доступа — это уже разговор о коммерческой лицензии.

AI-магии из коробки не будет. Слово AIOps в описании категории не означает, что платформа сама всё поймёт в первый день. Интеллектуальные функции требуют настроенной модели, накопленных данных и осмысленных правил. Сначала — аккуратная РСМ и подключённые источники, потом умные функции; в обратном порядке не работает.

Сравнение: Monq CE vs Zabbix vs Prometheus+Grafana для бизнеса до 50 РМ

Три бесплатных варианта, которые чаще всего оказываются на столе, когда компания до 50 рабочих мест выбирает мониторинг. Сравниваю по критериям, важным именно этому сегменту:

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

Кому мы рекомендуем внедрять, а кому нет

Рекомендуем, если узнаёте себя хотя бы в одном пункте:

• Бизнес критично зависит от 1С — торговля, услуги, производство, где час простоя учётной системы означает остановку отгрузок и кассы. Сервисная модель «диск → SQL → Бухгалтерия» здесь окупается первым же инцидентом.
• Госконтракты. Реестровое ПО в мониторинге — аргумент, который нечем крыть у открытых западных стеков.
• Медицина и другие сферы с чувствительными данными. Monq — self-hosted: платформа стоит на вашем железе, телеметрия и логи не уходят наружу, что упрощает разговор с регуляторикой по персональным данным.
• Есть аутсорсер или свой инженер, который будет вести модель. Зонтик — это инструмент процесса, а не однократная установка.

Не рекомендуем, если у вас 5–10 рабочих мест, один сервер и нет выделенных ресурсов под мониторинг. Виртуалка на 8 ядер и 24 ГБ памяти для такой компании — неоправданный расход: связки из лёгкого Zabbix и уведомлений в Telegram будет достаточно, а сервисную модель при трёх сервисах заменяет голова инженера. Честность требует сказать это прямо: Monq CE — инструмент для нижней границы среднего сегмента, а не для микробизнеса.

Эта статья — первая в серии про Monq в наших руках. Дальше по плану: развёртывание Community Edition с нуля по шагам (выйдет одновременно с этой статьёй — ссылка внизу), интеграции с источниками данных, регламент эксплуатации и разбор живого кейса внедрения. Серия строится так же, как наши циклы про GLPI и Zammad: от честного обзора к граблям продакшена.

FAQ и вывод техдиректора

Что будет, когда активных КЕ станет больше 500? Переход на коммерческую редакцию: лимит CE — жёсткий. Цены — у вендора, они зависят от объёма и состава модулей; сравнивать их стоит не с нулём, а со стоимостью простоев и ручной сборки картины инцидентов. До лимита компания из целевого сегмента, как я показал на расчёте выше, обычно не добирается двух-трёхкратно.

Можно ли использовать CE в коммерческой компании? Вендор позиционирует Community Edition в том числе для небольших компаний, но юридически точные условия закреплены в лицензионном соглашении, которое принимается в личном кабинете monq.ru при получении ключа. Наша стандартная рекомендация — показать текущую редакцию соглашения юристу до внедрения.

Обновляется ли Community Edition? Да, CE живёт на актуальной кодовой базе платформы: релиз 9.0 вышел в октябре 2025-го, в июле 2026-го вышла 9.2.0. Это не замороженная «бесплатная версия пятилетней давности», как бывает у некоторых вендоров.

Что с поддержкой? У CE — поддержка силами сообщества и документации, вендорская техподдержка — атрибут коммерческих редакций. Для нас как аутсорсера это нормальная модель: первую линию по платформе закрываем сами. Если своей экспертизы нет, закладывайте её аренду в бюджет внедрения.

Потянет ли одна виртуальная машина? Да, single-node инсталляция — штатный сценарий: 8+ ядер с AVX2, 24+ ГБ RAM, SSD от 60 ГБ с 700+ IOPS, Debian 12, наружу — порты 22 и 443. Для масштаба до 50 РМ этого хватает; главное — не экономить на дисковой подсистеме, под капотом ClickHouse и PostgreSQL, им нужны IOPS.

Где документация? docs.monq.ru — на русском, включая руководства по установке и работе с РСМ. Отдельно отмечу: это тот редкий случай, когда инженеру не приходится держать рядом переводчик.

Мой вывод. Monq Community Edition 9.x — первый известный мне бесплатный зонтичный мониторинг, который честно помещается в реалии компании до 50 рабочих мест: лимиты CE рассчитаны так, что типовая инфраструктура занимает треть разрешённого, русская документация снимает языковой налог, а реестровость закрывает формальные требования. Платить за это приходится железом (полноценная ВМ под Kubernetes-стек) и дисциплиной моделирования. Если у вас уже есть Zabbix и директор, который устал слышать «мы смотрим», — Monq CE поверх существующего мониторинга это ровно тот апгрейд, который переводит ИТ из «чёрного ящика» в управляемый сервис. Мы прошли этот путь на своих клиентах; в следующей статье покажу развёртывание по шагам.