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

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

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

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

Что именно записывается в файл 1Cv8.lgp

Состав событий определяется конфигурационным файлом logcfg.xml. В зависимости от настроек в .lgp могут попадать: события EXCP (исключения и ошибки платформы), DBMSSQL, DBPOSTGRS или DBORACLE (запросы к СУБД с текстом и длительностью), CALL (вызовы между компонентами), TLOCK и TTIMEOUT (управляемые блокировки и таймауты), TDEADLOCK (взаимоблокировки), PROC, SCALL, MEM и другие.

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

Важно понимать: ТЖ ведётся на уровне платформы, а не конфигурации. Поэтому события пишутся независимо от того, доработана ли конфигурация, и одинаково для «Бухгалтерии», «Зарплаты», «Управления торговлей» и самописных решений.

Где искать файлы .lgp на сервере и клиенте

Каталог размещения логов задаётся в logcfg.xml элементом <log location="...">. Если путь не задан явно, используются каталоги по умолчанию. На Windows-сервере это обычно подкаталог в профиле служебной учётной записи агента сервера 1С, например внутри C:\Program Files\1cv8\... либо в каталоге служебных файлов кластера. На Linux — подкаталоги в домашнем каталоге пользователя, от имени которого работает агент (типично /home/usr1cv8).

На клиентских машинах логи пишутся в профиль пользователя: для Windows это каталог вида %APPDATA%\1C\1cv8\logs или аналогичный, для Linux — ~/.1cv8/1C/1cv8/logs. Точный путь зависит от версии платформы и разрядности.

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

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

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

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

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

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

1. 1
   Создайте отдельный каталог для логов на диске с достаточным запасом места
2. 2
   Сформируйте logcfg.xml с нужными событиями и параметром history
3. 3
   Разместите файл в каталоге conf платформы на сервере (и на клиенте, если нужен клиентский ТЖ)
4. 4
   Перезапустите службу агента сервера 1С или клиентское приложение
5. 5
   Проверьте, что в каталоге появились подкаталоги процессов и файлы 1Cv8.lgp
6. 6
   После сбора данных удалите или переименуйте logcfg.xml и снова перезапустите процессы

Как читать и анализировать события

Файл .lgp — текстовый, его можно открыть любым редактором, но объёмы делают ручной разбор неудобным. Записи имеют формат «минуты:секунды.микросекунды-длительность,СОБЫТИЕ,процесс,свойства». Для анализа удобнее использовать специализированные инструменты: консольные парсеры, обработки для чтения ТЖ или средства мониторинга, которые агрегируют события и строят статистику по длительным запросам.

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

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

Риски и ограничения при работе с ТЖ

Главный риск — переполнение диска. Подробный журнал на нагруженном сервере генерирует гигабайты данных в час. Если логи лежат на системном диске или на том же разделе, что и база данных, исчерпание места приведёт к остановке сервера 1С и, возможно, СУБД. Поэтому параметр history и отдельный диск — обязательный минимум защиты.

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

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

Можно ли удалить файлы .lgp

Да, файлы 1Cv8.lgp можно удалять без последствий для информационной базы — они не участвуют в работе прикладного решения. Однако удалять файлы, которые в данный момент открыты работающим процессом, не всегда возможно (в Windows файл может быть заблокирован), а новые события продолжат записываться, пока ТЖ включён.

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

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

Журнал регистрации — прикладной механизм: он фиксирует действия пользователей, изменения данных и ошибки на уровне конфигурации и хранится внутри базы (или в отдельном файле .lgd). Он отвечает на вопрос «кто и что сделал».

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

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