Настройка технологического журнала (ТЖ) — это критически важная задача для администратора или разработчика 1С, особенно когда необходимо локализовать причины аварийного завершения процессов rphost.exe или проанализировать утечки памяти. Однако часто возникает ситуация, когда файл logcfg.xml создан, пути прописаны, права даны, но папки с логами остаются пустыми. В этой статье мы подробно разберем, почему ТЖ может не отрабатывать на современных платформах (включая 8.3.24) и как пошагово диагностировать эту проблему.
Прежде чем приступать к глубокому анализу, нам необходимо убедиться в соблюдении базовых правил именования. Часто ошибка кроется в простой опечатке. Файл конфигурации технологического журнала должен называться строго logcfg.xml. Любые вариации, такие как log.xml или logs.xml, будут проигнорированы платформой.
Рассмотрим, где именно платформа ищет этот файл. В современных версиях 1С:Предприятия существует несколько уровней расположения конфигурационных файлов:
C:\Program Files\1cv8\conf (для 64-битной версии) или C:\Program Files (x86)\1cv8\conf (для 32-битной).C:\Program Files\1cv8\8.3.XX.XXXX\bin\conf.Важно понимать приоритетность. Если файл logcfg.xml присутствует в каталоге конкретной версии, платформа может использовать именно его. Проанализируем типичную ошибку: если при обновлении платформы вы положили файл в папку версии, то после перехода на новый релиз журнал перестанет работать, так как новая версия будет искать его в своей папке bin\conf или общем каталоге. Поэтому рекомендуется размещать файл только в общем каталоге \1cv8\conf.
Платформа 1С крайне чувствительна к формату XML-файла. Одной из самых коварных проблем является наличие маркера последовательности байтов (BOM) в начале файла. Если вы создавали logcfg.xml с помощью стандартного блокнота Windows (Notepad) или некоторых других текстовых редакторов, они могли добавить невидимые символы BOM при сохранении в UTF-8.
Разберем, как это влияет на работу: парсер 1С считывает файл, натыкается на непонятные символы в самом начале и признает весь XML невалидным. В результате технологический журнал просто не инициализируется без вывода каких-либо ошибок пользователю. Для исправления ситуации необходимо пересохранить файл в кодировке UTF-8 без BOM (UTF-8 without BOM). Это можно сделать в таких редакторах, как Notepad++, VS Code или Sublime Text.
Если синтаксис XML нарушен, ТЖ также не запустится. Рассмотрим пример минимально необходимой конфигурации, которая должна собирать все события. Попробуем использовать этот шаблон для проверки работоспособности системы:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\Logs\1C" history="24">
<event>
<ne property="Name" value=""/>
</event>
<property name="all"/>
</log>
</config>
В данном примере мы указываем платформе собирать абсолютно все события (условие "имя не равно пустой строке"), предварительно убрав лишние переносы строк. Обратите внимание на закрывающие теги и правильность написания атрибутов location и history. Если после применения такого конфига логи не появились, значит, проблема не в фильтрах событий, а в правах доступа или расположении файлов.
Начиная с версий платформы 8.3.21 и выше, 1С усилила требования к безопасности и взаимодействию с файловой системой. Процессы rphost.exe, rmngr.exe и ragent.exe обычно работают под учетной записью USR1CV8. Нам необходимо убедиться, что у этого пользователя есть полные права (чтение, запись, изменение) на:
logcfg.xml.C:\PerfLogs\logs).Выясним важный нюанс: платформа 1С не умеет самостоятельно создавать глубокую иерархию папок, если у пользователя службы нет прав на создание папок в корне диска. Попробуйте вручную создать папку для логов и выдать на нее права "Полный доступ" для пользователя, от имени которого запущен сервер 1С. Также стоит проверить, не заблокирована ли запись в корень диска C:\ групповыми политиками безопасности или антивирусным ПО.
Если визуальный осмотр и проверка прав не помогают, перейдем к "тяжелой артиллерии" — инструменту Process Monitor от Microsoft. Это позволит нам точно увидеть, куда именно обращается 1С за файлом настроек и получает ли она отказ в доступе.
Рассмотрим алгоритм работы с ProcMon:
ProcMon.exe от имени администратора.Path contains logcfg.xml.SUCCESS — файл найден и прочитан. Если при этом логов нет — ищите ошибку в синтаксисе XML или кодировке.NAME NOT FOUND — платформа ищет файл совсем не там, где вы его положили. Посмотрите путь в колонке Path и переместите файл туда.ACCESS DENIED — у пользователя 1С нет прав на чтение файла.Также полезно настроить второй фильтр по пути к папке логов (например, Path contains C:\PerfLogs\logs), чтобы увидеть, пытается ли процесс rphost.exe вообще создать там файлы.
Автор исходного вопроса пытался отловить "аварийное завершение процесса фонового задания". Это классический случай падения процесса rphost.exe (что мешает удалению спящих сеансов). В версии 8.3.24, помимо обычных логов, крайне важно настроить сбор дампов. Если процесс падает слишком быстро ("крэшится"), он может просто не успеть записать информацию в текстовый лог ТЖ.
Проанализируем настройку секции dump в logcfg.xml:
<dump location="C:\Dumps" create="1" type="2" externaldump="1"/>
Если даже с этой настройкой дампы не создаются, мы можем использовать системный механизм Windows — Windows Error Reporting (WER). Для этого выполним следующие действия в реестре:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.rphost.exe.DumpFolder (тип REG_EXPAND_SZ) и укажем путь к папке.DumpType (тип REG_DWORD) со значением 2 (Full dump).Этот метод работает на уровне операционной системы и позволяет получить дамп процесса даже в тех случаях, когда механизмы самой 1С дают сбой.
Мы рассмотрели основные причины, по которым технологический журнал может "молчать". Подведем итог правильной последовательности действий:
logcfg.xml и лежит в C:\Program Files\1cv8\conf.USR1CV8 на папку с логами и папку с logcfg.xml.Соблюдение этих шагов гарантированно поможет вам запустить технологический журнал и приступить к анализу реальных причин нестабильной работы системы (в том числе через перенос логов в ClickHouse).