Використання Журналу реєстрації

1. Журнал реєстрації призначений для зберігання подій, що виникають у процесі роботи користувачів з інформаційною базою. Під час адміністрування цю інформацію часто необхідно аналізувати в різних розрізах для того, щоб, наприклад, дізнатися, які події відбувалися в певний момент часу, які дії виконував той чи інший користувач.

2. Рекомендується виконувати запис до Журналу реєстрації із вбудованої мови в тих випадках, коли адміністратору необхідно повідомити додаткову діагностичну інформацію про події, які не записуються платформою 1С:Підприємство. Така необхідність може виникнути як під час виконання бізнес-логіки, що викликається під час інтерактивної роботи, так і у фонових (регламентних) завданнях. Для зручності аналізу Журналу реєстрації один його запис має відповідати одній події, а самі записи повинні містити низку обов’язкових атрибутів, у розрізі яких проводиться аналіз.

2.1. Рядковий ідентифікатор типу події. Як правило, список типів подій у конфігурації може бути як завгодно великим, тому типи подій рекомендується групувати за функціональною ознакою: «Назва групи подій.Назва події». Наприклад, правильно записувати події з типами «Доручення.Сповіщення про нові завдання» та «Доручення.Сповіщення про завислі завдання» замість двох «плоских» типів подій «Сповіщення про нові завдання» та «Сповіщення про завислі завдання». Текст типу події локалізується, при цьому завжди задається основна мова конфігурації.

2.2. Рівень важливості події. Критичні події, що потребують підвищеної уваги адміністратора (помилки бізнес-логіки, збої в програмі тощо), записуються до Журналу реєстрації з рівнем важливості «Помилка». Потенційні проблеми та нефатальні помилки реєструються як «Попередження». Для виведення інформаційних повідомлень про успішне завершення тієї чи іншої операції використовується рівень важливості «Інформація». Також можливо застосовувати й нижчий рівень важливості — «Примітка».

2.3. Коментар. Містить текстову неструктуровану інформацію про подію. У разі помилок у цьому полі міститься інформація, необхідна для з’ясування причини проблеми. Не слід розміщувати в коментарі інформацію одразу про кілька подій. Наприклад, неправильно записувати одну подію з коментарем такого вигляду:

[01.01.2010 00:00:01] Початок ініціалізації обміну даними за налаштуванням "Вивантаження обміну даними", номер рядка налаштування: 1
[01.01.2010 00:00:02] Завершення ініціалізації обміну даними (успішно)
[01.01.2010 00:00:03] Початок процесу обміну даними за налаштуванням "Вивантаження обміну даними", номер рядка налаштування: 1
[01.01.2010 00:00:04] Початок запису змін до файлу обміну
[01.01.2010 00:00:05] Завершення запису змін до файлу обміну (успішно)
[01.01.2010 00:00:06] Завершення процесу обміну даними за налаштуванням "Вивантаження обміну даними", номер рядка налаштування: 1
[01.01.2010 00:00:07] Виконано, вивантаження даних, оброблено 1 об’єктів

правильно записати стільки подій, скільки їх насправді відбулося.

Текст коментаря локалізується. Для запису до Журналу реєстрації інформації про виняток, що виник, слід використовувати конструкцію:

ПодробноеПредставлениеОшибки(ИнформацияОбОшибке())

Приклад реєстрації додаткових подій у функціональній підсистемі «Мій механізм»:

Попытка 
	ЗаписьЖурналаРегистрации(НСтр("ru = 'Мой механизм.Действие с возможной ошибкой'", КодОсновногоЯзыка), 
	УровеньЖурналаРегистрации.Информация, , ,
	НСтр("ru = 'Начато действие'"));
	ДействиеСВозможнойОшибкой(ОбъектДействия);
	ЗаписьЖурналаРегистрации(НСтр("ru = 'Мой механизм.Действие с возможной ошибкой'", КодОсновногоЯзыка), 
	УровеньЖурналаРегистрации.Информация, , ,
	НСтр("ru = 'Завершено действие'"); 
Исключение
	ЗаписьЖурналаРегистрации(НСтр("ru = 'Мой механизм.Действие с возможной ошибкой'", КодОсновногоЯзыка), 
	УровеньЖурналаРегистрации.Ошибка, , ,
	НСтр("ru = '"Під час виконання дії сталася невідома помилка.'") + Символы.ПС +
	ПодробноеПредставлениеОшибки(ИнформацияОбОшибке());
КонецПопытки; 
КонецПроцедуры

де змінна КодОсновногоЯзыка містить код основної мови конфігурації. Докладніше див. Вимоги щодо локалізації конфігурації, п. 8.1.

3. Не слід використовувати вибірку з журналу реєстрації в тих завданнях, де критичною є висока швидкість виконання вибірки. Оскільки за великих обсягів журналу реєстрації швидкість вибірки падає пропорційно збільшенню його обсягу.

Рекомендується створювати окремий регістр для протоколювання цікавих подій або звертатися до спеціалізованих об’єктів платформи (наприклад, МенеджерФоновыхЗаданий для вибірки історії виконання фонових завдань).

Цю особливість також потрібно враховувати під час розробки звітів за журналом реєстрації.