Эксплуатация Monq CE в проде: обновления, бэкапы, безопасность и тюнинг — регламент, по которому мы обслуживаем мониторинг клиентов

Кто мониторит мониторинг: проблема последней инстанции

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

Первый вопрос, который надо решить, — кто заметит, что сам Monq умер. Система, которая следит за всем, сама по себе никем не наблюдается, и в момент её отказа наступает тишина, неотличимая от «всё хорошо». У нас это решается двумя независимыми способами:

• Внешняя перекрёстная проверка. С нашей площадки в ЦОД МТС (физически другое здание и другой канал) раз в минуту выполняется простая проба: веб-интерфейс Monq клиента отвечает кодом 200, а публичный API потока принимает тестовое событие. Пробу делает наш центральный Zabbix — та самая система, которую Monq у клиента якобы «заменяет». Взаимный контроль двух систем надёжнее любого самоконтроля.
• Встроенный самоконтроль «нет данных». На каждом ключевом потоке в Monq стоит порог: если от источника не приходило ни одного события или метрики дольше N минут (для агентов — 5, для вебхуков Zabbix — 30, для синтетики — 20), это само по себе событие высокой важности. Молчание источника — не норма, а симптом: отвалился агент, истёк ключ потока, поменяли пароль технической учётки.

Регламент эксплуатации: день / неделя / месяц

Регламент — это не документ «на случай проверки», а список действий, которые дежурный инженер выполняет по расписанию и отмечает в журнале. У нас он устроен тремя кольцами.

Самый недооценённый пункт — ежемесячная сверка с реальной инфраструктурой. За месяц у клиента появляется новая виртуалка «на пробу», которая через полгода становится продуктивной, но в мониторинге её нет. Или наоборот: сервер вывели, а его агент продолжает числиться и генерировать событие «нет данных», на которое все привыкли не смотреть. Забытый источник — слепая зона, привычный ложный алерт — ржавчина на всей системе.

Управление данными: ретеншн, диски, производительность

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

Наши типовые сроки хранения для клиента на 30–50 рабочих мест:

Под капотом платформы — ClickHouse для логов и аналитики, VictoriaMetrics для метрик, PostgreSQL для конфигурации, плюс ArangoDB, Redis, RabbitMQ и Consul, всё это внутри k3s-кластера. Требование документации — весь диск смонтирован в корень, файловая система ext4 или xfs, SSD. Мы закладываем 200 ГБ и следим за двумя цифрами: свободное место и скорость его расходования в гигабайтах в неделю. Расширять диск под нагруженным кластером можно, но это операция с окном простоя, поэтому лучше расширить заранее при 70% заполнения, чем аварийно при 95%.

Признаки деградации, которые мы проверяем первыми, когда «что-то стало медленно»:

1. Отставание потоков. Событие, которое Zabbix отправил минуту назад, появляется в Monq с задержкой в несколько минут. Обычно — очередь в брокере или перегруженный обработчик.
2. Медленный интерфейс на экранах логов. Почти всегда ClickHouse упёрся в диск: проверяем IOPS на уровне гипервизора; виртуалка на общем HDD-датасторе с другими ВМ — типичная причина.
3. Рост потребления памяти контейнерами хранилищ. Смотрим штатными средствами k3s: kubectl top pods -A; если под ClickHouse перезапускается по нехватке памяти — режем объём логов на входе, а не добавляем память до бесконечности.

Бэкап самой системы мониторинга

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

Документация вендора здесь лаконична: настроить регулярное резервное копирование и отладить контрольное восстановление до запуска в прод. Как именно — решать эксплуатанту. Наш минимум:

• Снапшот виртуальной машины по расписанию. Ежедневно ночью, хранение семь суток, раз в неделю — копия на отдельное хранилище. Это единственный способ, который гарантированно поднимает весь k3s-стек в согласованном состоянии: шесть хранилищ внутри кластера бэкапить по отдельности и потом сводить — занятие для энтузиастов. Снапшот делаем в окне минимальной нагрузки, когда ClickHouse не пишет крупные блоки.
• Выгрузка конфигурации перед изменениями. Перед каждым крупным изменением — новым источником, пакетом порогов, обновлением платформы — фиксируем состояние: экспорт того, что платформа умеет экспортировать (пороги, сценарии автоматизации, настройки потоков), плюс внеочередной снапшот. Выгрузки лежат в репозитории клиента с датой и описанием, что менялось.
• Документ «как поднять с нуля». Если снапшоты по какой-то причине непригодны, инженер должен за рабочий день развернуть платформу заново по инструкции и воспроизвести настройки из выгрузок. Эта инструкция — часть паспорта системы, о котором ниже.

Раз в полгода — тест восстановления на изолированном стенде: поднимаем снапшот в отдельной сети без доступа к продуктивным источникам, проверяем, что интерфейс открывается, пороги и сценарии на месте, история событий читается. По результатам фиксируем в паспорте два числа: RPO (у нас — сутки, по частоте снапшотов) и RTO (у нас — 4 часа из снапшота, рабочий день с нуля).

Обновления платформы: как не превратить апдейт в аварию

Линейка Monq 9 развивается быстро: 9.0.0 вышла 10 октября 2025 года, 9.1.0 — 19 ноября, 9.1.1 — 28 ноября, 9.2.0 — 10 июля 2026-го, 9.2.1 — 23 июля. То есть за девять месяцев — пять релизов, и каждый приносит не только возможности, но и изменения в требованиях. Сидеть на версии годичной давности — значит накопить скачок, который потом проходится болезненнее регулярных шагов.

Ключевое правило из документации вендора: обновления ставятся строго последовательно, пропускать версии нельзя. На странице загрузки публикуется последняя кумулятивная версия, а всё, что вышло после неё, накатывается вручную по порядку. Для обновления инсталляции нужен доступ к трём адресам — release-hub.monq.ru, registry.monq.ru и downloads.monq.ru; если мониторинг живёт в закрытом контуре с белым списком, эти адреса должны быть в нём заранее.

Наш порядок обновления:

1. Читаем список изменений. Особое внимание — разделам про изменения требований и миграции хранилищ. Например, в 9.2 хранилище порогов переехало из PostgreSQL в ClickHouse: ускорение на больших объёмах заметное, но это миграция данных, и её лучше делать с бэкапом под рукой.
2. Бэкап. Внеочередной снапшот ВМ плюс выгрузка конфигурации. Без этого шага обновление не начинается — правило без исключений.
3. Окно. Обновляем вечером или в выходной, вне отчётного периода клиента. На время обновления клиент предупреждён, что мониторинг может молчать, а внешняя проба с нашей площадки переведена в режим «ожидаем простой», чтобы не будить дежурного.
4. Smoke-тест. После обновления: интерфейс открывается, лицензия активна, потоки принимают данные (смотрим свежие события от Zabbix и агентов), пороги вычисляются, тестовое событие проходит сценарий уведомления до Telegram. Пять проверок, десять минут.
5. Уборка. Старые образы контейнеров после обновления автоматически не удаляются и занимают гигабайты. Чистим штатно: crictl rmi --prune. Этот шаг часто забывают, а потом удивляются, куда делось 20 ГБ диска.

Для клиентов с особо чувствительной инфраструктурой мы держим у себя стенд с копией их инсталляции и сначала обновляем его. Для типового клиента до 50 рабочих мест достаточно снапшота и окна: откат из снапшота занимает 15 минут.

Безопасность инсталляции

Система мониторинга знает о вашей инфраструктуре всё: имена серверов, адреса, версии, топологию, какие сервисы от чего зависят и когда они падают. Это карта для злоумышленника, и защищать её надо соответственно. Наш чек-лист:

• Только HTTPS с нормальным сертификатом. Документация вендора прямо рекомендует сертификаты от доверенного центра; самоподписанные — источник привычки кликать «продолжить» на любые предупреждения. Срок действия сертификата — в мониторинг с порогом 14 дней.
• Никакого проброса панели в интернет. Веб-интерфейс доступен из локальной сети клиента и через VPN с нашей площадки. Наружу у платформы смотрят только порты, нужные для приёма данных от внешних источников, и только с известных адресов. Вебхуки из внешнего Zabbix идут через site-to-site-туннель, а не через публичный адрес.
• Базы и брокеры без внешних адресов. PostgreSQL, ClickHouse, RabbitMQ живут внутри кластера и наружу не публикуются — это требование документации, и проверять его стоит после каждого обновления: ss -lntp на хосте покажет, что слушает внешний интерфейс.
• Роли по минимуму. В CE до десяти пользователей и нет тонкой ролевой модели коммерческих редакций, поэтому распределяем учётки дисциплиной: две — инженерам подрядчика, одна — ИТ-ответственному клиента, одна — руководителю для экрана статусов, остальное — резерв. Общих учёток «admin для всех» не бывает.
• Отдельные технические учётки для интеграций. Учётка Monq в Zabbix — только чтение нужных групп узлов; учётка для опроса гипервизора — только просмотр. Ключи потоков данных — разные для каждого источника, чтобы скомпрометированный ключ вебхука можно было перевыпустить, не трогая остальные.
• Секреты — в менеджере паролей и по графику. Ключи потоков, пароли технических учёток и доступ к кабинету вендора хранятся в корпоративном хранилище с разграничением доступа; ротация — раз в год и при уходе любого инженера, имевшего доступ.
• Патчи ОС. Хостовая Debian обновляется по расписанию вместе с платформой; ядро и openssh — не реже раза в месяц.

Self-hosted как аргумент для регулируемых клиентов

Для медицинских клиник, компаний с государственными контрактами и всех, кто живёт в контексте 152-ФЗ, self-hosted мониторинг — серьёзный плюс: имена серверов, топология и события не покидают контур заказчика, а платформа числится российским продуктом. Но у этого аргумента есть обратная сторона, которую я всегда проговариваю на старте: self-hosted означает, что за патчи, бэкапы и доступы отвечаете вы или ваш подрядчик. Облачный сервис обновляется сам; ваша виртуалка — нет. Если в компании нет человека, который будет выполнять регламент выше, лучше честно передать эту ответственность по договору, чем считать, что «оно само».

Тюнинг шумных алертов: гигиена, без которой всё умрёт

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

Методика еженедельной чистки:

1. Выгружаем топ-10 самых частых событий за неделю — в 9.2 для этого удобен отдельный дашборд порогов, он доступен и в Community Edition, с фильтрами по уровням, правилам и сохранёнными представлениями.
2. По каждому из десяти принимаем одно из трёх решений: чиним причину (диск действительно забит — расширяем), правим порог (80% на диске с логами — это норма, поднимаем до 90), подавляем (событие информационное, из уведомлений убираем, в истории оставляем).
3. Записываем решение в журнал с датой. Через квартал этот журнал показывает, какие источники шумят системно.

Два приёма, которые снимают больше всего шума у офисных клиентов:

• Пороги по календарю. С версии 9.2 одно правило порога поддерживает до двадцати календарных блоков с разными границами: в рабочие часы нагрузка на терминальный сервер 85% — тревога, ночью во время бэкапа — норма; в последние дни квартала порог по очереди SQL выше, потому что бухгалтерия закрывает период. Раньше под это заводили отдельные правила и путались.
• Подтверждение по времени. Событие открывается не при первом превышении, а при трёх подряд: всплеск на одну минуту из-за антивируса — не авария. Единственное исключение — недоступность хоста, там реагируем сразу.

Целевой показатель, к которому мы ведём каждого клиента: не более 5–8 осмысленных уведомлений в рабочий день на инженера, из которых на каждое есть понятный следующий шаг. Если цифра выше — чистим. Если ноль неделю подряд — проверяем, не умер ли мониторинг (см. первый раздел).

Паспорт системы и передача клиенту

Любое внедрение у нас заканчивается документом, который мы называем паспортом системы. Его смысл прост: если завтра ITfresh исчезнет, ИТ-ответственный клиента или новый подрядчик должны продолжить эксплуатацию, не разгадывая ребусы. Состав паспорта:

• Схема: где живёт платформа (ВМ, гипервизор, сеть), какие источники подключены и как (вебхук, коннектор, агент), какие адреса и порты задействованы.
• Перечень учёток и ключей с указанием, где они хранятся (не сами секреты — ссылки на записи в менеджере паролей) и когда ротировались.
• Регламент день/неделя/месяц с журналом выполнения за последний квартал.
• Политика хранения данных и параметры бэкапа с зафиксированными RPO/RTO и датой последнего теста восстановления.
• История обновлений: версия, дата, кто делал, что сломалось и как починили.
• Контакты эскалации: кто первый, кто второй, куда звонить вендору, где личный кабинет с лицензией.

Что должен уметь ИТ-ответственный на стороне клиента после передачи: войти в систему и прочитать экран событий; понять, какой источник замолчал; перезапустить агент на сервере; сделать внеочередной снапшот перед рискованными работами; позвонить по эскалации. Настраивать пороги и сценарии — уже наша работа по договору, но базовый минимум должен быть в руках заказчика.

Чек-лист самоаудита эксплуатации

Пятнадцать вопросов, на которые честный ответ «да» означает, что мониторинг у вас действительно эксплуатируется, а не просто установлен:

1. Есть внешняя проверка доступности самого Monq с независимой площадки и независимым каналом уведомления?
2. Для каждого ключевого источника настроен порог «нет данных N минут»?
3. Ежедневный разбор событий выполняется и фиксируется?
4. Еженедельно чистится топ-10 шумных событий?
5. Сроки хранения заданы по типам данных, а не оставлены по умолчанию?
6. Известна скорость расходования диска и дата, когда он кончится при текущем темпе?
7. Снапшот ВМ делается по расписанию и хранится на отдельном носителе?
8. Восстановление из бэкапа тестировалось за последние полгода?
9. Платформа обновлена до актуальной версии, а промежуточные шаги пройдены по порядку?
10. Веб-интерфейс недоступен из интернета напрямую?
11. У каждой интеграции своя техническая учётка с минимальными правами и свой ключ потока?
12. Количество пользователей известно и вписывается в лимит редакции, общих учёток нет?
13. Сертификат и лицензионный ключ под мониторингом срока действия?
14. Список источников сверен с реальной инфраструктурой в этом месяце?
15. Паспорт системы существует, актуален и лежит там, где его найдут без вас?

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