--- title: Мониторинг 1С-Битрикс изнутри — что показывает «Проверка системы» и чего она не покажет description: У Битрикса есть штатная «Проверка системы», монитор производительности и агенты — но их никто не смотрит, пока сайт не ляжет. Как превратить встроенную диагностику в автоматический мониторинг с алертами. source: https://pingvera.ru/blog/monitoring-bitrix-iznutri.html --- # Мониторинг 1С-Битрикс изнутри: что показывает «Проверка системы» и чего она не покажет У Битрикса, в отличие от большинства CMS, встроенная диагностика на удивление приличная: «Проверка системы» гоняет несколько десятков тестов, монитор производительности считает нагрузку, панель агентов показывает фоновые задачи. Проблема ровно одна, и она не техническая: **всё это надо открыть руками**. А открывают обычно тогда, когда сайт уже лёг и клиент звонит. ## Что Битрикс уже умеет сам Отдадим должное, прежде чем что-то предлагать: - **Проверка системы** (_Настройки → Инструменты → Проверка системы_) — десятки тестов: права на файлы, настройки PHP, база данных, почта, соединение с сайтом, безопасность. Выдаёт «успешно», «предупреждение» или «ошибка» по каждому. - **Монитор производительности** — измеряет скорость, показывает тяжёлые запросы и компоненты. - **Панель агентов** — фоновые задачи и их расписание. - **Проактивный фильтр (WAF)** — защита от типовых атак, если он включён. Это хорошие инструменты. Но все они пассивные: показывают состояние тому, кто пришёл посмотреть. Никто не смотрит на клиентский сайт каждый день. И самое обидное — проблемы, которые они находят, обычно копятся неделями до того, как проявятся. ## Что ломается тихо и стоит дорого ### Просроченные агенты Агенты Битрикса по умолчанию запускаются «на хитах» — при заходе посетителя. На сайте с небольшим трафиком они накапливают отставание, а если что-то пошло не так, встают совсем. Дальше тихо ломается всё фоновое: не уходят письма о заказах, не индексируется поиск, не идёт обмен с 1С, не выполняются служебные задачи. Сайт при этом открывается прекрасно и отдаёт честные 200. Правильное решение известно — перевести агенты на настоящий cron. Проблема в том, что «известно» не значит «сделано»: на клиентских сайтах агенты годами висят на хитах, и никто не замечает, пока клиент не спросит, почему заказы из магазина не попадают в 1С. ### Выключенный кеш и композит Управляемый кеш отключили при отладке и забыли включить. Композитный сайт не настроен. Сайт работает — просто в несколько раз медленнее, чем мог бы, и ложится под нагрузкой, которую пережил бы легко. Снаружи это выглядит как «сайт иногда тормозит» — самая бесполезная формулировка в поддержке. ### Отключённый проактивный фильтр Его отключают, чтобы «заработала форма» или чтобы не мешал интеграции, и почти никогда не включают обратно. Сайт живёт без защиты от типовых атак месяцами. Внешне — никак не проявляется. До момента взлома. ### Магазин перестал принимать заказы Самое дорогое. Витрина открывается, корзина считает, а заказы не проходят: платёжная система отключилась, оформление сломалось после обновления, растёт доля неоплаченных заказов. Мы [разбирали это подробно](https://pingvera.ru/blog/magazin-rabotaet-a-zakazov-net.html) — для магазина на Битриксе история ровно та же, что для WooCommerce. ## Идея простая: сделать штатную диагностику автоматической Мы не стали изобретать свои проверки там, где Битрикс уже всё придумал. Наш модуль ставится штатным способом, работает по расписанию самого Битрикса и **переиспользует его же диагностику** — читает результаты «Проверки системы», смотрит агенты, кеш, настройки безопасности. Наружу уходят только вердикты; никакого удалённого управления сайтом, модуль сам проверяет и сам отправляет. Что он отслеживает по факту: - **Результаты штатной проверки системы** — упавшие и предупреждающие тесты становятся событиями, а не строчками в админке, которую никто не откроет. - **Агенты** — просрочены ли, работают ли на хитах вместо cron. - **Кеш** — выключен ли управляемый кеш, не настроен ли композит, растёт ли размер кеш-файлов. - **Безопасность** — выключенный проактивный фильтр. - **Магазин** — поток заказов против нормы этого магазина, всплеск неоплаченных, доступность страницы оформления, наличие активных платёжных систем. Критичное (сломанное оформление заказа, всплеск неоплаченных) сразу летит алертом в Telegram, почту или Max. Остальное копится в панели здоровья сайта и попадает в отчёт клиенту. ## Снаружи и изнутри: что видит кто Ни один столбец не заменяет другой. Если сайт лёг, модуль внутри молчит — потому что он лежит вместе с сайтом; об этом скажет только внешняя проверка. Если встали агенты, внешняя проверка счастливо покажет зелёное — потому что сайт-то открывается. ## Зачем это студии на поддержке Битрикс-проекты почти всегда на абонентке, и главный вопрос клиента — «за что я плачу, если сайт и так работает». Внутренняя диагностика отвечает на него содержательно: в [отчёте за месяц](https://pingvera.ru/blog/kak-sledit-za-saytami-klientov.html) вместо «аптайм 99,9 %» появляется «починили агенты, из-за которых не уходили письма о заказах; включили кеш, сайт стал отвечать вдвое быстрее; вернули проактивный фильтр». Это разговор про деньги клиента, а не про наши графики. ## Частые вопросы **Что такое агенты в Битриксе и почему они отстают?** Агенты — фоновые задачи: отправка почты, индексация поиска, обмен с 1С, служебные операции. По умолчанию они запускаются «на хитах», то есть при заходе посетителя, и на низком трафике накапливают отставание. Если агенты просрочены, тихо ломается всё фоновое — от писем до обмена с учётной системой, при этом сайт открывается нормально. **Чем «Проверка системы» отличается от мониторинга?** Это разовая диагностика, которую надо открыть руками в админке и нажать кнопку. Она хорошо находит проблемы, но не следит за ними: никто не запускает её каждый день и не получает уведомление, когда результат ухудшился. Мониторинг — это когда та же диагностика идёт автоматически и присылает алерт при критичной проблеме. **Что видно изнутри, чего не видно снаружи?** Просроченные агенты, выключенный управляемый кеш и композит, отключённый проактивный фильтр, результаты штатной проверки системы, состояние приёма заказов в магазине: поток заказов, всплеск неоплаченных, отсутствие активных платёжных систем. Снаружи всё это выглядит как работающий сайт с кодом 200. **Нужен ли модуль, если уже есть внешний мониторинг?** Они закрывают разные слепые зоны. Внешний мониторинг единственный заметит падение сайта или хостинга — изнутри в этот момент жаловаться некому. Модуль внутри видит то, что снаружи невидимо: агенты, кеш, безопасность, приём заказов.