Как читать логи 1С: практическое руководство

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

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

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

Какие логи существуют в 1С и чем они отличаются

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

Технологический журнал — это текстовые файлы, которые пишут процессы платформы: rphost, ragent, rmngr на сервере и клиентское приложение на рабочем месте. Он фиксирует события на уровне платформы и СУБД: тексты запросов, длительность операций, таймауты, взаимоблокировки, обрывы соединений. По умолчанию он отключён, потому что при подробной настройке генерирует большие объёмы данных и нагружает диск.

Дополнительно существуют логи сервера СУБД (MS SQL, PostgreSQL), журналы Windows (Просмотр событий) и логи веб-сервера при публикации через HTTP. Полная картина часто складывается только из нескольких источников: например, ошибка в журнале регистрации указывает на момент времени, а технологический журнал и лог СУБД показывают, что именно выполнялось в эту секунду.

Как открыть и отфильтровать журнал регистрации

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

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

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

1. 1
   Уточните у пользователя точное время ошибки и текст сообщения на экране
2. 2
   Откройте журнал регистрации и задайте отбор: интервал ±10 минут, пользователь, уровень «Ошибка»
3. 3
   Найдите запись с совпадающим текстом ошибки и откройте её детали
4. 4
   Запомните номер сеанса и время — они понадобятся для поиска в технологическом журнале
5. 5
   Если причина неясна, включите технологический журнал на период воспроизведения ошибки

Как включить технологический журнал через logcfg.xml

Технологический журнал активируется файлом logcfg.xml, который нужно разместить в подкаталоге conf каталога установки платформы на сервере (или на клиенте, если диагностируется клиентский процесс). После создания или изменения файла процессы платформы подхватывают настройки автоматически в течение короткого времени — перезапуск службы обычно не требуется.

В файле задаются каталог для записи (элемент log с атрибутом location), глубина хранения истории в часах и перечень событий. Минимальный рабочий вариант для поиска длительных запросов выглядит так: включить события DBMSSQL (или DBPOSTGRS), EXCP, TLOCK, TDEADLOCK с условием на длительность. События с префиксом T — это длительности: TLOCK — ожидание блокировки, TTIMEOUT — таймаут.

<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="DBMSSQL"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <event><eq property="name" value="TLOCK"/></event>
    <property name="all"/>
  </log>
</config>

Важно ограничивать объём записи: включение всех событий без фильтров на загруженном сервере может заполнить диск за часы. Указывайте разумную глубину хранения (атрибут history — в часах), выделяйте отдельный дисковый раздел под логи и после завершения диагностики удаляйте или переименовывайте logcfg.xml, чтобы журнал отключился.

Как читать файлы технологического журнала

В указанном каталоге платформа создаёт подкаталоги по именам процессов (rphost, ragent, rmngr), а внутри — файлы вида ГГММДДЧЧ.log, по одному на каждый час. Зная время ошибки из журнала регистрации, вы сразу определяете нужный файл. Открывать его удобнее любым редактором, устойчивым к большим файлам, или фильтровать поиском по номеру сеанса.

Каждое событие в файле записывается блоком: сначала длительность в микросекундах, имя события, затем пары «свойство=значение» через запятую. Для событий DBMSSQL ключевые поля — Sql (текст запроса), Rows (число обработанных строк), planSQLText (план запроса) и Context (контекст исполнения в коде 1С). Именно колонка Context чаще всего приводит к конкретному модулю и процедуре конфигурации, вызвавшей тяжёлый запрос.

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

Типовые сценарии диагностики по логам

База «тормозит» у всех пользователей

Включите технологический журнал с фильтром на длительные события (например, длительность свыше заданного порога) и соберите данные за час пиковой нагрузки. Отсортируйте события DBMSSQL по длительности: если в топе несколько однотипных запросов с большим числом строк, проблема в конкретном отчёте или проведении документов. Если длинные события — это TLOCK, система упирается в ожидание блокировок, и анализировать нужно не запросы, а конкуренцию процессов.

Ошибка у одного пользователя

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

Фоновое задание завершается с ошибкой

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

Хранение, ротация и безопасность логов

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

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

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

Когда анализ логов лучше поручить специалисту

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

Если проблема воспроизводится нестабильно, затрагивает обмены с другими системами или связана с падением рабочих процессов сервера (события EXCP с аварийным завершением rphost), соберите логи за период сбоя и передайте их специалисту вместе с описанием симптомов и временем. Готовый пакет диагностики сокращает время решения в разы по сравнению с устным описанием «всё тормозит».

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