Эта категория про журнал регистрации и техжурнал. Такие инструменты нужны, когда агент должен расследовать ошибку по событиям, исключениям и runtime-следам.
Эта категория про журнал регистрации, технологический журнал и диагностику работы 1С. Такие инструменты нужны, когда агент должен не только читать код, но и разбираться в ошибках, событиях, длительных операциях и поведении системы после изменений.
В сравнении ниже видно, какие решения читают журнал напрямую, какие требуют отдельной инфраструктуры, а какие дают только общий доступ к диагностическим данным.
| Критерий | Что сравнивается |
|---|---|
| Контур | Живая база 1С, отдельный log-stack, gateway, продукт-конструктор |
| Журнал регистрации | Какие именно tools читают журнал регистрации |
| Фильтрация | Насколько детально можно фильтровать: дата, уровень, пользователь, событие, объект, приложение, комментарий |
| Технологический журнал | Есть ли отдельные tools для техжурнала |
| Управление техжурналом | Можно ли включать, настраивать, сохранять и отключать logcfg.xml |
| Безопасность и токены | Read-only, анонимизация, compact/minimal output, approval |
| Мультибаза / маршрутизация | Есть ли сессии, routing по базам, GUID map |
| Уровень подтверждения | исходники, описание, продукт |
| Набор инструментов | Контур | Журнал регистрации | Фильтрация | Техжурнал | Управление техжурналом | Безопасность / токены |
|---|---|---|---|---|---|---|
| отдельный 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 к backend | get_event_log через backend | дата, уровень, пользователь и другие фильтры backend; в ранее зафиксированной карточке показаны базовые сценарии | нет отдельного tool | нет | анонимизация на шлюзе, session routing | |
| HTTP gateway к подготовленному сервису 1С | event_log, object_history | период, уровень, события, пользователь, сеанс, тип/UUID объекта | нет | нет | отдельный scope mcp:admin:eventlog, OAuth audit, повторная ACL в 1С; PII не маскируется | |
| конструктор tools в 1С | зависит от настройки | зависит от настройки | зависит от настройки | зависит от настройки | зависит от настройки |
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.
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.
В категории журнала регистрации учитывается только публичная операция event_log workspace-профиля. Она читает журнал живой базы через опубликованное расширение BSL_Analyzer; локальный статический индекс и LSP сами по себе журнал не содержат.
журнал доступен рядом с диагностикой, графом, SDBL и runtime-операциями одного workspace MCP. Ограничения: нужен --onec-url, установленное расширение и право пользователя EventLog; это не техжурнал и не отдельная observability-система.
get_event_log читает журнал подключенной информационной базы из живого EDT-host. Инструмент полезен как часть общего IDE-контура вместе с проектом, отладкой и profiling, но не управляет технологическим журналом и не заменяет специализированный log-stack.
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.
onec-mcp-universal - не самостоятельный движок чтения журнала, а gateway к backend-сервисам. В логовой категории он важен как orchestration-слой вокруг get_event_log.
на 2026-05-29 GitHub-репозиторий недоступен; сравнение оставлено по ранее зафиксированной карточке.
get_event_log backend - чтение и фильтрация журнала через подключенный EPF/backend.если логовый доступ нужен сразу к нескольким базам и в одном MCP endpoint, gateway полезнее прямого Toolkit. В ранее зафиксированных материалах показаны session routing, работающий get_event_log и анонимизация ответов на стороне шлюза.
глубина фильтрации зависит от backend. Собственного отдельного logc_get_tech_log или управления logcfg.xml у gateway нет. Для новых внедрений надо отдельно проверить доступность проекта.
когда журнал регистрации нужен в мультибазовом контуре с маршрутизацией по сессиям и маскированием данных.
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.