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

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

ТЖ незаменим при диагностике аварийных завершений, расследовании медленной работы, анализе взаимоблокировок MS SQL Server и поиске причин ошибок, которые не попадают в журнал регистрации. При этом журнал пишется постоянно и может генерировать значительные объёмы данных, поэтому важно не только включить его, но и правильно ограничить состав событий и срок хранения.

Материал ниже описывает полный цикл: создание конфигурационного файла, выбор событий, размещение файла для серверного и файлового вариантов, проверку работоспособности и типичные ошибки, из-за которых журнал «не пишется».

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

Технологический журнал — это текстовые логи, которые пишут процессы платформы 1С (rphost, ragent, rmngr, тонкий и толстый клиенты). Каждый процесс создаёт собственный файл, в котором события фиксируются с точным временем, длительностью и контекстом: имя информационной базы, пользователь, номер соединения, текст запроса к СУБД.

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

Включать ТЖ на постоянной основе в полном объёме не рекомендуется: детальный лог всех событий способен генерировать десятки гигабайт в сутки на нагруженном сервере и влиять на производительность дисковой подсистемы. Разумная практика — включать журнал на время расследования конкретной проблемы либо держать постоянно включённым минимальный набор событий (ошибки и аварийные завершения).

Подготовка: куда платформа ищет конфигурационный файл

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

Альтернативный способ — переменная окружения LOGCFG_LOCATION. Если она задана, платформа берёт конфигурационный файл из указанного в ней каталога, игнорируя стандартный путь. Это удобно, когда нужно централизованно управлять настройками ТЖ на нескольких серверах или когда нет прав на запись в Program Files.

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

Создание logcfg.xml: минимальная рабочая конфигурация

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

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

Разберём элементы. Атрибут location задаёт каталог, куда будут складываться логи — он должен существовать и быть доступен на запись учётной записи, под которой работают процессы платформы (для сервера 1С это обычно учётная запись службы агента). Атрибут history — срок хранения логов в часах, по истечении которого старые файлы удаляются автоматически.

Условие <eq property="name" value=""/> с пустым значением означает «все события». Элемент <property name="all"/> включает запись всех свойств событий. Такая конфигурация годится для кратковременной диагностики, но для постоянной работы её следует сузить.

1. 1
   Создайте каталог для логов, например C:\1clogs, и дайте на него полные права учётной записи службы агента сервера 1С
2. 2
   Откройте блокнот от имени администратора и создайте файл logcfg.xml с нужной конфигурацией
3. 3
   Сохраните файл в каталог conf используемой версии платформы (например, C:\Program Files\1cv8\8.3.хх.хххх\bin\conf\)
4. 4
   Подождите до двух минут — платформа перечитывает конфигурацию автоматически, перезапуск служб не обязателен
5. 5
   Проверьте, что в каталоге логов появились подкаталоги с именами процессов (rphost, ragent) и файлы логов

Настройка событий под конкретную задачу

Записывать всё подряд имеет смысл только при кратковременном расследовании. Для конкретных задач выбирайте целевой набор событий — это снижает нагрузку и упрощает последующий разбор логов.

Диагностика ошибок и аварийных завершений

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

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

Анализ медленных запросов и взаимоблокировок

Для расследования «тормозов» на сервере СУБД полезны события DBMSSQL (запросы к MS SQL Server), DBPOSTGRS (PostgreSQL), TLOCK, TDEADLOCK и TTIMEOUT (управляемые блокировки, взаимоблокировки и таймауты). Чтобы не фиксировать каждый быстрый запрос, добавьте фильтр по длительности — например, событие с условием на длительность более 10 секунд (длительность указывается в микросекундах).

Расследование аварийного падения рабочего процесса

Если rphost падает, включите полный лог с дампами. За создание аварийного дампа отвечает элемент dump с атрибутами location и type. Дампы занимают много места, поэтому каталог для них размещайте на диске с достаточным запасом свободного пространства.

Какой набор событий выбрать

Все события (eq name="")

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

EXCP + EXCPCNTX

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

DBMSSQL/DBPOSTGRS + TLOCK + TDEADLOCK

Расследование производительности и блокировок. Включайте на период воспроизведения проблемы, затем отключайте.

Полный лог + dump

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

Особенности для клиент-серверного и файлового вариантов

В клиент-серверном режиме основная часть событий происходит на сервере 1С, поэтому logcfg.xml размещается на сервере в каталоге conf рабочей версии платформы. Если проблема связана с клиентским приложением (например, ошибки веб-клиента или тонкого клиента), конфигурационный файл нужно положить и на клиентский компьютер — в conf той версии платформы, под которой запускается клиент.

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

На Linux-сервере не забудьте про права: каталог логов должен принадлежать пользователю, под которым работает агент сервера (обычно usr1cv8), либо иметь соответствующие разрешения. Также учитывайте регистр символов в путях — в Linux /opt/1CLogs и /opt/1clogs — разные каталоги.

Проверка результата и ротация логов

Признак того, что ТЖ включился: в каталоге, указанном в location, появляются подкаталоги с именами процессов (rphost_*, ragent_*, 1cv8_*), а внутри — файлы вида ГГММДДЧЧ.log. Файл создаётся на каждый час работы процесса. Если через 2–3 минуты после сохранения logcfg.xml каталог пуст — конфигурация не подхватилась, и нужно искать ошибку.

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

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

Контрольные точки

Как проверить результат

Каталог логов

Норма

Появились подкаталоги rphost_*, ragent_* и файлы .log с текущей датой

Тревожный признак

Каталог пуст через 3–5 минут после создания logcfg.xml

Содержимое логов

Норма

В файлах есть строки событий с указанием времени и длительности

Тревожный признак

Файлы создаются, но пустые — не совпадает набор событий с реальной активностью

Свободное место на диске

Норма

Прирост логов умеренный, удаление старых файлов работает по history

Тревожный признак

Объём растёт быстро, старые файлы не удаляются

Влияние на работу

Норма

Пользователи не замечают изменений

Тревожный признак

Появились жалобы на замедление — сузьте набор событий

Типичные ошибки и ограничения

Самая распространённая причина молчащего журнала — ошибка в XML: незакрытый тег, неверный namespace или опечатка в имени события. Платформа при этом не выдаёт никаких сообщений — она просто игнорирует некорректный файл. Проверяйте файл в любом XML-валидаторе или хотя бы открывайте в браузере: он покажет синтаксическую ошибку.

Вторая частая проблема — права доступа. Служба агента сервера 1С работает под отдельной учётной записью, и если у неё нет прав на запись в каталог логов, файлы не появятся. Аналогично на стороне чтения: сохранение logcfg.xml в Program Files без прав администратора может молча завершиться неудачей.

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

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

Чтобы полностью отключить ТЖ, удалите или переименуйте файл logcfg.xml — платформа прекратит запись при очередном перечитывании конфигурации. Более мягкий вариант — оставить файл, но убрать из него все элементы <log> либо закомментировать их.

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

Частые вопросы

Нужно ли перезапускать сервер 1С после создания logcfg.xml?

Нет. Платформа периодически перечитывает конфигурационный файл, обычно в течение одной-двух минут. Перезапуск службы агента требуется только в редких случаях — например, если менялась переменная окружения LOGCFG_LOCATION, поскольку переменные окружения процесс читает только при старте.

Технологический журнал включён, но каталог пуст. С чего начать проверку?

Проверьте три вещи по порядку: валидность XML (откройте файл в браузере), расположение файла (каталог conf именно той версии платформы, что запущена) и права учётной записи службы на запись в каталог логов. Эти три причины покрывают подавляющее большинство случаев «молчания» журнала.

Можно ли включить ТЖ только для одной информационной базы?

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

Влияет ли технологический журнал на производительность?

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

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

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

Где искать логи, если сервер 1С работает на Linux?

Каталог логов определяется атрибутом location в logcfg.xml — вы задаёте его сами, например /var/log/1c. Сам файл logcfg.xml размещается в каталоге conf установленной платформы, обычно /opt/1cv8/x86_64/<версия>/conf/. Убедитесь, что пользователь, под которым работает агент сервера (по умолчанию usr1cv8), имеет право записи в каталог логов.