Как Dynatrace и ИИ-помощник в написании кода могут преодолеть разрыв между «что-то работает медленно» и «вот решение». Почему это важно для вывода ИИ-рабочих нагрузок в продакшн.
Разработка с использованием ИИ стремительно ускоряется. Разработчики просят своих ИИ-помощников писать код, объяснять архитектуру и отлаживать проблемы в режиме реального времени. Нередко бывает так, что ИИ видит код, но не видит того, что этот код на самом деле делает в продакшене.
Этот разрыв может стоить дорого: медленные запросы, перегрузка процессора, каскадные задержки, расход ценных токенов. Это проблемы, которые замедляют ИИ-рабочие нагрузки на пути к продакшену, и их редко можно выявить, анализируя только код.
Сервер Dynatrace MCP разработан для устранения этого разрыва. Подключив ИИ-помощника для написания кода напрямую к актуальным данным наблюдаемости Dynatrace, разработчики могут задавать вопросы о работающих системах на обычном языке и получать ответы, подкрепленные данными. Это позволяет значительно сократить путь от симптома до исправления.
Кроме того, Dynatrace публикует набор навыков, которые обучают агентов по написанию кода взаимодействию с платформой. Эти навыки представляют собой готовые инструкции, которые учат ИИ-помощника эффективно запрашивать данные наблюдаемости, определять доступные типы сущностей, соотносить симптомы со строками кода и проверять работоспособность исправлений. MCP-сервер предоставляет ИИ-агенту доступ, а навыки — способность принимать решения.
Вот как это выглядит на практике:
Настройка: многосервисное приложение и проблема производительности
В качестве примера взято многоуровневое приложение для управления задачами: шлюз Node.js, сервис задач (case-service) на базе PostgreSQL и сервис документов. Это типичный шаблон для тех рабочих нагрузок, которые организации сейчас ускоряют с помощью ИИ.
Симптомы в Dynatrace были очевидны: загрузка процессора хоста достигала 100%, а среднее время отклика сервиса задач выросло до ~89 секунд. Dynatrace обнаружил проблему деградации времени отклика, указав базу данных casemgt в качестве первопричины. Вопрос был прост: почему? И, что более важно, в какой части кода кроется замедление?
Задание правильных вопросов на обычном языке
Используя сервер Dynatrace MCP, подключенный к ИИ-агенту для написания кода, расследование началось с вопроса на естественном языке:
«Покажи мне 5 методов, которые оказывают наибольшее влияние на базу данных casemgt в моей среде Dynatrace».
«Покажи мне 5 методов, которые оказывают наибольшее влияние на базу данных casemgt в моей среде Dynatrace».
MCP-сервер выполнил запрос к Dynatrace в фоновом режиме, обнаружив сущность базы данных, проанализировав приложение и выведя ранжированный список рекомендаций. Никакой консоли. Никакой навигации по дашбордам. Никаких языков запросов.
Основные виновники были сразу выявлены:
- Поисковый запрос, вызывающий полное сканирование таблицы при каждом вызове
- Сервисный эндпоинт, выполняющий четыре последовательных запроса агрегации по всей таблице на каждый запрос
- Сложный запрос с множественной агрегацией и арифметикой дат по каждой строке в таблице
- Запрос постраничного списка, который препятствовал использованию индекса
- Оператор SELECT, обращающийся к базе данных каждые две секунды на каждый сервис
Затем тот же вопрос был задан относительно самого сервиса задач, и сервер Dynatrace MCP сопоставил 9 эндпоинтов сервиса с телеметрией в Dynatrace, соотнеся пути выполнения кода с измеренным временем отклика.
От телеметрии к коду: конкретные строки, конкретные исправления
Именно здесь эта комбинация становится по-настоящему мощной. Поскольку Dynatrace MCP предоставляет телеметрию из продакшена, а агент по написанию кода читает исходный код приложения в рамках того же диалога, ИИ смог сопоставить наблюдаемые проблемы производительности напрямую с конкретными строками:
Исправление 1: Параллелизация четырех последовательных запросов к базе данных
Эндпоинт /cases/stats выполняет четыре независимых запроса агрегации один за другим. Каждый раз, когда дашборд приложения обновляется, все четыре запроса запускаются последовательно, поэтому время отклика равно сумме времени выполнения всех четырех. Решение, предложенное ИИ-агентом, заключалось в параллельном выполнении этих запросов. Это сократило бы время отклика запросов примерно на 75%:
Исправление 2: Добавление триграммных индексов для поиска ILIKE
Каждый раз, когда в приложении выполняется поиск, отправляется запрос, который запускает ресурсоемкую операцию в базе данных. PostgreSQL не может использовать стандартный B-tree индекс для ILIKE, поэтому при каждом поиске он считывает каждую строку в таблице cases. Индекс делает такие запросы быстрыми без изменения кода приложения:
Первопричина: Параллелизация и индекс из двух строк
«Почему процесс моей базы данных casemgt потребляет так много ресурсов процессора?»
«Почему процесс моей базы данных casemgt потребляет так много ресурсов процессора?»
Ресурсоемкие операторы базы данных были явно выделяющимися элементами. Первопричиной была нагрузка от выполнения запросов: входящий трафик постоянно выполнял дорогостоящие, неоптимизированные SQL-запросы. В частности, каждый поисковый запрос, отправляемый приложением, запускал сопоставление по шаблону ILIKE. У базы данных не было иного выбора, кроме как считывать каждую строку в таблице cases при каждом вызове. При устойчивой нагрузке этот единственный шаблон запроса отвечал за большую часть потребления ресурсов процессора базой данных.
В этом случае ИИ определил точную строку в коде (case-service/server.js:169), объяснил, почему индекс не мог быть использован, и порекомендовал наиболее эффективное исправление: триграммный индекс через расширение pg_trgm. Изменения в коде приложения не потребовались, достаточно было выполнить два SQL-запроса к базе данных:
Это означает, что индекс создается без блокировки таблицы, и в данном сценарии его можно было применить к работающей базе данных. После внедрения база данных может обрабатывать шаблон ILIKE, используя триграммный индекс вместо последовательного сканирования, и нагрузка на процессор базы данных снижается пропорционально объему поискового трафика. Простой пример неэффективного кодирования с огромным влиянием.
Почему это важно для ИИ-рабочих нагрузок
Пример приложения является моделью шаблона, который часто используется в организациях, создающих решения с помощью ИИ: многосервисная архитектура и проблема производительности, которая находится где-то в пространстве между кодом и инфраструктурой.
Это расследование стало быстрее не благодаря одной платформе, а благодаря связи между ними. Сервер Dynatrace MCP предоставил ИИ-агенту доступ к актуальным данным наблюдаемости: связям сущностей, методам сервисов, SQL-запросам, метрикам загрузки процессора процессами. Агент по написанию кода обеспечил чтение кода, логические выводы на разных уровнях и способность переводить телеметрию в конкретные пути к файлам и номера строк.
Вместе они сократили то, что могло бы стать многочасовым расследованием, до диалога, занявшего несколько минут.
Для организаций, пытающихся перевести ИИ-рабочие нагрузки из прототипа в продакшен, такая скорость — это не просто приятное дополнение. Это может стать разницей между успешным релизом и простоем.
С чего начать
Сервер Dynatrace MCP и доступны уже сегодня и предназначены для работы с любым совместимым ИИ-помощником. Вы можете подключить его к своей существующей среде Dynatrace и начать задавать вопросы о работающих системах на естественном языке. Это позволит вам:
- Обнаруживать, какие сервисы и запросы к базе данных вызывают наибольшие задержки
- Получать данные о загрузке процессора, памяти и ошибках на уровне процессов параллельно с вашим кодом
- Устраните разрыв между тем, что ваш ИИ видит в коде, и тем, что происходит в продакшене
- Переходите от симптома к исправлению быстрее. Для любой рабочей нагрузки, включая ИИ
Попробуйте Dynatrace MCP Server
