Как прочитать логи 1С и найти причину ошибки

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

Журнал регистрации показывает события прикладного уровня: кто и когда вошёл в систему, какие документы проводились, какие ошибки возникали у пользователей. Технологический журнал фиксирует низкоуровневые события платформы: запросы к базе, блокировки, аварийные завершения процессов. Логи SQL Server или PostgreSQL помогают, когда проблема на стороне СУБД.

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

Журнал регистрации: первый источник ответов

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

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

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

Как фильтровать события и не утонуть в записях

В активно используемой базе журнал регистрации накапливает тысячи записей в день, поэтому читать его «лентой» бессмысленно. Нажмите кнопку «Отбор» и задайте условия: интервал дат вокруг момента сбоя (берите запас 10–15 минут до и после), уровень важности «Ошибка», конкретного пользователя, если жалоба пришла от него.

Полезные типовые отборы: событие «Данные. Ошибка выполнения» покажет сбои записи и проведения; «Доступ. Отказ в доступе» — попытки обращения к запрещённым объектам; «Фоновое задание. Ошибка выполнения» — упавшие регламентные операции. Если ищете, кто изменил документ, фильтруйте по событию «Данные. Изменение» с указанием представления объекта.

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

1. 1
   Уточните у пользователя точное время сбоя и текст сообщения на экране
2. 2
   Откройте журнал регистрации и установите отбор по интервалу времени с запасом
3. 3
   Добавьте отбор по уровню «Ошибка» и по пользователю, если он известен
4. 4
   Откройте найденную запись и скопируйте полный текст ошибки с именем модуля
5. 5
   Проверьте соседние записи в том же интервале — первопричина может быть на несколько минут раньше

Технологический журнал: когда журнала регистрации мало

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

По умолчанию ТЖ ведёт только минимальный протокол аварийных завершений (дампы в каталоге dumps). Полноценный сбор включается конфигурационным файлом logcfg.xml, который размещается в каталоге conf рядом с исполняемыми файлами платформы (например, C:\Program Files\1cv8\<версия>\bin\conf) или в каталоге кластера сервера.

В файле logcfg.xml задаются события для сбора (DBMSSQL, DBPOSTGRS, EXCP, TLOCK, TDEADLOCK, CALL, MEM и другие), глубина протоколирования и каталог выгрузки. После изменения файла сервер 1С нужно перезапустить, а клиентские приложения — перезапустить тоже, если сбор ведётся на стороне клиента.

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1clogs" history="24">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="all"/>
  </log>
</config>

Параметр history задаёт срок хранения логов в часах — без него каталог разрастётся и забьёт диск. Текстовые файлы ТЖ имеют вид имяпроцесса_пид_дата.log и содержат записи вида «время-длительность,СОБЫТИЕ,свойства». Длительность указывается в микросекундах, что удобно для поиска «тяжёлых» операций.

Как читать записи технологического журнала

Записи ТЖ выглядят пугающе, но структура у них единообразная. Например, строка с событием DBMSSQL содержит текст SQL-запроса, длительность выполнения и контекст прикладного кода, из которого запрос вызван. Если запрос выполняется секунды — это кандидат на оптимизацию индексов или переписывание запроса в конфигурации.

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

Для разбора больших файлов удобнее не читать их вручную, а фильтровать: штатными средствами поиска по имени события, скриптами PowerShell или специализированными инструментами разбора ТЖ. Ищите сначала события с наибольшей длительностью и все EXCP за проблемный период.

Логи СУБД и сервера 1С для клиент-серверного варианта

В клиент-серверной архитектуре часть проблем живёт ниже платформы. Microsoft SQL Server пишет журнал ошибок (ERRORLOG), где видны дедлоки на уровне СУБД, нехватка памяти, повреждения страниц данных. PostgreSQL протоколирует в свой лог медленные запросы и аварийные ситуации — настройка задаётся параметрами log_min_duration_statement и log_lock_waits.

Сам сервер 1С ведёт журнал кластера в служебном каталоге (например, srvinfo\reg_1541), а события службы агента сервера попадают в системный журнал Windows (Просмотр событий → Журналы Windows → Приложение). Если служба агента сервера неожиданно останавливается, причину ищите именно там, а не в журнале регистрации базы.

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

Как проверить, что причина найдена верно

Найденная запись в логе — ещё не диагноз. Проверяйте гипотезу воспроизведением: если ошибка «Фоновое задание. Ошибка выполнения» указывает на конкретную процедуру, запустите задание вручную и убедитесь, что ошибка повторяется с тем же текстом. Совпадение текста и времени — признак того, что вы нашли именно тот сбой.

Для проблем производительности контрольная точка — повторный замер после исправления. Если убрали причину длительного запроса, события DBMSSQL с большой длительностью по этой таблице должны исчезнуть или сократиться. Если записи остались — причина была в другом.

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

Частые вопросы о чтении логов 1С