Технологический журнал 1С: где находится и как настроить

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

Ключевой момент: технологический журнал по умолчанию выключен. Платформа начинает писать логи только тогда, когда обнаруживает файл настройки logcfg.xml в каталоге конфигурации технологического журнала. Если этого файла нет — никаких логов нет, и искать их бессмысленно. Поэтому сначала нужно проверить, включён ли журнал, и только потом искать каталог с файлами.

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

Как платформа определяет, куда писать технологический журнал

Платформа 1С при запуске каждого процесса (rphost, rmngr, ragent, толстый и тонкий клиент) проверяет наличие файла logcfg.xml. Он должен лежать в каталоге conf внутри каталога установки платформы. На Windows это обычно путь вида C:\Program Files\1cv8\<версия>\bin\conf\logcfg.xml, на Linux — /opt/1cv8/x86_64/<версия>/conf/logcfg.xml.

Внутри logcfg.xml элемент <log> содержит атрибут location — это и есть каталог, где будут создаваться файлы технологического журнала. Если атрибут не задан, платформа использует каталог по умолчанию: на Windows это подкаталог в профиле пользователя, под которым запущен процесс (например, C:\Users\<пользователь>\AppData\Local\1C\1cv8\logs), на Linux — домашний каталог служебного пользователя (например, ~/.1cv8/1C/1cv8/logs).

Важно понимать, что для сервера 1С процессы работают под служебной учётной записью (например, USR1CV8), а не под вашей. Поэтому логи, записанные «по умолчанию», будут лежать в профиле этой учётной записи, и искать их в своём профиле бесполезно. Именно поэтому рекомендуется всегда явно задавать location в logcfg.xml.

Где искать каталог с логами на практике

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

Типичные места, где стоит проверить наличие логов:

• каталог, указанный в атрибуте location файла logcfg.xml — основной вариант;
• C:\Program Files\1cv8\<версия>\bin\conf\ — здесь проверьте сам факт наличия logcfg.xml;
• профиль служебной учётной записи сервера 1С: C:\Users\USR1CV8\AppData\Local\1C\1cv8\logs (путь может отличаться в зависимости от версии платформы);
• на Linux: /opt/1cv8/x86_64/<версия>/conf/ для конфигурации и домашний каталог пользователя, под которым работает srv1cv8, для логов по умолчанию.

Если logcfg.xml задан, но логов в указанном каталоге нет — почти всегда дело в правах доступа. Учётная запись процесса должна иметь право записи в каталог логов. Проверьте это в первую очередь, прежде чем менять конфигурацию.

1. 1
   Откройте каталог conf внутри каталога установки платформы на нужном компьютере
2. 2
   Проверьте наличие файла logcfg.xml — если его нет, журнал выключен
3. 3
   Откройте logcfg.xml и найдите атрибут location в элементе log
4. 4
   Перейдите в указанный каталог и проверьте наличие подкаталогов с именами процессов (rphost, rmngr и др.)
5. 5
   Если location не задан — проверьте профиль служебной учётной записи процесса

Как включить технологический журнал и задать свой каталог

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

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

Параметр history задаёт время хранения логов в часах. Без него платформа будет хранить файлы ограниченное время по умолчанию, а при длительной записи «всего подряд» диск быстро переполнится. Для постоянного сбора на боевом сервере включайте только нужные события — например, ошибки (EXCP) и длительные запросы (DBMSSQL, DBPOSTGRS с фильтром по длительности).

После создания или изменения logcfg.xml перезапуск сервера не требуется: платформа перечитывает конфигурацию автоматически в течение короткого времени. Проверить результат просто — в указанном каталоге должны появиться подкаталоги с именами процессов и файлами вида <дата>_<время>.log.

Структура каталога и файлов журнала

Внутри каталога, заданного в location, платформа создаёт подкаталоги по именам процессов: rphost (рабочие процессы сервера), rmngr (менеджер кластера), ragent (агент сервера), 1cv8 (клиентские приложения). В каждом подкаталоге лежат файлы с расширением .log, имя которых содержит дату и время начала записи.

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

Каждая строка файла — это событие с меткой времени, длительностью (в микросекундах), именем события и набором свойств. Например, событие DBMSSQL содержит текст запроса к MS SQL Server, а EXCP — описание исключения. Для разбора больших логов удобно использовать специализированные инструменты чтения технологического журнала, так как вручную анализировать многочасовые файлы трудоёмко.

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

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

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

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

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

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

Частые вопросы о технологическом журнале 1С