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

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

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

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

Какие логи существуют в 1С и что искать в каждом

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

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

Где физически находятся файлы логов

В файловом варианте журнал регистрации лежит в каталоге информационной базы, в подпапке 1Cv8Log (для старых форматов — файл 1Cv8.lgf и папка 1Cv8Log, для нового формата — файл 1Cv8.lgd). Путь к каталогу базы виден в списке баз стартера 1С или в свойствах подключения.

В клиент-серверном варианте журнал регистрации хранится на сервере 1С:Предприятия в каталоге служебных файлов кластера: C:\Program Files\1cv8\<версия>\srvinfo\reg_1541\<GUID базы>\1Cv8Log (для Linux — аналогичный путь в /opt/1cv8 или домашнем каталоге пользователя агента). Точный GUID базы можно посмотреть в консоли кластера.

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

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

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

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

1. 1
   Откройте конфигуратор нужной базы: Администрирование → Журнал регистрации
2. 2
   Задайте отбор по периоду — интервал, когда проявилась проблема
3. 3
   Добавьте фильтр по типу события: Ошибка, Предупреждение или конкретное действие с данными
4. 4
   При необходимости укажите пользователя или конкретный документ/справочник
5. 5
   Двойной клик по строке откроет детали события: текст ошибки, объект, сеанс
6. 6
   Для передачи на анализ выгрузите выборку: Файл → Сохранить копию или кнопка выгрузки журнала

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

Как читать типовые события и ошибки

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

Типичные события и их трактовка:

• «Данные. Изменение / Удаление / Добавление» — кто и когда изменил объект. В колонке «Данные» видна ссылка на конкретный документ или элемент справочника.
• «Ошибка» с текстом исключения — в комментарии указан текст ошибки и часто место в коде. Фраза вида «Ошибка при выполнении обработчика» указывает на программную проблему в конфигурации, а не на действия пользователя.
• «Доступ. Отказ в доступе» — пользователю не хватило прав на объект. Решение — настройка ролей, а не поиск ошибки в коде.
• «Фоновое задание. Ошибка выполнения» — регламентная операция (обмен, расчёт, рассылка) завершилась аварийно; в комментарии — причина.
• «Сеанс. Аутентификация» с ошибкой — неверный пароль или заблокированный пользователь.

Технологический журнал: включение и анализ

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

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

Основные события для диагностики: EXCP — исключения платформы, DBMSSQL/DBPOSTGRS — запросы к СУБД с длительностью, TLOCK и TDEADLOCK — транзакционные блокировки и взаимоблокировки, CALL/SCALL — вызовы сервера. Каждое событие в логе содержит метку времени, длительность в микросекундах, имя процесса и контекст.

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

Диагностика типовых проблем по логам

База «тормозит»

Включите в logcfg.xml события запросов к СУБД с порогом длительности и соберите лог на период жалоб. Отсортируйте события DBMSSQL по длительности: топ самых долгих запросов покажет, какие операции нагружают систему. Далее запрос анализируют планом выполнения в СУБД — часто причина в отсутствующем индексе или устаревшей статистике.

Взаимоблокировки

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

Кто изменил или удалил данные

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

Ограничения, риски и типичные ошибки

Журнал регистрации не фиксирует всё: состав регистрируемых событий настраивается, и по умолчанию часть событий (например, чтение данных) не пишется. Кроме того, журнал периодически нужно сокращать — при больших объёмах он замедляет открытие и отбор. Сокращение выполняется через конфигуратор с указанием даты, до которой удалять записи; перед этим стоит выгрузить архивную копию.

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

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