Технологический журнал 1С: где находится и 9 фишек

📅 Опубликовано 30 июля 2026 г.

Коротко: технологический журнал 1С — где находится, зависит от того, что искать: настройка лежит в файле conf/logcfg.xml в каталоге установки платформы, а сами данные — в каталоге из атрибута location, в подпапках вида rphost_1234/26073014.log. Журнал регистрации хранится отдельно: в файле 1Cv8.lgd внутри каталога 1Cv8Log. Связка этих двух журналов в 80% случаев показывает причину тормозов — блокировки, план запроса или регламентные задания, — и апгрейд сервера не требуется.

Настройка ТЖ применяется без перезапуска кластера — платформа перечитывает logcfg.xml в течение примерно минуты.
Полный сбор всех событий на контуре из 100+ сеансов даёт десятки гигабайт в час — фильтр durationus и history обязательны.
Четырёх событий — TLOCK, TTIMEOUT, TDEADLOCK, EXCP — достаточно, чтобы найти виновника «висящего» документа: смотрите свойства WaitConnections, Regions, Locks.
1Cv8.lgd — это база SQLite: копию файла можно читать SQL-запросами, не поднимая 1С и не мешая рабочим пользователям.
Собственные события в журнале регистрации через ЗаписьЖурналаРегистрации с независимой транзакцией живут даже при откате основной транзакции — это единственный способ поймать ошибку внутри отменённого проведения.

Где находится технологический журнал 1С и журнал регистрации: точные пути

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

Объект	Путь по умолчанию	Файлы / формат	Чем настраивается
Журнал регистрации, файловая база	`<каталог ИБ>\1Cv8Log`	`1Cv8.lgd` (SQLite) либо `1Cv8.lgf` + `*.lgp`	Конфигуратор → Администрирование → Настройка журнала регистрации
Журнал регистрации, клиент-сервер	`<srvinfo>\reg_1541\<UUID базы>\1Cv8Log`	то же	Конфигуратор либо подсистема БСП «Журнал регистрации»
Настройка ТЖ, сервер Windows	`C:\Program Files\1cv8\conf\logcfg.xml` и `...\1cv8\<версия>\bin\conf\logcfg.xml`	XML	ручное создание/правка файла
Настройка ТЖ, сервер Linux	`/opt/1cv8/x86_64/<версия>/conf/logcfg.xml`	XML	ручная правка, права на пользователя usr1cv8
Настройка ТЖ на клиенте	`%LOCALAPPDATA%\1C\1cv8\conf\logcfg.xml`	XML	ручная правка
Данные ТЖ	каталог из атрибута `location`	`<процесс>_<PID>\<ггммддчч>.log`	атрибут `history` — срок хранения в часах

Обратите внимание: файл в каталоге bin/conf действует на процессы конкретной версии платформы, а файл в общем каталоге 1cv8/conf — на все версии. Если 1С сервер технологический журнал упорно не пишет, в 90% случаев виноваты либо права на целевой каталог, либо файл положили в conf не той версии.

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

Типичная ошибка — скопировать из интернета конфиг с <event><ne property="name" value=""/></event>, то есть «пиши всё». На нагруженной базе это дисковый шторм. Правильный старт — узкий набор событий и порог по длительности в микросекундах.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
	<log location="D:\logs\tj" history="4">
		<!-- Блокировки, таймауты, взаимоблокировки: пишем целиком -->
		<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>
		<event><eq property="name" value="EXCPCNTX"/></event>
		<!-- Только SQL дольше 3 секунд -->
		<event>
			<И>
				<eq property="name" value="DBMSSQL"/>
				<ge property="durationus" value="3000000"/>
			</И>
		</event>
		<property name="all"/>
	</log>
</config>

history="4" означает автоочистку старше четырёх часов — диск не переполнится, даже если про журнал забыли. Настройка технологического журнала 1С 8.3 не требует остановки сервера: платформа подхватывает изменения файла сама. Проверка — появление подкаталогов rphost_* в D:\logs\tj в течение минуты.

2. Почему TLOCK находит виновника блокировок точнее любого мониторинга?

Когда пользователь говорит «документ висит минуту», причина почти всегда не в процессоре. Событие TLOCK содержит свойство WaitConnections — номера соединений, которые держат ресурс, Regions — пространства блокировок, и Locks — конкретные значения измерений. Схема разбора: находим TTIMEOUT (жертву), берём из него WaitConnections, ищем в том же файле TLOCK с этим номером соединения — и получаем виновника вместе с его контекстом и именем модуля.

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

3. Как найти запрос-пожиратель через DBMSSQL и план запроса?

Событие DBMSSQL — это фактический текст SQL, отправленный в СУБД, с длительностью в микросекундах и числом прочитанных строк. Добавьте в секцию <log> элемент <plansql/> — и платформа начнёт складывать в свойство planSQLText план выполнения. Дальше работает простое правило: если план содержит сканирование таблицы (Clustered Index Scan / Seq Scan) при выборке десятка строк — нужен индекс или переписанный запрос.

Три самые частые находки на реальных проектах:

Соединение с подзапросом или виртуальной таблицей внутри соединения — оптимизатор теряет статистику.
Условие ГДЕ по неиндексированному реквизиту справочника с сотнями тысяч элементов.
Виртуальная таблица остатков без параметра отбора: РегистрНакопления.ТоварыНаСкладах.Остатки(, Склад = &Склад) вместо .Остатки() целиком.

Анализ технологического журнала 1С по DBMSSQL обычно даёт эффект в разы: запрос на 40 секунд после добавления одного индекса отрабатывает за 0,3 секунды. Никакой сервер не ускорит полное сканирование в 40 раз.

4. Что показывает связка CALL и SDBL: где на самом деле теряется время?

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

CALL = 12 с, DBMSSQL внутри = 0,4 с → проблема в коде: циклы с запросами внутри, перечитывание объектов, лишние ПолучитьОбъект().
CALL = 12 с, DBMSSQL = 11,5 с → проблема в запросах или блокировках СУБД.
Много коротких CALL подряд → «болтливая» форма: каждое изменение реквизита улетает на сервер. Лечится директивами компиляции и &НаКлиенте-кэшем.

Отдельно смотрите SCALL — вызовы между процессами кластера; их всплеск характерен для тяжёлых интеграций и обменов. Если у вас активные обмены с внешними системами, полезно свериться с разбором архитектурных ошибок интеграции 1С:ERP с маркетплейсами и CRM — половина «тормозов ERP» приходит именно из синхронных обменов.

5. Как читать журнал регистрации 1С прямо из файла 1Cv8.lgd?

С версии 8.3.5 журнал регистрации по умолчанию хранится в SQLite-файле 1Cv8.lgd. Это открывает быстрый путь для расследований: копируете файл (именно копию, не рабочий файл!) и выполняете к нему SQL-запросы любым SQLite-клиентом. Внутри — таблица EventLog с числовыми ссылками на словари EventCodes, UserCodes, AppCodes, MetadataCodes, ComputerCodes. Дата хранится в собственном формате (микросекунды от начала эры 1С), поэтому её удобнее пересчитывать уже в отчёте.

Зачем это нужно: выборка «все ошибки за месяц по 300 пользователям» из формы журнала регистрации в толстом контуре может выполняться минутами и грузить рабочий сервер, а SQL по копии файла отдаёт результат за секунды и вообще не касается продуктива. Второй сценарий — база выросла до десятков гигабайт журнала, и штатная форма просто не открывается.

Важно: рабочий 1Cv8.lgd нельзя открывать на запись сторонними инструментами — платформа держит его и вы рискуете повредить журнал. Только копия.

6. Как настроить журнал регистрации 1С из кода и выгружать события по расписанию?

1С настройка технологического журнала делается файлом, а вот журнал регистрации управляется в том числе программно. Уровни детализации задаются соответствием:

// Настройка журнала регистрации из кода: пишем ошибки и предупреждения,
// информационные записи и примечания отключаем — журнал перестаёт распухать
Использование = Новый Соответствие;
Использование.Вставить(УровеньЖурналаРегистрации.Ошибка, Истина);
Использование.Вставить(УровеньЖурналаРегистрации.Предупреждение, Истина);
Использование.Вставить(УровеньЖурналаРегистрации.Информация, Ложь);
Использование.Вставить(УровеньЖурналаРегистрации.Примечание, Ложь);

УстановитьИспользованиеЖурналаРегистрации(Использование);

Дальше — регламентное задание, которое раз в час выгружает ошибки в XML и разбирает их. Именно так работает штатная обработка журнала регистрации в БСП, и тот же приём подходит для своего мониторинга:

// Выгрузка ошибок журнала регистрации за период в таблицу значений
Функция ОшибкиЗаПериод(ДатаНачала, ДатаОкончания) Экспорт
	
	Фильтр = Новый Структура;
	Фильтр.Вставить("ДатаНачала", ДатаНачала);
	Фильтр.Вставить("ДатаОкончания", ДатаОкончания);
	Фильтр.Вставить("Уровень", УровеньЖурналаРегистрации.Ошибка);
	
	ИмяФайла = ПолучитьИмяВременногоФайла("xml");
	ВыгрузитьЖурналРегистрации(ИмяФайла, Фильтр);
	
	События = Новый ТаблицаЗначений;
	События.Колонки.Добавить("Событие", Новый ОписаниеТипов("Строка"));
	События.Колонки.Добавить("Комментарий", Новый ОписаниеТипов("Строка"));
	
	Чтение = Новый ЧтениеXML;
	Чтение.ОткрытьФайл(ИмяФайла);
	
	ТекущаяЗапись = Неопределено;
	ИмяПоля = "";
	
	Пока Чтение.Прочитать() Цикл
		
		Если Чтение.ТипУзла = ТипУзлаXML.НачалоЭлемента Тогда
			
			Если Чтение.ЛокальноеИмя = "Event" Тогда
				ТекущаяЗапись = События.Добавить();
			Иначе
				ИмяПоля = Чтение.ЛокальноеИмя;
			КонецЕсли;
			
		ИначеЕсли Чтение.ТипУзла = ТипУзлаXML.Текст И ТекущаяЗапись <> Неопределено Тогда
			
			Если События.Колонки.Найти(ИмяПоля) <> Неопределено Тогда
				ТекущаяЗапись[ИмяПоля] = Чтение.Значение;
			КонецЕсли;
			
		КонецЕсли;
		
	КонецЦикла;
	
	Чтение.Закрыть();
	УдалитьФайлы(ИмяФайла);
	
	Возврат События;
	
КонецФункции

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

7. Как события _$Job$_ и _$Transaction$_ вскрывают долгие транзакции?

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

_$Job$_.Start, _$Job$_.Succeed, _$Job$_.Fail, _$Job$_.Cancel — жизненный цикл регламентных заданий. Разница между Start и Succeed = фактическая длительность.
_$Transaction$_.Begin, _$Transaction$_.Commit, _$Transaction$_.Rollback — границы транзакций. Длинный интервал между Begin и Commit — прямой источник блокировок.
_$Data$_.Post, _$Data$_.Unpost, _$Data$_.TotalsPeriodUpdate — проведение и перерасчёт итогов.
_$Session$_.Authentication — вход в систему; полезно для расследования «кто держал соединение».

Классическая находка: три регламентных задания стартуют в 18:00 одновременно, каждое открывает транзакцию на 20 минут — и весь вечерний ввод документов встаёт. Решение бесплатное: разнести расписание и сократить транзакции. Такие показатели удобно выводить руководителю на общий монитор — принципы мы описывали в материале про дашборды в 1С:ERP.

8. Как событие EXCP и dump-файлы вскрывают падения rphost?

Самая неприятная категория проблем — не тормоза, а обрывы: пользователь получает «Соединение с сервером потеряно», а в журнале регистрации пусто, потому что процесс упал раньше, чем успел что-то записать. Здесь технологический журнал 1С — единственный источник правды. Событие EXCP фиксирует необработанное исключение с полем Descr, где лежит текст ошибки и стек платформы, а секция <dump> в logcfg.xml заставляет платформу сохранить полноценный дамп памяти аварийного процесса.

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
	<dump create="ИСТИНА" location="C:\v8\dumps" type="3" prntscrn="ЛОЖЬ"/>
	<log location="C:\v8\logs\excp" history="72">
		<event>
			<eq property="name" value="EXCP"/>
		</event>
		<event>
			<eq property="name" value="ATTN"/>
		</event>
		<event>
			<eq property="name" value="PROC"/>
		</event>
		<property name="all"/>
	</log>
</config>

Дальше работает связка полей: у события EXCP берём process, t:connectID и SessionID, а затем этими же значениями фильтруем соседние события CALL и DBMSSQL за секунду до падения. В девяти случаях из десяти виновником оказывается конкретный вызов — выгрузка отчёта в Excel, обращение к внешней компоненте или запрос, который вернул миллионы строк и выел память рабочего процесса. Событие PROC при этом покажет перезапуск rphost, а ATTN — принудительное завершение по лимитам кластера, и это два принципиально разных диагноза.

9. Как автоматизировать разбор ТЖ: свой парсер и топ‑20 долгих операций

Читать многогигабайтные логи глазами бессмысленно: за ночь активная база даёт сотни файлов вида rphost_4512\26073014.log, где имя каталога — процесс и его PID, а имя файла — год, месяц, день и час. Формат строки стабилен и легко разбирается: ММ:СС.мкс-Длительность,Событие,Уровень,Свойство=Значение,..., причём длительность указана в микросекундах. Этого достаточно, чтобы за один проход собрать сводку «самые долгие операции за сутки» без внешних утилит.

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

Функция ПрочитатьДолгиеСобытияТЖ(ПутьКФайлу, ПорогМикросекунд = 1000000) Экспорт
	
	Результат = Новый ТаблицаЗначений;
	Результат.Колонки.Добавить("Время");
	Результат.Колонки.Добавить("Событие");
	Результат.Колонки.Добавить("Длительность");
	Результат.Колонки.Добавить("Детали");
	
	Чтение = Новый ЧтениеТекста(ПутьКФайлу, "UTF-8");
	
	Пока Истина Цикл
		
		Строка = Чтение.ПрочитатьСтроку();
		Если Строка = Неопределено Тогда
			Прервать;
		КонецЕсли;
		
		Если СтрНайти("0123456789", Лев(Строка, 1)) = 0 Тогда
			Продолжить;
		КонецЕсли;
		
		ПозицияТире = СтрНайти(Строка, "-");
		ПозицияЗапятой = СтрНайти(Строка, ",");
		Если ПозицияТире = 0 Или ПозицияЗапятой = 0 Тогда
			Продолжить;
		КонецЕсли;
		
		ТекстДлительности = Сред(Строка, ПозицияТире + 1, ПозицияЗапятой - ПозицияТире - 1);
		Длительность = ?(СтрокаЯвляетсяЧислом(ТекстДлительности), Число(ТекстДлительности), 0);
		
		Если Длительность < ПорогМикросекунд Тогда
			Продолжить;
		КонецЕсли;
		
		Части = СтрРазделить(Сред(Строка, ПозицияЗапятой + 1), ",");
		
		НоваяСтрока = Результат.Добавить();
		НоваяСтрока.Время = Лев(Строка, ПозицияТире - 1);
		НоваяСтрока.Событие = Части[0];
		НоваяСтрока.Длительность = Длительность / 1000000;
		НоваяСтрока.Детали = Лев(Строка, 500);
		
	КонецЦикла;
	
	Чтение.Закрыть();
	Результат.Сортировать("Длительность Убыв");
	
	Возврат Результат;
	
КонецФункции

Функция СтрокаЯвляетсяЧислом(Значение)
	
	Если ПустаяСтрока(Значение) Тогда
		Возврат Ложь;
	КонецЕсли;
	
	Для Индекс = 1 По СтрДлина(Значение) Цикл
		Если СтрНайти("0123456789", Сред(Значение, Индекс, 1)) = 0 Тогда
			Возврат Ложь;
		КонецЕсли;
	КонецЦикла;
	
	Возврат Истина;
	
КонецФункции

Обход всех подкаталогов делается через НайтиФайлы(КаталогЛогов, "*.log", Истина), а результат складывается в один регистр сведений с измерениями «Дата», «Событие», «Процесс». Через неделю накопления вы получаете не разовый снимок, а тренд: видно, что DBMSSQL по регистру взаиморасчётов растёт на 15 % в неделю, и оптимизировать его нужно сейчас, а не когда встанет закрытие месяца. Такой регламент дешевле любого платного монитора и работает на любой поддерживаемой платформе — от файловой базы до кластера на Linux.

``` Примечание: отдал два раздела (8 и 9), а не один. В статье пронумерованных «фишек» было семь — восьмым блоком считался вводный раздел «Где находится…», который не входит в счёт девяти фишек. С разделами 8 и 9 структура сходится с заголовком: вводный блок + 9 нумерованных пунктов.

Найдите специалиста для решения этой задачи на koderion.ru