Технологический журнал 1С: настройка logcfg.xml, фильтры и безопасная диагностика

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

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

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

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

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

Журнал регистрации и технологический журнал собирают разные данные и используются для разных задач. Они дополняют друг друга, но не заменяют.

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

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

Упрощённо сбор данных выглядит так:

            Пользователь или задание
                      │
                      ▼
              Клиентский процесс
                      │
                      ▼
          Серверные процессы 1С
       ragent / rmngr / rphost
                      │
                      ▼
              SQL Server или
                 PostgreSQL
                      │
                      ▼
       События технологического журнала
                      │
                      ▼
         Каталоги и текстовые файлы
                *.log

Где находится logcfg.xml и куда записываются файлы

Параметры технологического журнала задаются в XML-файле с именем logcfg.xml. Платформа считывает его из каталога конфигурационных файлов.

На Windows обычно проверяются каталоги conf, связанные с установленной платформой 1С. В зависимости от способа установки, разрядности и версии расположение может отличаться. На Linux каталог также зависит от варианта установки платформы.

Перед созданием нового файла нужно проверить:

• где установлена платформа;
• какая версия фактически запускает серверные процессы;
• существует ли уже logcfg.xml;
• не используется ли общий каталог конфигурации;
• от имени какой учётной записи работает служба сервера 1С;
• есть ли у этой учётной записи права на каталог журналов.

Выбор каталога для журналов

Файлы лучше записывать в отдельный каталог, который не смешивается с файлами платформы, информационной базой и резервными копиями.

Например, на Windows можно заранее создать структуру:

D:\1CLogs\
├── exceptions\
├── locks\
├── database\
└── calls\

На Linux может использоваться отдельный каталог внутри /var/log или другого раздела, предназначенного для технических данных.

При выборе места нужно учитывать:

• объём свободного пространства;
• скорость дисковой подсистемы;
• права учётной записи службы 1С;
• политику антивирусной проверки;
• резервирование и очистку файлов;
• наличие мониторинга заполнения диска.

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

Как проверить, что журнал включился

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

Если каталог остаётся пустым, последовательно проверяются:

• имя файла — строго logcfg.xml;
• расширение файла, особенно если Windows скрывает известные расширения;
• корректность XML;
• пространство имён в корневом элементе;
• правильный каталог conf;
• права службы на запись;
• наличие событий, соответствующих фильтру;
• фактический путь запуска процессов 1С.

Как устроен файл logcfg.xml

Файл состоит из корневого элемента config и одного или нескольких разделов log. Каждый раздел определяет каталог хранения, срок хранения, набор событий и свойства, которые будут записываться.

Минимальный пример для сбора технологических исключений:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="D:\1CLogs\exceptions" history="24">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

В этом примере:

• location задаёт каталог хранения;
• history="24" ограничивает срок хранения файлов;
• event описывает условие отбора;
• EXCP означает технологические исключения;
• property name="all" включает запись всех доступных свойств выбранных событий.

Несколько журналов в одном файле

Разные группы событий можно записывать в отдельные каталоги. Это упрощает анализ и позволяет назначить каждой группе собственный срок хранения.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">

    <log location="D:\1CLogs\exceptions" history="24">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>

    <log location="D:\1CLogs\locks" history="4">
        <event>
            <eq property="Name" value="TLOCK"/>
        </event>
        <event>
            <eq property="Name" value="TTIMEOUT"/>
        </event>
        <event>
            <eq property="Name" value="TDEADLOCK"/>
        </event>
        <property name="all"/>
    </log>

</config>

Так исключения можно хранить дольше, а подробные события блокировок — только в течение короткого диагностического окна.

Проверка XML до установки

Даже одна пропущенная кавычка или незакрытый тег делает конфигурацию некорректной. Перед копированием файла на рабочий сервер его нужно открыть в редакторе с проверкой XML или проверить стандартными средствами.

В PowerShell базовую проверку синтаксиса можно выполнить так:

[xml](Get-Content "C:\Temp\logcfg.xml") | Out-Null

Если структура XML нарушена, PowerShell вернёт ошибку. Такая проверка не подтверждает правильность всех параметров технологического журнала, но обнаруживает ошибки разметки.

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

Состав журнала следует выбирать по симптому. Собирать все события на постоянной основе обычно не требуется.

Диагностика технологических исключений

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

<log location="D:\1CLogs\exceptions" history="24">
    <event>
        <eq property="Name" value="EXCP"/>
    </event>
    <property name="all"/>
</log>

При анализе важно сопоставлять время исключения с:

• жалобой пользователя;
• журналом регистрации;
• событиями Windows или Linux;
• перезапуском процессов;
• состоянием СУБД;
• загрузкой CPU, памяти и диска.

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

Диагностика блокировок

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

<log location="D:\1CLogs\locks" history="4">
    <event>
        <eq property="Name" value="TLOCK"/>
    </event>
    <event>
        <eq property="Name" value="TTIMEOUT"/>
    </event>
    <event>
        <eq property="Name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
</log>

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

Диагностика обращений к СУБД

События DBMSSQL и DBPOSTGRS используются для анализа обращений к соответствующей СУБД. Они могут включать текст запросов и дополнительный контекст, поэтому объём журналов быстро увеличивается.

Такой сбор следует включать:

• на ограниченный период;
• по возможности во время воспроизведения проблемы;
• с контролем свободного места;
• с заранее определённым временем отключения;
• с учётом конфиденциальности записываемых данных.

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

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

Пример полного отбора:

<log location="D:\1CLogs\full" history="1">
    <event>
        <ne property="Name" value=""/>
    </event>
    <property name="all"/>
</log>

Такую конфигурацию можно использовать только после оценки свободного места и на минимально необходимый срок.

Как безопасно организовать сбор и ротацию

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

Безопасный порядок сбора выглядит так:

          Зафиксировать симптом и время
                      │
                      ▼
             Выбрать события ТЖ
                      │
                      ▼
       Проверить каталог и свободное место
                      │
                      ▼
             Установить logcfg.xml
                      │
                      ▼
        Проверить появление файлов журнала
                      │
                      ▼
             Воспроизвести проблему
                      │
                      ▼
          Скопировать нужный интервал
                      │
                      ▼
      Отключить или сузить конфигурацию

Контроль свободного места

На Windows свободное место можно проверить в PowerShell:

Get-Volume |
    Select-Object DriveLetter, FileSystemLabel,
        @{Name="FreeGB";Expression={[math]::Round($_.SizeRemaining / 1GB, 2)}},
        @{Name="SizeGB";Expression={[math]::Round($_.Size / 1GB, 2)}}

На Linux:

df -h

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

Хранение на отдельном разделе

Для подробной диагностики желательно использовать отдельный диск или раздел. Это снижает риск заполнения системного тома и упрощает установку порогов мониторинга.

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

Копирование данных для анализа

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

Полезно приложить к журналу:

• точное время ошибки;
• часовой пояс сервера и рабочего места;
• имя информационной базы;
• имя пользователя или номер сеанса;
• описание выполненной операции;
• текст сообщения об ошибке;
• версию платформы;
• сведения о СУБД;
• момент начала и завершения сбора.

Как анализировать собранный журнал

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

Начинать с временного интервала

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

Далее события сопоставляются по:

• процессу;
• сеансу;
• соединению;
• информационной базе;
• пользователю;
• типу события;
• продолжительности операции;
• контексту выполнения.

Не искать проблему по одной строке

Некоторые события занимают несколько строк и содержат длинный контекст. Обычный построчный поиск может показать только часть события или потерять связанные данные.

Поэтому при фильтрации нужно сохранять событие целиком, особенно при анализе обращений к СУБД, серверных вызовов и исключений.

Сопоставлять с другими источниками

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

• журналом регистрации 1С;
• событиями операционной системы;
• журналами SQL Server или PostgreSQL;
• метриками CPU, памяти и диска;
• историей перезапусков служб;
• мониторингом сети;
• изменениями конфигурации и платформы.

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

Типичные ошибки при анализе

Практический чек-лист безопасной диагностики

Перед включением технологического журнала на рабочем сервере стоит пройти контрольный список.

• Зафиксировано точное описание проблемы.
• Определён примерный период её воспроизведения.
• Проверена версия платформы и путь запуска процессов.
• Найден фактически используемый каталог конфигурационных файлов.
• Сохранена копия существующего logcfg.xml.
• Выбран минимально необходимый набор событий.
• Создан отдельный каталог для журналов.
• Учётной записи службы предоставлены права на запись.
• Проверено свободное место и настроен контроль его заполнения.
• Установлен ограниченный срок хранения.
• Проверено появление файлов после включения.
• Записано точное время воспроизведения ошибки.
• Нужный интервал скопирован в отдельное место.
• Временная конфигурация отключена или уменьшена.
• После завершения проверено свободное место.

Заключение

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

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

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

Что почитать дальше

Для продолжения диагностики серверной инфраструктуры 1С будут полезны следующие материалы:

• Почему 1С тормозит на сервере — какие компоненты проверить до углублённого анализа журналов.
• Как включить отладку на сервере 1С — чем отладка прикладного кода отличается от технологической диагностики.
• Сетевые порты сервера 1С — как проверить соединения между клиентами, кластером и СУБД.
• Серверная инфраструктура 1С — как устроено взаимодействие сервера приложений, СУБД и пользователей.

Когда стоит обратиться к специалистам

Небольшой журнал с событиями EXCP можно настроить самостоятельно, если известны расположение платформы, учётная запись службы и время возникновения проблемы. Для блокировок, длительных запросов и периодических зависаний обычно требуется сопоставление нескольких источников данных.

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

Кратко

• Технологический журнал фиксирует работу процессов платформы 1С.
• Параметры сбора задаются в файле logcfg.xml.
• Состав событий нужно выбирать под конкретную диагностическую задачу.
• Полный журнал не следует оставлять на продукционном сервере без необходимости.
• Параметр history ограничивает срок хранения файлов.
• Во время сбора необходимо контролировать свободное место и скорость роста каталога.
• Для анализа нужно знать точное время, пользователя, базу и выполняемую операцию.
• После диагностики временную конфигурацию следует отключить или сузить.