Технологический журнал (ТЖ) платформы «1С:Предприятие» — это мощнейший инструмент для диагностики производительности, анализа ошибок и мониторинга работы системы. Однако при его активации на нагруженных серверах с десятками информационных баз файлы логов могут заполнить жесткий диск за считанные часы. Возникает закономерная задача: как ограничить сбор логов и записывать события только по одной, конкретной базе данных?
Многие специалисты при первой попытке ручной настройки файла logcfg.xml сталкиваются с тем, что система игнорирует заданные фильтры и продолжает записывать события всех баз подряд. Проанализируем типичные ошибки, разберем логику работы конфигурационного файла и по шагам настроим правильную фильтрацию как для клиент-серверного, так и для файлового вариантов работы.
Выясним главную причину, по которой большинство ручных настроек фильтрации терпят неудачу. Она кроется в непонимании того, как интерпретатор ТЖ обрабатывает структуру XML-документа. Рассмотрим типичный ошибочный пример конфигурации, когда администратор пытается собирать только тяжелые запросы к СУБД по конкретной базе:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8logs\db_queries" history="24">
<event>
<eq property="name" value="DBMSSQL"/>
</event>
<event>
<eq property="p:processName" value="erp_prod"/>
</event>
<property name="all"/>
</log>
</config>
Давайте разберем по шагам, как этот фрагмент будет прочитан платформой 1С. Каждый отдельный тег <event> представляет собой независимое условие выборки. Между разными блоками <event> действует правило логического ИЛИ (OR). В то же время условия внутри одного конкретного тега <event> объединяются по принципу логического И (AND).
В приведенном выше ошибочном коде платформа прочитает настройки так: «Записывать в лог абсолютно любые события обращения к СУБД Microsoft SQL Server (DBMSSQL) по ВСЕМ базам данных ИЛИ записывать вообще все события (включая запуски сеансов, транзакции, ошибки), где имя серверного процесса совпадает с erp_prod». В итоге каталог логов моментально забьется лишней информацией.
Чтобы фильтрация работала корректно, условия по типу события и имени базы должны находиться строго внутри одного тега <event>. Посмотрим на правильный пример структуры:
<event>
<eq property="name" value="DBMSSQL"/>
<eq property="p:processName" value="erp_prod"/>
</event>
При такой записи система зафиксирует событие в логе только тогда, когда совпадут оба условия одновременно: событие относится к запросам к СУБД И выполняется в контексте базы erp_prod.
В процессе поиска решения на форумах часто можно встретить совет использовать свойства ref (имя информационной базы в кластере) или ib (строка соединения). Проанализируем эту ситуацию и выясним, почему этот совет является вредным для большинства задач мониторинга.
Дело в том, что свойства ref и ib присутствуют только в очень ограниченном наборе высокоуровневых событий ТЖ. К ним относятся, например, события установки соединения CONN или административные действия в кластере CLSTR.
В низкоуровневых и наиболее критичных для производительности событиях, таких как DBMSSQL, DBPOSTGRS (запросы к СУБД), SDBL (запросы на внутреннем языке СУБД 1С) или CALL (удаленные вызовы процедур), свойств ref или ib просто не существует в структуре метаданных события.
Если мы попытаемся настроить фильтрацию события DBMSSQL по свойству ref, платформа 1С применит это условие к событию, не найдет в нем такого свойства, посчитает результат сравнения ложным и вообще перестанет записывать события обращения к СУБД в технологический журнал.
Для надежного разделения логов по базам данных в клиент-серверном варианте работы (когда сеансы обслуживаются рабочими процессами сервера приложений rphost) необходимо использовать специальное системное свойство — p:processName. Данное свойство содержит имя информационной базы ровно в том виде, в котором оно зарегистрировано в консоли администрирования кластера серверов 1С.
При использовании этого свойства крайне важно соблюдать два правила:
p:processName (с заглавной буквой N). Если написать p:processname, парсер платформы проигнорирует фильтр, и логи будут записываться по всем базам без разбора.<eq> (равно) может не сработать из-за нюансов инициализации контекста серверного вызова. Более надежным решением является использование оператора <like> (подобие) с маской поиска.Рассмотрим пример готового, рабочего файла конфигурации logcfg.xml для сбора медленных запросов к СУБД PostgreSQL (длительностью более 5 секунд / 5000000 микросекунд) по конкретной рабочей базе данных с именем erp_prod:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8logs\erp_heavy_queries" history="48">
<event>
<eq property="name" value="DBPOSTGRS"/>
<like property="p:processName" value="%erp_prod%"/>
<gt property="duration" value="5000000"/>
</event>
<event>
<eq property="name" value="SDBL"/>
<like property="p:processName" value="%erp_prod%"/>
<gt property="duration" value="5000000"/>
</event>
<property name="all"/>
</log>
</config>
Отдельно рассмотрим проблему, о которой упоминал автор темы: «подхватывает логи всех баз, будь то серверная структура или же файловая».
В файловом режиме работы физически отсутствует сервер приложений 1С (процессы rphost и rmngr не запускаются). Все вычисления и запросы к базе выполняются непосредственно в процессе клиентского приложения (1cv8.exe, 1cv8c.exe или тонкого клиента) на локальном компьютере пользователя.
Это накладывает жесткие ограничения на фильтрацию ТЖ:
p:processName в файловом режиме всегда остается пустым, так как нет серверного процесса, который мог бы его заполнить.DBV8DBENG. У этого события нет свойств, содержащих путь к файлу базы или её имя.Как же решить задачу изоляции логов конкретной базы в файловом варианте, если на компьютере одновременно запускается несколько разных файловых баз? Разберем два надежных способа обхода этого ограничения.
Если конкретную базу запускает определенный пользователь операционной системы (или выделенная сервисная учетная запись), мы можем разместить конфигурационный файл ТЖ не в общем каталоге установки платформы (например, C:\Program Files\1cv8\conf), а в персональной папке настроек пользователя.
Для ОС Windows этот путь выглядит следующим образом: %APPDATA%\1C\1cv8\conf\ (или развернутый путь C:\Users\<ИмяПользователя>\AppData\Roaming\1C\1cv8\conf\).
Создадим папку conf по указанному пути и поместим туда наш файл logcfg.xml. В этом случае технологический журнал будет активироваться и собирать логи только тогда, когда запуск любых баз производится под данной учетной записью операционной системы.
Наиболее гибкий и профессиональный метод адресации технологического журнала для файловых баз — использование ключа запуска 1С. Мы можем явно указать платформе, из какого каталога ей следует считывать конфигурационные файлы (включая logcfg.xml) для данного конкретного сеанса работы.
Разберем этот способ по шагам:
C:\1C_configs\target_db\.logcfg.xml со стандартными настройками сбора нужных событий (без использования фильтра p:processName, так как мы изолируем весь сеанс целиком)./ConfLocation:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /F "C:\1C_Bases\TargetBase" /ConfLocation "C:\1C_configs\target_db"
При таком запуске платформа обратится к индивидуальной папке конфигурации. Технологический журнал будет записывать события только для этого запущенного экземпляра программы, полностью игнорируя работу пользователя в любых других файловых базах данных на этом компьютере.
Если вы выполнили все инструкции, но файлы логов в целевом каталоге так и не появились, рекомендуем последовательно проверить следующие важные технические параметры:
logcfg.xml должен быть сохранен строго в кодировке UTF-8. Обратите внимание, что текстовый редактор (например, Блокнот Windows) может сохранить его в кодировке UTF-8 с пометкой BOM (Byte Order Mark) или в ANSI. Платформа 1С не сможет корректно прочесть такой файл. Используйте продвинутые редакторы (Notepad++, VS Code) и выбирайте кодировку «UTF-8 без BOM».USR1CV8), должен обладать полными правами (чтение, запись, изменение) на каталог, указанный в атрибуте location вашего файла конфигурации. Если у службы нет прав на создание папок и файлов по этому пути, ТЖ работать не будет без вывода каких-либо предупреждений.conf.cfg, расположенном в папке bin\conf конкретной версии платформы. Если там задан параметр ConfLocation, платформа будет искать файл logcfg.xml именно по указанному в нем пути, а не в локальной папке установки.logcfg.xml автоматически в фоновом режиме. Периодичность проверки составляет 60 секунд. Вам не требуется перезапускать службу сервера 1С или клиентское приложение после редактирования конфигурации — достаточно подождать одну минуту, и новые фильтры вступят в силу автоматически.