Технологический журнал 1С: назначение, настройка и анализ

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

Именно ТЖ — главный инструмент диагностики, когда система «тормозит», падает с непонятной ошибкой или зависает без видимой причины. По его записям можно восстановить последовательность событий: какой запрос к базе данных выполнялся, сколько времени занял, какой процесс его инициировал и что произошло дальше. Без технологического журнала анализ таких проблем превращается в гадание.

Журнал ведётся в текстовые файлы на диске и управляется конфигурационным файлом logcfg.xml. Администратор сам определяет, какие события фиксировать, с какой детализацией, как долго хранить логи и куда их складывать. Гибкость настройки позволяет включать как точечный сбор по одному событию, так и полный дамп всех операций — но последний режим сильно нагружает дисковую подсистему и применяется только на короткое время для расследования инцидентов.

Чем технологический журнал отличается от журнала регистрации

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

Технологический журнал работает ниже уровнем. Он пишется процессами платформы (ragent, rmngr, rphost, rproc и клиентскими приложениями) независимо от прикладного кода. Если конфигурация «упала» до того, как успела записать ошибку в журнал регистрации, ТЖ всё равно зафиксирует исключение, дамп или аварийное завершение процесса.

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

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

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

Каждое событие имеет свойства, которые можно использовать в фильтрах: длительность, имя пользователя, имя компьютера, текст запроса. Например, событие DBMSSQL с фильтром по длительности позволит писать в лог только запросы длиннее заданного порога — это стандартный приём поиска «тяжёлых» запросов.

Где находятся файлы журнала и как задаётся каталог

По умолчанию, если конфигурационный файл не создан, платформа пишет минимальный набор событий (аварийные завершения и дампы) в стандартный каталог. В Windows это подкаталог 1cv8 внутри %APPDATA%\1C\1cv8\conf\ для настроек и служебных каталогов вида C:\ProgramData\1C\1cv8\ для серверных логов; в Linux — каталоги внутри /opt/1cv8/ и домашних каталогов пользователей, от имени которых работают процессы.

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

В файле logcfg.xml каталог задаётся явно через элемент <log location="...">. Рекомендуется выносить логи на отдельный диск с достаточным запасом места: при интенсивной записи объём может расти на гигабайты в час.

Как настроить logcfg.xml: структура и пример

Настройка выполняется созданием файла logcfg.xml в каталоге конфигурации платформы: C:\Program Files\1cv8\<версия>\bin\conf\ на сервере Windows или /opt/1cv8/x86_64/<версия>/conf/ в Linux. Для клиентского приложения файл кладётся в каталог conf установленной платформы на рабочей станции.

Файл описывает одно или несколько правил <log>: какие события писать, с какими условиями, куда и сколько хранить. Минимальный рабочий пример для поиска медленных запросов и взаимоблокировок выглядит так:

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

Здесь history="24" означает хранение логов за последние 24 часа, после чего старые файлы удаляются автоматически. Элементы <event> задают перечень событий, а <property name="all"/> включает запись всех свойств события. Для фильтрации по длительности добавляют элемент <conditions> с условием вида <gt property="duration" value="1000000"/> — длительность указывается в микросекундах.

1. 1
   Определите, на каком процессе возникает проблема: сервер 1С, клиент или оба
2. 2
   Создайте каталог для логов на диске с запасом свободного места
3. 3
   Создайте logcfg.xml в каталоге conf нужной версии платформы с нужными событиями и фильтрами
4. 4
   Убедитесь, что у учётной записи службы сервера 1С есть права на запись в каталог логов
5. 5
   Дождитесь воспроизведения проблемы — перезапуск служб обычно не требуется, платформа подхватывает файл
6. 6
   Проанализируйте логи, затем отключите или сократите сбор, удалив или переименовав logcfg.xml

Как читать и анализировать файлы журнала

Файлы ТЖ — текстовые, с расширением .log, сгруппированные по часовым каталогам и процессам. Каждая строка содержит метку времени, длительность, имя события и пары «свойство=значение». Формат компактный, но при больших объёмах читать его вручную неудобно.

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

Типовой приём при анализе взаимоблокировки: найти событие TDEADLOCK, посмотреть время, затем поднять записи TLOCK и DBMSSQL обоих участвующих процессов за секунды до события — так восстанавливается картина, кто какие ресурсы захватил.

Типовые сценарии использования

Диагностика медленной работы

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

Расследование аварийных завершений

Если рабочий процесс rphost падает, в ТЖ фиксируется событие EXCP и формируется дамп. По стеку вызовов и контексту можно понять, связано ли падение с конкретной операцией, расширением или внешней компонентой, и при необходимости передать дамп в службу поддержки.

Поиск источника блокировок

События TLOCK, TTIMEOUT и TDEADLOCK показывают, какие сеансы конкурируют за одни данные. Это основной способ найти регламентное задание или интеграцию, которая пересекается по данным с работой пользователей.

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

Технологический журнал — мощный инструмент, но у него есть границы. Он не показывает прикладную логику: вы увидите SQL-запрос, но не название документа, который его породил (только контекст кода). Для связи с бизнес-сущностями ТЖ сопоставляют с журналом регистрации по времени и пользователю.

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

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

ТЖ отвечает на вопрос «что делала платформа», но не всегда объясняет «почему». Если лог показывает медленный запрос, следующий шаг — анализ плана запроса и индексов средствами СУБД. Если видны частые исключения в конкретном модуле — нужен отладчик конфигуратора. Если проблема в сети между сервером 1С и СУБД — потребуется мониторинг инфраструктуры.

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

Частые вопросы о технологическом журнале 1С