Эта категория про журнал регистрации и техжурнал. Такие инструменты нужны, когда агент должен расследовать ошибку по событиям, исключениям и 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 | |
| живая база 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С | |
| живая база 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 | |
| конструктор 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.
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.
logcfg.xml: 1C Log Checker.get_event_log в live-базе без отдельного log-stack: 1C MCP Toolkit.