Коробочный Битрикс24 отличается от облака одним неприятным свойством: когда он начинает тормозить, снаружи об этом никто не сообщит. В облаке за инфраструктурой следит вендор, и о проблеме вы узнаёте из статуса сервиса. В коробке сервер ваш, база ваша, и деградация накапливается тихо. Сначала карточка сделки открывается на полсекунды дольше. Потом менеджеры начинают говорить про «подвисания». Через полгода отдел продаж работает в системе, которая отвечает по шесть-восемь секунд, и все давно считают это нормой.
Момент, когда всё окончательно сломалось, обычно так и не наступает. Портал не падает, он просто становится медленнее, и к этому привыкают. Поэтому мониторинг Битрикс24 в коробочной версии работает только как постоянный фон: набор метрик, которые снимаются регулярно и сравниваются с прошлым месяцем. Разовый замер после жалобы даёт мало, потому что сравнить его не с чем.
Три слоя, на которых живут проблемы производительности
Производительность коробки складывается из трёх независимых слоёв, и метрики для каждого свои.
Первый слой, инфраструктура: процессор, память, дисковая подсистема, сеть, состояние сервисов. Здесь проблемы выглядят как рост Load Average, уход в swap, забитый диск или упавший демон.
Второй слой, база данных: медленные запросы, отсутствующие индексы, разросшиеся таблицы, блокировки. Тут деградация чаще связана с объёмом накопленных данных, чем с нагрузкой. То, что летало на десяти тысячах сделок, на трёхстах тысячах начинает пыхтеть.
Третий слой, само приложение: тяжёлые страницы, неэффективные компоненты, кастомные доработки, отвалившееся кеширование, ошибки PHP. Именно здесь чаще всего прячутся последствия самописной автоматизации.
Отдельно стоит четвёртый пункт, который формально относится к инфраструктуре, но ведёт себя самостоятельно. Это сервисы реального времени. Чаты, уведомления, живая лента и мобильное приложение работают через сервер очередей, и он ломается независимо от всего остального.
Встроенный монитор производительности: с чего начинать
В платформе есть штатный модуль «Монитор производительности» (perfmon). Он входит во все редакции продукта, отдельно покупать ничего не нужно. Живёт в административной части, раздел Настройки → Производительность → Панель производительности.
Панель разбита на несколько вкладок, и у каждой своя задача:
- «Тестирование производительности» измеряет, сколько пустых страниц сервер генерирует за секунду. Цифра грубая, но полезная: она отражает связку «железо плюс PHP плюс настройки» без влияния бизнес-логики.
- «Конфигурация» оценивает параметры системы отдельным тестом.
- «Битрикс» показывает таблицу рекомендаций по настройке системы, то есть сверку вашей конфигурации с тем, что вендор считает оптимальным.
- «Разработка» собирает статистику самых нагруженных страниц во время замера.
- «Масштабируемость» тестирует систему под многопоточной нагрузкой.
Начинать имеет смысл с вкладки «Конфигурация». Она измеряет среднее время ответа в секундах, количество операций процессора в секунду, производительность файловой системы, время отправки письма почтовой системой и скорость запросов к базе на чтение, запись и изменение. Пять цифр, которые описывают базовое состояние площадки.
Толк от этих цифр появляется только в динамике. Снимите замер на свежеразвёрнутом портале, запишите результат и повторяйте раз в месяц. Если операции процессора в секунду просели вдвое, а конфигурация не менялась, вы либо соседствуете на гипервизоре с прожорливым соседом, либо сервер начал что-то делать в фоне.
Масштабируемость: как портал ведёт себя под нагрузкой
Вкладка «Масштабируемость» проверяет систему в многопоточном режиме и показывает результаты таблицей: количество одновременных соединений, количество страниц в секунду и время генерации страницы. Это самый честный тест перед тем, как подключать к порталу новый отдел.
Смотреть тут стоит на точку перелома, а не на абсолютные значения. До какого-то количества одновременных соединений время генерации страницы держится ровно, а потом начинает расти нелинейно. Вот эта точка и есть ваш практический потолок. Если в компании сто сотрудников, а перелом наступает на тридцати параллельных соединениях, запаса прочности нет: любой всплеск активности вроде утренней планёрки положит отзывчивость портала.
Тест даёт нагрузку, поэтому на боевом портале в рабочее время его запускать не стоит. Правильное место для него: тестовый контур или окно технических работ.
Метрики уровня приложения: страницы, хиты, компоненты, SQL
Панель производительности только вершина модуля. Под ней есть разделы с детальной статистикой: «Страницы», «Хиты», «Компоненты», «SQL запросы», «Кеширование», «Ошибки PHP», а также «Таблицы», «Проверка БД», «Анализ индексов» и «Список индексов» для работы с базой. Отдельно доступны «Настройки PHP», «Сервер БД» и «История замеров производительности».
Многие пропускают одну деталь: сбор статистики включается вручную и на ограниченное время. В настройках модуля есть параметр «Активность монитора» с текущим статусом и команды «Включить монитор» с указанием длительности и «Отключить монитор». Максимальный срок работы составляет час в обычном режиме и до недели, если включён фильтр только по медленным SQL-запросам.
Логика понятная: сам сбор данных нагружает систему и пишет много информации. Поэтому в настройках модуля журналы управляются по отдельности:
- «Вести журнал предупреждений PHP» регистрирует ошибки и предупреждения интерпретатора;
- «Вести журнал кеширования» сохраняет информацию о файлах кеша, с опцией «Записывать только операции с большими файлами кеша» и настраиваемым порогом размера;
- «Вести журнал SQL запросов» логирует обращения к базе, с опцией «Записывать только медленные SQL запросы» и настраиваемым временем исполнения;
- «Сохранять стек вызова для SQL запросов» показывает, какой именно код породил тяжёлый запрос.
Последний пункт стоит включать всегда, когда вы ищете причину, а не просто фиксируете симптом. Без стека вызова вы получите список медленных запросов и не узнаете, какой компонент или робот их выполняет. Со стеком картина обычно проясняется за один рабочий день.
Для регулярного наблюдения схема выглядит так: журнал SQL с фильтром по медленным запросам включается на неделю раз в месяц, остальные журналы точечно, когда есть конкретная гипотеза. Собранные данные потом чистятся командой «Удалить собранные ранее данные», которая доступна при отключённом мониторе.
База данных: где деградация появляется раньше всего
На коробке с историей в несколько лет база почти всегда становится узким местом первой. Таблицы сделок, дел, истории изменений и логов растут постоянно, а индексы, которых хватало на старте, перестают справляться.
Что смотреть регулярно.
Медленные запросы отслеживаются двумя способами: через журнал SQL-запросов в мониторе производительности и через slow query log на стороне СУБД. Первый покажет запрос в контексте портала, второй в контексте сервера, включая обращения от сторонних интеграций и фоновых задач.
Индексы разбираются в разделах «Анализ индексов» и «Список индексов». Они помогают найти таблицы, по которым запросы идут полным перебором. На больших порталах добавление одного индекса иногда снимает половину проблемы, но добавлять его нужно осознанно: лишние индексы замедляют запись.
Размеры таблиц видны в разделе «Таблицы». Часто выясняется, что половину базы составляют технические логи, которые никто не читает и которые можно чистить по расписанию.
Состояние СУБД отдаёт раздел «Сервер БД». Смотреть стоит на размеры буферов и попадание в кеш. Если рабочий набор данных перестал помещаться в память, портал начнёт упираться в диск, и никакая оптимизация кода это не компенсирует.
Инфраструктура: что снимать на уровне сервера
Штатный монитор производительности видит систему изнутри портала. Чтобы видеть её снаружи, нужен обычный серверный мониторинг. Если коробка развёрнута на «1С-Битрикс: Веб-окружение» (BitrixVM/BitrixEnv), большая часть работы уже сделана: в состав окружения версии 5.x входят Munin и Nagios. Munin собирает метрики и рисует графики, Nagios следит за состоянием компонентов и умеет присылать оповещения.
Включается это через меню виртуальной машины: пункт 9. Monitoring in pool, далее 1. Enable monitoring in the pool. Интерфейсы после включения доступны по адресам вида http://адрес_сервера/munin/ и http://адрес_сервера/nagios/.
Здесь есть важная деталь по безопасности. У обоих интерфейсов после установки стандартные учётные данные, описанные в публичной документации вендора. Их нужно менять сразу же, утилитой htpasswd для файлов /etc/munin/passwd и /etc/nagios/passwd. Панель мониторинга со стандартным паролем на публичном адресе выкладывает карту вашей инфраструктуры в открытый доступ.
Минимальный набор метрик, который должен сниматься непрерывно:
- Load Average и загрузка CPU по ядрам. Одно упёршееся в потолок ядро при общей загрузке в 20% означает однопоточную задачу, которая тормозит всех.
- Оперативная память и swap. Любая активность swap на портале уже авария, даже если пользователи ещё не жалуются.
- Дисковое пространство отдельно по разделам: под базой, под файлами портала и под логами. Забитый лог-раздел кладёт коробку так же надёжно, как отказ диска.
- Дисковый ввод-вывод: очередь запросов и время отклика. Рост времени отклика диска при неизменной нагрузке обычно означает проблемы на стороне хранилища.
- Состояние сервисов: веб-сервер, PHP-FPM, СУБД, сервер очередей, планировщик. Проверка «процесс жив» здесь слабее, чем проверка «отвечает на запрос».
- Сетевой трафик и количество соединений. Резкий рост соединений без роста активности пользователей это повод посмотреть логи на предмет ботов или сканеров.
Базовая линия важнее абсолютных цифр
Самый частый вопрос при настройке наблюдения звучит так: какие значения считать нормальными. Универсального ответа нет, и любая таблица «правильных» порогов из интернета для вашего портала будет выдумкой. Норма зависит от количества пользователей, объёма базы, набора интеграций и того, сколько кастомного кода живёт в проекте.
Работает подход через собственную базовую линию. Сразу после развёртывания или после ближайшей оптимизации снимите полный набор метрик и сохраните его как эталон: показатели вкладки «Конфигурация», результат теста масштабируемости, среднее время генерации ключевых страниц, размеры основных таблиц, типовую загрузку сервера в пиковый час. Дальше вы сравниваете с собственной историей. Отклонение на 20–30% от базовой линии уже повод разобраться, даже если пользователи ещё ни на что не жалуются.
Агенты и фоновые задачи: скрытый источник тормозов
Про фоновые задачи платформы при настройке мониторинга обычно вспоминают последними. Агенты по умолчанию выполняются на хитах пользователей: тяжёлая периодическая операция запускается в момент, когда кто-то открыл страницу, и этот сотрудник ждёт дольше остальных. На небольшом портале разница незаметна, на нагруженном превращается в случайные подвисания, которые невозможно воспроизвести.
Штатное решение это перевод агентов на cron. Настраивается он через опции модуля main и запуск обработчика по расписанию на стороне сервера. С точки зрения наблюдения появляется побочный, но ценный эффект: фоновая нагрузка перестаёт смешиваться с пользовательской, и на графиках становится видно, что происходит ночью, а что днём.
После перевода на cron за самим планировщиком тоже нужно следить. Отвалившееся задание не даёт явной ошибки: почтовые уведомления просто перестают уходить, а бизнес-процессы зависают на стадиях. Вопрос «когда последний раз отрабатывал агент» стоит в списке обязательных пунктов еженедельного просмотра.
Сервер очередей: отдельная зона наблюдения
Модуль Push & Pull обеспечивает мгновенное взаимодействие между инструментами портала. Через него работают задачи, календари, живая лента, группы, чаты, мобильное приложение, телефония и ряд других сервисов. Для коробочных версий требования к серверному окружению для работы модуля «Веб-мессенджер» изменились ещё в начале 2021 года: сервер очередей стал обязательным условием работы чатов.
Исторически push-сервер был реализован на nginx с дополнительным модулем nginx-push-stream-module, но такая схема не справлялась с нагрузкой, и ей на смену пришёл push-сервер на Node.js. Проверять его состояние нужно отдельно от веб-сервера. Портал может открываться идеально, а сообщения при этом не доходить.
Признак проблемы пользователи замечают раньше любого мониторинга: сообщения в чате появляются только после обновления страницы, счётчики уведомлений не двигаются, звонок в телефонии не показывает карточку. Если такие жалобы повторяются, проверять надо очередь, а не CRM.
Проверка системы: квартальная гигиена
Ещё об одном штатном инструменте вспоминают обычно при обращении в поддержку. Это «Проверка системы». Путь в админке: Настройки → Инструменты → Проверка системы, прямой адрес /bitrix/admin/site_checker.php.
Инструмент проверяет соответствие параметров системы минимальным и рекомендуемым требованиям продукта. В нём две основные вкладки. «Тестирование конфигурации» комплексно проверяет параметры сервера и может занять несколько минут. «Проверка доступа к диску» предлагает варианты полной проверки, проверки папки для загрузки файлов и проверки ядра. Параметры, выделенные красным, требуют исправления: при них корректная работа портала не гарантируется.
Запускать эту проверку разумно ежеквартально и обязательно после любого обновления PHP, СУБД или переезда на другой сервер. Именно там всплывают расхождения, которые потом полгода объясняют необъяснимыми сбоями.
Как собрать всё это в рабочий регламент
Отдельные инструменты бесполезны без расписания. Схема, которая работает на коробках среднего размера, выглядит так.
Непрерывно и автоматически снимаются серверные метрики через Munin и Nagios с оповещениями на почту или в мессенджер. Пороги настраиваются под конкретный сервер, значения по умолчанию тут почти всегда мимо.
Еженедельно вы просматриваете графики за неделю. Задача не в том, чтобы найти аварию, а в том, чтобы заметить тренд. Память, которая каждую неделю прирастает на пару процентов, за квартал доведёт сервер до swap.
Ежемесячно делается замер на вкладке «Конфигурация» со сравнением с прошлым месяцем плюс неделя сбора медленных SQL-запросов.
Ежеквартально запускается «Проверка системы», проводится ревизия размеров таблиц, чистка технических логов и проверка резервных копий на восстановление.
Перед каждым изменением снимается замер до и после. Внедрили новую воронку с двадцатью роботами, снимите метрики до запуска и через неделю после. Иначе через полгода никто не вспомнит, что именно замедлило портал.
Как это выглядит на практике, проще показать на условном примере. Портал на семьдесят пользователей начинает подтормаживать по утрам. Серверные графики показывают всплеск дискового ввода-вывода с девяти до десяти утра, CPU при этом свободен. Журнал медленных SQL-запросов со стеком вызова указывает на выборку по большой таблице истории. Дальше вариантов два: добавить индекс или ограничить выборку. Без мониторинга ту же задачу решали бы перебором гипотез неделями, а закончилось бы всё покупкой более мощного сервера, который тормозил бы точно так же, только дороже.
Когда пора звать подрядчика
Своими силами закрывается многое: включить мониторинг, настроить оповещения, регулярно снимать замеры. Сложности начинаются там, где метрики уже собраны, а что с ними делать, непонятно. Чтение стека вызова, решение о добавлении индекса, тюнинг СУБД и разбор кастомного кода требуют человека, который делал это не один раз.
Мы в B2BPRO.KZ занимаемся коробочными порталами как раз с этой стороны: настраиваем мониторинг, разбираем накопленную деградацию и приводим в порядок то, что тормозит. Если производительность коробки стала проблемой, посмотрите наши услуги по Битрикс24. Начать можно с разового аудита, а дальше решать, нужна ли постоянная поддержка.
Производительность коробочного Битрикс24 меняется сама по себе, без вашего участия. Портал, который сегодня отвечает за секунду, через год при том же железе будет отвечать за три, просто потому что данных стало больше. Регулярные замеры превращают этот дрейф в управляемую задачу с понятным горизонтом планирования.
Частые вопросы
Нужно ли покупать отдельную лицензию для монитора производительности?
Нет. Модуль «Монитор производительности» входит во все редакции продукта, он уже есть в вашей коробке. Отдельно оплачивать его не нужно.
Можно ли держать сбор статистики включённым постоянно?
Нет, это ограничение самой платформы. Монитор включается на заданный срок: максимум на час в обычном режиме и до недели при фильтре только по медленным SQL-запросам. Ограничение разумное, потому что сбор данных сам по себе нагружает систему.
Мы на обычном хостинге, а не на BitrixVM. Что делать с серверными метриками?
Munin и Nagios привязаны к «1С-Битрикс: Веб-окружение», но сами метрики универсальны. На обычном сервере ставится любая система мониторинга, а список показателей остаётся тем же: CPU по ядрам, память и swap, место на диске, дисковый ввод-вывод, состояние сервисов, соединения.
Портал открывается быстро, но чаты и уведомления отстают. Где искать?
В сервере очередей Push & Pull. Он отвечает за мгновенное взаимодействие в чатах, задачах, календарях, живой ленте и мобильном приложении и выходит из строя независимо от веб-сервера. Смотреть нужно состояние push-сервера.
Как часто снимать замеры, если портал маленький?
На портале до двадцати-тридцати человек хватает ежемесячного замера конфигурации и ежеквартальной «Проверки системы». Непрерывный серверный мониторинг всё равно нужен: он стоит недорого и ловит отказы. Упавший сервис или закончившееся место на диске одинаково критичны при любом размере компании.