Эта категория про журнал регистрации и техжурнал. Такие инструменты нужны, когда агент должен расследовать ошибку по событиям, исключениям и runtime-следам.
Эта категория про журнал регистрации, технологический журнал и диагностику работы 1С. Такие инструменты нужны, когда агент должен не только читать код, но и разбираться в ошибках, событиях, длительных операциях и поведении системы после изменений.
В сравнении ниже видно, какие решения читают журнал напрямую, какие требуют отдельной инфраструктуры, а какие дают только общий доступ к диагностическим данным.
| Критерий | Что сравнивается |
|---|---|
| Контур | Живая база 1С, отдельный log-stack, gateway, продукт-конструктор |
| Журнал регистрации | Какие именно tools читают журнал регистрации |
| Фильтрация | Насколько детально можно фильтровать: дата, уровень, пользователь, событие, объект, приложение, комментарий |
| Технологический журнал | Есть ли отдельные tools для техжурнала |
| Управление техжурналом | Можно ли включать, настраивать, сохранять и отключать logcfg.xml |
| Безопасность и токены | Read-only, анонимизация, compact/minimal output, approval |
| Мультибаза / маршрутизация | Есть ли сессии, routing по базам, GUID map |
| Уровень подтверждения | исходники, описание, продукт |
| Набор инструментов | Контур | Журнал регистрации | Фильтрация | Техжурнал | Управление техжурналом | Безопасность / токены |
|---|---|---|---|---|---|---|
| локальные файлы журналов | XLSX / SQLite .lgd | уровень, пользователь, событие | каталоги ТЖ, время/длительность | нет | чтение файлов | |
| отдельный log-stack на Docker + ClickHouse | logc_get_event_log | время, уровень, GUID базы/кластера, limit; compact/full mode | да, logc_get_tech_log | да | minimal / full, rate limiting | |
| локальный desktop + DuckDB по архивам ТЖ | нет | время, process role, event type и cross-filter между views; SQL Console | да, основной источник | TJ Config Builder генерирует logcfg.xml, но не применяет его на сервере 1С | локальные архивы; read-only SQL; AI только по кнопке, telemetry/cloud disclosure | |
| живая база 1С | get_event_log | широкий набор: дата, levels, events, object/data, metadata_type, user, session, application, computer, comment, transaction status, cursor paging | нет | нет | анонимизация, approval, cursor pagination | |
| живая база 1С | get_event_log | период, пользователь, событие и лимит | нет | нет | зависит от прав пользователя 1С | |
| workspace MCP + расширение в живой базе | event_log | параметры action/schema и фильтры backend расширения | нет | нет | требуется право EventLog; подключение через --onec-url | |
| живая EDT-сессия и подключенная ИБ | get_event_log | параметры запроса журнала через EDT host | нет | нет | учетные данные ИБ задаются в EDT-MCP | |
| живая база 1С | get_event_log | по docs: дата, пользователь, событие и др. | нет | нет | не раскрыто | |
| живая база 1С | get_event_log | дата, уровень, пользователь, limit | нет | нет | read-only, limit 50 по умолчанию / 500 max | |
| HTTP gateway к подготовленному сервису 1С | event_log, object_history | период, уровень, события, пользователь, сеанс, тип/UUID объекта | нет | нет | отдельный scope mcp:admin:eventlog, OAuth audit, повторная ACL в 1С; PII не маскируется | |
| конструктор tools в 1С | зависит от настройки | зависит от настройки | зависит от настройки | зависит от настройки | зависит от настройки | |
| мониторинг внутри расширения | сбор ошибок платформой | период, уровни, тестовые маркеры | нет | нет | права базы; контроль отправок в LLM/Telegram | |
| файлы подключённой ИБ через EDT | read_event_log | from/to, event, user, severity, limit | нет | нет | маскировка свободного текста |
Плагин определяет каталог файловой ИБ по приложению EDT и разбирает файлы журнала напрямую. Это самостоятельный файловый reader, без расширения в базе.
read_event_log | принимает projectName, опциональный applicationId, период, событие, пользователя, важность и лимит; возвращает события, число просмотренных записей, файлы и признак усечения. |
|---|---|
infobase_admin operation=read_event_log | фасад того же reader. |
Серверная ИБ и однофайловый SQLite-формат журнала отклоняются. Поддержанный файловый журнал должен быть доступен процессу EDT. Свободный текст проходит шаблонную маскировку; имена пользователей и компьютеров не гарантированно скрываются. Технологический журнал и настройка его сбора не предоставляются.
читает журнал регистрации средствами платформы, сохраняет сгруппированные ошибки и статистику в регистрах базы. Управление доступно через обработку настроек, дашборд и регламентные задания, а не отдельный MCP log-tool.
Нужны платформа 1С, БСП и расширение; для ИИ-анализа — модель, для уведомлений — Telegram. Технологический журнал не разбирается, logcfg.xml не настраивается. Внешний MCP-клиент не получает отдельной операции чтения ЖР; чтение регистров мониторинга возможно только обычным запросом при наличии соответствующих прав.
MCP-сервер onec-ops получает пути к доступным ему файлам и разбирает их локально: журнал регистрации читает из XLSX-выгрузки или SQLite .lgd, технологический журнал — из одного или нескольких каталогов файлов ТЖ. Для этих двух инструментов не нужны опубликованная база, Zabbix или Prometheus.
event_log_parse_tool(source, level, user, events, top, table) | читает XLSX-выгрузку или SQLite .lgd, фильтрует записи по уровню, пользователю и событию, возвращает сводку и записи. |
|---|---|
tech_journal_parse(roots, events, min_duration, since, until, top) | разбирает один или несколько каталогов ТЖ, фильтрует события по виду, времени и длительности, возвращает сводку и наиболее долгие события. |
анализ журналов без подключения к работающей базе, в том числе по нескольким каталогам ТЖ. Ограничения: нужны доступные файлы выгрузки/журнала; сервер читает данные и не управляет настройкой или очисткой журналов.
1C Log Checker - отдельный MCP и log-stack для журнала регистрации и технологического журнала. Он не ходит в живую базу за get_event_log, а строит собственный контур: читает файлы журналов, складывает их в ClickHouse и отдает агенту уже нормализованный log API.
logc_get_event_log | читает журнал регистрации 1С. По tools.json требует cluster_guid и infobase_guid, поддерживает from, to, level, limit и режимы minimal / full. |
|---|---|
logc_get_tech_log | читает технологический журнал по окну времени и типу события. |
logc_get_actual_log_timestamp | показывает, до какого момента parser уже обработал техжурнал; полезно для polling перед запросом. |
logc_save_techlog | сохраняет текущий logcfg.xml как backup. |
logc_configure_techlog | генерирует и при необходимости сохраняет logcfg.xml. |
logc_restore_techlog | восстанавливает предыдущую конфигурацию техжурнала из backup. |
logc_disable_techlog | отключает техжурнал. |
logc_get_techlog_config | читает текущую конфигурацию logcfg.xml. |
это самый специализированный MCP в категории. Он покрывает оба источника логов 1С, умеет экономить токены через minimal mode, поддерживает отдельный workflow включения/отключения техжурнала и хорошо подходит для системной диагностики, когда обычного get_event_log уже недостаточно.
контур тяжелее остальных. Нужны Docker, ClickHouse, parser service, GUID map и доступ к log-файлам Windows-хоста. Это не "быстрый log tool внутри базы", а отдельная observability-инфраструктура.
когда журнал регистрации и техжурнал нужны как постоянный диагностический контур, а не как разовый вспомогательный tool из live-базы.
1C MCP Toolkit - основной универсальный live-MCP, у которого журнал регистрации является частью общего доступа к базе. Внутри категории логов он интересен тем, что get_event_log у него заметно богаче, чем у простых MCP с одним log-tool.
get_event_log | читает журнал регистрации с расширенной фильтрацией. |
|---|
Что именно умеет get_event_log по README_FULL.md:
start_date, end_datelevels, eventsdatametadata_typeuser, session, application, computercomment_containstransaction_statussame_second_offset, last_date, next_same_second_offset, has_moreсамый детальный get_event_log среди универсальных MCP для живой базы. Особенно полезны object/data filter, типы метаданных, статус транзакции и курсорная пагинация. Плюс на этот tool распространяются анонимизация и approval flow.
это только журнал регистрации. Отдельных tools для технологического журнала и управления logcfg.xml тут нет.
когда журнал регистрации нужен как часть общего live-доступа к базе, без отдельного стека ClickHouse/Grafana.
Встроенный сервер работает в клиентском сеансе 1С без веб-публикации базы; прокси обменивается запросами с обработкой через polling. Для macOS требуется соответствующая нативная сборка; скриншоты доступны только на Windows.
INFATON MCP Server дает журнал регистрации как один из инструментов общего MCP-доступа к живой базе. Это не отдельный log-stack, а MCP-инструмент внутри расширения 1С.
get_event_log | читает журнал регистрации с фильтрами. |
|---|
простой log-tool рядом с другими live-операциями INFATON: запросами, метаданными, документами, регистрами и правами. Удобно, если этот сервер уже используется как общий backend к базе.
нет техжурнала, управления logcfg.xml, отдельной observability-инфраструктуры, явной анонимизации, cursor pagination и такого широкого набора фильтров, как у 1C MCP Toolkit.
когда нужен базовый журнал регистрации внутри уже подключенного INFATON MCP Server.
Полный HTTP-каталог содержит 93 tools; STDIO-обёртка публикует 51. Вызовы исполняются с правами пользователя 1С.
В категории журнала регистрации учитывается только публичная операция event_log workspace-профиля. Она читает журнал живой базы через опубликованное расширение BSL_Analyzer; локальный статический индекс и LSP сами по себе журнал не содержат.
журнал доступен рядом с диагностикой, графом, SDBL и runtime-операциями одного workspace MCP. Ограничения: нужен --onec-url, установленное расширение и право пользователя EventLog; это не техжурнал и не отдельная observability-система.
get_event_log читает журнал подключенной информационной базы из живого EDT-host. Инструмент полезен как часть общего IDE-контура вместе с проектом, отладкой и profiling, но не управляет технологическим журналом и не заменяет специализированный log-stack.
Для изображений и структуры визуального макета формы EDT требуется запуск с -DnativeFormBufferedLayoutRender=true. Поддерживаются EDT 2026.1/Java 17 и 2026.2/Java 25; опубликованный набор зависит от toolsets.
OneBridge - live-MCP к базе 1С, где журнал регистрации доступен как один из базовых tools.
get_event_log | получает журнал регистрации с фильтрацией. |
|---|
простой log-сценарий прямо внутри общего live-MCP к базе. По docs есть фильтрация по дате, пользователю, событию и другим полям, чего достаточно для типовых запросов вроде "покажи ошибки за сутки" или "найди записи конкретного пользователя".
репозиторий не содержит исходники .epf, поэтому здесь подтверждение только по README/docs. Публично не раскрыты точная схема параметров, лимиты, анонимизация, пагинация и формат ответа.
когда нужен базовый get_event_log внутри уже используемого OneBridge-контура и не нужен отдельный log-stack.
MCP-1C дает журнал регистрации как простой read-only tool поверх живой базы.
get_event_log | читает журнал регистрации с фильтрацией по периоду, уровню и пользователю. |
|---|
start_dateend_dateleveluserlimitминималистичный и понятный tool без лишней сложности. Для типовых сценариев "последние ошибки", "ошибки пользователя X", "что было сегодня" его достаточно.
фильтров меньше, чем у Toolkit. Нет object filter, metadata filter, transaction status, application type и пагинации.
когда нужен легкий live-tool для чтения журнала регистрации без глубокого log workflow.
AI Коннектор попадает в категорию журнала регистрации только как конструктор собственных tools.
можно сделать собственный доступ к журналу ровно в том виде, который нужен конкретной команде или конфигурации.
это не готовый сервер журнала регистрации с фиксированным списком log-tools. Публичное сравнение здесь возможно только на уровне продукта-конструктора, а не на уровне конкретных MCP-операций.
когда нужен конструктор своих log-tools внутри платного продуктового контура, а не готовый стандартный log MCP.
get_event_log_path находит 1Cv8Log зарегистрированной в EDT файловой или серверной базы, а query_event_log читает .lgf/.lgp с фильтрами периода, пользователя, события, важности и подстрок. Ответ проходит privacy-фильтр v1.17, если база помечена как содержащая реальные ПДн.
get_event_log_path | определяет путь к файлам журнала регистрации выбранной информационной базы. |
|---|---|
query_event_log | читает и фильтрует записи .lgf/.lgp. |
это локальный reader файлов журнала, не API к технологическому журналу и не потоковый мониторинг; качество обезличивания ограничено каталогом, словарем имен и regex.
OneC MCP публикует два инструмента, которые непосредственно читают один привилегированный endpoint журнала регистрации в подготовленном HTTP-сервисе 1С.
event_log | выбирает события по периоду, уровням, техническим именам событий, пользователю, сеансу, типу и UUID объекта. |
|---|---|
object_history | использует тот же endpoint, но задает объектно-ориентированный сценарий восстановления истории конкретного объекта. |
отдельный чувствительный scope mcp:admin:eventlog; tool скрывается из tools/list без права, gateway повторно проверяет scope и передает его в 1С для defense in depth. Поддерживаются несколько баз с разными issuer/audience, а вызовы и отказы пишутся в OAuth/MCP audit log.
готовый BSL endpoint /mcp/admin/eventlog в репозиторий не входит и должен быть реализован самостоятельно. Чтение на стороне 1С выполняется в привилегированном режиме; журнал содержит PII, а встроенного обезличивания ответа нет. Техжурнал и управление logcfg.xml не поддерживаются.
когда журнал нужен как часть контролируемого мультибазового read-only gateway с OAuth, а не как отдельный комплекс сбора технологических логов.
1C-Optimyzer — не MCP и не live-reader журнала регистрации. Это desktop workbench, который принимает папку/архив файлов технологического журнала, потоково парсит события и строит локальный per-archive DuckDB-индекс.
TJ Config Builder — графическое создание logcfg.xml и AI-мастер; файл нужно самостоятельно установить на сервер 1С.Operations / Operation Anatomy / Session Anatomy — группировка событий в бизнес-операции и детализация последовательности.Slow Queries — медленные DBMSSQL/DBPOSTGRS события и переход к анализу плана.Locks Timeline, список дедлоков и Deadlock Anatomy — блокировки, участники и lock graph.Process Roles, Duration Histogram, Errors Feed, Activity Heatmap — готовые аналитические срезы.Archive Comparison — baseline/current summary, сравнение медленных запросов и regression detection.SQL Console — произвольные read-only SELECT/WITH по локальным таблицам событий, 13 templates, schema autocomplete, saved queries и экспорт CSV/TSV/JSON.не требует постоянного Docker/ClickHouse stack; работает с уже собранными архивами произвольного размера, распознаёт UTF-8/cp1251/cp866 и шесть process roles. Cross-filter одного view применяется к остальным, а operation/deadlock anatomy связывает запросы, блокировки и контекст выполнения. Plan Analyzer извлекает planSQLText прямо из ТЖ, если он включен в logcfg.xml.
нет журнала регистрации .lgf/.lgp, live polling и автоматического применения/backup/restore logcfg.xml; TJ Config Builder только генерирует конфигурацию. Это интерактивное desktop-приложение для человека, а не агентский API. Удаление archive item/bulk удаляет локальные индексы. AI отправляет агрегированный контекст в облако по явному действию, а anonymous telemetry включена продуктом согласно privacy-документации.
для локального расследования конкретного архива ТЖ, сравнения производительности до/после и анализа запросов/планов без разворачивания постоянного observability stack.
logcfg.xml: 1C Log Checker.get_event_log в live-базе без отдельного log-stack: 1C MCP Toolkit.