Self-hosted мониторинг сайта: как выбрать закрытый контур
Сравнение module-only, self-hosted и SaaS для 1С-Битрикс CMS: где лежат данные, как проверить egress и пройти ИБ-чеклист без гайда по Uptime Kuma.
ИБ запретил облачный мониторинг, а интегратор поставил Uptime Kuma "внутри контура" и успокоился. На аудите всплыла типичная проблема: модуль Битрикс шлёт heartbeat наружу, а Kuma не видит ни диск, ни бэкапы, ни зависшие агенты. За один проход выберете поставку для сайта на 1С-Битрикс: Управление сайтом — module-only, свой self-hosted стек или облачный SaaS в РФ. Пройдёте чеклист, что метрики не уходят за периметр без согласования.
Self-hosted мониторинг - это когда программа крутится на вашем сервере, а не у чужого провайдера в облаке. Для CMS Битрикс одного "пинга" мало: нужны внешняя доступность и внутренние метрики (диск, бэкап, агенты, лицензия). Три поставки: только модуль на сайте, свой контур (Docker/Kuma/Zabbix) или SaaS с данными в РФ. Перед запуском сверьте egress, состав данных и договор с политикой на /privacy/.
Статья про сайт на CMS "1С-Битрикс: Управление сайтом" на своём хостинге. В выдаче по запросу «закрытый контур мониторинг битрикс» часто попадают материалы про CRM-портал в изолированной сети — это другая задача, не замена мониторинга витрины.
Типичная ошибка: путать "сервер в России" у SaaS-провайдера с "данные не покидают наш DMZ". Первое - хостинг у вендора, второе - вы контролируете, куда уходит трафик модуля и алертов.
Определите, когда облачный мониторинг нельзя
Облачный SaaS удобен: probe снаружи, кабинет, алерты за минуты. Но ИБ или заказчик может заблокировать сценарий, если метрики, логи или webhook уходят за периметр без договора.
Чаще всего блокируют не "мониторинг как идею", а конкретные риски:
- требование хранить технические данные только в инфраструктуре заказчика (закрытый контур, air-gap);
- политика по 152-ФЗ: локализация и договор поручения, если в потоке теоретически могут оказаться персональные данные;
- запрет исходящих соединений на произвольные домены - только whitelist;
- аудит АС МПДн: нужно доказать состав передаваемых полей, а не "мы доверяем вендору".
Делать: зафиксировать требование письменно (что можно наружу, какие порты, какие каналы алертов). Не делать: ставить Kuma "для галочки" и не проверять, куда модуль реально стучится ночью.
Сравните три поставки для сайта на Битрикс
Три варианта: данные только на сервере сайта, в DMZ клиента или у провайдера в РФ
Module-only - модуль в /local/modules/ собирает внутренние метрики и алертит локально (email, webhook внутри сети), без облачного кабинета. Self-hosted - вы поднимаете стек у себя (Uptime Kuma, Zabbix, BX Pulse в Docker): probe и база в вашей инфраструктуре. SaaS - модуль и внешние проверки идут в кабинет провайдера; старт быстрый, если ИБ не против.
| Критерий | Module-only | Self-hosted у клиента | Облачный SaaS (РФ) |
|---|---|---|---|
| Где лежат данные | На сервере сайта | В DMZ / VPS клиента | У провайдера (часто РФ) |
| Внешний uptime | Нет без отдельной probe | Да, если probe снаружи или в DMZ | Да, из коробки |
| Диск, бэкап, агенты Bitrix | Да (модуль) | Да (модуль или Zabbix-скрипты) | Да (модуль) |
| Сопровождение | Низкое | Высокое (патчи, бэкапы, on-call) | Низкое |
| Время старта | Часы | Дни - недели | Минуты (см. гайд за 15 минут) |
Делать: выбирать поставку по требованию ИБ, а не по моде "все ставят Kuma". Не делать: дублировать B10 - там уже разобраны классы аналогов UptimeRobot, включая self-hosted Kuma как строку в таблице.
Итоговый вердикт: строгий air-gap без исходящего интернета - module-only или self-hosted BX Pulse в контуре. Есть DevOps и нужна глубина - Zabbix плюс модуль. ИБ не блокирует облако - SaaS в РФ быстрее всего; сравнение классов сервисов - в обзоре аналогов UptimeRobot.
Разберите классы self-hosted без гайда по установке
Kuma закрывает uptime, Zabbix - инфраструктуру, module-only - внутренние метрики CMS без облака
В поиске доминируют how-to по Uptime Kuma - мы их не повторяем. Важно понять роль класса, а не копировать docker-compose из Habr.
Uptime Kuma (и похожие) - self-hosted "пингер": HTTP, TCP, ping, SSL с красивой панелью. Не видит диск Битрикс, бэкапы и агенты. На одном хосте с сайтом может не заметить внешнее падение - probe должна жить в другом домене отказа.
Zabbix / Prometheus - мощная инфраструктура: агенты, триггеры, зависимости алертов. Для одного сайта без SRE-команды часто избыточен: дни настройки, отдельный on-call за сам мониторинг. Имеет смысл при десятках серверов и готовых шаблонах под Bitrix.
Module-only или модуль + свой backend - фокус на CMS: heartbeat, диск, бэкап, лицензия. Внешний uptime подключаете отдельно или через self-hosted probe в том же контуре.
Если сайт на VPS в РФ, но не в закрытом контуре, "русский сервер" у SaaS и свой Kuma на VPS - разные уровни контроля. Для тестового размещения probe удобен проверенный хостинг, например Beget - но для банковского DMZ это не замена согласованного whitelist.
Делать: комбинировать внешний synthetic и внутренний модуль. Не делать: считать Kuma полноценным мониторингом Битрикс.
Пройдите чеклист: метрики не уходят наружу
Семь пунктов проверки периметра перед сдачей аудиту
Чеклист для ИБ и интегратора - не формальность. Он отвечает на вопрос "куда реально уходит трафик после установки модуля".
- Состав данных: сверьте с политикой вендора - нет заказов, форм, cookie, файлов upload, ключей лицензии. Для BX Pulse канон - страница политики и передаваемых данных.
- Egress с сервера сайта: на время теста смотрите firewall log или tcpdump - куда уходит heartbeat модуля и retry-очередь.
- Whitelist: в закрытом контуре разрешите только согласованные FQDN и порты; иначе модуль будет копить локальную очередь.
- Probe-ноды: внешние проверки - с IP, которые ИБ знает; при полном air-gap - только internal synthetic плюс module-only.
- Webhook и алерты: URL webhook внутри периметра; секрет HMAC не в логах; Telegram и email - по политике исходящих каналов.
- Договорная база для SaaS: договор поручения по 152-ФЗ, реестр оператора, актуальная privacy.
- SERP-шум: требование «CRM в изолированной сети без интернета» не заменяет мониторинг CMS — не подменяйте задачи.
Делать: прогнать чеклист до production. Не делать: полагаться на устное "у нас всё внутри" без логов.
Схема проверки периметра:
Установка модуля → снятие egress 24 ч → сверка с privacy → тест webhook внутри сети → документ для ИБ → только потом включение внешних probe
Выберите сценарий: дерево решений для интегратора
Короткий алгоритм без лишней теории:
- ИБ запрещает любой исходящий трафик с боевого сайта → module-only с локальными алертами или self-hosted backend в том же контуре.
- Исходящий разрешён только на согласованный API в РФ → SaaS с подписанным договором и проверенной privacy; быстрый старт — настройка за 15 минут.
- Есть DevOps, нужны сотни метрик и корреляция → Zabbix (или аналог) плюс Bitrix-модуль; закладывайте сопровождение, не только установку.
- Нужен только uptime внутри LAN → класс Kuma, но добавьте контроль диска и агентов отдельно; до закупки покажите демо BX Pulse в read-only режиме.
- После выбора сценария зафиксируйте поставку в паспорте проекта и назначьте владельца алертов до включения внешних probe.
- Готовы к пилоту после чеклиста ИБ → войдите в кабинет BX Pulse и подключите первый сайт.
Если облако допустимо, но важны Bitrix-метрики изнутри, пилот SaaS или self-hosted обсуждайте после чеклиста - не до него.
Что дальше: отправьте тестовое уведомление по выбранному каналу и приложите к паспорту проекта пройденный чеклист egress. Если ИБ уже согласовала SaaS или self-hosted — войдите в кабинет BX Pulse и подключите первый сайт.
Делать: один стек и один чеклист на проект. Не делать: параллельно три системы "на всякий случай" - получите шторм ложных алертов.
Материал проверен. Автор: Максим Мольков, основатель BX Pulse, инженер по эксплуатации 1С-Битрикс.
Источники:документация 1С-Битрикс, практика внедрений CMS в закрытых контурах, политика передаваемых данных BX Pulse.
Вопросы и ответы
Частые вопросы про self-hosted мониторинг и закрытый контур для сайта на Битрикс.
Безопасен ли модуль мониторинга для сайта на Битрикс?
Нормальный модуль работает read-only: собирает служебные метрики (диск, агенты, версии), не читает заказы и не выгружает upload. Перед установкой откройте политику вендора, прогоните чеклист egress и убедитесь, что исходящий трафик разрешён ИБ.
Нужен ли модулю доступ к базе данных сайта?
Для внутренних проверок модуль использует API и окружение Битрикс, а не произвольные SELECT по таблицам заказов. Уточните в документации решения: если вендор требует широкие права к БД - это красный флаг для ИБ.
Где хранятся данные при self-hosted и при SaaS?
При self-hosted - на серверах клиента (DMZ/VPS). При SaaS - у провайдера, часто в РФ, но это не ваш контур. Module-only хранит всё на сервере сайта. Сверьте вариант с требованием заказчика и страницей privacy.
Чем self-hosted отличается от "мониторинга на русском сервере"?
"Русский сервер" у SaaS значит, что провайдер хостит сервис в РФ. Self-hosted - вы сами ставите софт у себя и отвечаете за патчи и бэкапы. Для строгого DMZ второе ближе к требованию "данные не наружу".
Достаточно ли Uptime Kuma для сайта на Битрикс?
Для внешней доступности - часто да. Для эксплуатации CMS - нет: Kuma не ловит переполненный диск, старый бэкап и зависшие агенты. Добавьте Bitrix-модуль или Zabbix-метрики, иначе главная будет "зелёной", а бизнес - нет.
Как проверить, что heartbeat модуля не уходит за периметр?
Снимите лог firewall или tcpdump на 24 часа после установки, сравните адреса с whitelist ИБ и с политикой вендора. Если адрес не согласован - переключитесь на module-only или self-hosted backend внутри контура.
Когда выбрать облако, а не свой контур?
Когда ИБ не блокирует SaaS в РФ, нужен быстрый старт и нет команды на сопровождение Zabbix/Kuma. Пройдите чеклист privacy, подпишите договор при необходимости и настройте мониторинг по гайду за 15 минут - self-hosted оставьте для жёсткого периметра.
