Чем смотреть технологический журнал 1С

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

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

Ниже разобраны основные инструменты, порядок включения журнала, типичные сценарии анализа и ограничения каждого способа. Материал ориентирован на администраторов и разработчиков, которые работают с клиент-серверной или файловой 1С.

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

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

В файле logcfg.xml задаются события, которые нужно фиксировать: DBMSSQL или DBPOSTGRS для запросов к СУБД, EXCP для исключений, CALL и SCOM для вызовов, LEAKS для утечек памяти. Там же указывают каталог размещения логов и глубину хранения в часах через элемент history.

<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>
    <property name="all"/>
  </log>
</config>

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

Встроенные средства: чем смотрит сама платформа

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

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

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

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

Основной класс инструментов — бесплатные утилиты, созданные сообществом специалистов по 1С. Наиболее известна программа для просмотра технологического журнала (часто упоминается как 1C TJ Viewer или «Просмотр технологического журнала»), которая парсит файлы логов и показывает события в виде таблицы с фильтрами по имени события, процессу, длительности и тексту.

Такие программы умеют группировать события по контексту, подсвечивать долгие запросы, строить связку «запрос 1С — запрос СУБД — ошибка», что вручную по текстовым файлам делать мучительно долго. Часть утилит распространяется через портал Infostart и GitHub; перед использованием на рабочем сервере стоит проверять источник и скачивать только из доверенных репозиториев.

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

Просмотр журнала в текстовом редакторе

Если специализированной утилиты под рукой нет, файлы технологического журнала вполне читаются в Notepad++ или VS Code. Формат записи: каждая строка начинается с метки времени и длительности в микросекундах, затем идёт имя события, процесс и список свойств через запятую. Записи, длящиеся дольше минуты, могут разбиваться на пару событий начала и конца.

Практический приём — поиск по имени события. Например, чтобы найти все исключения, ищите ,EXCP,; чтобы найти запросы к MS SQL — ,DBMSSQL,. Для поиска взаимоблокировок ищите событие TDEADLOCK и текст ошибки СУБД внутри событий EXCP.

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

1. 1
   Откройте каталог логов и найдите файл за час, когда произошла ошибка, в подкаталоге rphost.
2. 2
   Откройте файл в Notepad++ и выполните поиск по тексту ошибки или по событию ,EXCP,.
3. 3
   Поднимитесь выше по файлу и найдите связанный запрос DBMSSQL или CALL с тем же номером соединения.
4. 4
   Выпишите текст запроса, контекст и длительность — этого достаточно для передачи разработчику или анализа плана запроса.
5. 5
   После завершения сократите глубину записи журнала в logcfg.xml, чтобы не заполнить диск.

Автоматизация: скрипты и системы мониторинга

Когда журнал нужно анализировать регулярно, ручной просмотр заменяют скриптами. Типовая задача — выбрать из логов все события EXCP и TDEADLOCK за сутки и сложить их в один файл или отправить уведомление администратору. На Windows это делается через PowerShell с поиском по шаблону, на Linux — через grep и awk.

Для крупных внедрений логи 1С направляют в системы централизованного сбора: Elasticsearch с Kibana, Grafana Loki, Zabbix с парсингом логов. Это позволяет строить графики количества ошибок, длительности запросов и настраивать оповещения. Минус подхода — формат журнала 1С нестандартный, поэтому потребуется написать регулярные выражения для разбора строк.

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

Типичные ошибки при работе с журналом

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

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

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

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

Признак корректно найденной записи — совпадение времени, имени пользователя или соединения и текста ошибки с тем, что видел пользователь. В событии EXCP поле Descr содержит текст исключения, а свойство Context — стек вызовов встроенного языка, по которому разработчик найдёт место в коде.

Для проблем производительности ориентир — длительность события. Она указывается в начале строки в микросекундах; значения в миллионы микросекунд означают секунды выполнения. Долгий запрос DBMSSQL с длительностью в несколько секунд при жалобах на «тормоза» — прямой кандидат на оптимизацию.

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