Файлы LGD в 1С: что это и как работать с технологическим журналом

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

Технологический журнал — основной инструмент диагностики проблем производительности и ошибок в 1С. Если пользователи жалуются, что «1С тормозит», документы долго проводятся или периодически возникают непонятные ошибки, именно анализ LGD-файлов позволяет увидеть, какие запросы выполнялись, сколько времени заняла каждая операция и где произошёл сбой.

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

Что такое технологический журнал и зачем ему формат LGD

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

Каждый процесс платформы (rphost, ragent, rmngr, тонкий или толстый клиент) пишет свой набор файлов. Внутри каталога события группируются по процессам и по времени: создаются подкаталоги с именами процессов, а внутри — файлы вида YYMMDDHH.lgd, где имя отражает дату и час создания. Один файл обычно покрывает один час работы процесса.

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

Где лежат LGD-файлы и как включить их запись

По умолчанию технологический журнал выключен — платформа не создаёт LGD-файлы сама по себе. Запись включается конфигурационным файлом logcfg.xml, который размещается в каталоге conf сервера 1С (для Windows обычно в каталоге установки платформы или в каталоге srvinfo, для Linux — в домашнем каталоге пользователя, под которым работает агент, в подкаталоге .1cv8/.../conf).

В файле logcfg.xml задаются: каталог размещения логов (элемент location), перечень событий (элементы event), свойства и фильтры. Минимальная конфигурация для сбора всех событий выглядит так:

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

Параметр history задаёт глубину хранения логов в часах — это ключевая защита от переполнения диска. После создания или изменения logcfg.xml сервер 1С подхватывает конфигурацию без перезапуска, но с задержкой (обычно до минуты). Признак того, что журнал включился — появление каталога с подкаталогами процессов и первых LGD-файлов в указанной папке.

Какие события записываются в LGD

Технологический журнал поддерживает десятки типов событий. На практике чаще всего используются несколько групп:

• DBMSSQL, DBPOSTGRS, DBORACLE, DB2 — запросы к соответствующей СУБД с текстом запроса и длительностью;
• EXCP — исключения (ошибки платформы), включая те, что не показываются пользователю;
• DEADLOCK — взаимоблокировки на уровне СУБД;
• TLOCK, TTIMEOUT, TTDEADLOCK — управляемые блокировки транзакций, таймауты и взаимоблокировки на уровне платформы;
• CALL, SCALL — вызовы между процессами и серверами;
• CONN, PROC, CLSTR — соединения, процессы и события кластера;
• LEAKS, MEM — события, связанные с памятью процессов.

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

Как читать содержимое LGD-файла

Каждая строка (точнее, каждая запись) в LGD-файле имеет формат: минуты:секунды.микросекунды-длительность,ИмяСобытия,процесс:поток,свойство='значение',.... Длительность указывается в микросекундах, что позволяет точно сравнивать операции по времени выполнения.

Для ручного анализа небольшого файла достаточно текстового редактора с поиском: ищите имя события (например, EXCP) или большие значения длительности. Для систематической работы используют инструменты: штатную консоль обработки технологического журнала, обработки с ИТС-дисков, а также сторонние анализаторы логов, которые строят топ медленных запросов и группируют ошибки.

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

1. 1
   Включите ТЖ с событиями вашей СУБД и фильтром по длительности, задайте history
2. 2
   Воспроизведите проблемную операцию в то время, пока журнал пишется
3. 3
   Откройте LGD-файл за нужный час и найдите события с максимальной длительностью
4. 4
   По свойству Context определите вызывающий код конфигурации
5. 5
   Проанализируйте текст запроса и план его выполнения в СУБД
6. 6
   После диагностики отключите журнал, удалив или переименовав logcfg.xml

Можно ли удалять LGD-файлы и как чистить логи

LGD-файлы не содержат данных информационной базы — это только диагностическая информация. Их удаление не влияет на работу 1С и на целостность базы. Единственное ограничение: файл, который процесс пишет прямо сейчас, может быть занят; на Windows его удаление может быть заблокировано, на Linux файл удалится из каталога, но место освободится только после закрытия дескриптора процессом.

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

Лучшая профилактика переполнения — не ручная чистка, а корректная настройка: параметр history в logcfg.xml заставляет платформу автоматически удалять устаревшие файлы. Дополнительно каталог логов стоит размещать на отдельном диске или томе, чтобы даже при сбое очистки пострадал только он, а не системный раздел.

Чем LGD отличается от журнала регистрации и дампов

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

Третий механизм — аварийные дампы (dump) и файлы ошибок, которые платформа создаёт при аварийном завершении процессов. Они также могут лежать рядом с логами, но служат для анализа падений, а не штатной работы. Настраиваются дампы отдельно, в том же logcfg.xml элементом dump.

Ограничения и меры предосторожности

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

Вторая сторона — конфиденциальность. В событиях DBMSSQL в тексте запросов могут встречаться значения параметров, то есть фрагменты реальных данных: ФИО, суммы, номера документов. Доступ к каталогу с LGD-файлами нужно ограничивать так же, как к резервным копиям, и не пересылать логи третьим лицам без очистки чувствительных фрагментов.

Наконец, не стоит пытаться «лечить» систему самим технологическим журналом: он только показывает симптомы. Если анализ LGD показывает системные проблемы — массовые взаимоблокировки, регулярные падения rphost, утечки памяти — следующий шаг это анализ кода конфигурации, настроек СУБД и, при необходимости, обращение к специалистам с уже собранной диагностикой.

Частые вопросы о файлах LGD