Как запустить технологический анализ в 1С

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

Подход одинаков для файлового и клиент-серверного режимов, но различается расположение настроек и объём доступных событий. На сервере 1С:Предприятия журнал ведётся на каждом рабочем процессе, поэтому файлы логов могут быть объёмными — это нужно учитывать при выборе каталога хранения и глубины сбора.

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

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

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

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

Подготовка: что проверить перед включением

Перед настройкой убедитесь, что у вас есть права администратора на сервере или компьютере, где работает платформа. Для клиент-серверного режима потребуется доступ к серверу 1С и, при анализе запросов, желательно доступ к СУБД. Также определите, где именно возникает проблема: на стороне клиента, сервера приложений или СУБД — от этого зависит, где размещать конфигурацию.

Подготовьте отдельный каталог для логов на диске с достаточным свободным местом. Не размещайте его на системном диске сервера: при активном сборе журнал может заполнить диск и остановить работу не только 1С, но и операционной системы. Учётная запись службы агента сервера 1С должна иметь право записи в этот каталог.

Включение журнала через logcfg.xml

Основной способ включения — файл logcfg.xml. Для серверного сбора его размещают в каталоге conf внутри каталога установки платформы на сервере (например, в подкаталоге srvinfo для агента сервера) либо в каталоге conf конкретной версии платформы. Для клиентского приложения файл кладётся в каталог conf той версии платформы, под которой запущен клиент.

Минимальная конфигурация задаёт каталог логов и список событий. Пример для сбора ошибок и событий СУБД:

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

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

1. 1
   Создайте каталог для логов на диске с запасом свободного места и дайте туда права записи службе 1С
2. 2
   Создайте файл logcfg.xml с указанием каталога, глубины хранения и нужных событий
3. 3
   Разместите файл в каталоге conf платформы на сервере или у клиента
4. 4
   Перезапустите службу агента сервера 1С или клиентское приложение
5. 5
   Воспроизведите проблему и проверьте, что в каталоге появились файлы логов

Настройка фильтров под конкретную задачу

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

Типовые сценарии фильтрации:

• Медленные запросы — события DBMSSQL (или DBPOSTGRS, DBORACLE) с условием по длительности, например duration больше заданного порога в микросекундах.
• Ошибки пользователей — события EXCP с фильтром по имени пользователя или по фрагменту текста ошибки.
• Взаимоблокировки — события TDEADLOCK и TLOCK, собираемые на сервере в момент возникновения проблемы.
• Аварийные завершения — события PROC, EXCP и системные события, плюс дампы, если они настроены отдельно.

Анализ собранных логов

Логи технологического журнала хранятся в каталогах по именам процессов; внутри — текстовые файлы с временными метками в имени. Формат строки: длительность, тип события, затем пары «свойство=значение». Для небольших объёмов достаточно текстового редактора с поиском, для больших удобнее специализированные инструменты.

На практике применяют несколько подходов:

• ручной разбор файлов поиском по типу события и тексту ошибки;
• консольные утилиты и скрипты для агрегации длительных запросов;
• специализированные инструменты экосистемы 1С (например, консоли анализа ТЖ и инструменты на базе EDT), которые группируют события и показывают самые тяжёлые запросы и контексты.

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

Проверка результата и завершение сбора

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

Когда диагностика завершена, отключите или сократите сбор: удалите файл logcfg.xml либо оставьте только минимальный набор событий (например, EXCP) с короткой глубиной хранения. После этого снова перезапустите службу. Оставленный широкий сбор — самая частая причина переполненных дисков на серверах 1С.

Типичные ошибки и ограничения

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

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

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