Как правильно настроить технологический журнал (ТЖ) для сервера 1С?

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

Где располагается конфигурационный файл logcfg.xml

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

1. 64-разрядный сервер Windows: поместим файл в глобальный каталог C:\Program Files\1cv8\conf\logcfg.xml (параметры будут действовать для всех установленных версий платформы) либо в каталог конкретной версии платформы C:\Program Files\1cv8\<номер_версии>\conf\logcfg.xml.
2. 32-разрядный сервер Windows: файл размещается в каталоге C:\Program Files (x86)\1cv8\conf\logcfg.xml.
3. Сервер под управлением Linux: глобальный файл располагается по пути /opt/1cv8/conf/logcfg.xml, а версия-зависимый — в /opt/1cv8/x86_64/<номер_версии>/conf/logcfg.xml.

Синтаксис и пример базовой конфигурации

Рассмотрим структуру XML-документа. Файл logcfg.xml крайне чувствителен к регистру тегов и атрибутов, а также должен быть сохранен строго в кодировке UTF-8 (желательно без маркера BOM). Корневым элементом всегда выступает <config> с указанием пространства имен.

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\LOGS\1C_EXCP" history="168">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <event>
            <eq property="name" value="EXCPCNTX"/>
        </event>
        <property name="all"/>
    </log>
</config>

Как создаются файлы и работает ротация логов

Проанализируем особенности формирования каталогов и файлов журнала:

1. Разделение по процессам: платформа создает внутри указанной в атрибуте location папки отдельные подкаталоги для каждого рабочего процесса — например, для процессов rphost, менеджера кластера rmngr и агента ragent.
2. Почасовые файлы: процесс не пишет весь объем данных в один файл на протяжении 168 часов. Каждые 60 минут рабочий процесс закрывает текущий лог и открывает новый с именем вида ГГММДДЧЧ.log.
3. Очистка устаревших данных: атрибут history определяет глубину хранения файлов в часах. По истечении этого времени процесс 1С автоматически удаляет файлы старше указанного интервала при условии, что процесс продолжает активную запись.

Применение настроек и права доступа к каталогам

Разберем важные нюансы вступления конфигурации в силу и частые причины, по которым сбор логов не начинается:

1. Перезапуск не обязателен: для применения изменений в logcfg.xml перезапускать службу ragent или сервер целиком не требуется. Процессы 1С опрашивают дату изменения файла конфигурации с периодичностью около одной минуты и автоматически применяют новые правила.
2. Права учетной записи службы: каталог, указанный в параметре location, должен быть доступен на чтение, запись и создание подкаталогов пользователю операционной системы, от которого запущена служба сервера 1С (по умолчанию USR1CV8 в Windows или usr1cv8 в Linux). Если прав недостаточно, логи записываться не будут, а служба не выдаст явного предупреждения.
3. Отключение журнала: чтобы полностью прекратить сбор технологического журнала, достаточно удалить или переименовать файл logcfg.xml из каталога conf. В течение минуты запись логов остановится.

Фильтрация событий и предотвращение высокой нагрузки

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

1. Поиск ошибок и падений: события EXCP, EXCPCNTX, QERR.
2. Анализ долгих запросов и узких мест: события CALL, SDBL, DBMSSQL, DBPOSTGRS с обязательной фильтрацией в секции <filter> по свойству duration больше установленного порога в микросекундах.
3. Расследование блокировок: события TLOCK, TTIMEOUT, TDEADLOCK.
4. Создание дампов памяти: при необходимости глубокого расследования аварийного закрытия рабочих процессов в конфигурационный файл добавляется секция <dump>.

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