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

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

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

Ниже — полный порядок действий: где искать каталоги платформы, как составить logcfg.xml под конкретную задачу, как проверить, что логирование заработало, и как не уронить производительность чрезмерным сбором событий.

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

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

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

Где разместить файл logcfg.xml

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

Если каталога conf нет — создайте его вручную. Учётная запись, под которой работает служба агента сервера 1С (по умолчанию USR1CV8), должна иметь право чтения файла и право записи в каталог логов. Это частая причина «молчания» техжурнала: файл создан, а служба не может его прочитать или не может создать файлы логов.

Для диагностики на стороне клиента (например, ошибки толстого клиента) logcfg.xml кладётся в каталог conf клиентской платформы, а логи будут писаться процессом клиента. На сервере и клиенте настройки независимы — включение на одной стороне не включает другую.

Минимальная настройка: включаем техжурнал за пять минут

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

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

Здесь location — каталог, куда будут складываться логи (создайте его заранее и дайте права на запись), history — время хранения в часах, после которого старые файлы удаляются автоматически. Внутри блока log перечислены события: в примере пишутся все исключения и все запросы к MS SQL Server.

Перезапускать службу сервера не нужно: платформа проверяет наличие и изменение logcfg.xml примерно раз в минуту. Если через минуту-две в каталоге логов появились подкаталоги с именами процессов (rphost, ragent, 1cv8) и файлами .log — техжурнал работает.

1. 1
   Создайте каталог для логов и дайте учётной записи службы 1С права на запись в него
2. 2
   Создайте файл logcfg.xml с нужными событиями и каталогом логов
3. 3
   Разместите файл в каталоге conf нужной версии платформы
4. 4
   Подождите 1–2 минуты и проверьте появление файлов .log в каталоге
5. 5
   После сбора данных удалите или переименуйте logcfg.xml, чтобы отключить запись

Настройка событий и фильтров под задачу

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

Основные события, которые чаще всего используются на практике:

• EXCP — исключения и ошибки платформы;
• DBMSSQL, DBPOSTGRS, DBORACLE, DBV8DBENG — запросы к соответствующей СУБД;
• DEADLOCK, TDEADLOCK — взаимоблокировки;
• TTIMEOUT, TLOCK — таймауты и управляемые блокировки;
• CALL, SCOM — вызовы сервера и контекстные операции;
• CONN, PROC, SESN — соединения, процессы и сеансы;
• CLSTR — события кластера серверов.

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

<event>
<eq property="name" value="DBMSSQL"/>
<gt property="duration" value="5000000"/>
</event>

Можно фильтровать по имени базы (p:processName), пользователю (Usr) и другим свойствам. Несколько условий внутри одного события объединяются логическим «И».

Для расследования взаимоблокировок включайте пару событий TLOCK и DEADLOCK вместе с DBMSSQL: по одному событию взаимоблокировки видно только факт конфликта, а по записям запросов — какие именно операции к нему привели.

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

Первый признак успеха — в каталоге логов появились папки с именами процессов (rphost_*, ragent_*, rmngr_* для сервера или 1cv8_* для клиента), а внутри — файлы вида YYMMDDHH.log. Откройте свежий файл: записи имеют формат «минуты:секунды.микросекунды-длительность,ИмяСобытия,свойства».

Если файлов нет, проверяйте по списку: файл называется именно logcfg.xml (не logcfg.xml.txt — включите показ расширений в проводнике); файл лежит в conf той версии платформы, которая реально запущена; XML валиден (откройте файл в браузере — он покажет синтаксическую ошибку); у службы есть права на чтение файла и запись в каталог логов.

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

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

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

Норма

Появились папки rphost_*, ragent_* с файлами .log

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

Каталог пуст спустя 2–3 минуты после размещения logcfg.xml

Содержимое .log

Норма

Строки с событиями EXCP, DBMSSQL и т.п. с текущим временем

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

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

Синтаксис logcfg.xml

Норма

Файл открывается в браузере без ошибок разбора XML

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

Браузер сообщает об ошибке в структуре документа

Риски, ограничения и типичные ошибки

Главный риск техжурнала — переполнение диска. Полный сбор событий на активной базе генерирует огромные объёмы, и если диск заполнится, пострадает не только логирование, но и работа сервера 1С или СУБД. Всегда задавайте параметр history, размещайте логи на отдельном диске и не оставляйте широкий сбор включённым надолго.

Второй риск — снижение производительности. Запись каждого запроса к СУБД с детальными свойствами добавляет накладные расходы. На пиковой нагрузке это заметно. Поэтому для постоянного мониторинга используют узкие фильтры по длительности, а полный сбор включают только на время расследования.

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

Отключение выполняется просто: удалите или переименуйте logcfg.xml. Платформа прекратит запись в течение минуты, уже собранные файлы останутся в каталоге логов и будут удаляться по мере истечения срока history либо вручную.

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

Часто задаваемые вопросы

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

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

Почему техжурнал включён, но файлы логов не появляются?

Чаще всего причины такие: файл назван с двойным расширением .xml.txt, лежит не в том каталоге conf, содержит ошибку синтаксиса XML, либо у учётной записи службы сервера нет прав на запись в каталог логов. Проверяйте эти пункты последовательно.

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

Да, с помощью фильтра по свойству p:processName в условиях событий. Укажите имя базы, и в лог будут попадать только события, относящиеся к ней. Это существенно снижает объём записей на многобазовых серверах.

Сильно ли техжурнал замедляет работу 1С?

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

Чем открывать и анализировать файлы техжурнала?

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

Как собрать логи с клиентского компьютера, а не с сервера?

Разместите logcfg.xml в каталоге conf платформы на клиентском компьютере — той же разрядности, что и запускаемый клиент. Логи будет писать процесс клиентского приложения. Это полезно при ошибках, которые не доходят до сервера.