Почему не работает ЗаписьЖурналаРегистрации при ручном запуске регламентного задания на копии базы?

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

В этой статье мы подробно разберем, почему так происходит, исследуем особенности поведения платформы «1С:Предприятие 8.3» на копиях баз и рассмотрим четыре неочевидные технические причины, приводящие к «молчаливому» игнорированию записи логов.

Причина 1: Специфика ручного запуска в контексте сеанса пользователя

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

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

1. Код метода регламентного задания выполняется **синхронно в контексте вашего текущего сеанса** (сеанса тонкого или толстого клиента), под которым открыта консоль заданий. Реальное фоновое задание в операционной системе не создается.
2. В списке фоновых заданий в консоли не фиксируется история выполнения, поскольку системного события создания фонового процесса физически не происходило.
3. Метод ЗаписьЖурналаРегистрации отрабатывает успешно, однако записывает событие не под системным сеансом фонового задания, а под вашим текущим пользовательским сеансом.

Проанализируем последствия: если в этот момент в Журнале Регистрации у вас установлен отбор по метаданным «Регламентные задания» или по типу приложения «Фоновое задание», вы просто не увидите созданную запись. Она будет записана, например, под типом приложения «Тонкий клиент» и именем вашего пользователя.

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

Причина 2: Неявная фильтрация по уровню детализации ЖР в Конфигураторе

Очень частая и банальная причина, о которой забывают при развертывании тестовых контуров. На копии базы настройки журнала регистрации могут отличаться от рабочих. Если в Конфигураторе (меню Администрирование -> Настройка журнала регистрации) установлен уровень детализации «Регистрировать ошибки», то поведение платформы при записи логов будет следующим:

Рассмотрим пример кода, который часто пишут разработчики:

ЗаписьЖурналаРегистрации("РегламентноеЗадание.ВыгрузкаДанных",,,, "Выгрузка успешно завершена.");

В данном вызове второй параметр Уровень (тип УровеньЖурналаРегистрации) опущен. По умолчанию платформа присваивает ему значение УровеньЖурналаРегистрации.Информация. Проанализировав настройки ЖР («Регистрировать ошибки»), ядро 1С понимает, что данная запись не соответствует минимальному уровню логирования, и **просто игнорирует ее**.

При этом платформа не генерирует никаких ошибок выполнения и не прерывает работу кода, чтобы не нарушать транзакционную целостность бизнес-логики. Запись просто отбрасывается.

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

// Гарантированная запись, которая обойдет фильтр "Только ошибки"
ЗаписьЖурналаРегистрации(
    "ТестЛогирования",
    УровеньЖурналаРегистрации.Ошибка,
    ,
    ,
    "Это тестовая запись с уровнем Ошибка"
);

Причина 3: Блокировка и повреждение файлов журнала регистрации (формат .lgd)

Начиная с версии 8.3.5, журнал регистрации по умолчанию создается в формате базы данных SQLite (файл 1Cv8.lgd в каталоге логов). Этот формат обеспечивает быструю выборку, но крайне чувствителен к операциям копирования и блокировкам со стороны операционной системы:

• Блокировка базы данных (Database locked): Если копия базы создавалась путем «горячего» копирования файлов или в процессе выполнения кода активна отладка с остановкой на точках останова, файл 1Cv8.lgd может оказаться заблокирован процессом сервера 1С или утилитами резервного копирования. Метод ЗаписьЖурналаРегистрации в этом случае отрабатывает «вхолостую» — запись физически не сбрасывается на диск.
• Повреждение файла лога: При некорректном завершении работы сервера 1С или сбоях СУБД структура файла SQLite может повредиться. В такой ситуации новые транзакции записи в файл лога молча отклоняются СУБД SQLite.

Выясним причину экспериментально. Выполните следующие шаги для очистки и проверки работоспособности файлов журнала:

1. Завершите все активные сеансы пользователей в копии базы данных.
2. Остановите службу сервера «1С:Предприятие».
3. Перейдите в каталог хранения журнала регистрации (по умолчанию для серверной базы это подкаталог 1Cv8Log внутри каталога вашей информационной базы на сервере).
4. Переименуйте папку 1Cv8Log в 1Cv8Log_OLD.
5. Запустите службу сервера 1С и зайдите в базу. Платформа автоматически создаст новый, пустой и гарантированно исправный файл журнала регистрации.
6. Запустите ваше регламентное задание и проверьте появление записей.

Причина 4: Транзакционный режим и влияние «битых» транзакций

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

• Независимая (по умолчанию) — запись фиксируется в ЖР сразу, даже если текущая транзакция 1С в последующем будет отменена.
• Транзакционная — запись фиксируется в ЖР только в том случае, если текущая транзакция СУБД завершится успешно (будет зафиксирована). Если произойдет откат (Rollback), запись из ЖР также удалится.

Рассмотрим детально ситуацию с «битыми» транзакциями (doomed transactions). Если в коде регламентного задания внутри транзакции (после вызова НачатьТранзакцию()) происходит любая критическая ошибка СУБД (например, блокировка или нарушение уникальности данных), платформа помечает текущую транзакцию как поврежденную.

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

Разберем правильный паттерн написания безопасного логирования с обработкой транзакций:

НачатьТранзакцию();
Попытка
    // Выполнение бизнес-логики регламентного задания
    // ...
    
    ЗафиксироватьТранзакцию();
Исключение
    // Сначала отменяем транзакцию, чтобы вернуть систему в стабильное состояние
    Если ТранзакцияАктивна() Тогда
        ОтменитьТранзакцию();
    КонецЕсли;
    
    // Теперь безопасно пишем информацию об ошибке в Журнал Регистрации
    ЗаписьЖурналаРегистрации(
        "РегламентноеЗадание.СистемнаяОшибка",
        УровеньЖурналаРегистрации.Ошибка,
        ,
        ,
        "Произошел сбой: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке())
    );
КонецПопытки;

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