Настройка логирования действий пользователей 1С-Битрикс
Когда на сайте 200+ контент-менеджеров и администраторов, вопрос «кто изменил цену на товар вчера в 17:30» без логирования не имеет ответа. Штатный журнал событий Битрикса фиксирует далеко не всё, а то, что фиксирует — хранит без удобной фильтрации. Задача — настроить полноценное логирование: кто, когда, что сделал, какие значения были до и после.
Штатные средства: модуль «Журнал событий»
Битрикс из коробки пишет события в таблицу b_event_log. Включается в настройках главного модуля: Настройки → Настройки продукта → Настройки модулей → Главный модуль → вкладка «Журнал событий».
Что логируется штатно:
- Авторизация / выход (
USER_LOGIN,USER_LOGOUT) - Ошибки авторизации (
USER_LOGIN_FAILED) - Изменение настроек модулей (
MODULE_RIGHTS_CHANGED) - Действия с файлами через файловый менеджер (
FILE_DELETE,FILE_EDIT) - Операции с пользователями (
USER_ADD,USER_EDIT,USER_DELETE)
Что НЕ логируется:
- Изменения элементов инфоблоков (товары, статьи, новости)
- Изменения заказов (смена статуса, редактирование)
- Изменения цен и остатков
- Действия в модуле CRM (при наличии)
Именно эти действия обычно и нужно отслеживать.
Расширение логирования через обработчики событий
Для логирования изменений в инфоблоках подписываемся на события модуля 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 и видны в штатном интерфейсе журнала событий.
Логирование действий с заказами
Модуль sale имеет собственные события: OnSaleOrderSaved, OnSaleStatusOrder, OnSalePayOrder. Для полного аудита заказов подписываемся на OnSaleOrderSaved — оно срабатывает при любом сохранении заказа.
Внутри обработчика доступен объект \Bitrix\Sale\Order, из которого получаем текущее состояние. Для сравнения с предыдущим — загружаем заказ из БД до сохранения (в OnBeforeSaleOrderSaved).
Ротация и хранение
Таблица b_event_log растёт быстро. На активном магазине (1000+ заказов/день, 50+ редакторов) — до 100 000 записей в месяц. Настройки ротации:
- Время хранения — задаётся в настройках журнала событий (по умолчанию не ограничено)
-
Ручная очистка —
CEventLog::CleanUp($days)через агент - Рекомендация — хранить 90 дней в Битрикс, старые записи архивировать в отдельную таблицу или файл
Быстрая проверка настройки
После подключения обработчиков: измените тестовый товар в админке, затем откройте Настройки → Инструменты → Журнал событий, отфильтруйте по типу IBLOCK_ELEMENT_UPDATE. Запись должна содержать ID элемента и diff изменений в описании.
Настройка базового логирования занимает один рабочий день. Сюда входит написание обработчиков для инфоблоков и заказов, проверка на тестовых данных и настройка ротации.