Вопрос логирования действий пользователей в системе 1С:Предприятие является фундаментальным при построении систем аудита, безопасности и анализа пользовательской активности. Зачастую стандартного Журнала регистрации недостаточно из-за его закрытости, сложности программного анализа или риска повреждения файла лога при высокой интенсивности записи. Рассмотрим подробно, как спроектировать собственную систему логирования, какие объекты метаданных выбрать и как избежать типичных проблем с производительностью.
Большинство разработчиков сходятся во мнении, что РегистрСведений является наиболее подходящим объектом для хранения логов. В отличие от справочников, регистр представляет собой плоскую таблицу, запись в которую происходит быстрее, а отсутствие ссылочной тяжести делает его более компактным. Однако при использовании регистра сведений мы сталкиваемся с проблемой уникальности записей.
Проанализируем классическую проблему: стандартная периодичность регистра сведений составляет 1 секунду. Если один и тот же пользователь выполнит два действия в течение одной секунды (что вполне реально при автоматизированных процессах или открытии нескольких сеансов), система выдаст ошибку при записи второй записи с тем же набором измерений. Разберем способы решения этой проблемы:
ИдентификаторСобытия с типом Строка (или УникальныйИдентификатор). Это гарантирует уникальность каждой записи, даже если дата и пользователь совпадают.ТекущаяУниверсальнаяДатаВМиллисекундах(). Это значительно снижает вероятность коллизии, хотя и не исключает её на 100% в сверхнагруженных системах.НомерСеанса позволяет разграничить действия, выполняемые параллельно в разных окнах 1С одним и тем же пользователем.Рассмотрим пример структуры такого регистра:
Период (ДатаВремя), Пользователь (СправочникСсылка.Пользователи), ИдентификаторЗаписи (УникальныйИдентификатор).ТипСобытия (Перечисление), Описание (Строка).ДанныеОбъекта (ХранилищеЗначения или Строка).Пример кода для записи события в такой регистр:
МенеджерЗаписи = РегистрыСведений.ЛогДействийПользователей.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Период = ТекущаяДата();
МенеджерЗаписи.Пользователь = ПараметрыСеанса.ТекущийПользователь;
МенеджерЗаписи.ИдентификаторЗаписи = Новый УникальныйИдентификатор();
МенеджерЗаписи.ТипСобытия = ПредопределенноеЗначение("Перечисление.ТипыСобытийЛога.ИзменениеДанных");
МенеджерЗаписи.Описание = "Пользователь открыл форму списка";
МенеджерЗаписи.Записать(Истина);
Иногда возникает соблазн использовать Справочник для хранения логов. Проанализируем аргументы "за" и "против". Главный минус справочника — наличие кластерного индекса по Ссылке, который в контексте логов практически бесполезен, но занимает место и замедляет запись. Однако справочник проще чистить: удаление элементов справочника происходит стандартно, в то время как очистка огромного регистра сведений может вызвать блокировки всей базы данных.
Важный нюанс: при записи в РегистрСведений платформа всегда проверяет уникальность по набору измерений. Если мы используем УникальныйИдентификатор в измерениях, платформа все равно тратит ресурсы на проверку индекса. В последних версиях платформы для независимых регистров сведений в режиме "Запись без проверок" (через НаборЗаписей) можно добиться очень высокой скорости работы, сопоставимой с прямой записью в SQL.
Начиная с версии платформы 8.3.11, появился встроенный механизм ИсторияДанных. Выясним, почему это может быть полезно. Этот механизм работает на уровне платформы и автоматически логирует изменения объектов. Вам не нужно писать код для отслеживания того, кто и когда изменил реквизит в справочнике Контрагенты — достаточно включить соответствующую настройку в метаданных.
Однако у Истории данных есть ограничения: она предназначена именно для версионирования объектов, а не для логирования абстрактных "действий" (например, нажатие кнопки "Печать" или просмотр отчета без изменения данных). Для таких задач самописный регистр остается единственным верным решением.
В высоконагруженных системах прямая запись в регистр сведений в основном потоке выполнения (в транзакции) может существенно замедлить работу пользователя. Рассмотрим, как это оптимизировать. Вместо того чтобы заставлять пользователя ждать, пока запишется строка лога, мы можем использовать асинхронный подход.
Разберем алгоритм работы через фоновое задание:
Если объем логов превышает сотни миллионов записей в месяц, хранить их внутри основной базы 1С становится рискованно — это раздувает бэкапы и замедляет регламентные операции. В таких случаях проанализируем возможность выноса логов во внешние базы данных.
ClickHouse — идеальное решение для хранения логов благодаря своей колончатой структуре. Запись происходит через HTTP-запросы. Вы можете отправлять данные из 1С следующим образом:
Соединение = Новый HTTPСоединение("clickhouse-server.local", 8123);
Запрос = Новый HTTPЗапрос("/?query=INSERT INTO user_logs VALUES");
Запрос.УстановитьТелоИзСтроки(ДанныеЛогаВФорматеCSV);
Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Такой подход позволяет хранить терабайты логов, выполняя по ним аналитические отчеты (например, "среднее количество действий пользователя в час") за считанные секунды, не нагружая при этом основную базу 1С.
Подведем итоги нашего исследования. Для большинства задач средней сложности оптимальным выбором будет независимый регистр сведений с измерением типа УникальныйИдентификатор. Это обеспечит надежность и простоту доступа к данным через стандартные запросы 1С. Если же вы работаете с крупной системой, рассмотрите внедрение асинхронной записи или использование внешних аналитических баз данных, чтобы логирование не стало "бутылочным горлышком" вашей системы.
Помните о необходимости регламентной очистки данных. Раз в месяц или квартал следует удалять устаревшие записи, используя методы НаборЗаписей.Записать() с установленным отбором, чтобы избежать фрагментации индексов и избыточного роста таблиц базы данных.