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

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

Настройка сводится к трём шагам: создать или отредактировать файл logcfg.xml, указать каталог для записи логов и перезапустить службу сервера 1С (или клиентское приложение). Однако на практике есть нюансы: неправильно выбранный набор событий за сутки может сгенерировать сотни гигабайт текста и исчерпать место на диске, а отсутствие фильтров превратит анализ в поиск иголки в стоге сена.

Ниже разобрано, где должен лежать конфигурационный файл, какие события включать под разные задачи диагностики, как ограничить объём логов и как проверить, что журнал реально пишется. Отдельный раздел посвящён типичным ошибкам, из-за которых ТЖ «не работает» или, наоборот, кладёт сервер.

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

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

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

Где разместить файл logcfg.xml

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

Для диагностики на стороне клиента (например, ошибки толстого клиента у конкретного пользователя) logcfg.xml размещают в каталоге conf клиентской установки или в каталоге конфигурационных файлов пользователя — путь зависит от версии платформы и способа установки. Важно, чтобы у процесса, который будет писать логи, были права на чтение logcfg.xml и на запись в каталог логов. Для сервера это обычно учётная запись службы агента (по умолчанию USR1CV8 на Windows).

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

Минимальная рабочая конфигурация

Базовый вариант logcfg.xml для диагностики ошибок и долгих запросов выглядит так:

<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="D:\1c_logs" 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>

Здесь location — каталог для логов (создайте его заранее и дайте права на запись), history — время хранения логов в часах, после которого платформа удаляет старые файлы. Секция <event> перечисляет события: EXCP — исключения, DBMSSQL — запросы к MS SQL Server, TLOCK и TDEADLOCK — управляемые блокировки и взаимоблокировки. Свойство all включает запись всех свойств событий, включая контекст.

Для PostgreSQL вместо DBMSSQL используется событие DBPOSTGRS, для IBM DB2 — DB2, для Oracle — DBORACLE. Если СУБД неизвестна или нужно смотреть запросы на уровне платформы, добавляют событие DBV8DBENG.

1. 1
   Создайте каталог для логов, например D:\1c_logs, и дайте учётной записи службы сервера 1С полные права на него
2. 2
   Создайте файл logcfg.xml в каталоге conf сервера 1С с нужным набором событий
3. 3
   Перезапустите службу агента сервера 1С в технологическое окно
4. 4
   Выполните в системе действие, которое хотите диагностировать
5. 5
   Проверьте, что в каталоге логов появились папки процессов (rphost, rmngr) с файлами *.log
6. 6
   Проанализируйте логи, затем отключите или сократите конфигурацию, чтобы не расходовать диск

Какие события включать под конкретную задачу

Главная ошибка — включать «всё сразу». Полный набор событий с контекстами на нагруженной базе генерирует десятки гигабайт в час и заметно грузит дисковую подсистему. Подбирайте события под задачу.

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

Включайте DBMSSQL (или аналог для вашей СУБД) с фильтром по длительности. Для этого используют событие с условием по свойству duration — например, писать только запросы дольше заданного порога. Порог задают в микросекундах, поэтому 5 секунд — это 5000000. Дополнительно полезно событие EXCP, чтобы видеть ошибки запросов.

Поиск взаимоблокировок

Нужны события TLOCK, TTIMEOUT и TDEADLOCK. По ним видно, какие сеансы и на каких ресурсах конфликтовали. Дополнительно включают DBMSSQL, чтобы видеть тексты запросов участников взаимоблокировки — без этого понять прикладную причину сложно.

Аварийное завершение рабочего процесса

Для анализа падений rphost включают EXCP, CALL, SCALL и MEM. События CALL/SCALL показывают входящие и серверные вызовы, MEM — события памяти. Это самый «тяжёлый» по объёму сценарий, поэтому его включают на ограниченное время и с фильтрами по пользователю или базе, если это возможно.

Сравнение вариантов

Минимальный набор (EXCP)

Подходит для постоянного мониторинга ошибок. Малый объём логов, но нет информации о запросах и блокировках.

Диагностический набор (EXCP + DBMSSQL + TLOCK/TDEADLOCK)

Оптимален для разбора тормозов и блокировок. Средний объём, включают на период расследования.

Полный набор (все события + контексты)

Только для кратковременной точечной диагностики. Огромный объём логов и заметная нагрузка на диск.

Фильтры: как ограничить объём логов

Каждое событие можно фильтровать по его свойствам через элемент <eq>, <ne>, <gt>, <lt> и <like>. Например, чтобы писать только долгие запросы, добавляют условие по duration:

<event>
<eq property="name" value="DBMSSQL"/>
<gt property="duration" value="5000000"/>
</event>

Фильтровать можно по имени базы (p:processName на уровне log), по пользователю (Usr), по имени компьютера. Это критично, когда проблема воспроизводится у одного пользователя: вместо гигабайтов общего потока вы получите компактный лог только нужного сеанса.

Отдельно контролируйте параметр history. Значение указывается в часах; если поставить 0 или убрать атрибут, старые логи не будут удаляться автоматически, и рано или поздно диск переполнится. Для диагностических сессий обычно достаточно 24–72 часов.

Как проверить, что техжурнал работает

После перезапуска службы откройте каталог, указанный в location. Внутри должны появиться подкаталоги с именами процессов кластера — rphost, rmngr, ragent, — а в них файлы вида YYMMDDHH.log. Если каталоги появились, но файлы пустые — скорее всего, события отфильтрованы условиями или нужное действие ещё не выполнялось.

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

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

Контрольные точки

Как проверить результат

Каталог логов после перезапуска службы

Норма

Появились подкаталоги rphost/rmngr с файлами .log

Тревожный признак

Каталог пуст — проверяйте путь к logcfg.xml, права и валидность XML

Содержимое логов после воспроизведения проблемы

Норма

Есть события нужных типов с временными метками, совпадающими с моментом проблемы

Тревожный признак

Файлы пустые или событий нет — слишком жёсткие фильтры или событие не наступило

Свободное место на диске с логами

Норма

Объём растёт умеренно, старые файлы удаляются по history

Тревожный признак

Диск стремительно заполняется — срочно сократите набор событий или отключите ТЖ

Типичные ошибки при настройке

Первая и самая частая — файл logcfg.xml сохранён с ошибкой в XML или в неверной кодировке. Платформа молча игнорирует битый файл, и администратор часами ищет события, которых нет. Проверяйте файл любым XML-валидатором или хотя бы открытием в браузере.

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

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

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

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

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

Можно ли включить техжурнал без перезапуска сервера 1С?

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

Насколько техжурнал замедляет работу системы?

Зависит от набора событий. Минимальный набор (только EXCP) практически не влияет на производительность. Полный набор с контекстами и событиями CALL на нагруженной базе может давать заметную дополнительную нагрузку на диск и процессор, поэтому его используют кратковременно.

Как найти в техжурнале причину взаимоблокировки?

Ищите событие TDEADLOCK — в нём перечислены сеансы-участники. Затем по времени и номерам сеансов находите ближайшие события TLOCK и DBMSSQL этих сеансов: они покажут, какие запросы и на каких таблицах конфликтовали. Дальше анализируете прикладной код, который эти запросы формирует.

Где искать logcfg.xml для клиентского приложения?

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

Логи пишутся, но нужных событий нет. Что проверить?

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

Чем удобнее всего анализировать файлы техжурнала?

Вручную большие логи читать тяжело из-за многострочных событий. Используют специализированные инструменты разбора ТЖ, которые парсят события в табличный вид с фильтрами по типу, длительности и сеансу. Минимальная альтернатива — поиск по файлам с регулярными выражениями по имени события и временной метке.