Когда начали активно обсуждать MCP, это не выглядело как что-то неожиданное — мониторинг уже подошёл к точке, где идея «просто спросить систему» из эксперимента превратилась в логичное продолжение.
Данных в мониторинге всегда много, но ответ на конкретный вопрос всё равно добывается вручную: открываешь дашборды, переключаешься между сервисами, смотришь метрики, идёшь в логи, возвращаешься обратно.
В итоге картина складывается, только путь к ней довольно механический.
Мы попробовали собрать такую схему через MCP — как наиболее понятный способ дать модели доступ к данным. Не вспоминать, где лежит нужная метрика, не писать запросы, а задать вопрос и получить ответ.
И опять, в моменте кажется, что действительно разобрались: root cause найден, причина понятна — задача закрыта.
Но система сложная, здесь важно не путать «разобрались с инцидентом» и «разобрались с его последствиями». Потому что за первым слоем вопросов — «что произошло» и «почему это произошло» — стоит другой, на который проще найти причину, чем ответ:
что будет дальше,
насколько это системная проблема,
где ещё может «стрельнуть»,
и как это всё влияет на бизнес.
Причину инцидента мы уже умеем находить достаточно хорошо. Вопрос в том, удастся ли так же хорошо понять её последствия. Прежде чем разбираться, как модель ведёт себя, когда от неё требуют не факт, а вывод, расскажу про устройство MCP.
Как это вообще работает
MCP — это протокол прикладного уровня, построенный поверх JSON-RPC 2.0. Его задача — стандартизировать обмен контекстом между ИИ-моделью (Хост) и источниками данных (Сервер). Тут нужно понимать, что это не REST и не gRPC, а типизированный обмен между LLM-хостами и источниками данных.
Архитектура строится вокруг трёх ключевых ролей:
MCP Хост — приложение, которое управляет жизненным циклом подключений к серверам и встраивает в себя LLM. Пользователь работает именно с хостом: это может быть VS Code, Claude Desktop или специализированный чат-бот.
MCP Клиент — «прослойка» внутри хоста. Она держит соединение 1:1 с сервером.
MCP Сервер — легковесная программа, которая предоставляет специфичную логику через внешний интерфейс. Она подключается к вашей БД, API
Три примитива MCP:
Tools (Инструменты) — управляются моделью. Модель сама решает вызвать функцию (например,
get_problems), чтобы получить данные. Это основное, что используется в APM: серверу нужно описать свои инструменты так, чтобы модель могла корректно сопоставить их с задачами мониторинга.Resources (Ресурсы) — управляются приложением. Это данные, доступные приложению, которое само решает, когда и какие из них передать модели для контекста — в отличие от Tools, здесь выбор делает не модель.
Prompts (Промпты) — управляются пользователем. Шаблоны запросов (например, «Проанализируй эти метрики»).
Если отвлечься от терминологии, MCP делает довольно конкретную вещь: даёт модели доступ к API через описанные инструменты. Модель видит, какие у неё есть «ручки», и сама решает, какую из них дёрнуть.
В теории всё вполне аккуратно. Есть модель, есть набор инструментов, которые она может вызывать, есть сервер, который ходит в API. Модель получает вопрос, выбирает инструмент, забирает данные и формирует ответ. По описанию процесс выглядит почти линейным, без сюрпризов.
Что происходит, когда пробуешь на практике
Давайте предположим разные варианты, где необходимо облегчить взаимодействие пользователя с данными:
Небольшой опыт работы с системой мониторинга, нет уверенного понимания интерфейса, к тому же нет времени с этим разбираться. В этом случае MCP-сервер выступает в роли мостика между мониторингом и языковыми моделями: превращает запрос с человеческого языка в технический согласно спецификации REST API, а затем, получив в ответ JSON, трансформирует его обратно в человеческий язык.
Сложный запрос к мониторингу, который требует времени, чтобы найти необходимые данные, сопоставить их и сделать анализ. Например: «Какие проблемы за последнюю неделю оказали влияние на SLO по доступности и какой прогноз на следующую неделю?». Здесь MCP так же переводит запрос в технический язык, получает набор JSON-ов, передаёт данные в ИИ для анализа и прогноза — и выдаёт готовый ответ.
Когда пробуешь это на простых сценариях, ощущение действительно приятное. Если не очень хорошо знаешь систему мониторинга, то возможность не вспоминать названия метрик экономит время. В каком-то смысле модель берёт на себя ту часть работы, которая раньше требовала «памяти о системе».
Но это ощущение держится недолго.
Как только запрос становится чуть менее очевидным, появляется неопределённость. Модель сама решает, что именно вызвать и в каком порядке, и это решение не фиксировано. Иногда она идёт коротким путём, иногда делает лишние шаги, или просто выбирает не тот инструмент. Это не выглядит как ошибка в привычном смысле — скорее, как особенность поведения, с которой приходится жить.
Ещё заметнее становится на этапе интерпретации. Даже если данные пришли корректные, дальше модель должна объяснить, что они значат. И вот оно, пространство для расхождений, потому что причинно-следственные связи модель строит не всегда так, как ожидаешь.
Со временем начинаешь обращать внимание на вещи, которые в начале просто не видны. Например, на задержки. Пока запрос один — всё быстро. Как только модель начинает делать несколько вызовов подряд, цепочка удлиняется: сначала она думает, потом идёт в MCP, потом в API, потом обратно, потом снова «думает». Плюс стоимость, которая растёт вместе с количеством вызовов.
Отдельная тема — доступ к данным. В какой-то момент становится важно не только то, что модель может спросить, но и то, что ей вообще разрешено. Здесь она уже не просто интерфейс, а полноценный участник системы, который может дёргать API, а это требует более аккуратной настройки.
И, пожалуй, самое приземлённое наблюдение: MCP никак не улучшает сам API. Если API мониторинга запутанный или плохо структурирован, модель будет спотыкаться точно так же, как и человек. Иногда даже чаще, потому что у неё нет «интуиции» — она опирается только на описание инструментов.
Как реализовано у нас
Стоит сразу разделить два разных применения ИИ в продукте, чтобы не путать одно с другим.
У нас, в Ключ-АСТРОМ, уже есть ИИ, но с совершенно другим назначением. Основная цель — объединить данные с инфраструктуры, трейсы, логи, события k8s, пользовательский опыт, чтобы оценить влияние инцидентов на окружение и конечных пользователей и найти первопричину происходящего. То есть здесь речь об анализе причинно-следственных связей при помощи ИИ.
Теперь же ИИ-агент (Copilot, Claude Desktop или бот) сам подключается к APM через MCP-сервер и отдаёт команды: «Найди мне проблему за последний час» или «Посчитай p99 latency для сервиса payment».
В нашей системе MCP-сервер реализован как отдельный сервис, который проксирует вызовы к REST API и добавляет слой интерпретации для LLM.
1. Архитектура подключения
MCP-сервер устанавливается на отдельную машину рядом с кластером Ключ-АСТРОМ. Чтобы его запустить, нужно сделать пару настроек — подключить MCP к мониторингу и наладить связь с LLM.
Тут сделаю замечание. Часто метрики мониторинга считаются чувствительными, не всегда использование внешней LLM допустимо. Для этого мы реализовали возможность подключения как к внешним, так и к локальным LLM.
Сам MCP-сервер настроен на работу с мониторингом.
2. Какие данные получает ИИ?
Через MCP-сервер ИИ получает доступ к следующим возможностям Ключ-АСТРОМ:
Проблемы: сведения обо всех обнаруженных проблемах с описанием влияния и корневой причиной.
Логи: глубокий поиск по логам, собранных агентами мониторинга.
Метрики: метрики инфраструктуры, процессов (например, Garbage Collector).
Сущности: информация о сервисах, хостах, процессах.
Пользовательский опыт: сведения о действиях пользователей в веб- или мобильном приложении, Apdex, Web Vitals метрики и другое.
Безопасность: уязвимости и угрозы.
3. Пример выполнения запроса
Разберем сценарий: «Покажи мне топ-3 сервиса с самой высокой задержкой»
Вот что происходит под капотом:
Хост (Copilot) отправляет промпт LLM.
LLM анализирует список доступных Tools от MCP-сервера. Она видит инструменты, например
query_metricsилиget_entities, и решает, что для ответа нужно сначала найти сервисы (Entities), а потом вытянуть их метрики.MCP-клиент → MCP-сервер: LLM возвращает структурированный JSON-RPC запрос
tools/callс аргументами (например,entitySelector=type("SERVICE")).MCP-сервер (Ключ-АСТРОМ) принимает запрос, аутентифицируется с помощью токена и делает прямое API-обращение к эндпоинту
/api/v2/metrics/queryResponse: MCP-сервер получает сырой JSON от Ключ-АСТРОМ, отдаёт его обратно клиенту, тот передаёт LLM, и LLM генерирует ответ на естественном языке.
Ложка дёгтя в бочке мёда
Обсудим не только плюсы этого подхода, но и к чему нужно быть готовым.
С самим MCP всё довольно понятно: задача простая — настроить его на правильные вызовы к системе мониторинга. А вот по взаимодействию с LLM, вопросы появляются регулярно.
Расскажу про нюансы, с которыми мы столкнулись, проверяя разные модели — наши и зарубежные, облачные и локальные.
Галлюцинации метрик
LLM — всё-таки в первую очередь лингвистическая модель, а не калькулятор распределённых систем.
Например, MCP корректно передаёт значения метрик, но LLM начинает их «интерпретировать». Она может увидеть p95 задержки в 1500 мс и сказать «Всё в порядке, это допустимо», хотя SLA — 200 мс.
Тут важно понимать, что есть прямая зависимость от промпта, а самое главное — от того, сколько токенов выделено модели на то, чтобы развернуть рассуждение. Если включить режим экономии и существенно ограничить контекстное окно или длину ответа, модели буквально не хватает места, чтобы аккуратно сопоставить цифру с порогом, и она склоняется к короткому, уверенному, но поверхностному выводу — то есть начинает фантазировать.
Грубо говоря, чем меньше у LLM «воздуха» в виде токенов, чтобы рассуждать пошагово, тем выше риск, что она срежет путь и выдаст готовый ответ без промежуточных сопоставлений.
Причём порог, после которого начинается такая фантазия, у разных LLM разный: одна модель уверенно держится на коротком контексте и режет рассуждение только при жёсткой экономии, другая начинает терять точность гораздо раньше — даже когда токенов формально хватает на простой ответ, но не хватает на полноценное сопоставление метрики с порогом и объяснение выбора.
Логические разрывы: встречали ситуации, когда LLM часто путает Latency с Duration, путает клиентские (4xx) с серверными (5xx) ошибками. MCP-сервер отдает сырые поля, а модель склеивает их неверно, давая убедительный, но математически неверный вывод. Но хорошо, что такое поведение скорее редкость чем обыденность.
LLM может допридумывать синтаксис запросов в API
API системы мониторинга может иметь сложные вложенные фильтры (AND/OR/NOT), но LLM через MCP может генерировать невалидный JSON-запрос для API и приведёт к тому, что MCP-сервер возвращает ошибку «400 Bad Request». Но LLM, вместо того чтобы признать косяк, начинает галлюцинировать причину: «Ошибка доступа, проверьте права» (хотя проблема в синтаксисе) или «Данных нет, потому что сервер недоступен» (хотя данные есть, просто фильтр некорректный).
Чтобы LLM дала адекватный ответ, ей нужен адекватный точный промт. Если запрос «Почему все тормозит?» — MCP дернет 5 разных эндпоинтов (метрики CPU, GC, Response time, Network time). LLM захлебнётся в разнородных данных и выдаст кашу. Но если сформулировать промт корректно, например: «Покажи корневые причины проблем, которые возникли в проде на системе А за вчера», то тут запрос понятен и какие нужно вызвать тоже.
Цена вопроса: SLO и инциденты
Возвращаясь к вопросам, с которых начали — насколько это системная проблема и как это влияет на бизнес — вот как они выглядят не в виде абстрактного списка, а в виде конкретных рабочих сценариев.
Например, довольно типичная работа с SLO.
Доступность мобильного приложения начала снижаться. Сам факт деградации — ещё не проблема, а сигнал. Хочется понять, это разовый всплеск или тренд, что повлияло и что будет дальше.
В классическом подходе аналитика будет ручной: собрать данные, сопоставить их и сделать вывод.
С MCP можно задать вопрос напрямую: «Проанализируй динамику SLO за последнюю неделю и оцени риск выхода за порог». И получить сразу интерпретацию:
что показатели действительно снижаются,
что текущая динамика ведёт к нарушению порога,
и когда это может произойти.
То есть система сразу работает на уровне вывода, а не на уровне данных.
Другой сценарий — уже не про метрики, а про конкретные процессы, где лучше всего видно бизнес-влияние.
Допустим, вы ИТ-директор, вас не устраивает время решения критических инцидентов. При этом до конца непонятно, где именно узкое место: мониторинг не находит проблему или команда долго реагирует.
Обычно такой анализ занимает время: нужно собрать инциденты, посмотреть таймлайны, сопоставить данные.
С MCP можно задать вопрос: «Какие критические инциденты были за последние 8 недель и сколько времени заняло их устранение?»
И получить ответ, где уже видно:
когда инцидент был обнаружен,
сколько пользователей пострадало,
в чём была причина,
и сколько времени заняло восстановление.
Если оказывается, что мониторинг зафиксировал проблему за несколько минут, а устранение заняло несколько часов, то дело не в обнаружении, а в скорости реакции команды.
На этом месте легко сделать неправильный вывод, что MCP — это просто умный чат над мониторингом. Но это не совсем так.
Чат здесь — только точка входа. Основная работа происходит внутри: сбор данных, сопоставление, учёт зависимостей, построение выводов. Если убрать интерфейс, сама логика не исчезнет.
Что в итоге
Развитие систем-помощников на базе языковых моделей продолжает активно развиваться и применяется в совершенно разных отраслях. Сегодня мы рассмотрели, как этот процесс добрался до связки LLM-MCP-Мониторинг.
Из пользы можно выделить главное: он снижает порог входа в работу с APM-мониторингом и сокращает время на получение нужных сведений — человеку не нужно помнить синтаксис запросов, чтобы получить ответ. Особенно ощутимо это в стрессовых ситуациях, когда инцидент требуется разобрать как можно быстрее.
При этом на практике связка показала и обратную сторону: модель может уверенно ошибаться там, где данных недостаточно или термины похожи, придумывать причину сбоя вместо того, чтобы признать невалидный запрос. Все эти случаи объединяет одно — модель ведёт себя увереннее, чем должна бы, особенно когда ей не хватает токенов или точности в промпте.
Но если смотреть на это шире, что и показывают оба сценария выше, — MCP не сводится к удобному способу задать вопрос мониторингу. Это инфраструктура, которая меняет сам подход к работе с системой: не вытаскивать метрики по одной, а сразу получать вывод с учётом зависимостей.
Посмотреть наш продукт на сайте: MCP-сервер Ключ-АСТРОМ
