Администрирование · 12 мин
Технологический журнал 1С: что это такое и как с ним работать
Что такое технологический журнал 1С, для чего нужен, как включить и настроить logcfg.xml, какие события фиксировать и как анализировать логи без вреда для системы.
Технологический журнал 1С — это встроенный механизм платформы «1С:Предприятие», который фиксирует низкоуровневые события работы системы: обращения к СУБД, вызовы, ошибки, взаимоблокировки, длительные операции. В отличие от журнала регистрации, который пишет прикладные события (проведение документов, вход пользователей), технологический журнал показывает, что происходит «под капотом» — на уровне сервера 1С, клиентских приложений и запросов к базе данных.
Администраторы и разработчики используют ТЖ как основной инструмент диагностики: он помогает найти причину медленной работы, разобрать взаимоблокировку, понять, какой запрос к СУБД выполняется слишком долго, и установить, на каком этапе возникла ошибка. Без технологического журнала анализ производительности сводится к догадкам.
Важно понимать: по умолчанию технологический журнал отключён. Платформа начинает писать события только после того, как вы создадите конфигурационный файл logcfg.xml и поместите его в нужный каталог. Это сделано намеренно — полная запись событий создаёт заметную нагрузку на дисковую подсистему и может быстро заполнить диск.
Ниже разберём, как устроен журнал, как его включить и настроить, какие события собирать в типовых сценариях и как не навредить рабочей системе чрезмерным логированием.
Что фиксирует технологический журнал и чем он отличается от журнала регистрации
Технологический журнал состоит из текстовых файлов, которые платформа раскладывает по каталогам с именами процессов (rphost, ragent, rmngr, 1cv8c и другие). Каждый файл содержит записи в формате «время — длительность — событие — свойства». Записи накапливаются в течение часа, затем создаётся новый файл.
Журнал регистрации и технологический журнал решают разные задачи. Журнал регистрации отвечает на вопрос «кто и что сделал в прикладном решении»: какой пользователь провёл документ, изменил справочник, получил отказ в доступе. Технологический журнал отвечает на вопрос «как платформа это выполнила»: какой SQL-запрос был отправлен, сколько он выполнялся, какие соединения и транзакции при этом использовались, какая ошибка вернулась от СУБД.
На практике их используют вместе: по журналу регистрации находят момент и контекст проблемы (пользователь, документ, время), а по технологическому журналу за ту же секунду смотрят, что именно происходило на уровне запросов и вызовов.
Как включить технологический журнал через logcfg.xml
Включение ТЖ сводится к созданию файла logcfg.xml и размещению его в каталоге conf рядом с исполняемыми файлами платформы. Для сервера 1С это обычно подкаталог conf в каталоге установки (например, внутри каталога конкретной версии платформы). Для файлового варианта или диагностики на клиенте файл кладут в аналогичный каталог conf на клиентской машине.
Минимальный рабочий пример конфигурации выглядит так:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="D:\1c_logs" history="24">
<event><eq property="name" value="EXCP"/></event>
<property name="all"/>
</log>
</config>В этом примере включается запись только событий исключений (EXCP) в каталог D:\1c_logs, а параметр history="24" ограничивает хранение логов 24 часами — старые файлы платформа удалит сама. Указание history обязательно в продуктивной среде: без него логи будут копиться, пока не закончится место на диске.
После создания файла перезапускать сервер 1С обычно не требуется: процессы подхватывают конфигурацию при старте, а уже работающие процессы — при обращении к настройкам. Если логи не появились в течение нескольких минут, проверьте права на каталог: учётная запись, под которой работает агент сервера (по умолчанию это служебная учётная запись), должна иметь право записи в указанную папку.
- 1Создайте отдельный каталог для логов на диске с достаточным свободным местом
- 2Убедитесь, что учётная запись агента сервера 1С имеет полные права на этот каталог
- 3Создайте logcfg.xml с нужными событиями и параметром history
- 4Поместите файл в каталог conf платформы на сервере или клиенте
- 5Подождите несколько минут и проверьте появление подкаталогов с именами процессов
- 6После сбора данных отключите или сократите логирование, чтобы не держать лишнюю нагрузку
Какие события собирать под конкретную задачу
Главная ошибка при работе с ТЖ — включать «всё и сразу». Платформа генерирует огромный поток событий, и полный лог на нагруженной системе вырастает до гигабайтов за часы, а разобрать его становится сложнее, чем найти проблему без лога. Правильный подход — собирать только те события, которые отвечают на конкретный вопрос.
| Задача | События | Комментарий |
|---|---|---|
| Ошибки и аварийные завершения | EXCP, EXCPCNTX | Исключения и их контекст — первая точка анализа сбоев |
| Медленные запросы к СУБД | DBMSSQL, DBPOSTGRS, DBORACLE с фильтром по длительности | Выбирайте события своей СУБД, фильтруйте по duration |
| Взаимоблокировки | TDEADLOCK, TLOCK, TTIMEOUT | Показывают участников тупика и ожидания на блокировках |
| Длительные вызовы сервера | CALL, SCALL с фильтром по длительности | Помогают найти тяжёлые серверные вызовы |
| Утечки памяти и рост потребления | MEM, PROC | Используются редко, в основном совместно с поддержкой |
Фильтрация по длительности задаётся условием на свойство duration. Например, чтобы писать только запросы к MS SQL Server дольше одной секунды, добавьте к событию DBMSSQL условие вида «property duration больше 1000000» (длительность в ТЖ указывается в микросекундах). Это резко сокращает объём лога и сразу отсекает нормальные быстрые запросы.
Как выбрать набор событий
Структура логов и как их читать
Внутри указанного каталога платформа создаёт подкаталоги по именам процессов: rphost (рабочие процессы сервера), ragent (агент), 1cv8c (тонкий клиент) и другие. В rphost-каталогов может быть несколько — по числу рабочих процессов. Файлы внутри имеют вид, привязанный к дате и часу, например 24051514.log — часовой лог.
Каждая строка лога начинается с метки времени и длительности в микросекундах, затем идёт имя события и пары «свойство=значение». Для событий СУБД в свойстве Sql записан текст запроса, в Descr — описание контекста. Длительные события удобно искать сортировкой по первому числу в строке или специализированными инструментами разбора.
Читать сырые логи вручную тяжело: на активной системе за час накапливаются сотни тысяч строк. На практике применяют инструменты анализа — например, консольные утилиты фильтрации по имени события и длительности или специализированные обработки и программы разбора ТЖ, которые группируют запросы, показывают топ по длительности и связывают события между собой. Для разовой диагностики достаточно текстового редактора с поиском по имени события и времени инцидента.
Нагрузка, диск и безопасные ограничения
Запись технологического журнала — это дисковые операции, и на нагруженной системе они ощутимы. Полный лог со всеми событиями на крупной базе способен генерировать десятки гигабайтов в сутки и заметно влиять на отклик системы. Поэтому в продуктивной среде действуют три правила: всегда задавать history, всегда фильтровать события и выделять под логи отдельный дисковый ресурс.
Каталог для логов лучше размещать не на системном диске и не на том же массиве, где лежат файлы базы данных, — иначе при переполнении пострадает не только диагностика, но и работа СУБД. Перед включением оцените запас свободного места с учётом того, что даже фильтрованный лог на активной системе растёт быстро.
Отдельный риск — конфиденциальность. В событиях СУБД записываются тексты запросов с параметрами, а значит, в лог могут попадать персональные данные, суммы и другие чувствительные сведения. Доступ к каталогу логов должен быть ограничен так же строго, как доступ к самой базе, а при передаче логов третьим лицам их следует очищать.
Типичные ошибки при работе с технологическим журналом
Первая распространённая ситуация — логи не пишутся вообще. Причины почти всегда одни и те же: logcfg.xml положен не в тот каталог conf (например, версия платформы обновилась, а файл остался в каталоге старой), в XML допущена синтаксическая ошибка, или у служебной учётной записи нет прав на запись в целевую папку. Проверка начинается с валидности XML и прав доступа.
Вторая ошибка — анализ лога не с той машины. В клиент-серверном варианте события СУБД и серверные вызовы пишутся процессами сервера 1С, а не клиентом. Если logcfg.xml создан только на клиентской машине, событий DBMSSQL там не появится. Для диагностики серверной части конфигурация должна быть на сервере.
Третья ошибка — делать выводы по одному событию. Долгий запрос в логе не всегда означает проблему именно в запросе: он мог ждать блокировку или ресурсы сервера. Корректный анализ смотрит на картину целиком: длительность, ожидания, параллельные события других процессов в тот же интервал времени.
Когда технологического журнала недостаточно
ТЖ показывает поведение платформы, но не заменяет мониторинг СУБД и операционной системы. Если запрос к базе выполняется долго, ТЖ зафиксирует факт и текст запроса, но причину — нехватку памяти, ожидание диска, устаревшую статистику — нужно искать средствами самой СУБД: планами запросов, системными представлениями, счётчиками производительности.
Полная диагностика производительности обычно строится в три слоя: технологический журнал 1С (что и сколько выполнялось), мониторинг СУБД (как выполнялся запрос и чего не хватило) и счётчики ОС (загрузка процессора, памяти, дисков). Только сопоставление всех трёх даёт достоверную картину и защищает от неверных выводов.
Что важно запомнить
Технологический журнал включается файлом logcfg.xml и пишет низкоуровневые события платформы. Собирайте только нужные события с фильтрами, всегда ограничивайте срок хранения, размещайте логи на отдельном диске и помните, что в них содержатся данные из запросов.
Частые вопросы о технологическом журнале 1С
Нужно ли перезапускать сервер 1С после создания logcfg.xml?
Как правило, нет: новые процессы подхватывают конфигурацию при старте, а работающие — при обращении к настройкам логирования. Если логи не появились в течение нескольких минут, проверьте путь к файлу, валидность XML и права на каталог, а не спешите перезапускать службы.
Сколько места на диске резервировать под логи?
Точная цифра зависит от набора событий и нагрузки системы. Отфильтрованный лог ошибок занимает немного, а лог всех запросов на активной базе растёт очень быстро. Практичный подход: начать с минимального набора событий, понаблюдать за скоростью роста и задать history так, чтобы хранимый объём гарантированно помещался на выделенном диске с запасом.
Можно ли включить технологический журнал для файловой базы?
Да. logcfg.xml размещается в каталоге conf на той машине, где запускается клиентское приложение, работающее с файловой базой. В этом случае события СУБД будут относиться к файловой СУБД платформы, а не к внешней СУБД.
Чем технологический журнал отличается от дампов при аварийном завершении?
Дамп — это снимок памяти процесса в момент аварии, он настраивается отдельно и нужен для анализа падений. Технологический журнал — непрерывная запись событий в текстовые файлы. Они дополняют друг друга: по ТЖ видно, что происходило до аварии, а дамп показывает состояние процесса в момент сбоя.
Опасно ли держать технологический журнал включённым постоянно?
Постоянно включённый лог ошибок (EXCP) с ограниченным history — распространённая и безопасная практика. Опасно держать постоянно включёнными тяжёлые события без фильтров: это создаёт нагрузку на диск и риск переполнения. Правило простое — диагностические события включаются на период расследования, лог ошибок может работать всегда.
Как быстро найти в логе события конкретного пользователя или документа?
Сначала по журналу регистрации определите точное время и контекст проблемы. Затем в технологическом журнале откройте файл соответствующего часа и ищите по имени пользователя (свойство Usr), тексту запроса или идентификатору соединения. Сопоставление по времени между двумя журналами — стандартный приём расследования инцидентов.