При администрировании и разработке в среде 1С:Предприятие специалисты часто сталкиваются с ситуацией, когда в Журнале регистрации фиксируется ошибка выполнения фонового задания, но при попытке открыть стандартный список фоновых заданий в консоли или через обработку администрирования в указанное время ничего не обнаруживается. В этой статье мы подробно разберем, почему фоновые задания исчезают из видимости, как их гарантированно идентифицировать по номеру сеанса, как настроить систему для сбора детальной информации и как отлавливать подобные сбои «на лету».
Для начала разберем внутренние механизмы платформы 1С. Многие начинающие разработчики и администраторы полагают, что список фоновых заданий в консоли кластера серверов или в типовой обработке «Регламентные и фоновые задания» должен хранить историю бесконечно или хотя бы в течение нескольких дней. Однако это не так.
Платформа 1С:Предприятие накладывает жесткие ограничения на хранение истории выполнения фоновых процессов в памяти кластера:
Если фоновое задание выполнялось вчера или даже сегодня утром, но при интенсивной работе базы его уже нет в стандартном списке, нам на помощь приходят другие инструменты диагностики. Рассмотрим их по шагам.
Каждое фоновое задание выполняется в рамках отдельного сеанса. Номер этого сеанса фиксируется в Журнале регистрации (ЖР) в поле «Сеанс» (например, 20457). Вопреки распространенному мнению, что отбор по номеру сеанса покажет лишь тонну бесполезных системных записей, правильная работа с фильтрами ЖР позволяет мгновенно локализовать проблему.
Проанализируем алгоритм работы с Журналом регистрации:
_$Job$_.Start — запуск фонового задания;_$Job$_.Fail — аварийное завершение (ошибка выполнения).ФоновыеЗадания.Выполнить().{ОбщийМодуль.ДлительныеОперации.Модуль(1432)} четко указывает, где именно произошел сбой.Данные.Добавление, Данные.Изменение или Данные.Проведение. Записанные объекты (например, элементы справочников или документы конкретного типа) подскажут, какая бизнес-логика выполнялась в этот момент.Если Журнал регистрации не дал полной картины (например, запись комментариев отключена для экономии места или в стеке вызовов фигурируют только общие методы-обертки), наиболее мощным инструментом становится Технологический журнал (ТЖ). ТЖ позволяет зафиксировать точные параметры вызовов методов на стороне сервера.
Для того чтобы локализовать проблему, нам необходимо настроить сбор событий EXCP (исключительные ситуации) и событий CALL/SCALL (вызовы процедур и функций на сервере).
Рассмотрим пример настройки файла конфигурации ТЖ logcfg.xml. Этот файл необходимо разместить в каталоге конфигурации сервера 1С (обычно это C:\Program Files\1cv8\conf на Windows или /opt/1cv8/conf на Linux):
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<!-- Лог для записи всех исключений на сервере -->
<log location="C:\v8_logs\exceptions" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
<!-- Лог для записи вызовов процедур и функций, привязанных к конкретному сеансу -->
<log location="C:\v8_logs\calls" history="12">
<event>
<eq property="Name" value="CALL"/>
</event>
<event>
<eq property="Name" value="SCALL"/>
</event>
<property name="all"/>
</log>
</config>
Важное примечание: Сбор событий CALL и SCALL для всей системы может создавать огромную нагрузку на дисковую подсистему сервера и генерировать гигабайты логов за короткий промежуток времени. Поэтому рекомендуется настраивать фильтрацию по свойству SessionID (идентификатор сеанса), если вы уже знаете номер проблемного сеанса из Журнала регистрации. Пример фильтрации по сеансу:
<event>
<eq property="Name" value="CALL"/>
<eq property="SessionID" value="20457"/>
</event>
После настройки ТЖ проанализируем полученные файлы логов. В логе EXCP мы найдем точное описание ошибки, а по логу CALL сможем проследить всю цепочку серверных вызовов непосредственно перед падением процесса. Это позволит определить имя экспортного метода общего модуля, который запускался в фоне.
В современных конфигурациях, разработанных на базе Библиотеки стандартных подсистем (БСП), практически все фоновые задачи запускаются через стандартизированный программный интерфейс — подсистему «Длительные операции». К таким конфигурациям относятся 1С:ERP, 1С:Комплексная автоматизация, 1С:Управление торговлей, 1С:Бухгалтерия и многие другие.
Разработчики БСП предусмотрели проблему быстрого затирания фоновых заданий платформой и реализовали собственный механизм логирования. При использовании БСП фоновые задания регистрируются в информационной базе:
Поэтому, если ваша конфигурация построена на БСП, всегда начинайте анализ со специализированных панелей администрирования БСП, а не только с системной консоли кластера.
Выяснив причину сбоя или хотя бы локализовав процедуру, которая его вызывает, мы переходим к этапу отладки. Отладка фоновых заданий имеет свои особенности, так как они выполняются в изолированных процессах на сервере.
Выполним следующие шаги для настройки отладчика:
-debug (или -http для протокола HTTP). Без этого подключиться к фоновым процессам из Конфигуратора будет невозможно.
ИмяПользователя() = "ИвановИИ"
Или проверяйте параметры сеанса в конфигурациях БСП:
ПараметрыСеанса.ТекущийПользователь = Справочники.Пользователи.НайтиПоРеквизиту("Имя", "ИвановИИ")
ДлительныеОперации.ЗапуститьВыполнениеВФоне(), мы можем временно заставить систему выполнять код не в фоновом процессе, а в текущем сеансе клиента (синхронно). Для этого в структуре параметров запуска длительной операции достаточно установить свойство, отвечающее за запуск в фоне, в значение Ложь (или воспользоваться специальными ключами отладки в параметрах запуска конфигуратора). В этом случае код выполнится в вашем текущем сеансе, и вы легко сможете пройти его по шагам без сложных настроек серверной отладки.Потеря информации о фоновых заданиях в 1С — это контролируемая проблема платформы, связанная с экономией оперативной памяти кластера. Используя связку из Журнала регистрации (с отбором по номеру сеанса), Технологического журнала (события EXCP и CALL) и специализированных механизмов БСП, мы можем гарантированно восстановить хронологию событий, выявить ошибочный метод и успешно устранить программный сбой.