Разворачиваем Monq Community Edition с нуля: пошаговая инструкция от инженеров ITfresh — от требований к железу до первого экрана здоровья

Планирование: где жить мониторингу

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

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

На практике мы выбираем из двух схем:

• Отдельная ВМ на втором гипервизоре клиента. Если у компании два независимых хоста виртуализации — мониторинг едет на тот, где нет критичной нагрузки. Все данные остаются внутри периметра, что важно для клиентов с жёсткими требованиями по персональным данным и коммерческой тайне: журналы событий, логи 1С и метрики никуда наружу не уходят. Минус — за железом под мониторингом тоже надо следить, и при аварии единственной площадки вы всё равно слепнете.
• Площадка ITfresh в ЦОД МТС. Мы поднимаем ВМ на своих серверах, соединяем её с сетью клиента site-to-site VPN-туннелем. Плюсы: мониторинг физически в другом здании и на другом канале, авария у клиента не валит наблюдателя, резервирование и бэкапы — наша забота. Минус, о котором надо честно сказать юристам заказчика: телеметрия покидает офис. Мы решаем это тем, что в туннель уходят только метрики и события, а не содержимое баз, и фиксируем перечень передаваемых данных в договоре.

Для типового клиента на 30–50 рабочих мест с одним гипервизором мы почти всегда рекомендуем второй вариант. Для компаний с распределённой инфраструктурой и собственным ИБ-отделом — первый. Гибрид тоже бывает: платформа у нас, агенты и прокси-сборщики у клиента.

Требования к ресурсам: сколько железа просит платформа

Здесь важно сразу перестроить ожидания. Monq — это не лёгкий демон вроде Zabbix-сервера, который довольствуется парой гигабайт памяти. Это микросервисная платформа поверх Kubernetes: инсталлятор разворачивает k3s-кластер (в актуальной версии — k3s 1.31), внутри которого крутятся десятки контейнеров — PostgreSQL, ClickHouse, ArangoDB, Redis, RabbitMQ, Consul и собственные сервисы платформы. Такой архитектуре нужен нормальный запас ресурсов, и экономить тут — верный способ получить нестабильную систему.

Официальные минимальные требования для single-node инсталляции на момент написания статьи выглядят так (актуальную редакцию всегда сверяйте с docs.monq.ru — от версии к версии цифры меняются):

Три комментария из практики. Первый — про AVX2: ClickHouse внутри платформы требует современных инструкций процессора, и на старом железе или в виртуалке с процессором в режиме совместимости контейнеры аналитической БД просто не стартуют. Проверяется одной командой ещё до установки, покажу её ниже.

Второй — про IOPS. 700 операций в секунду — это порог, ниже которого etcd-подобные компоненты и очереди начинают деградировать. На HDD-массиве платформу разворачивать бессмысленно: инсталляция либо не пройдёт по таймаутам, либо пройдёт и будет мучить вас фантомными сбоями. Только SSD или NVMe.

Третий — про размер диска. Минимальные 60 ГБ — это «платформа встала и дышит». Но смысл зонтичного мониторинга — собирать логи и события, а они растут каждый день. Журнал регистрации 1С со средней базы, syslog с гипервизора и сетевого оборудования, события Windows с серверов — на клиенте в 50 рабочих мест это легко гигабайты в неделю. Мы закладываем 200 ГБ сразу, потому что расширять диск под нагруженным k3s-кластером — операция нервная, а место под ClickHouse кончается всегда внезапно. Дешевле выделить запас на старте.

Подготовка ОС и окружения

Основа — чистый Debian 12 из официального netinst-образа, без панелей управления, без Docker «из прошлой жизни», без чужих репозиториев. Платформа сама приносит всё, что ей нужно, и любой посторонний софт на хосте — источник конфликтов. Разметка диска — важный и неочевидный момент: документация требует, чтобы весь диск был смонтирован в корень «/» с файловой системой xfs. Никаких отдельных /home и /var на своих разделах — k3s и контейнерные тома живут в общем пространстве, и раздробленная разметка приведёт к тому, что место кончится в одном разделе при пустых остальных.

Дальше по чек-листу. Статический IP-адрес — очевидно. NTP — обязательно: расхождение часов между источниками событий и платформой превращает корреляцию событий в кашу. И третий пункт, который часто становится сюрпризом: платформе нужно полноценное DNS-имя. Оно не только для удобства — доменное имя указывается при активации лицензии Community Edition, без него ключ просто не выпустить. Имя должно резолвиться у всех, кто будет открывать веб-интерфейс: либо запись во внутренней DNS-зоне, либо публичная запись, если портал будет доступен снаружи.

Мини-набор проверок перед установкой — прогоняем его на каждой новой ВМ:

# процессор: должны увидеть и sse4_2, и avx2
grep -o -m1 'sse4_2\|avx2' /proc/cpuinfo | sort -u

# ядра и память
nproc && free -h

# время: включаем NTP и проверяем синхронизацию
timedatectl set-ntp true
timedatectl status | grep -E 'synchronized|Time zone'

# сеть и имя
ip a | grep 'inet '
hostname -f
getent hosts monq.client.local   # имя должно резолвиться в IP этой ВМ

# диск: xfs, всё в корне, запас места
df -h /
lsblk -f

Сетевые доступы. Самому серверу нужны входящие 22/tcp (SSH для администрирования) и 443/tcp (веб-интерфейс и приём данных), исходящие 80/tcp (репозитории и реестры образов на время установки) и 25/465 — если планируете почтовые уведомления через внешний SMTP. По архитектуре сети мы придерживаемся классики: сервер мониторинга живёт в серверном VLAN, а наблюдает за источниками во всех сегментах — значит, на межсетевом экране между VLAN нужно заранее открыть пути от Monq к гипервизорам, серверам и сетевому оборудованию по нужным протоколам. Сделать это до установки — сэкономить себе день переписки с «а почему источник не подключается».

Установка платформы шаг за шагом

Дистрибутив Monq не лежит в открытом доступе — он выдаётся через личный кабинет на monq.ru после регистрации. Там же живут инструкция по установке под конкретную версию и лицензионные ключи. Сам установщик поставляется в виде Docker-контейнера: вы запускаете его по инструкции из кабинета, отвечаете на вопросы конфигурации (имя домена, параметры сети, пути), и дальше он делает основную работу — разворачивает k3s-кластер и раскатывает в него весь стек: PostgreSQL 16 под реляционные данные, ClickHouse 24.8 под события и метрики, ArangoDB 3.11 под графовую модель связей, Redis 7.4, RabbitMQ 4.0 и Consul под кэш, очереди и координацию сервисов. Конкретный синтаксис запуска инсталлятора я сознательно не привожу — он меняется от версии к версии, берите из инструкции в кабинете под свой релиз. Часть инфраструктурных объектов после раскатки настраивается вручную — это тоже описано в документации, закладывайте время на внимательное чтение.

Реалистичный тайминг: на канале 100 Мбит/с у нас установка занимает от часа до двух. Львиная доля — скачивание контейнерных образов, их много и они тяжёлые. На канале потоньше или через нагруженный прокси процесс растягивается пропорционально, так что запускать установку в 17:45 пятницы — плохая идея.

Контроль готовности — стандартными средствами Kubernetes. После завершения работы инсталлятора смотрим на кластер:

# нода должна быть в статусе Ready
kubectl get nodes

# все поды платформы — Running, счётчик рестартов не растёт
kubectl get pods -A

# если какой-то под завис — смотрим причину
kubectl describe pod <имя-пода> -n <namespace>
kubectl logs <имя-пода> -n <namespace> --tail=50

# веб-интерфейс отвечает
curl -k -o /dev/null -w '%{http_code}\n' https://monq.client.local/

Когда все поды перешли в Running, открываем в браузере https://<ваш-домен> и попадаем на первый вход в веб-интерфейс. Дальше — создание административной учётки и активация лицензии, о ней в следующем разделе.

Где спотыкаются чаще всего — наш топ-3 по опыту установок:

1. DNS. Имя не резолвится с самой ВМ или резолвится в чужой адрес — сервисы не могут собраться, сертификаты не выпускаются, интерфейс не открывается. Проверка getent hosts до установки снимает проблему полностью.
2. Нехватка RAM или IOPS. Симптом — поды бесконечно перезапускаются, статусы CrashLoopBackOff и OOMKilled в выводе kubectl get pods. Лечится только приведением ВМ к требованиям, никакие «подождать» не помогают.
3. Недоступность реестра образов из корпоративной сети. Инсталляция висит на скачивании, в логах — таймауты. Виноват обычно прокси или фильтр исходящего трафика; решается правилом на межсетевом экране на время установки.

Активация Community Edition

Community Edition — это полноценная платформа с бесплатной лицензией, а не демо-режим. Ключ выпускается в том же личном кабинете monq.ru: регистрируетесь, выбираете бесплатную редакцию, указываете доменное имя, по которому развёрнута ваша инсталляция, — то самое, что мы готовили на этапе DNS, — и получаете ключ, который вводится в интерфейсе платформы. Привязка к домену — причина, по которой «поставлю пока по IP, имя придумаю потом» не работает: имя нужно до активации.

Ограничения бесплатной редакции на момент написания:

• до 500 активных конфигурационных единиц (КЕ) — для компании на 50 рабочих мест это запас с многократным избытком, если не заводить в модель каждый принтер;
• один пользователь и одна рабочая группа — самое чувствительное ограничение: штатно в системе работает один ответственный (свой инженер или аутсорсер); нужна команда с разграничением прав — это уже коммерческая редакция;
• один параллельный обработчик автоматизации — сценарии выполняются по очереди, это надо учитывать при их проектировании;
• логи и метрики — без ограничения срока хранения: глубина истории упирается только в ваш диск;
• есть и альтернативный вариант лицензирования — по объёму обрабатываемых логов; какой выгоднее, зависит от профиля вашей инфраструктуры.

Отдельный абзац для юристов заказчика — мы проходим этот разговор на каждом втором внедрении. Условия использования Community Edition закреплены лицензионным соглашением, которое публикуется в личном кабинете monq.ru. Я сознательно не пересказываю его условия своими словами — соглашение может меняться, и юридически значим только его актуальный текст. Наша практика: при внедрении клиенту мы фиксируем в договоре ссылку на конкретную редакцию лицензионного соглашения и дату ознакомления. Служба безопасности и юристы заказчика такую аккуратность ценят, а вы застрахованы от спора «а нам сказали, что всё можно».

Первые источники данных: с чего начинаем

Платформа установлена и активирована — начинается самое интересное. Главная ошибка первого дня — попытка «завести всё и сразу». Зонтичный мониторинг ценен не количеством подключённого, а осмысленной моделью, поэтому мы всегда стартуем с минимального набора, который закрывает 90% реальных инцидентов типового клиента:

• шлюз и интернет-канал — доступность роутера, состояние WAN-линков, у кого есть резервный канал — обоих;
• гипервизор — доступность хоста, датасторы, состояние дисковых массивов;
• ВМ с 1С и SQL — доступность, CPU, память, место на дисках, состояние служб;
• дисковые массивы и СХД — здоровье RAID, свободное место, SMART-события;
• почтовый сервер — доступность служб, очередь отправки, место под базами писем.

Каждый наблюдаемый объект оформляется в Monq как конфигурационная единица. И здесь второе правило: КЕ — это то, за здоровье чего вы отвечаете перед бизнесом, а не каждый пингуемый адрес. Рабочие станции пользователей, IP-телефоны и принтеры мы на старте в модель не заводим вовсе — о них и так сообщат сами пользователи, а модель из трёх сотен объектов на второй неделе жизни системы превращается в шум, который никто не читает. Типовая структура для клиента на 50 рабочих мест у нас выглядит примерно так: 2 сетевых устройства периметра, 1–2 гипервизора, 5–8 ключевых ВМ, СХД, почта, 2–4 бизнес-сервиса поверх — итого 15–25 КЕ. До лимита в 500 — как до Луны, и это нормально.

Строим первую ресурсно-сервисную модель

Ресурсно-сервисная модель (РСМ) — то, ради чего вообще берут зонтичную систему вместо ещё одного «пингера». Это дерево зависимостей от железа к бизнес-услуге: внизу инфраструктура, выше платформенные компоненты, на вершине — сервисы, понятные директору. Наш первый сервис у любого клиента — «Работа в 1С», потому что именно его смерть бизнес чувствует кошельком в первые же минуты.

Дерево для него собирается так: сервис «Работа в 1С» зависит от терминального сервера, сервера СУБД и сервера 1С; те — от своих виртуальных машин; ВМ — от гипервизора и дискового массива; всё вместе — от сети и шлюза. Настраиваем правила распространения влияния снизу вверх: деградация диска подсвечивает гипервизор, гипервизор — виртуалки, виртуалки — сервис. В результате директор видит не сорок лампочек, а один светофор «Работа в 1С: зелёный/жёлтый/красный», а инженер по подсвеченной ветке дерева за секунды понимает, почему он красный и с какого узла начинать.

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

Настраиваем уведомления и первый сценарий автоматизации

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

• Telegram-канал для инженеров — туда падают события по инфраструктурным КЕ: деградации, недоступности, пороги по месту и памяти. Это рабочий поток, он может быть шумным, его читают дежурные.
• Дайджест руководителю — короткая сводка по статусам бизнес-сервисов: что падало, сколько длилось, что сделано. Директору не нужны сорок алертов про IOPS — ему нужен ответ на вопрос «работала ли 1С и почта». Формат и периодичность согласуем при внедрении: кому-то достаточно еженедельного письма, кто-то хочет ежедневную сводку к утреннему кофе.

Дальше — первый сценарий автоматизации. В Monq они собираются в low-code конструкторе, и для первого месяца мы всегда делаем один и тот же: эскалация при красном статусе бизнес-сервиса. Логика простая: сервис «Работа в 1С» стал красным → мгновенное сообщение дежурному инженеру → если статус не сменился за оговорённое время, уведомление уходит уровнем выше. Всё, больше на старте не надо.

Важная оговорка именно для Community Edition: лицензия даёт один параллельный обработчик автоматизации. Это значит, что сценарии выполняются последовательно, и длинный тяжёлый сценарий блокирует очередь для остальных. Правила выживания простые: сценарии — короткие и быстрые, никаких многоминутных ожиданий внутри логики, тяжёлые проверки — на стороне источников мониторинга, а не в обработчике. При таком подходе одного обработчика для компании нашего профиля хватает с запасом; упрётесь в лимит — это как раз тот момент, когда стоит смотреть на коммерческую редакцию.

Грабли первого месяца — наш список

Установка — это день. Первый месяц эксплуатации — вот где система либо приживается, либо тихо умирает. Четыре грабли, на которые наступают почти все (мы в своё время — тоже):

Недооценённый диск под логи. Классика: на старте подключили журнал регистрации 1С и события Windows «посмотреть», через три недели диск заполнен, ClickHouse встал, платформа лежит. Правило: после подключения каждого нового источника логов — неделя наблюдения за скоростью роста данных и пересчёт прогноза заполнения диска. df -h / раз в сутки в первые недели — дёшево и отрезвляюще.

Шторм событий от «сырого» источника. Подключили syslog с сетевого железа без фильтров — и получили тысячи событий уровня debug, в которых утонули три действительно важных. Любой новый источник сначала проходит через фильтрацию и нормализацию: в платформу должно попадать только то, на что вы готовы реагировать. Остальное — либо отсекается на источнике, либо фильтруется на входе.

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

Забытая ротация данных. «Хранение без ограничения срока» в CE — это возможность, а не обязанность. Политику хранения задаёте вы: какие данные нужны в полном виде месяц, какие — квартал, что можно агрегировать. Если не задать её осознанно в первый месяц, за вас решит заполненный диск — в самый неудобный момент.

Чек-лист самопроверки через месяц после внедрения:

1. Диск заполнен менее чем на 70%, скорость роста данных известна и прогнозируема.
2. Все поды платформы в Running, счётчики рестартов за неделю не растут.
3. В модели нет КЕ, на события которых никто ни разу не отреагировал.
4. Каждый алерт в канале инженеров требует действия; «информационный шум» отфильтрован.
5. Красный статус бизнес-сервиса хотя бы раз прошёл полный путь: событие → уведомление → реакция → разбор.
6. Руководитель получает дайджест и может пересказать его содержание.
7. Политика хранения данных задана явно, а не «по умолчанию».
8. Есть свежий бэкап конфигурации платформы и понятный план восстановления ВМ.

Если по всем восьми пунктам «да» — поздравляю, у вас не инсталляция, а работающая система мониторинга.

Что дальше

За кадром этой статьи осталось многое, и это осознанно — серию про Monq мы продолжаем. Что уже есть и что впереди:

• Обзор Community Edition — предыдущая статья серии: что умеет платформа, чем девятая версия отличается от ранних, кому бесплатной редакции хватит, а кому нет.
• Подключение Zabbix и Prometheus «зонтиком» — следующий материал: как отдать Monq события из уже работающих систем мониторинга и получить единую картину, не выбрасывая накопленное.
• Эксплуатация и бэкапы — обновление платформы, резервное копирование конфигурации и данных, восстановление после аварии ВМ.
• Отраслевой кейс — разбор реального внедрения у клиента: цифры, инциденты, выводы.

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

Не хочется проходить этот путь самостоятельно — приходите: развернём, построим модель под вашу инфраструктуру и возьмём мониторинг на сопровождение вместе со всей IT-инфраструктурой.