Журналирование действий в Битрикс: журналы сайта для диагностики

Журналирование действий в Битрикс — это фиксация событий сайта для восстановления последовательности действий пользователей и системных процессов. Ниже — рабочая схема журналирования, разбор связки «действие пользователя — сбой интеграции», учебный пример и чек-лист приёмки.

Задача бизнеса и границы решения

При сбоях (пропажа товара, ошибки оплаты) возникает вопрос: «Что именно произошло?» Без журналов диагностика невозможна, так как нет данных о последовательности действий. Журналирование действий в Битрикс решает именно эту задачу — оставляет след, по которому можно восстановить ход событий.

Границы решения важно очертить сразу, иначе проект расползётся:

• Журналирование не предотвращает сбои, но делает их наблюдаемыми и поддающимися анализу.
• Журналирование не заменяет мониторинг доступности и не подменяет резервное копирование.
• Журналирование не равно «писать всё подряд». Избыточные записи так же мешают, как и их отсутствие: в шуме теряется нужное событие, а хранилище растёт.
• Журналирование не отменяет требований к персональным данным. Записи, где есть имена, телефоны, адреса, нужно ограничивать по составу и сроку.

Задача формулируется не как «включить логи», а как «обеспечить возможность за разумное время ответить на типовые вопросы диагностики». Дальше разберём, какие журналы для этого есть, как выстроить схему и как проверить, что она работает.

Какие журналы есть в Битрикс и что они фиксируют

В продукте есть несколько уровней журналирования, и путать их не стоит. У каждого — свой источник событий, своё место хранения и свой срок жизни.

Журнал событий главного модуля

Основной инструмент администратора — журнал событий. Он открывается в административном разделе, в инструментах, и показывает список событий сайта. Список можно фильтровать, чтобы быстро найти нужные записи. Отдельные строки связаны со стоп-листом: оттуда можно перейти к списку пользователей, которым запрещены те или иные действия на сайте.

Состав событий и срок хранения (по умолчанию 7 дней) настраиваются в параметрах главного модуля на вкладке «Журнал событий». Это значение часто оказывается недостаточным: неделя подходит для оперативной диагностики, но для разбора инцидента «месяц назад» её не хватит.

Журналы отдельных модулей

Помимо главного модуля, свой вклад в журнал вносят и другие: информационные блоки, форум, облачные хранилища, управление структурой. Состав событий настраивается отдельно для каждого. Кроме того, для конкретного информационного блока можно задать собственные параметры журналирования — это удобно, когда один каталог требует пристального внимания, а остальные нет.

Некоторые модули (контроллер, проактивная защита, техподдержка) ведут отдельные журналы. При инцидентах с этими подсистемами поиск нужно вести в их специализированных логах.

Логгеры приложения

Третий уровень — логгеры, доступные разработчику. Они позволяют писать сообщения из кода приложения в едином формате, с уровнями важности и настраиваемым форматированием. Это инструмент для тех мест, где штатных событий недостаточно: например, для собственной интеграции, у которой нет готового журнала.

Разделение простое: журнал событий — для действий в интерфейсе и штатных операций продукта; журналы модулей — для специфичных подсистем; логгеры — для прикладного кода. Схема журналирования должна опираться на все три уровня, а не на один.

Схема журналирования: что писать, куда и как долго

Схема журналирования — это документ, по которому настраивают журналы и потом читают записи. Без него настройка превращается в набор случайных галочек. Разберём её по слоям.

Слой 1. Источники событий

Определите, какие подсистемы вообще важны для диагностики. Обычно это:

• вход и действия пользователей с повышенными правами;
• операции с контентом: создание, изменение, удаление элементов и разделов;
• интеграции: обмен с внешними системами, отправка писем, приём данных;
• платежи и заказы, если на сайте есть магазин;
• изменения настроек и структуры сайта.

Для каждого источника решите, штатного журнала достаточно или нужен отдельный логгер.

Слой 2. Состав записи

Минимальный набор записи для восстановления картины: время, тип события, объект, инициатор (пользователь/система) и результат. Если в записи есть персональные данные, это фиксируется отдельно — см. раздел о сроках и ограничениях.

Слой 3. Место хранения

Штатные журналы хранятся в самой системе. Логгеры могут писать в файлы или другие приёмники. Решите, где вы будете смотреть записи при разборе: если источников несколько, договоритесь о единой точке входа, иначе диагностика будет состоять из переключения между разделами.

Слой 4. Срок хранения

Срок хранения — компромисс между полнотой картины и объёмом. По умолчанию в главном модуле это семь дней. Для каждого слоя задайте свой срок: оперативные события можно держать недолго, а записи об изменениях настроек и правах — дольше, потому что их последствия проявляются позже.

Слой 5. Доступ и защита

Журналы содержат чувствительную информацию. Доступ к ним ограничивают теми же принципами, что и к административным разделам. Записи не должны становиться способом обойти разграничение прав.

Собранная схема — это ответ на пять вопросов: что пишем, в каком составе, куда, как долго и кому видно. Дальше её нужно связать с реальными сценариями диагностики.

Связь действия пользователя и ошибки интеграции

Журналы бесполезны без контекста. Ошибки интеграции обычно вызваны предыдущими действиями. Задача журналирования — сохранить связь между действием и результатом.

Разберём типовую цепочку. Пользователь оформляет заказ. Система создаёт заказ, обращается к внешнему сервису, получает ответ и записывает результат. Если на шаге обращения к сервису что-то пошло не так, в журнале должно остаться не только сообщение об ошибке, но и то, к какому заказу и к какому пользователю оно относится.

Что для этого нужно:

• Единый идентификатор. У события и связанных с ним записей должен быть общий признак — номер заказа, идентификатор пользователя, идентификатор операции. Без него записи не склеиваются.
• Согласованное время. Все источники должны фиксировать время сопоставимо, иначе выстроить последовательность не получится.
• Запись и об успехе, и о неудаче. Если журналировать только ошибки, вы не увидите, что операция вообще доходила до нужного шага. Отсутствие ошибки и отсутствие записи — разные вещи.

Практический вывод: при настройке журналирования думайте не о событиях по отдельности, а о сценариях. Сценарий «оформление заказа», «публикация товара», «синхронизация каталога» — это то, что вы потом будете восстанавливать по записям. Если сценариев много, начните с тех, где сбой дороже всего: там журналирование окупается быстрее всего.

При расхождении записей из-за задержек опирайтесь на самый надёжный источник, а расхождение фиксируйте как отдельную задачу.

Сроки хранения и ограничение персональных данных

Журналы — это данные, и часть из них относится к персональным. Имя, телефон, адрес доставки, адрес электронной почты, история действий конкретного человека — всё это требует аккуратного обращения. Здесь важно не подменять юридическую оценку технической.

Что стоит зафиксировать в схеме:

• Состав. Определите, какие поля действительно нужны для диагностики. Если для разбора сбоя достаточно идентификатора пользователя, не нужно дублировать в журнале его контактные данные.
• Срок. Для записей с персональными данными срок хранения задаётся осознанно, а не «по умолчанию». Помните, что штатный срок в главном модуле — семь дней, и его изменение влияет на весь объём записей.
• Доступ. Круг лиц, которые могут читать журналы, ограничивается. Это не только вопрос безопасности, но и вопрос корректной обработки данных.
• Основание. Обработка персональных данных должна иметь основание, и его наличие — предмет сверки с профильным специалистом, а не технического решения.

Отдельно отмечу: требования законодательства в этой области меняются, и конкретные формулировки лучше сверять с юристом, который знает ваш случай. Техническая часть — состав полей, срок, доступ — ложится на плечи тех, кто настраивает журналирование, но итоговые границы определяются не только ими.

Таблица принятия решения

Ниже — ориентир, помогающий выбрать уровень журналирования для типового сценария. Это не жёсткий регламент, а отправная точка для обсуждения.

Таблица помогает договориться до настройки, а не после инцидента. Если по строке мнения расходятся, это сигнал уточнить задачу диагностики.

Учебный пример: разбор инцидента на тестовых данных

Ниже — учебный пример. Компания, количество объектов и детали условны и приведены только для иллюстрации порядка действий.

Входные условия. Условный интернет-магазин на Битрикс с каталогом и обменом с внешней системой учёта. Включён журнал событий главного модуля и журнал информационных блоков. Срок хранения — семь дней по умолчанию. Отдельного логгера для обмена нет. Поступает обращение: часть товаров не обновилась после ночного обмена.

Шаг 1. Определяем сценарий. Диагностика начинается не с журнала, а с вопроса: какой сценарий сломался? Здесь это «обмен каталогом». Значит, смотреть нужно записи, связанные с изменением элементов инфоблока и с работой обмена.

Шаг 2. Сужаем окно. Известно примерное время обмена. Фильтруем журнал по этому интервалу. Уже на этом шаге выясняется первая проблема: в журнале нет записей о самом обмене, потому что отдельный логгер для него не настроен. Видны только изменения элементов.

Шаг 3. Смотрим, что есть. По записям об изменении элементов видно, что часть товаров обновилась, а часть — нет. Это важный сигнал: обмен в целом работал, сбой локальный.

Шаг 4. Ищем связь. Сопоставляем обновлённые и необновлённые товары. В учебном примере выясняется, что не обновились позиции, у которых изменилось значение одного из свойств. Это указывает на обработку конкретного поля, а не на отказ всего обмена.

Шаг 5. Проверяем гипотезу. На тестовой копии повторяют обмен с теми же данными и смотрят, воспроизводится ли пропуск. Если да — причина в обработке поля. Если нет — дело в данных конкретного запуска.

Шаг 6. Фиксируем вывод и дорабатываем схему. По итогам разбора в схему журналирования добавляют отдельный логгер для обмена: без него каждый подобный инцидент будет упираться в нехватку записей.

Наблюдаемый результат. После доработки схемы при следующем сбое обмена в журнале есть запись о запуске, о каждом обработанном объекте и о результате. Диагностика сводится к фильтрации по времени и поиску записей с неуспешным результатом.

Ответственный. За настройку журналирования отвечает тот, кто сопровождает сайт; за границы по персональным данным — профильный специалист; за приёмку — заказчик или руководитель проекта.

Проверка. Схема считается рабочей, если по ней удаётся воспроизвести разбор учебного сценария на тестовых данных, не прибегая к догадкам.

Как проверить результат и принять работу

Приёмка журналирования — это не «посмотрели, что логи есть». Проверяется способность ответить на вопросы диагностики. Ниже — чек-лист, который можно пройти вместе с исполнителем.

• Определён перечень сценариев, для которых нужна диагностика, и он согласован.
• Для каждого сценария понятно, в каком журнале искать записи.
• Состав записей позволяет восстановить время, объект, инициатора и результат.
• У связанных записей есть общий идентификатор, по которому они сопоставляются.
• Срок хранения задан осознанно для каждого слоя, а не оставлен по умолчанию.
• Записи с персональными данными ограничены по составу и сроку.
• Доступ к журналам ограничен кругом ответственных.
• Проведён учебный разбор на тестовых данных, и он дал результат.
• Зафиксировано, кто отвечает за настройку и кто — за чтение журналов.
• Описан порядок действий при инциденте: с чего начинать разбор.

Если по какому-то пункту ответ «не знаю», это не повод откладывать приёмку — это конкретная задача, которую нужно закрыть.

Типичные ошибки и ограничения

Ошибки при настройке журналирования повторяются из проекта в проект. Соберём самые частые.

• Включить всё и не настроить срок. Журнал быстро растёт, а нужное событие в нём теряется. Состав и срок задаются вместе.
• Оставить срок по умолчанию. Семь дней — разумная отправная точка, но для разбора отложенных последствий её не хватает.
• Журналировать только ошибки. Тогда не видно, доходила ли операция до нужного шага. Отсутствие записи об успехе и отсутствие ошибки — разные вещи.
• Нет общего идентификатора. Записи из разных источников не склеиваются, и восстановить цепочку не получается.
• Забыть про журналы модулей. Часть подсистем ведёт собственные журналы, и искать в общем списке бесполезно.
• Не ограничить доступ. Журналы содержат чувствительные данные и не должны быть доступны всем.
• Не проверить на тестовых данных. Схема, не проверенная разбором, остаётся гипотезой.

Ограничения тоже стоит назвать честно. Журналирование не восстановит данные, если они уже потеряны, — для этого нужно резервное копирование. Оно не покажет причину сбоя, если событие не записывалось. И оно не заменяет разбор с участием того, кто знает логику интеграции.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ по настройке журналирования, нужны не общие пожелания, а конкретика. Подготовьте:

• Перечень сценариев диагностики. Что именно вы хотите уметь разбирать: обмен, оплату, публикацию, вход администраторов.
• Описание текущего состояния. Какие журналы уже включены, какой срок хранения задан, есть ли отдельные логгеры.
• Список интеграций. С какими внешними системами идёт обмен и как он устроен.
• Требования к хранению. Как долго нужно хранить записи по каждому сценарию.
• Границы по данным. Какие поля допустимо писать в журнал, а какие — нет.
• Круг ответственных. Кто настраивает, кто читает, кто принимает работу.
• Доступы и окружение. Есть ли тестовая копия, на которой можно проверить схему без риска для рабочего сайта.

Чем конкретнее этот список, тем точнее оценка. Если по каким-то пунктам ясности нет, это нормально — их уточняют в процессе, но лучше до начала работ.

Если сайт уже сопровождается и вы хотите выстроить журналирование в рамках регулярной работы, посмотрите, как устроена поддержка сайта на Битрикс: там журналы — часть общей диагностики, а не отдельная задача. Полезно также заранее понять что входит в техническую поддержку сайта на Битрикс, чтобы не дублировать работы, и свериться с тарифами и составом поддержки, если речь идёт о выборе формата.

FAQ