Технологический анализ в 1С: где находится и как им пользоваться

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

Частая путаница возникает из-за того, что в интерфейсе конфигуратора или клиентского приложения нет пункта меню «Технологический анализ». Администраторы, ищущие эту функцию, обычно имеют в виду одно из трёх: технологический журнал платформы, анализ журнала регистрации или типовые инструменты диагностики вроде «Центра администрирования» и обработки «Анализ технологического журнала». Ниже разобрано, где находится каждый из этих инструментов и как их включить.

Где находится технологический журнал и зачем он нужен

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

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

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

Как включить сбор событий через logcfg.xml

Минимальная конфигурация logcfg.xml задаёт каталог размещения логов и список событий. Файл имеет XML-структуру: корневой элемент config, внутри — элементы log с атрибутом location (путь к каталогу), вложенными событиями event и условиями property. Например, чтобы собирать все события с длительностью операций, задают события DBMSSQL, DBPOSTGRS, EXCP, TLOCK и другие в зависимости от задачи.

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

1. 1
   Создайте каталог для логов, например D:\1c_logs, и выдайте службе сервера 1С права на запись в него.
2. 2
   Создайте файл logcfg.xml в каталоге conf установленной платформы.
3. 3
   Укажите в файле location, список событий (EXCP, DBMSSQL, TLOCK) и параметр history для ограничения хранения.
4. 4
   Подождите 1–2 минуты: платформа подхватывает настройку без перезапуска.
5. 5
   Воспроизведите проблему и проверьте, что в каталоге появились подкаталоги rphost, rmngr или 1cv8 с файлами *.log.
6. 6
   После диагностики удалите или закомментируйте logcfg.xml, чтобы остановить сбор.

Проверить, что журнал заработал, просто: в указанном каталоге должны появиться папки с именами процессов (rphost_<номер>, rmngr_<номер>, 1cv8_ для клиента), а внутри — файлы вида ГГММДДЧЧ.log. Если каталог пуст, чаще всего причина в опечатке в XML, неверном пути или отсутствии прав на запись у учётной записи службы агента сервера.

Где искать анализ событий в интерфейсе 1С

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

Для анализа производительности в типовых конфигурациях на базе БСП есть подсистема «Оценка производительности» (АЦК-методика замеров): она находится в разделе «Администрирование» → «Обслуживание» → «Оценка производительности». Там накапливаются замеры длительности ключевых операций, что позволяет найти узкие места без включения тяжёлого технологического журнала.

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

Что использовать для анализа

Журнал регистрации

Ошибки прикладного уровня, действия пользователей, изменение данных. Доступен из интерфейса, но не показывает запросы к СУБД и блокировки.

Технологический журнал

Запросы к СУБД, взаимоблокировки, длительные вызовы, аварийные завершения. Требует настройки logcfg.xml и разбора текстовых логов.

Замеры производительности (БСП)

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

Как разобрать собранные логи

Файлы технологического журнала — текстовые, их можно открыть любым редактором, но ручной разбор больших логов трудоёмок. События записываются в формате «минуты:секунды.микросекунды-длительность,ИмяСобытия,процесс:свойства», и по конкретной проблеме обычно ищут: EXCP (исключения и ошибки), TLOCK и TDEADLOCK (блокировки и взаимоблокировки), DBMSSQL/DBPOSTGRS с большой длительностью (медленные запросы), CALL с большим значением Memory (потребление памяти).

Для ускорения анализа применяют специализированные средства: обработки разбора ТЖ, доступные в сообществе разработчиков, или штатные механизмы СУБД — например, Extended Events и Profiler для MS SQL Server, pg_stat_statements для PostgreSQL. Комбинация ТЖ и средств СУБД даёт наиболее полную картину: ТЖ показывает контекст вызова из кода 1С, а СУБД — план и стоимость запроса.

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

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

Как проверить результат диагностики

Наличие файлов логов

Норма

В каталоге появились папки процессов с файлами *.log и свежими датами

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

Каталог пуст — проверьте путь в logcfg.xml, синтаксис XML и права на запись

События ошибок

Норма

События EXCP содержат текст ошибки и контекст (пользователь, сеанс)

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

Ошибка воспроизводится, но событий EXCP нет — событие не добавлено в конфигурацию

Нагрузка на диск

Норма

Объём логов растёт умеренно, history ограничивает хранение

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

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

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

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

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

Когда обращаться к специалисту

Самостоятельный анализ оправдан, когда есть понятный симптом (медленная операция, повторяющаяся ошибка) и доступ к серверу. Базовые действия — включить ТЖ по инструкции, воспроизвести проблему, найти события EXCP и длительные запросы — под силу администратору без глубокой специализации.

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

Маршрут решения

Как выбрать действие

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

Операция выполняется неприемлемо долго без ошибокВключите ТЖ с событиями DBMSSQL/DBPOSTGRS и фильтром по длительности, воспроизведите операцию

Пользователи жалуются на зависания и конфликты блокировокСоберите события TLOCK и TDEADLOCK за период жалоб и сопоставьте сеансы

Рабочий процесс сервера аварийно завершаетсяВключите запись дампов в logcfg.xml и сохраните логи для передачи специалисту

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

Есть ли кнопка «Технологический анализ» в меню 1С?

Нет, такого пункта не существует. Под технологическим анализом обычно понимают работу с технологическим журналом (включается файлом logcfg.xml), журналом регистрации (Конфигуратор → Администрирование → Журнал регистрации) и замерами производительности в типовых конфигурациях.

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

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

Работает ли технологический журнал в файловой базе?

Да. Файл logcfg.xml размещается в каталоге conf той платформы, под которой запускается клиент, и события пишутся для процесса 1cv8. Это основной способ диагностировать медленную работу файловой базы на конкретном компьютере.

Насколько технологический журнал замедляет работу?

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

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

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

Где в типовой конфигурации посмотреть медленные операции без настройки ТЖ?

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