Технологический журнал 1С: настройка, чтение и поиск проблем производительности / Хабр

Привет, Хабр!

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

Настройка техжурнала — это XML‑файл на 10 строк. Чтение — это grep, awk и немного терпения. Но между «включил и смотрю» и «нашёл причину за 5 минут» — разница в понимании структуры событий. Разберём и то, и другое.

Как включить

Техжурнал настраивается через файл logcfg.xml, расположенный в каталоге конфигурации платформы.

На Windows это обычно C:\Program Files\1cv8\conf\logcfg.xml (для всех версий платформы) или C:\Program Files\1cv8\8.3.25.1394\bin\conf\logcfg.xml (для конкретной версии).

На Linux — /opt/1cv8/x86_64/current/conf/logcfg.xml.

Минимальная конфигурация — собрать всё (для диагностики проблемы, не для постоянного использования):

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="/var/log/1c/techlog" history="24">
        <event>
            <eq property="name" value="DBMSSQL"/>
        </event>
        <event>
            <eq property="name" value="DBPOSTGRS"/>
        </event>
        <event>
            <eq property="name" value="TLOCK"/>
        </event>
        <event>
            <eq property="name" value="TTIMEOUT"/>
        </event>
        <event>
            <eq property="name" value="TDEADLOCK"/>
        </event>
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

location — каталог, куда будут писаться файлы. history="24" — хранить файлы за последние 24 часа (старые удаляются автоматически). Каждый тег <event> — фильтр: собираем только указанные типы событий.

После создания файла перезапуск сервера 1С не нужен. Платформа подхватывает logcfg.xml автоматически в течение минуты. Удалите файл — сбор прекратится так же автоматически.

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

Типы событий: что собирать

DBMSSQL / DBPOSTGRS — запросы к СУБД. Самое ценное для поиска «тормозов». Содержат текст SQL‑запроса, время выполнения, количество строк в результате, имя базы данных, контекст вызова (какой модуль 1С инициировал запрос).
TLOCK — установка управляемой блокировки. Показывает, какой процесс поставил блокировку, на какой ресурс и в каком пространстве.
TTIMEOUT — таймаут ожидания блокировки. Процесс ждал освобождения ресурса и не дождался.
TDEADLOCK — взаимная блокировка (дедлок). Два процесса заблокировали друг друга, один из них был убит.
EXCP — исключение (ошибка). Стек вызова, текст ошибки, контекст.
CALL / SCALL — вызовы между процессами (клиент‑сервер). Показывают время серверного вызова, что полезно для диагностики «где уходит время».
MEM — потребление памяти процессами rphost. Полезно для диагностики утечек памяти.
CONN — соединения. Подключения и отключения пользователей.

Структура файлов

Техжурнал создаёт подкаталоги для каждого процесса (rphost, ragent, rmngr) и файлы с именами вида 25032615.log (год, месяц, день, час — 25 марта 2026, 15 часов). Каждый файл — текст, одно событие — один блок.

Пример события DBPOSTGRS:

53:12.456789-3,DBPOSTGRS,3,process=rphost,p:processName=erp_prod,t:clientID=42,
t:applicationName=1CV8,t:connectID=156,
Context='ОбщийМодуль.РасчётСебестоимости.Модуль : 234 : Запрос.Выполнить()',
Sql='SELECT T1."_Fld123", T1."_Fld456" FROM "dbo"."_AccumRg789" T1 WHERE T1."_Fld123" = $1',
Rows=15000,RowsAffected=0,
Dur=12543210

Основные поля:

Dur=12543210 — длительность в микросекундах. 12 543 210 мкс = 12.5 секунд. Это запрос, который выполнялся 12.5 секунд.

Sql — текст SQL‑запроса. Имена таблиц и полей обфусцированы (_Fld123, _AccumRg789), но по структуре таблицы можно определить, к какому объекту метаданных относится запрос.

Context — стек вызова в терминах 1С. ОбщийМодуль.РасчётСебестоимости.Модуль : 234 — модуль и номер строки, откуда вызван запрос. Это связующее звено между SQL‑запросом и кодом конфигурации.

Rows=15000 — запрос вернул 15 000 строк. Если запрос на получение одного документа возвращает 15 000 строк — что‑то не так с запросом или с данными.

p:processName=erp_prod — имя информационной базы. Если на сервере 20 баз, вы видите, какая именно «тормозит».

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

Самая частая задача: найти запросы, которые выполняются дольше N секунд. На Linux — grep + awk:

# Найти все запросы к СУБД дольше 5 секунд (5 000 000 мкс)
grep -E "DBPOSTGRS|DBMSSQL" /var/log/1c/techlog/rphost_*/*.log \
  | awk -F'Dur=' '{if ($2+0 > 5000000) print $0}' \
  | sort -t'=' -k$(grep -o 'Dur=' <<< "Dur=" | wc -l) -n -r \
  | head -20

Для более структурированного анализа удобнее скрипт на Python или OneScript, который парсит события в CSV или загружает в таблицу для анализа.

Может быть, например, такая находка: один запрос выполняется 30 секунд, вызывается из модуля проведения документа «Реализация товаров», строка 234. Смотрим код — запрос без условий по периоду, сканирует весь регистр за все годы. Добавляем условие по периоду — запрос выполняется 200 мс.

Поиск блокировок и дедлоков

# Все события блокировок
grep "TLOCK\|TTIMEOUT\|TDEADLOCK" /var/log/1c/techlog/rphost_*/*.log

Событие TTIMEOUT покажет:

45:23.123456-0,TTIMEOUT,5,process=rphost,p:processName=erp_prod,
WaitConnections=156,
Locks='AccumRg789.Fld123=42:Fld456=1:Exclusive',
Context='Документ.РеализацияТоваровУслуг.МодульОбъекта : 89 : Движения.Записать()'

WaitConnections=156 — соединение 156 заблокировало ресурс, и текущий процесс не дождался его освобождения. Locks — описание заблокированного ресурса. Context — откуда вызывался код, который ждал.

Связка TLOCK + TTIMEOUT позволяет восстановить полную картину: кто заблокировал (TLOCK), кто ждал и не дождался (TTIMEOUT), на каком ресурсе пересеклись.

Фильтрация: не собирать лишнее

На нагруженном сервере полный техжурнал генерирует гигабайты. Фильтры в logcfg.xml позволяют собирать только нужное.

По длительности (только медленные запросы):

<event>
    <eq property="name" value="DBPOSTGRS"/>
    <ge property="Dur" value="5000000"/>
</event>

ge — greater or equal. Собирать DBPOSTGRS только если Dur >= 5 000 000 мкс (5 секунд). Это сильно снижает объём: вместо миллионов событий — десятки самых проблемных.

По имени базы (только конкретная информационная база):

<event>
    <eq property="name" value="DBPOSTGRS"/>
    <eq property="p:processName" value="erp_prod"/>
</event>

Комбинация фильтров: только медленные запросы в конкретной базе:

<event>
    <eq property="name" value="DBPOSTGRS"/>
    <eq property="p:processName" value="erp_prod"/>
    <ge property="Dur" value="3000000"/>
</event>

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

Расшифровка имён таблиц и полей

Имена в SQL‑запросах обфусцированы: AccumRg789, Fld123. Чтобы понять, к какому объекту метаданных относится запрос, нужна таблица соответствий.

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

Связка: _AccumRg789 — регистр накопления, 789 — номер в метаданных. По маппингу находим: это «ОстаткиТоваровНаСкладах». Теперь SQL‑запрос читаем как бизнес‑запрос.

Постоянный мониторинг: что держать включённым

Для прода рекомендуется постоянный сбор с жёсткими фильтрами:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="/var/log/1c/techlog" history="72">
        <!-- Медленные запросы к СУБД (> 3 секунд) -->
        <event>
            <eq property="name" value="DBPOSTGRS"/>
            <ge property="Dur" value="3000000"/>
        </event>
        <!-- Таймауты блокировок -->
        <event>
            <eq property="name" value="TTIMEOUT"/>
        </event>
        <!-- Дедлоки -->
        <event>
            <eq property="name" value="TDEADLOCK"/>
        </event>
        <!-- Исключения -->
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

72 часа истории. Только проблемные события. Объём — десятки мегабайт в день. Когда пользователь скажет «вчера в 15:00 всё тормозило», вы откроете файл 26032515.log и за минуту найдёте запрос, который работал 30 секунд.

Для расследования конкретной проблемы — временно расширяете фильтры (убираете порог по Dur, добавляете TLOCK и CALL), воспроизводите проблему, анализируете, убираете расширенные фильтры.

Автоматизация анализа

Ручной grep по файлам работает для разовой диагностики. Для постоянного мониторинга — нужна автоматизация.

Подходы:

Скрипт на OneScript / Python, который раз в час парсит новые файлы техжурнала, извлекает медленные запросы и блокировки, и отправляет сводку в Telegram или на дашборд.
Загрузка в ClickHouse / Elasticsearch. Техжурнал — по сути структурированный лог. Парсер разбирает события в строки, загружает в аналитическую СУБД. Дальше — Grafana‑дашборд с топ-10 медленных запросов за день, графиком количества блокировок по часам, алертами на дедлоки.
Обработка 1С, встроенная в конфигурацию. Регламентное задание читает файлы техжурнала и формирует отчёт в самой 1С. Подход хуже (нагружает сервер 1С), но не требует внешней инфраструктуры.
Техжурнал — единственный инструмент, который показывает, что происходит внутри сервера 1С на техническом уровне. Журнал регистрации говорит «что произошло» (провели документ). Техжурнал говорит «как происходило» (запрос к СУБД выполнялся 12 секунд, потому что сканировал 15 000 строк без индекса). Для DevOps 1С это разница между «работаем вслепую» и «видим каждый проблемный запрос в реальном времени».

Когда в 1С всё «вроде работает», но пользователи жалуются на тормоза, дедлоки и случайные падения — разбираться приходится вслепую: логи шумные, причины неочевидны, время уходит на догадки. В какой‑то момент становится ясно, что проблема не в конкретном запросе, а в отсутствии системного контроля. Курс «DevOps 1С» как раз про то, как перестать тушить пожары и начать управлять стабильностью и производительностью системы.

Пройдите бесплатное тестирование по курсу, чтобы оценить свои знания и навыки. До 30 апреля за прохождение теста действует скидка 15%

Также приходите на открытые уроки, где рассмотрим, как на практике связать 1С с RabbitMQ и выстроить CI/CD через Jenkins без догадок и лишней теории:

14 апреля в 20:00 — «1С и RabbitMQ». Записаться
23 апреля в 20:00 — «Интеграция 1С:EDT с CI/CD (Jenkins)». Записаться

Технологический журнал 1С: настройка, чтение и поиск проблем производительности