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

Технологический журнал включается одним файлом — logcfg.xml. Его кладут в папку conf каталога платформы (C:\Program Files\1cv8\conf\ в Windows, /opt/1cv8/conf/ в Linux), после чего платформа сама подхватывает настройки в течение примерно минуты — перезапускать сервер не нужно. Графической консоли для технологического журнала в 1С 8.3 нет: вся настройка — это редактирование XML.

Журнал пишет низкоуровневые события платформы: исключения, обращения к СУБД, управляемые блокировки, тайм-ауты, вызовы сервера. Это не то же самое, что журнал регистрации с файлами .lgp/.lgd — тот хранит действия пользователей (вход, проведение документов). Технологический журнал нужен, когда журнала регистрации не хватает: ловим причину падения rphost, разбираем взаимоблокировки, ищем медленные запросы к базе.

Что именно попадает в журнал и в каких случаях он выручает

Платформа фиксирует события по категориям. На практике чаще всего нужны несколько:

• 🔴 EXCP — исключения (ошибки платформы, аварийные завершения процессов);
• ⚠️ QERR — ошибки при выполнении запросов;
• 🐢 DBMSSQL, SDBL — обращения к СУБД и к модели базы данных, с текстом запроса и длительностью;
• 🔒 TLOCK, TTIMEOUT, TDEADLOCK — установка управляемых блокировок, тайм-ауты ожидания и взаимоблокировки;
• 📞 CALL, SCALL — серверные вызовы, полезны при разборе «тормозов» клиента.

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

Подготовка: куда писать, какие права и сколько места

До того как создавать logcfg.xml, решите три вопроса.

Где хранить логи. Папку под журнал вынесите на отдельный диск — не на системный и не на тот, где лежит база данных. Запись журнала конкурирует за диск с самой 1С, и на одном томе это замедлит работу.

Права на запись. Писать в папку должен пользователь, под которым запущена служба сервера 1С (обычно USR1CV8). Если прав нет, журнал молча не появится — ни ошибки, ни предупреждения не будет.

Объём и срок хранения. Атрибут history задаёт, сколько часов хранить файлы; старые платформа удаляет сама. Для разовой диагностики хватает 2–4 часов, для фонового сбора ошибок — 24.

Как включить техжурнал: разбираем logcfg.xml по шагам

1. Найдите папку conf в каталоге платформы. Для Windows это C:\Program Files\1cv8\conf\, для Linux — /opt/1cv8/conf/. Если папки conf нет, создайте её рядом с папкой bin.
2. Создайте в ней текстовый файл logcfg.xml в кодировке UTF-8.
3. Опишите, что и куда писать. Минимальная конфигурация под сбор ошибок:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\1c-logs\techlog" history="24">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <event>
            <eq property="name" value="QERR"/>
        </event>
        <property name="all"/>
    </log>
</config>

Что здесь что:

• location — папка, куда лягут логи (её создаст платформа, но том должен существовать);
• history="24" — хранить файлы сутки;
• каждый <event> — отдельный фильтр событий; несколько блоков <event> работают по «или»;
• <eq property="name" value="EXCP"/> — писать события с именем EXCP;
• <property name="all"/> обязателен — без него в файлы попадут только имена событий без подробностей.

4. Сохраните файл. Через минуту в папке location появятся подкаталоги и файлы. Перезапуск службы не требуется.

Структуру файла формально описывает logcfg.dtd из папки bin — по нему можно свериться, если платформа игнорирует конфигурацию из-за опечатки в теге.

Фильтры событий: пишем точечно, без перегрузки

Внутри одного <event> условия объединяются по «и». Это позволяет сузить выборку до того, что действительно нужно. Классический пример — ловить только медленные запросы к СУБД:

<log location="C:\1c-logs\perf" history="4">
    <event>
        <eq property="name" value="DBMSSQL"/>
        <ge property="Duration" value="1000000"/>
    </event>
    <event>
        <eq property="name" value="TDEADLOCK"/>
    </event>
    <event>
        <eq property="name" value="TTIMEOUT"/>
    </event>
    <property name="all"/>
</log>

Первый фильтр берёт обращения к СУБД длительностью не меньше заданной. Число после дефиса в строке лога и значение Duration указываются в микросекундах, поэтому 1000000 — это одна секунда. Так в журнал попадут только по-настоящему тяжёлые запросы, а не весь поток.

Доступные операторы сравнения: eq (равно), ne (не равно), gt и ge (больше / не меньше), lt и le (меньше / не больше), like (по шаблону с %). Фильтровать можно по любому свойству события — например, по имени процесса p:processName или по пользователю Usr.

Фильтр умеет не только добавлять события, но и отсекать шум. Если нужный поток забивается лишними записями, добавьте условие ne — например, писать все исключения, кроме конкретного ожидаемого. А чтобы к медленным запросам приложить ещё и план их выполнения, внутри <log> ставят элемент <plansql/> — тогда в события DBMSSQL попадёт план СУБД, и видно, где запрос упирается в полное сканирование вместо индекса.

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

Анализ журнала: как устроены файлы и что в них искать

Внутри папки location платформа создаёт подкаталоги по процессам — rphost_1234, ragent_5678, rmngr_..., где число после подчёркивания это PID. В каждом подкаталоге лежат файлы с именами вида YYMMDDHH.log — один файл на час.

Строка события выглядит так:

53:21.836000-1250003,DBMSSQL,5,process=rphost,Usr=Иванов,Sql='SELECT ...',Rows=14,RowsAffected=0

Разбор по частям:

• 53:21.836000 — минуты, секунды и доли секунды внутри часа (сам час — в имени файла);
• -1250003 — длительность события в микросекундах;
• DBMSSQL — имя события;
• 5 — уровень события; дальше через запятую идут его свойства вида имя=значение.

Свойства у каждого типа событий свои. У DBMSSQL это текст запроса Sql, число строк Rows и затронутых строк RowsAffected; у блокировок — описание конфликта и регионы блокировки. Общие для большинства событий: процесс process, пользователь Usr, имя приложения t:applicationName, компьютер t:computerName. По любому из них можно и фильтровать на этапе настройки, и группировать при разборе.

При разборе ошибок смотрите события EXCP: в свойстве Descr лежит текст исключения, в Context — стек, в Usr — пользователь. Для взаимоблокировок читайте TDEADLOCK и TTIMEOUT — там видно, какие управляемые блокировки столкнулись и кто кого ждал.

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

Логов за сутки накапливается много, и открывать их по одному бессмысленно. Задача почти всегда одна: собрать все .log из папки, отфильтровать нужные события и свести их. Для Windows это делается одной командой PowerShell — вытащить все исключения:

Get-ChildItem C:\1c-logs\techlog -Recurse -Filter *.log |
  ForEach-Object { Get-Content $_.FullName } |
  Where-Object { $_ -match ',EXCP,' }

Для Linux то же самое делает grep по всем файлам сразу:

grep -rh ",EXCP," /var/log/1c/techlog/

Фильтрация и сведение ошибок

Чаще всего нужен не поток строк, а свод: какие ошибки повторяются и как часто. Вытащим тексты исключений и посчитаем повторы (Linux):

grep -rh ",EXCP," /var/log/1c/techlog/ \
  | grep -oP "Descr=[^,]+" \
  | sort | uniq -c | sort -rn | head -20

Команда собирает все EXCP, оставляет только текст ошибки из Descr, группирует одинаковые и показывает двадцать самых частых. Так за минуту видно, какая проблема массовая, а какая — единичная.

Топ пользователей по ошибкам

Чтобы понять, у кого ошибки сыплются чаще, группируйте те же события по свойству Usr. PowerShell для Windows:

Get-ChildItem C:\1c-logs\techlog -Recurse -Filter *.log |
  ForEach-Object { Get-Content $_.FullName } |
  Where-Object { $_ -match ',EXCP,' } |
  ForEach-Object { if ($_ -match "Usr=([^,]+)") { $matches[1] } } |
  Group-Object |
  Sort-Object Count -Descending |
  Select-Object -First 5 Count, Name

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

Техжурнал на кластере серверов и в РИБ

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

На каждом сервере в папке location появятся подкаталоги всех процессов кластера, которые там работают: rphost_* (рабочие процессы), rmngr_* (менеджер кластера), ragent_* (агент сервера). Собирая логи для разбора, берите папки со всех серверов и объединяйте — события одного сеанса могут оказаться на разных машинах.

Для распределённой информационной базы (РИБ) журнал настраивается так же — по месту, на сервере каждого узла. Сам обмен РИБ технологический журнал напрямую не показывает: обмен данными смотрят в журнале регистрации и в настройках узлов. А вот ошибки проведения или блокировки, возникающие в узле при загрузке сообщения обмена, в техжурнале видны через EXCP и TLOCK.

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

Чаще всего журнал «не работает» или мешает по одним и тем же причинам:

• 📁 Файл положили не туда. logcfg.xml работает только из папки conf каталога платформы. В папке информационной базы или в произвольном месте он не действует.
• 🔑 Забыли про права на запись. Служба 1С не может создать папку логов — и молчит. Проверяйте права пользователя службы на том из location.
• 🌊 Оставили широкий фильтр в бою. Запись all или необрезанного DBMSSQL на нагруженной базе за ночь забивает диск и роняет производительность.
• 🧩 Пропустили <property name="all"/>. Без него события пишутся «пустыми» — одни имена, разбирать нечего.
• ⏱️ Не выставили history. Без ограничения срока логи копятся, пока не кончится место.
• 🧹 Не убрали конфигурацию после диагностики. Журнал включают под задачу. Разобрались — удалите или очистите logcfg.xml, чтобы он не писал фоном.

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