Как создать и настроить журнал регистрации в 1С

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

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

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

Где находится журнал регистрации и как его открыть

Для просмотра журнала регистрации откройте конфигуратор и перейдите в меню «Администрирование → Журнал регистрации». Откроется таблица событий с колонками: дата и время, пользователь, компьютер, событие, комментарий, данные, представление данных и другие служебные поля. Тот же пункт доступен в режиме 1С:Предприятие, если у пользователя есть административные права — обычно через «Администрирование → Обслуживание → Журнал регистрации» (точный путь зависит от конфигурации).

Физически журнал хранится по-разному в зависимости от режима работы. В файловой базе это каталог 1Cv8Log рядом с файлом информационной базы, а в клиент-серверном варианте — каталог на сервере 1С, внутри папки регистрационной информации кластера. Начиная с платформы 8.3.5 журнал может храниться в формате SQLite (файл 1Cv8.lgd), что ускоряет выборку и снижает риск повреждения по сравнению со старым текстовым форматом lgf/lgp.

Настройка уровней регистрации событий

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

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

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

1. 1
   Откройте конфигуратор под пользователем с правами администратора
2. 2
   Перейдите: Администрирование → Настройка журнала регистрации
3. 3
   Выберите уровень: ошибки и предупреждения для штатной работы
4. 4
   Установите период разделения журнала — день или неделя
5. 5
   Сохраните настройку и проверьте, что новые события появляются в журнале

Фильтрация и поиск нужных событий

В окне журнала регистрации кнопка «Отбор» открывает гибкий фильтр: по интервалу дат, пользователю, компьютеру, событию, уровню важности, содержимому комментария, конкретным данным (ссылке на объект). Комбинация отборов позволяет за секунды ответить на вопрос «кто изменил этот документ вчера вечером» — достаточно указать период, событие «Данные. Изменение» и ссылку на документ в поле «Данные».

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

Для регулярного анализа удобно выгружать журнал: кнопка «Выгрузить журнал» сохраняет выбранный диапазон в текстовый файл или XML. Выгруженный файл можно разбирать скриптами, загружать в Excel или внешние системы мониторинга. В клиент-серверном варианте выгрузка выполняется на сервере — убедитесь, что у учётной записи сервера 1С есть права на каталог назначения.

Запись собственных событий из кода

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

Метод принимает имя события, уровень (Ошибка, Предупреждение, Информация, Примечание), объект метаданных, данные и комментарий. Имя события лучше задавать иерархически через точку — например, «ОбменДанными.ЗагрузкаЗаказов» — тогда в отборе журнала можно фильтровать сразу всю группу событий по префиксу.

Процедура ЗагрузитьЗаказы() Экспорт
	Попытка
		ВыполнитьЗагрузку();
		ЗаписьЖурналаРегистрации("ОбменДанными.ЗагрузкаЗаказов",
			УровеньЖурналаРегистрации.Информация, , ,
			"Загрузка завершена успешно");
	Исключение
		ЗаписьЖурналаРегистрации("ОбменДанными.ЗагрузкаЗаказов",
			УровеньЖурналаРегистрации.Ошибка, , ,
			ОписаниеОшибки());
	КонецПопытки;
КонецПроцедуры

Важная деталь: в обработчике исключения записывайте полное описание ошибки через ОписаниеОшибки() или ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()), а не только краткий текст. Краткое сообщение часто не содержит имени модуля и строки, и расследование придётся начинать заново.

Сокращение и обслуживание журнала

Со временем журнал разрастается, и его нужно чистить. В конфигураторе: «Администрирование → Настройка журнала регистрации → Сократить». Укажите дату, до которой удалить записи, и при желании сохраните сокращаемую часть в файл — это позволит вернуться к старой истории при необходимости.

Перед сокращением файловой базы выполните резервное копирование. Операция переписывает файлы журнала, и прерывание (отключение питания, сбой сети при размещении базы на сетевом диске) может повредить файл журнала. Сами данные информационной базы при этом не пострадают, но история событий будет утеряна.

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

Типичные ошибки при работе с журналом

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

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

Когда журнала регистрации недостаточно

Журнал регистрации фиксирует факт события, но не всегда содержит детали: например, он покажет, что документ изменён, но не покажет, какие именно реквизиты поменялись. Если требуется детальный аудит изменений данных, рассмотрите версионирование объектов (в типовых конфигурациях на базе БСП есть подсистема «Версионирование объектов») или собственный механизм истории изменений.

Для мониторинга производительности и технических проблем кластера журнал регистрации тоже не подходит — для этого служит технологический журнал (ТЖ), который настраивается отдельно через файл logcfg.xml. Эти два механизма дополняют друг друга: журнал регистрации отвечает на вопрос «что делал пользователь», технологический журнал — «что происходило на уровне платформы и СУБД».

Частые вопросы