Анализ технологического журнала 1С через MCP-1C
tj_analyze для технологического журнала 1С: медленные обращения к СУБД, блокировки, исключения, окно времени и ограничения выводов по сводному отчёту.
Для разбора зависания начните с короткого фрагмента технологического журнала вокруг времени сбоя. tj_analyze поможет найти длительные обращения к СУБД, события блокировок и исключения. По одной сводке нельзя установить причину, но можно выбрать события и код для дальнейшей проверки.
С v2.41.0 в Расширенной и Профессиональной редакциях MCP-1C есть tj_analyze. Он читает журнал и ничего в нём не изменяет. Действие suggest_logcfg возвращает текст настройки, но включение сбора выполняет администратор. Требования и ограничения опубликованы в справочнике tj_analyze, версия — в истории изменений.
В статье: подготовка, выбор действия, время и длительность, выводы.
Подготовьте каталог и временное окно
Параметр dir задаётся в каждом вызове и открывается на машине MCP-сервера. Читается структура <процесс>_<pid>/ГГММДДЧЧ.log, например каталог rphost_1234. Поддерживаются обычный и JSON-формат записей. Параметр base к этому инструменту не применяется.
Для первичной сводки передайте в tj_analyze аргументы с путём и окном инцидента:
{
"action": "parse",
"dir": "/srv/1c/tj",
"since": "2026-10-11T10:00:00+03:00",
"until": "2026-10-11T10:15:00+03:00",
"top": 10
}
Это условный путь и время. Сначала уточните часовой пояс и момент воспроизведения, иначе отчёт может описывать соседний период. Журнал способен содержать тексты запросов и другие чувствительные сведения: образцы в ответе не маскируются. До передачи результата модели проверьте допустимость этих данных для выбранной среды.
Выберите нужный срез
| Действие | Результат |
|---|---|
parse |
Состав файлов, форматы, окно, события и сводные разделы |
perf |
Группы обращений к СУБД и SDBL по длительности |
locks |
Группы событий блокировок |
errors |
Группы исключений |
suggest_logcfg |
Текст настройки сбора, без записи файла |
Для perf можно задать нижнюю границу min_duration_us в микросекундах. top ограничивает число показанных групп. У parse параметр classes выбирает разделы perf, lock, error; параметры, которые действие не использует, отклоняются, поэтому не переносите весь набор аргументов из одного среза в другой.
Если журнала ещё нет, запросите suggest_logcfg, укажите каталог назначения и передайте полученный текст администратору. Он должен разместить logcfg.xml по правилам своей установки. Сам инструмент не включает сбор и не создаёт каталог с журналом.
Учитывайте смысл времени и сумм
Метка записи считается концом её интервала, длительность отсчитывается назад. Окно выбирается по этой метке, а until входит в него. Дата без времени означает начало дня; для времени без часового пояса используется пояс машины сервера. Явный RFC3339 с поясом снижает неоднозначность.
В группах есть число записей, суммарная, максимальная и средняя длительность в микросекундах. Это характеристики записанных событий. Сумма длительностей нескольких событий не является автоматически временем ожидания одного пользователя: события могли выполняться параллельно или относиться к разным операциям.
Группировка также не нормализует литералы запросов: похожие запросы с разными значениями могут оказаться в разных группах. Образец относится к самой долгой записи группы. Учитывайте это перед выводом о частоте одной бизнес-операции.
Превратите сводку в проверяемую гипотезу
Начните со состава прочитанных файлов и заметок об отказах или пропусках. Неполное чтение не доказывает отсутствие исключений или блокировок. Поддержка события парсером тоже не означает, что оно проверено на каждом варианте платформы: справочник отдельно обозначает пределы проверки форматов и событий.
Затем выберите конкретную группу, сопоставьте её с временем воспроизведения и найдите соответствующий код. Проверьте гипотезу в тестовой среде: тот же сценарий, сопоставимые данные и одинаковое окно наблюдения до и после изменения.
Для продолжения пригодятся анализ кода и поиск запроса динамического списка.