Администрирование · 11 мин
Технологический журнал 1С: как читать и анализировать события
Как включить технологический журнал 1С, настроить logcfg.xml, читать события EXCP, DBMSSQL, CALL и находить причины ошибок и медленной работы.
Технологический журнал (ТЖ) — это текстовый лог, в который платформа 1С:Предприятие записывает внутренние события: вызовы сервера, запросы к СУБД, исключения, взаимоблокировки, утечки памяти. В отличие от журнала регистрации, который показывает действия пользователей на уровне прикладных объектов, ТЖ фиксирует работу самой платформы и является основным инструментом диагностики ошибок и производительности.
По умолчанию технологический журнал выключен или пишет только аварийные события. Чтобы получить полезные данные, его нужно включить через конфигурационный файл logcfg.xml, указав, какие события собирать и куда складывать логи. Дальше остаётся самое сложное — прочитать записи и связать их с реальной проблемой: зависанием, ошибкой СУБД или падением рабочего процесса.
Что записывает технологический журнал и чем он отличается от журнала регистрации
Журнал регистрации отвечает на вопрос «кто и что сделал в базе»: провёл документ, изменил справочник, вошёл в систему. Технологический журнал отвечает на вопрос «что происходило внутри платформы»: какой SQL-запрос выполнялся, сколько длился вызов, какое исключение выбросил сервер, какие блокировки возникли.
Типовые ситуации, когда без ТЖ не обойтись: пользователь получает «Ошибка СУБД» без деталей, рабочий процесс rphost падает, отчёт выполняется десять минут вместо десяти секунд, возникают взаимоблокировки. Во всех этих случаях журнал регистрации либо пуст, либо показывает только факт ошибки без причины.
Как включить технологический журнал через logcfg.xml
Настройка выполняется файлом logcfg.xml, который нужно разместить в каталоге conf установки платформы. Для сервера 1С это обычно каталог вида C:\Program Files\1cv8\<версия>\bin\conf, а для Linux — /opt/1cv8/<версия>/conf. Для диагностики на стороне клиента файл кладётся в conf каталога клиентской установки.
Минимальная конфигурация для сбора ошибок и долгих запросов выглядит так:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="D:\1clogs" history="24">
<event><eq property="name" value="EXCP"/></event>
<event><eq property="name" value="DBMSSQL"/></event>
<event><eq property="name" value="CALL"/></event>
<property name="all"/>
</log>
</config>Параметр history задаёт, сколько часов хранить логи; location — каталог сбора. Внутри событий можно добавлять фильтры: например, собирать DBMSSQL только при длительности больше заданного порога через условие на свойство duration. После создания файла конфигурация подхватывается платформой автоматически, перезапуск сервера обычно не требуется — агент перечитывает logcfg.xml периодически.
Структура каталогов и формат файлов журнала
В указанном каталоге платформа создаёт вложенные папки по имени процесса: rphost, ragent, rmngr, 1cv8c (толстый клиент) и так далее. Внутри каждой папки лежат файлы вида ГГММДДЧЧ.log — каждый файл покрывает один час работы конкретного процесса.
Каждая строка файла имеет формат: минуты:секунды.микросекунды-длительность,ИмяСобытия,уровень,свойства. Длительность указывается в микросекундах, что важно при анализе: число 5000000 — это пять секунд, а не миллисекунд. Свойства записываются парами «имя=значение» через запятую, многострочные значения (например, тексты запросов) заключаются в кавычки.
Для событий, у которых есть начало и конец (запросы, вызовы), в логе встречаются пары записей: событие с длительностью 0 открывает операцию, второе событие с реальной длительностью её закрывает. При чтении вручную ориентируйтесь на завершающие записи.
Ключевые события и как их интерпретировать
Чтобы читать ТЖ, достаточно уверенно знать несколько групп событий. Ниже — те, что покрывают большинство диагностических задач.
| Событие | Что фиксирует | Когда смотреть |
|---|---|---|
| EXCP | Исключения платформы с текстом и контекстом | Любые ошибки у пользователей, падения операций |
| DBMSSQL / DBPOSTGRS / DBORACLE | Запросы к СУБД с текстом и длительностью | Медленная работа, ошибки СУБД |
| CALL | Вызовы между клиентом и сервером | Диагностика сетевых задержек, «подвисаний» клиента |
| TLOCK, TTIMEOUT, TDEADLOCK | Управляемые блокировки, таймауты, взаимоблокировки | Конфликты блокировок, ошибки «Конфликт блокировки при выполнении транзакции» |
| PROC, MEM | Состояние процессов и памяти | Рост потребления памяти rphost |
| CLSTR, CONN | События кластера и соединений | Проблемы с подключениями, разрывы сеансов |
При анализе ошибки начинайте с EXCP: найдите запись по времени, совпадающему с моментом ошибки у пользователя (свойства Usr и SessionID помогут привязаться к конкретному сеансу). Текст исключения обычно содержит исходную причину — например, сообщение СУБД о дедлоке или нарушении ограничения целостности.
При анализе производительности смотрите DBMSSQL (или событие вашей СУБД) с большой длительностью. В записи есть полный текст запроса и плановые свойства; по свойству Context видно, какой код конфигурации породил запрос. Дальше запрос можно воспроизвести в консоли СУБД и проверить план выполнения.
Значение в микросекундах; всё, что измеряется секундами, — кандидат на оптимизацию
Показывает модуль и строку, откуда инициирован запрос или вызов
Позволяют сопоставить запись ТЖ с жалобой конкретного пользователя
Содержит данные о жертве и участниках — основа для переработки кода
Практический сценарий: находим причину ошибки «Ошибка СУБД»
Типовая задача: пользователь сообщает, что при проведении документа в 14:32 получил «Ошибка СУБД». Порядок чтения журнала в этом случае следующий.
- 1Включите ТЖ с событиями EXCP, DBMSSQL и TDEADLOCK, если он ещё не включён
- 2Откройте папку rphost и файл часа, в который произошла ошибка (14:00–15:00)
- 3Найдите поиском по файлу записи EXCP около метки времени 14:32
- 4Проверьте свойства Usr и SessionID, чтобы убедиться, что это сеанс нужного пользователя
- 5Прочитайте текст исключения и ближайшие записи DBMSSQL выше по времени
- 6Скопируйте текст запроса и воспроизведите проблему в консоли СУБД или передайте администратору БД
- 7Зафиксируйте вывод: причина в запросе, блокировке или ограничении данных — и планируйте исправление
Если в EXCP виден текст про deadlock, ищите рядом событие TDEADLOCK — оно покажет, какие сеансы участвовали во взаимоблокировке и какие ресурсы делили. Это уже повод анализировать порядок обращения к таблицам в коде, а не перезапускать сервер.
Если исключение говорит о таймауте, смотрите TLOCK и длительные DBMSSQL в тот же период: таймаут почти всегда означает, что сеанс ждал блокировку, которую держал другой длительный запрос.
Читать ТЖ вручную удобнее не в «Блокноте», а в редакторе с подсветкой и поиском по нескольким файлам (Notepad++, VS Code) или через специализированные инструменты разбора ТЖ. Поиск по имени пользователя и SessionID сокращает время анализа в разы — не листайте лог целиком.
Анализ производительности: как найти медленные места
Для задач производительности настраивают ТЖ с порогом длительности: собираются только события DBMSSQL и CALL длиннее, например, одной секунды. Это резко сокращает объём логов и сразу показывает «тяжёлые» операции.
После сбора логов за период жалоб отсортируйте записи по длительности. Частая картина: один и тот же запрос из свойства Context повторяется сотни раз — это признак запроса в цикле. Либо запрос выполняется один раз, но минутами — тогда нужен анализ плана запроса, индексов и статистики на стороне СУБД.
События CALL с большой длительностью при коротких DBMSSQL указывают, что время тратится не в базе, а в коде на сервере или на передаче данных клиенту. В таком случае ТЖ комбинируют с замером производительности в конфигураторе.
Как проверить результат диагностики
В EXCP найдено исключение с конкретным текстом и контекстом, привязанное к сеансу пользователя
В логе за нужный час нет записей — ТЖ не включён или пишет не те события
Есть запись DBMSSQL с большой длительностью, текстом запроса и Context
Лог переполнен миллисекундными запросами — не задан фильтр по длительности
Каталог растёт предсказуемо, старые файлы удаляются по history
Диск заполняется — слишком широкий набор событий без фильтров
Типичные ошибки при работе с технологическим журналом
Отдельная ошибка — забыть выключить или сузить сбор после завершения диагностики. ТЖ — инструмент расследования, а не постоянный мониторинг: для регулярного наблюдения за производительностью используют счётчики СУБД, СУБД-мониторинг и специализированные решения, а ТЖ включают точечно.
Что важно запомнить
Технологический журнал включается через logcfg.xml, читается по событиям EXCP, DBMSSQL, CALL, TLOCK и TDEADLOCK, а привязка к проблеме делается по времени, пользователю и SessionID. Собирайте только нужные события с фильтрами по длительности, храните логи на отдельном диске и отключайте сбор после диагностики.
Частые вопросы о технологическом журнале 1С
Нужно ли перезапускать сервер 1С после создания logcfg.xml?
Как правило, нет: агент сервера периодически перечитывает конфигурацию, и сбор начинается автоматически. Если логи не появились через несколько минут, проверьте путь к каталогу conf, права на запись в каталог логов и корректность XML — ошибка в файле молча отключает сбор.
Где искать ТЖ, если проблема на стороне клиента, а не сервера?
Файл logcfg.xml нужно положить в каталог conf клиентской установки платформы — тогда логи будут писаться процессом 1cv8 или 1cv8c на машине пользователя. Это полезно при диагностике сетевых задержек и ошибок толстого или тонкого клиента.
Чем технологический журнал отличается от замера производительности в конфигураторе?
Замер производительности показывает время по строкам встроенного кода и работает в отладочном режиме. ТЖ фиксирует события платформы и СУБД без остановки работы пользователей. На практике их комбинируют: ТЖ находит проблемный запрос и контекст, замер — конкретную строку кода.
Как понять, что взаимоблокировка — это проблема кода, а не СУБД?
Событие TDEADLOCK показывает участников взаимоблокировки и ресурсы. Если одни и те же объекты и таблицы повторяются в разных эпизодах, причина в порядке обращения к данным в прикладном коде — его и нужно менять. Разовые дедлоки под пиковой нагрузкой чаще связаны с нехваткой индексов и длинными транзакциями.
Можно ли читать ТЖ автоматически, а не вручную?
Да, формат лога текстовый и стабильный, поэтому существуют разборщики, которые складывают события в базу и строят отчёты по длительным запросам и ошибкам. Для разовой диагностики достаточно редактора с поиском, для постоянного контроля удобнее автоматический разбор.
Почему в логе нет событий за нужный период, хотя ТЖ включён?
Чаще всего события отфильтрованы условиями logcfg.xml — например, задан порог длительности, которому операция не соответствует. Также проверьте, что пишется тот процесс: серверные события ищите в папках rphost, а не в клиентских логах, и сверяйте часовой пояс времени сервера с временем, которое называет пользователь.