Внешняя обработка на управляемых формах. Включает технологический журнал, читает его и отвечает на вопросы человеческим языком. Без внешних компонент, без python, без ClickHouse: всё средствами платформы.
Отдельно она умеет то, ради чего её и делали: сводит журнал в один markdown-файл на несколько килобайт, который кладётся в чат с нейросетью и разбирается там за минуту. Замер на боевой ERP: 288 мегабайт и 2 055 229 строк ужались в 17 459 знаков.
К СУБД обработка не обращается ни разу. В базу ничего не пишет.
Шесть кнопок
| Разобрать журнал | читает указанный каталог и показывает ответы, свод по событиям и счётчик потерь. Идёт порциями, по файлу за шаг, с полосой прогресса: на большом журнале форма не выглядит зависшей |
| Включить журнал | открывает окно настройки с галочками человеческим языком. Обработка сама создаёт logcfg.xml, сама выбирает каталог и подставляет путь. При включённом журнале кнопка называется "Настроить журнал" и меняет состав событий, не выключая его |
| Удалить логи | сносит собранные файлы: и в текущем каталоге, и в каталогах прошлых включений. Перед удалением показывает путь и объём отдельно по тому и другому |
| Выключить журнал | удаляет logcfg.xml. Собранные логи остаются на диске |
| Скрыть имена | показывает на экране псевдонимы вместо имён баз и пользователей. Нажать ещё раз - вернутся настоящие |
| Отдать нейросети (.md) | сохраняет снимок разбора одним файлом. Нажимать не обязательно: снимок сохраняется сам после каждого разбора |
Плюс выгрузка свода событий в xlsx, если нужно посчитать в таблице.
При открытии сразу видно состояние: включён журнал или нет, где лежит настройка, куда пишутся логи, сколько уже собрано и сколько примерно займёт разбор. Путь заполняется сам. Если журнал выключен, а логи от прошлого сбора лежат, каталог тоже подставится: разобрать и удалить можно и после выключения.
Прав администратора обычно не требуется. Общий каталог C:\Program Files\1cv8\conf закрыт на запись всем, кроме администратора, а каталог conf рядом с bin работающей версии службе 1С доступен. Обработка пишет туда. Если закрыт и он, она скажет об этом прямо и не оставит пустое поле.
Окно настройки: галочки вместо имён событий
Человек приходит к журналу с вопросом, списка событий он в голове не держит. Поэтому в окне настройки пять строк:
| Кто блокирует базу | ожидания блокировок, таймауты и взаимоблокировки. Событий мало, а без них на главный вопрос ответить нечем |
| Ошибки и исключения | прикладные ошибки, ошибки запросов и внутренние исключения платформы |
| Тяжёлые запросы к СУБД | запросы и обращения к слою данных. Пишутся только те, что дольше порога: без порога это самая объёмная часть журнала |
| Серверные вызовы и память | вызовы с длительностью и пиком памяти. Отвечают на вопрос, какой код съедает память |
| Соединения и сеансы | установка и разрыв соединений. Нужны редко, объём дают заметный, по умолчанию выключены |
Тут же порог длительности в миллисекундах и время хранения журнала в часах. После ОК обработка говорит, получилось или нет, и показывает путь к настройке.
Тринадцать вопросов, на которые обработка отвечает
Первая закладка после разбора это список вопросов. У каждого вердикт цветом, ответ и колонка "что это значит".
| Кто блокирует базу? | сколько было ожиданий блокировки, кто ждал дольше всех, сколько секунд и на каком регистре. В подробностях - держащее соединение и контекст |
| Были ли таймауты и взаимоблокировки? | это уже отказы в работе, замедлением тут дело не кончилось |
| Какие таблицы блокируются чаще всего? | если это один и тот же регистр, смотреть надо, кто и зачем пишет в него в конкурентных сеансах |
| Какой запрос к СУБД самый тяжёлый? | длительность, контекст и текст запроса целиком |
| Какой код суммарно грузит СУБД больше всех? | почти всегда важнее предыдущего: разовый долгий запрос заметен и так, а тысяча по пятьдесят миллисекунд не видна нигде и даёт нагрузку больше |
| Какой запрос читает больше всего строк? | много прочитанных строк при малом результате означает отсутствие индекса или выборку без отбора |
| Какой пользователь чаще всего обращается к базе? | само по себе не диагноз, читается вместе со следующим |
| Кто создаёт больше всего нагрузки по времени? | если это служебный пользователь, ищите регламентное задание; если живой человек - смотрите, каким отчётом он это делает |
| Какой вызов съедает больше всего памяти? | пик памяти рабочего процесса. Процесс общий на все сеансы, и упёршись в лимит кластера, он утащит за собой чужих людей |
| Какая прикладная ошибка повторяется чаще всего? | внутренние исключения платформы отсюда исключены, это ошибка вашего контура |
| Сколько ошибок это внутренний шум платформы? | исключения самой 1С с путями к её исходникам на C++. Искать среди них свои бесполезно |
| Это вообще события моей базы? | журнал пишет весь кластер. Доля своей базы это показатель того, насколько вообще можно верить разбору |
| Можно ли верить этому разбору? | сколько строк не разобралось и сколько файлов пропущено, с оценкой соразмерно потере |
Вердикты четырёх видов: чинить (найдена проблема), внимание (повод посмотреть руками), норма (вопрос закрыт), нет данных (таких событий в журнале не было). Строки с вердиктом "чинить" подсвечены, чтобы их было видно сразу.
Остальные закладки: Разбор - свод по именам событий с количеством, суммарной и максимальной длительностью и двумя долями, по числу событий и по времени; Виновники - события по убыванию длительности с контекстом и полной строкой журнала; Что не разобралось - появляется только когда есть что показать; Справка - как это устроено.
Снимок для нейросети
Журнал целиком в чат не положишь, снимок кладётся. В нём: чем снято, окно замера и скорость роста журнала, состав по базам кластера, словарь встреченных свойств, формы событий, свод и все вердикты.
Файл сам себя объясняет. В шапке лежит готовое задание, так что достаточно перетащить его в чат и не писать ничего. Там же для модели собраны правила чтения журнала: что длительности в микросекундах, что у TLOCK длительность это время ожидания, что SDBL и DBMSSQL нельзя складывать, что пик памяти общий на процесс, что callWait это нехватка рабочих процессов. Без этих правил ответ получается общим.
Задание просит таблицу с колонками "что происходит / чем подтверждается в файле / что сделать / как проверить, что помогло" и запрещает советы без ссылки на конкретную строку файла.
Там же написано, чего в журнале не могло быть в принципе: обработка читает состав настройки и перечисляет, какие события собирались. Иначе фраза "запросов к СУБД нет" читается двусмысленно.
Снимок сохраняется сам, сразу после разбора, в C:\ProgramData\tezbase-tezh\ под именем с датой и временем, и полный путь показан в своде.
Обезличивание встроено
Имена баз становятся БАЗА_01, имена пользователей ПОЛЬЗОВАТЕЛЬ_01. Одному псевдониму отвечает ровно одно исходное имя, поэтому вывод "тот же пользователь держал блокировку" остаётся верным.
Файл разделён чертой. Выше неё только числа и псевдонимы. Ниже то, что обезличить нельзя, не потеряв смысла: контексты модулей вашей конфигурации, неразобранные строки и текст самого тяжёлого запроса. Отрезал по черте и выше остался рабочий разбор.
Кнопка "Скрыть имена" делает то же самое на экране. Нужна, когда экран снимают: кадр в статью, скриншот в тикет вендору, запись для коллеги.
Что она считает своим долгом сказать
Инструменты разбора журнала обычно не сообщают, сколько строк они уронили. Отчёт получается красивый и неполный, и заметить это нечем.
Здесь шесть чисел стоят до всех таблиц: прочитано строк, собрано событий, не разобрано строк, дублей ключей, файлов прочитано, файлов пропущено. Если в неудобных четырёх нули, разбору можно верить. Если нет, отдельная закладка показывает неразобранные строки целиком, чтобы причина была видна глазами.
Отдельным ответом обработка говорит, какая доля событий относится к вашей базе.
В своде по событиям две доли, а не одна: по числу событий и по времени. Разница между ними и есть приоритет работы. На боевом прогоне TLOCK занял 72,5 процента журнала по числу событий и меньше процента по времени, а SDBL наоборот: 14,5 процента событий и почти всё время. Одна колонка тут вводит в заблуждение, и это было проверено на живой нейросети, которая назвала прежний однодольный свод внутренне несогласованным.
Как устроено внутри
Память постоянная. Файл не поднимается целиком: чтение построчное, свод копится сразу при чтении. Расход одинаковый на сотне мегабайт и на десятках гигабайт.
Значения с запятыми и кавычками разбираются целиком. Свойства Sql и Context набиты запятыми, и наивное деление строки по запятой на них врёт. Разбор идёт по состояниям с учётом кавычек и экранирования.
Дубли ключей видны оба. Свойства не складываются в соответствие, поэтому повторяющиеся имена не теряются. На боевом журнале их нашлось 433 на 14 500 событий, и почти все пришлись на одно имя.
Живой журнал читается. Файлы открываются немонопольно, так что разбирать можно не выключая журнал.
Многострочные события собираются целиком по признаку шапки, а хвосты, разрезанные границей часа, попадают в счётчик потерь, а не выбрасываются молча.
Поддерживаются оба формата: старый текстовый и новый JSON с 8.3.25.
Требования
Платформа 8.3.17 и выше, режим управляемого приложения. Проверена на 8.3.17.1386 и 8.3.27.1606, на конфигурациях ERP 2 и УТ 11.5. Версии для обычных форм пока нет.
Каталог журнала должен быть виден серверу 1С, а не вашему компьютеру: журнал пишет сервер приложений, и обработка читает его оттуда.
Как устроен сам журнал, какие события в нём бывают и что каждое ловит, разобрано в статье Технологический журнал 1С: одиннадцать событий, которые объясняют, почему база тормозит. Все числа там сняты этой обработкой.
Другие наши инструменты диагностики 1С:
- Трансформатор SQL в 1С - первое, что понадобится после разбора: журнал показал тяжёлый запрос, а в тексте одни
_Document123. - Оптимизатор временных таблиц - если тяжёлым оказался пакетный запрос: где не хватает индекса и где лишний проход по временной таблице.
- Чек-ап СУБД под 1С - когда журнал говорит, что база ждёт СУБД, а смотреть надо уже не на код: настройки сервера, память, файлы данных.
- Анализ кода внешних обработок - когда в контексте события всплыла обработка из справочника и непонятно, что она делает с базой.
Проверено на следующих конфигурациях и релизах:
- Управление торговлей, редакция 11, релизы 11.5.22.67
Вступайте в нашу телеграмм-группу Инфостарт