Где в 1С находятся инструменты технологического анализа

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

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

Что обычно имеют в виду под технологическим анализом в 1С

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

Набор инструментов зависит от задачи. Для анализа медленной работы нужны технологический журнал и замер производительности. Для расследования ошибок — журнал регистрации и технологический журнал с фильтром по событию EXCP. Для поиска причины взаимоблокировок — события TLOCK и TDEADLOCK технологического журнала плюс данные СУБД.

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

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

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

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

Файлы журнала появляются в указанном каталоге: платформа создаёт подпапки по имени процесса (rphost, 1cv8, 1cv8c) и складывает туда текстовые файлы с именами вида «дата-время.log». Параметр history задаёт, сколько часов хранить логи — старые файлы удаляются автоматически. Если каталог не заполняется в течение пары минут при активной работе пользователей, проверяйте путь, права на запись и синтаксис XML.

Замер производительности: где находится в конфигураторе

Замер производительности — самый быстрый способ понять, какой участок кода «съедает» время. Находится он в конфигураторе: меню «Отладка» → «Замер производительности». Работает в паре с запущенной отладкой: сначала подключаете отладку к клиентскому сеансу, затем включаете замер, выполняете в клиенте проблемную операцию и выключаете замер.

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

1. 1
   Откройте конфигуратор и запустите отладку нужного клиентского сеанса (Отладка → Подключение).
2. 2
   Включите замер: Отладка → Замер производительности.
3. 3
   В клиентском приложении выполните операцию, которая работает медленно.
4. 4
   Вернитесь в конфигуратор и выключите замер тем же пунктом меню.
5. 5
   Отсортируйте таблицу результата по колонке времени и проанализируйте верхние строки.

Журнал регистрации: анализ действий пользователей и ошибок

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

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

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

Отладчик и протоколирование: что ещё доступно из конфигуратора

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

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

Анализ на уровне СУБД и внешние инструменты

Часть технологического анализа в клиент-серверном варианте логично выполнять средствами СУБД: мониторинг активных запросов, планов выполнения, блокировок. Данные технологического журнала (события DBMSSQL, DBPOSTGRS и подобные) содержат текст запроса и контекст — их сопоставляют с тем, что видит администратор базы данных.

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

Типичные ошибки при настройке и анализе

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

Ещё одна ошибка — анализировать замер производительности без учёта кэша: первый запуск операции почти всегда медленнее повторных. Для честной картины замер делают на «прогретой» системе либо сравнивают несколько прогонов. И наконец, многие забывают выключить технологический журнал после сбора данных — через неделю диск оказывается заполнен логами.

FAQ: частые вопросы о технологическом анализе в 1С