Технологический журнал 1С - источник правды о том, что реально происходит в базе: какие запросы тормозят, где блокировки, у кого зависла транзакция. Проблема в том, что ТЖ - это гигабайты текстовых логов в собственном формате, и "из коробки" с ними работать неудобно.
Классический путь: gawk + grep + sed, самописные Python-обработки, которые парсят построчно и складывают то, что нашли, во временную таблицу. Работает, но каждый раз заново - свой скрипт под свою задачу, свои костыли под кодировки (UTF-8 с BOM, cp1251, cp866 - в одном архиве может быть всё сразу), свой формат вывода, который потом ещё смотреть в Excel.
Есть 1С:ЦКК - тяжёлый, требует отдельной инфраструктуры, не для разового "глянуть, что там тормозит". Есть pgBadger и подобные - но это про логи PostgreSQL, а не про ТЖ 1С, и не про MS SQL. В итоге у большинства, кто регулярно разбирает производительность 1С, есть свой зоопарк скриптов, собранный за годы - и он не масштабируется на новые задачи и на других людей в команде.
Я делаю приложение - 1C-Optimyzer, которое пытается закрыть именно эту нишу: нормальный, локальный, быстрый инструмент анализа ТЖ без необходимости поднимать сервер или тащить логи куда-то наружу. Дальше - что там реально есть на сегодня, без маркетинга, с техническими деталями.
Что это технически
Tauri 2 + React + TypeScript на фронте, Python под капотом (JSON-RPC поверх stdio), DuckDB как аналитический движок хранения. Всё локально: архив ТЖ загружается, парсится потоковым лексером (проверено на 12 ГиБ архиве без падения по памяти - все, что смог нагенерить на своем ноуте), кладётся в DuckDB-файл - один файл на один загруженный архив. Хочешь передать коллеге результат анализа - просто отдаёшь файл, он самодостаточен.
Отдельно есть облачная часть (FastAPI-сервер) - но она отвечает только за AI-функции, аккаунт и лицензирование. Всё остальное - парсинг, хранение, аналитика, SQL-консоль, планы запросов - работает полностью офлайн. Это осознанное архитектурное решение: у ТЖ бывает содержимое, которое компания не готова отправлять куда-либо за пределы своего контура, поэтому AI - опциональная надстройка, а не обязательное условие работы.
Почему DuckDB, а не SQLite или PostgreSQL
ТЖ после парсинга - это, по сути, широкая аналитическая таблица: миллионы событий с десятками полей (длительность, тип события, контекст, SQL-текст, роль процесса и т.д.), по которой нужно быстро считать агрегаты, гистограммы, перцентили, группировки по произвольным полям. Это классическая OLAP-нагрузка, а не OLTP.
SQLite отлично подходит для метаданных приложения (список загруженных архивов, сохранённые запросы). Но для аналитики по десяткам миллионов строк построчный движок SQLite начинает заметно тормозить на GROUP BY или агрегатах с сортировкой - в общем, SQLite отпал еще на этапе архитектуры.
PostgreSQL решил бы задачу производительности, но требует сервера - а мне принципиально важно, чтобы приложение работало без установки СУБД и без сетевой инфраструктуры. DuckDB - колоночный embedded-движок: не нужен сервер, файл открывается напрямую, а колоночное хранение + векторизованное исполнение дают на аналитических запросах (перцентили по длительности, гистограммы по интервалам) намного лучший отклик, чем построчная БД на том же объёме данных.
Как это работает на практике
Сценарий 1: Где тормозит
Загружаешь папку с логами ТЖ - приложение само определяет кодировку (UTF-8 с BOM / без / cp1251 / cp866), парсит и раскладывает по ролям процессов (rphost, rmngr, ragent, клиентские/серверные). Дальше - анализ: медленные запросы, таймлайн блокировок, разбивка по ролям процессов, гистограмма длительностей, лента ошибок, тепловая карта активности по времени. Все они кросс-фильтруются между собой - кликнул на пик в тепловой карте, остальные представления сузились на этот интервал.
Отдельно есть сравнение архивов "до/после" - грузишь два снимка ТЖ (например, до и после релиза) и получаешь diff с автоматическим определением деградаций: приложение сопоставляет операции по отпечатку (имя + нормализованный контекст) и классифицирует изменение - регрессия, улучшение, новая операция, пропавшая, стабильная - с оценкой уверенности и приоритетом, на что смотреть в первую очередь.
Сценарий 2: Настроил ТЖ за минуту, а не полез редактировать logcfg.xml руками
Отдельный инструмент - ТЖ Билдер. Обычно логи собирают через ручное редактирование logcfg.xml: смотришь документацию, вспоминаешь синтаксис фильтров, боишься собрать слишком много и забить диск. Здесь - графический конструктор: выбираешь события из списка с подсказками, что каждое событие означает и зачем оно нужно, приложение сразу оценивает ожидаемый объём логов в час (по трём профилям нагрузки - тихая база, типичная, нагруженная) и генерирует валидный XML с превью.
Есть шесть готовых шаблонов под типовые задачи (минимальный сбор, поиск медленных операций, полная диагностика, только блокировки, экспертный аудит, baseline перед релизом) - и отдельно AI-мастер: описываешь словами, что хочешь поймать ("ищу, почему раз в день тупит проведение документов"), выбираешь СУБД - получаешь сгенерированный конфиг с объяснением, зачем каждый параметр, и предупреждениями, если конфигурация может дать слишком большой объём логов.
Сценарий 3: разбор конкретного запроса
Если открыть медленный запрос из списка, видно его SDBL-текст с диагностикой: часть антипаттернов ловится статически (без ИИ) - под MS SQL это 9 правил (сравнение с NULL через "=", неявные преобразования типов, SELECT * в JOIN и так далее), под PostgreSQL - 15 (в том числе то, что специфично для Postgres: отсутствие GIN-индекса под jsonb, ILIKE без триграммного индекса, OFFSET без LIMIT, UNION вместо UNION ALL там, где дублей быть не может). Плюс встроенный bsl-language-server даёт диагностику самого SDBL-кода (19 правил).
AI-объяснение - опциональная надстройка сверху: берёт запрос + найденные антипаттерны + (если есть) план выполнения и объясняет по-человечески, что происходит и что можно сделать. Здесь я сознательно не делаю AI валидатором, критерием истины: движок для плана выполнения - либо реальный SHOWPLAN из MS SQL, либо EXPLAIN из PostgreSQL, оба разбираются структурно (у меня отдельные парсеры под оба движка), а не угадываются моделью. AI объясняет уже разобранный объективный план, а не сам решает, что там написано, - это разница между "ИИ подтверждает то, что можно проверить" и "ИИ говорит, а вы верьте на слово". Ответы AI кэшируются по содержимому (не по пользователю), так что одинаковый запрос с одинаковым планом не гоняется через модель повторно (что критично если использовать дорогие модели).
Честное сравнение с альтернативами
- gawk и самописные скрипты - порог входа низкий, если умеешь писать на bash/Python, но каждый раз пишешь заново под конкретную задачу. Сервер не нужен, с ТЖ работает напрямую. Главное преимущество - абсолютная гибкость: нужен нестандартный разрез данных - переписал скрипт за 10 минут. Главный минус - ничего нет из коробки: ни антипаттернов, ни планов запросов, ни сравнения архивов, ни AI. Каждый раз с чистого листа, и результат остаётся у автора скрипта, а не передаётся команде.
- 1С:ЦКК - это конечно мощь, глубоко интегрирован с платформой 1С, умеет мониторить в реальном времени. Но тяжёлый: требует отдельной инфраструктуры, сервера, настройки. Для разового "глянуть, что тормозит" - избыточен. Планы запросов разбирает частично, антипаттерны и сравнение архивов до/после - нет. Да и ставить его - отдельный квест.
- pgBadger - отличный инструмент, но для другой задачи: он работает с логами PostgreSQL, а не с технологическим журналом 1С. Если у вас PostgreSQL и вам нужен анализ именно его логов - pgBadger хорош. Но ТЖ 1С он не понимает, MS SQL не поддерживает, и 1С-специфики (роли процессов, контексты, SDBL) в нём нет.
- 1C-Optimyzer - desktop-приложение, всё локально без сервера. Нативно работает с ТЖ, разбирает планы запросов под оба движка (MS SQL и PostgreSQL), ловит SQL-антипаттерны из коробки (9 правил T-SQL, 15 PostgreSQL), сравнивает архивы до/после с автоматической классификацией регрессий, AI-объяснения опционально поверх объективных данных. Логи никуда не отправляются - облако нужно только для AI, и то по желанию.
Где я честно проигрываю: проект еще не протестирован на настоящих тяжелых задачах, гибкость скриптов пока не заменяет полностью (для нестандартных задач есть SQL-консоль, но это уже не "в один клик"), и глубина интеграции с 1С у ЦКК будет повыше - десктопный инструмент для анализа не заменяет мониторинг.
Куда это движется
Ядро (парсинг, шесть представлений, SQL-консоль, сравнение архивов) - стабильно и используется. Анализ планов запросов сделан для MS SQL и PostgreSQL. Отдельный экран статического анализа кода конфигурации (не ТЖ, а метаданных) реализован, но сейчас временно скрыт из интерфейса - тестирую, насколько он реально нужен пользователям - вообще конечно надо большинство функций оценить так.
Дальше в работе, планирую - облачная часть для команд, более глубокая работа с блокировками (разбор цепочек ожиданий). Ничего из этого пока не готово, пишу честно — не хочу обещать раньше времени.
Итог: вообще я этот сервис писал, чтобы получить инструмент для подготовки к 1С:Эксперту - но как-то незаметно он превратился в такой вот продукт - затянуло в общем.
Заключение
Проект живой, я продолжаю с ним работать и разбираться в производительности 1С по ходу дела. Если у вас похожая боль с ТЖ или производительностью 1С - попробуйте, буду рад обратной связи, багрепортам и идеям, чего ОЧЕНЬ не хватает. А если у вас есть конкретная задача по производительности 1С и нужен человек, который в этом плотно сидит - пишите, открыт к обсуждению.
Ссылка на проект:
Вступайте в нашу телеграмм-группу Инфостарт