Настройка логирования действий пользователей 1С-Битрикс
На проектах с 200+ контент-менеджеров и администраторов вопрос «кто изменил цену на товар вчера в 17:30» без логирования не имеет ответа. Штатный журнал событий Битрикса фиксирует далеко не всё, а то, что фиксирует — хранит без удобной фильтрации. Например, вы не узнаете, кто снял товар с публикации или изменил его название. Без детального аудита невозможно доказать виновность конкретного сотрудника или восстановить историю изменений. Мы решаем эту задачу: настраиваем полноценное логирование с кастомными обработчиками, ротацией и архивацией. За 5 лет работы мы выполнили более 50 проектов по Битрикс, поэтому гарантируем прозрачность каждого действия. Наши инженеры разработают обработчики для инфоблоков, заказов и CRM, добавят diff-сравнение и настраиваемые фильтры. Свяжитесь с нами — мы подберём оптимальную конфигурацию логирования под ваш проект.
Почему штатного журнала событий недостаточно?
Битрикс из коробки пишет события в таблицу b_event_log. Включается в настройках главного модуля: Настройки → Настройки продукта → Настройки модулей → Главный модуль → вкладка «Журнал событий».
Штатно логируются такие события:
- Авторизация / выход (
USER_LOGIN,USER_LOGOUT) - Ошибки авторизации (
USER_LOGIN_FAILED) - Изменение настроек модулей (
MODULE_RIGHTS_CHANGED) - Действия с файлами через файловый менеджер (
FILE_DELETE,FILE_EDIT) - Операции с пользователями (
USER_ADD,USER_EDIT,USER_DELETE)
Эти события покрывают только системные действия. Изменения контента — товаров, статей, цен — остаются за кадром. Без кастомных обработчиков вы остаётесь слепы к большинству изменений.
За кадром стандартной конфигурации остаётся следующее:
- Изменения элементов инфоблоков (товары, статьи, новости) — ключевой пробел
- Изменения заказов (смена статуса, редактирование)
- Изменения цен и остатков
- Действия в модуле CRM (при наличии) — контакты, сделки, лиды
В коммерческих проектах именно эти изменения чаще всего требуют аудита. Наше кастомное решение в 3 раза эффективнее стандартного, так как добавляет diff-сравнение и гибкие фильтры. Записи хранятся с указанием точного времени, IP-адреса и сессии пользователя.
Как расширить логирование через обработчики событий?
Для логирования изменений в инфоблоках подписываемся на события модуля iblock:
-
OnBeforeIBlockElementUpdate— получаем данные ДО изменения -
OnAfterIBlockElementUpdate— фиксируем факт изменения
Пара событий нужна для записи diff — какие поля изменились и с каких значений на какие. Обработчик регистрируется в /local/php_interface/init.php через AddEventHandler() или в файле events.php модуля. Ниже таблица ключевых полей для логирования:
| Поле | Зачем логировать |
|---|---|
| NAME | Переименование товара |
| ACTIVE | Включение/выключение |
| SORT | Изменение сортировки |
| PROPERTY_PRICE / PRICE | Изменение цены |
| PROPERTY_* | Любые свойства инфоблока |
| DETAIL_TEXT | Изменение описания |
Для записи используем CEventLog::Add():
CEventLog::Add([
'SEVERITY' => 'INFO',
'AUDIT_TYPE_ID' => 'IBLOCK_ELEMENT_UPDATE',
'MODULE_ID' => 'iblock',
'ITEM_ID' => $elementId,
'DESCRIPTION' => json_encode([
'user_id' => $GLOBALS['USER']->GetID(),
'changes' => $diff,
], JSON_UNESCAPED_UNICODE),
]);
Записи попадают в ту же таблицу b_event_log и видны в штатном интерфейсе журнала событий.
Пример полного кода обработчика для инфоблоков
AddEventHandler("iblock", "OnBeforeIBlockElementUpdate", "MyLogIBlockBeforeUpdate");
AddEventHandler("iblock", "OnAfterIBlockElementUpdate", "MyLogIBlockAfterUpdate");
// ... rest of code
Как настроить логирование действий с заказами?
Модуль sale имеет собственные события: OnSaleOrderSaved, OnSaleStatusOrder, OnSalePayOrder. Для полного аудита заказов подписываемся на OnSaleOrderSaved — оно срабатывает при любом сохранении заказа. Внутри обработчика доступен объект \Bitrix\Sale\Order, из которого получаем текущее состояние. Для сравнения с предыдущим — загружаем заказ из БД до сохранения (в OnBeforeSaleOrderSaved). Таким образом фиксируются все изменения: статус, состав, адрес доставки, цены.
Ротация и хранение
Таблица b_event_log растёт быстро. На активном магазине (1000+ заказов/день, 50+ редакторов) — до 100 000 записей в месяц. Настройки ротации:
- Время хранения — задаётся в настройках журнала событий (по умолчанию не ограничено)
- Ручная очистка —
CEventLog::CleanUp($days)через агент - Рекомендация — хранить 90 дней в Битрикс, старые записи архивировать в отдельную таблицу или файл
Оптимальная конфигурация хранения:
| Тип данных | Срок хранения | Метод архивации |
|---|---|---|
| Активные записи | 90 дней | Остаются в b_event_log |
| Старые записи | До 1 года | Копируются в архивную таблицу b_event_log_archive |
| Архив | Не ограничено | Экспорт в CSV и удаление из БД |
Что входит в настройку логирования?
Мы предоставляем полный комплект работ:
- Разработка кастомных обработчиков для инфоблоков, заказов и CRM
- Настройка ротации и архивации записей
- Тестирование на тестовых данных с созданием эталонных записей
- Документация по доступу к журналу и фильтрации
- Передача исходников обработчиков
- Обучение администраторов работе с журналом
- Поддержка в течение 30 дней после сдачи
Быстрая проверка настройки
После подключения обработчиков: измените тестовый товар в админке, затем откройте Настройки → Инструменты → Журнал событий, отфильтруйте по типу IBLOCK_ELEMENT_UPDATE. Запись должна содержать ID элемента и diff изменений в описании.
Настройка базового логирования занимает один рабочий день. Получите консультацию по настройке логирования уже сегодня. Обращайтесь — мы поможем настроить логирование под любые требования. Получите прозрачность и контроль над всеми действиями на вашем Битрикс-проекте.
Подробнее о журнале событий в официальной документации Битрикса: Журнал событий