Наблюдение за API, когда агенты ИИ чаще всего обращаются к вам
Gartner сообщает, что 30% нового трафика API поступает от LLM. Пять шаблонов наблюдения для обнаружения вызывающих агентов, отслеживания цепочек использования инструментов и установки ограничений скорости, соответствующих пакетным нагрузкам.
Ваша панель API показывает четырехкратный всплеск трафика в 3 часа ночи. Никакой маркетинговой кампании. Никакого запуска продукта. Никаких хакерских новостей пост. Агент ИИ обнаружил ваши конечные точки через ваш сервер MCP и запустил многоступенчатую систему безопасности. аудиты; Поиск DNS, проверки SSL, анализ заголовков, 15 конечных точек в двухсекундных пакетах каждые 10 минут.
Сейчас это нормально. Gartner прогнозирует, что 30% или более роста спроса на API будет приходиться на агентов, работающих на базе LLM. 2026. Опрос Cisco показал, что 89% организаций уже отслеживают поведение агентов на производстве. трафик здесь. Вопрос в том, сможет ли ваш стек наблюдения отличить человека от разработчик тестирует конечную точку и агента, выполняющего 12-шаговый рабочий процесс в 3 часа ночи.
Традиционные инструменты APM агрегируют показатели для каждой конечной точки. Они показывают вам это /v1/dns/lookup получил 500
запросов за последний час, но они не скажут вам, что 480 из них поступили от 40 агентов, каждый из которых звонил
Поиск DNS, проверка SSL и анализ заголовков в предсказуемой последовательности. Это слепое пятно дорого вам обходится; ты не можешь
установите соответствующие ограничения скорости, вы не сможете устранять сбои агентов и не можете прогнозировать затраты на инфраструктуру.
Пять шаблонов исправят это. Каждый из них устраняет определенный разрыв между тем, что обеспечивает стандартный APM, и тем, что вы необходимость, когда агенты вам чаще всего звонят.
Почему традиционный APM пропускает агентский трафик
Разработчик-человек вызывает одну конечную точку, читает ответ и, возможно, через несколько минут вызывает другую. Агент ИИ вызывает от 5 до 15 конечных точек в быстрой последовательности, программно анализирует каждый ответ, повторяет попытки. в случае сбоя и переходит к следующему рабочему процессу. Эти две формы трафика выглядят одинаково для каждой конечной точки. уровне, но ведут себя по-разному во всех отношениях, которые важны для операций.
| Измерение | Человеческий трафик | Агентский трафик |
|---|---|---|
| Запросить частоту вращения | 1-3 запроса в минуту, длинные паузы | 5-15 запросов за 2 секунды, потом простое |
| Разнообразие конечных точек | 1-2 конечных точки за сеанс | 5–12 конечных точек на рабочий процесс |
| Повторить попытку | Повторная попытка вручную после ошибки чтения | Немедленная повторная попытка, экспоненциальная отсрочка, если закодировано |
| Время суток | Часы работы с учетом часового пояса | Круглосуточно, 7 дней в неделю, часто срабатывает по cron в неурочные часы |
| Обработка ошибок | Читает сообщение об ошибке, корректирует запрос | Повторяет тот же запрос или переходит к следующему инструменту |
| Продолжительность сеанса | От минут до часов | 2–30 секунд на рабочий процесс |
Datadog, New Relic и Grafana показывают процентили задержки для каждой конечной точки и частоту ошибок. Они не покажем вам: «Запуск агента #a3f7 последовательно вызвал 8 инструментов, произошел сбой на инструменте 6, повторил попытку 4 раза и сжег через 35 вызовов API для выполнения задачи, которая должна занять 8». Для этого вам нужна специально созданная трассировка.
Такие платформы, как Лангфус, Аризе Феникс, Мозговой трест, и Геликон специализируются на наблюдаемости агентов. Они отслеживают цепочки использования инструментов, токены потребление и пути принятия решений агентом. OpenTelemetry (OTEL) становится стандартной телеметрией формат, который соединяет эти платформы с существующей инфраструктурой.
Схема 1: обнаружение вызывающих агентов
Прежде чем вы сможете наблюдать трафик агента, вам необходимо его идентифицировать. Три сигнала работают вместе: Строки User-Agent, частота запросов и явные заголовки.
Сопоставление пользовательского агента
Платформы агентов устанавливают идентифицируемые строки User-Agent. LangChain, CrewAI, AutoGen и Anthropic SDK
все они включают имена фреймворков в заголовки по умолчанию. Сгенерированные SDK запросы из таких библиотек, как
axios, node-fetch, и python-requests также сигнализировать о небраузерности
трафик.
Запросить определение частоты вращения педалей
Люди не вызывают 4 разных конечных точки в течение 5 секунд. Детектор частоты кадров на стороне сервера помечает клиентов которые достигают нескольких уникальных конечных точек за короткое окно:
Промежуточное программное обеспечение полного обнаружения
Объедините оба сигнала в промежуточное программное обеспечение, которое помечает каждый запрос как агент или человек. Этот тег переходит в ваши уровни журналирования, метрик и ограничения скорости:
The X-Agent-Detected заголовок ответа позволяет разработчикам агентов подтвердить, что их запросы
классифицируются правильно. Уровни достоверности учитываются в ваших правилах оповещения; «высокая» уверенность
обнаружение (явный заголовок) является окончательным, тогда как для «среднего» (соответствие UA) может потребоваться подтверждение каденции.
Схема 2: отслеживание цепочек нескольких инструментов с помощью OpenTelemetry
Агент, вызывающий MCP-сервер Ботои для проверки домена, попадет /v1/dns/lookup, затем
/v1/ssl-cert/certificate, затем /v1/headers в течение нескольких секунд. В стандарте
APM, это три отдельных, не связанных друг с другом запроса. С общим X-Agent-Run-ID заголовок
и OpenTelemetry, они становятся одним отслеживаемым рабочим процессом.
Каждый рабочий процесс агента получает родительский диапазон. Каждый вызов инструмента становится вложенным в него дочерним диапазоном. В Jaeger, Grafana Tempo или любой другой OTEL-совместимый бэкэнд, вы увидите полную цепочку: поиск DNS занял 45 мс, Проверка SSL заняла 120 мс, заголовков — 30 мс, общее время рабочего процесса — 210 мс. Когда инструмент 6 из 8 выходит из строя и агент повторяет попытку 4 раза, вы видите это в трассировке вместо поиска в отдельных журналах конечных точек.
The agent.tool_index атрибут в каждом диапазоне позволяет восстановить точный порядок
операции. Это имеет значение при отладке: «почему агент вызвал проверку SSL перед поиском DNS?»
становится наглядной трассировкой вместо упражнения по корреляции журналов.
Схема 3: ограничение скорости для пакетных рабочих нагрузок
Ограничение скорости фиксированного окна наказывает агентов. Агент отправляет 15 запросов за 2 секунды для выполнения рабочий процесс, затем замолкает на 58 секунд. Фиксированного окна «60 запросов в минуту» вполне достаточно. места, но фиксированное окно «5 запросов в 5 секунд» блокирует агента по запросу 6, даже хотя устойчивый уровень значительно ниже предела.
Token Bucket решает эту проблему. Емкость сегмента определяет размер пакета (сколько запросов может выполнить агент). огонь очередью), а скорость пополнения контролирует постоянную пропускную способность (насколько быстро ведро восстанавливается). Два параметра, которые определяют, как работают агенты.
Ключевой вывод: агентам необходима более высокая пакетная мощность и сопоставимая устойчивая скорость. Пользователь-человек с корзиной на 5 токенов и скоростью пополнения 0,5 токенов в секунду можно сделать 5 быстрых запросов, а затем по одному каждый раз 2 секунды. Агент с корзиной на 20 токенов и пополнением 2 токенов в секунду может запустить рабочий процесс с 15 конечными точками. за один раз и наполните ведро для следующего запуска через 10 секунд.
Вот как API botoi обрабатывает смешанный трафик. Анонимные запросы (без ключа API) получают пакетную скорость 5 запросов в минуту. с ограничением 100 запросов в день, отслеживаемым по IP. Аутентифицированные запросы на платных планах используют корзину токенов Unkey. на границе с более высокими взрывными и устойчивыми ограничениями на уровень.
Шаблон 4: протоколирование контекста использования инструмента с корреляционными заголовками
Просьба к /v1/dns/lookup изолированно ничего не говорит вам о намерении. Тот же запрос, что и
Шаг 1 восьмиэтапного аудита безопасности расскажет вам все. Заголовки корреляции устраняют этот пробел.
Два заголовка содержат весь необходимый вам контекст:
X-Agent-Run-ID: UUID, который группирует все запросы в одном рабочем процессе.X-Agent-Tool-Index: позиция этого вызова в цепочке инструментов (1, 2, 3...)
На стороне клиента агент присоединяет оба заголовка к каждому запросу в рабочем процессе:
На стороне сервера вы регистрируете оба заголовка при каждом запросе. Реконструкция того, что сделал агент, становится
один запрос: «покажи мне все запросы с X-Agent-Run-ID = abc-123 по заказу
X-Agent-Tool-IndexНикакой корреляции временных меток, никакого сопоставления IP-адресов, никаких догадок.
Если ваши агенты используют сервер MCP Botoi, протокол MCP уже группирует вызовы инструментов в сеансы.
MCP-сервер по адресу api.botoi.com/mcp пересылает ключ API через заголовки, и вы можете расширить
ему необходимо передать идентификатор запуска, который сохраняется во всех 49 доступных инструментах.
Схема 5: оповещение об аномалиях, характерных для агента
Стандартные оповещения срабатывают в зависимости от частоты ошибок HTTP и процентилей задержки. Оповещения для конкретного агента срабатывают шаблоны поведения, которые указывают на то, что что-то не так с самим агентом, а не с вашим API.
Три типа оповещений фиксируют наиболее распространенные сбои агентов:
- Неожиданный заказ инструмента: агент вызвал проверку SSL перед поиском DNS, что указывает на логическую ошибку на этапе планирования агента
- Обнаружен цикл повтора: одна и та же конечная точка была поражена 5 или более раз за 10 секунд при одном запуске агента, что указывает на то, что агент не читает ответы об ошибках.
- Пик стоимости: запуск агента превысил 50 вызовов API, что означает, что цикл или галлюцинация приводят к безудержному потреблению
Предупреждение о повторной попытке является сигналом наивысшего значения. Агент, который получает ошибку 400 (неправильный ввод) и повторение одного и того же запроса 20 раз приводит к превышению ограничений скорости и не дает никакого полезного результата. Ловля это за секунды, а не за минуты, экономит как ваш бюджет на инфраструктуру, так и оператор-агент Квота API.
Собираем все вместе: стек наблюдаемости для смешанного трафика
Вот стек, охватывающий все пять шаблонов:
| Слой | Инструмент | Что это дает |
|---|---|---|
| Обнаружение агента | Пользовательское промежуточное ПО (шаблон 1) | Отмечает каждый запрос как агента или человека |
| Распределенная трассировка | OpenTelemetry + Jaeger или Grafana Tempo | Связывает цепочки нескольких инструментов в единые следы |
| Ограничение скорости | Корзина токенов (шаблон 3) | Максимальные лимиты для каждого типа вызывающего абонента |
| Телеметрия агента | Лангфузе, Аризе Феникс или Геликон | Использование токенов, цепочки инструментов, пути принятия решений агентами |
| Оповещение | Пользовательские правила для данных трассировки (шаблон 5) | Отлавливает циклы повторов, неожиданные последовательности и скачки затрат. |
Если вы уже используете Datadog или Grafana для своего API, вам не нужно их заменять. Добавьте Уровень инструментов OTEL сверху, трассировки с тегами агента передаются на специальную панель мониторинга и создавать правила оповещений на основе атрибутов, специфичных для агента. Существующие метрики для каждой конечной точки остаются полезен для мониторинга инфраструктуры. Новые трассировки с поддержкой агентов отвечают на ваши вопросы. дежурный инженер спрашивает в 3 часа ночи: «Что делает этот агент, почему он повторяет попытку и должен ли я заблокировать?"
Ключевые выводы
- Сначала обнаружьте, затем наблюдайте. Помечайте каждый запрос как агент или человек, использующий Шаблоны User-Agent, обнаружение каденции и явные заголовки. Все, что происходит дальше, зависит по этой классификации.
- Отслеживайте рабочие процессы, а не конечные точки. Единица работы агента – это мультиинструмент. цепочка, ни одного вызова API. Родительские и дочерние диапазоны OpenTelemetry создают рабочие процессы агента. первоклассные объекты в вашей системе трассировки.
- Корзина токенов в фиксированном окне. Агенты взорвались. Корзина токенов вмещает всплески соблюдая при этом устойчивые ограничения. Подберите емкость ковша к самой длинной ожидаемой цепочке инструментов.
-
Заголовки корреляции дешевы и эффективны.
X-Agent-Run-IDиX-Agent-Tool-Indexпревратить непрозрачные журналы запросов в читаемые рабочие процессы агента с помощью одного запроса к базе данных. - Оповещение о поведении, а не о громкости. Циклы повторов, неожиданный порядок инструментов и подсчет неконтролируемых вызовов выявляет реальные проблемы до того, как они станут инцидентами.
API Botoi обрабатывает как человеческий, так и агентский трафик через более чем 150 конечных точек и сервер MCP с 49 инструментами.
Каждый ответ включает в себя X-RateLimit заголовки. Если вы создаете агента, который звонит
внешние API, передайте X-Agent-Run-ID заголовок, соблюдайте заголовки ограничения скорости и
дайте своему провайдеру API сигналы, необходимые для бесперебойной работы вашего агента. Попробуйте
интерактивная документация API
или подключите своего AI-помощника через
MCP-сервер видеть
эти закономерности на практике.
FAQ
- Как узнать, вызывает ли агент ИИ мой API?
- Ищите три сигнала: строки User-Agent, содержащие имена инфраструктур агентов (langchain, Creupai, Autogen), шаблоны пакетных запросов, в которых от 5 до 15 конечных точек вызываются в быстрой последовательности с интервалами в доли секунды, и корреляционные заголовки, такие как X-Session-ID или X-Agent-Run-ID. Вы также можете проверить последовательность использования инструментов, при которой поиск DNS, SSL и заголовков происходит в предсказуемом порядке в течение нескольких секунд.
- Почему традиционный APM пропускает трафик агента ИИ?
- Традиционные инструменты APM агрегируют показатели для каждой конечной точки. Шаблоны трафика агента охватывают несколько конечных точек в рамках одной логической операции. Агент аудита безопасности, вызывающий поиск DNS, затем проверку SSL, а затем анализ заголовка за 2 секунды, выглядит как три несвязанных запроса в Datadog или New Relic. Вам нужна распределенная трассировка с общим идентификатором корреляции, чтобы связать эти вызовы в один рабочий процесс агента.
- Какой алгоритм ограничения скорости для трафика агента ИИ является лучшим?
- Корзина токенов лучше всего подходит для рабочих нагрузок агентов. Агенты отправляют пакеты от 5 до 15 запросов в течение нескольких секунд, а затем бездействуют. Корзина токенов позволяет контролировать всплески до предела емкости, обеспечивая при этом постоянную скорость пополнения. Исправлены нарушения ограничения частоты окон, поскольку агент может исчерпать полный лимит окна за 2 секунды, а затем бездействовать в течение 58 секунд.
- Как отслеживать многоэтапный рабочий процесс агента ИИ при вызовах API?
- Пусть агент отправляет заголовок X-Agent-Run-ID с каждым запросом в рабочем процессе. На стороне сервера создайте родительский диапазон OpenTelemetry для каждого уникального идентификатора запуска и вложите под него отдельные диапазоны конечных точек. Это дает вам единое представление трассировки, показывающее, что поиск DNS занял 45 мс, проверка SSL — 120 мс, а заголовки — 30 мс, и все это в рамках одного рабочего процесса агента.
- Должен ли я установить разные ограничения скорости для агентов ИИ и пользователей-людей?
- Да. Пользователи-люди делают от 1 до 3 запросов в минуту с длительными паузами между ними. Агенты делают от 5 до 15 запросов в течение 2 секунд, а затем ничего не делают в течение нескольких минут. Фиксированное окно с поминутной оплатой несправедливо наказывает агентов. Используйте корзину токенов с более высокой пакетной емкостью (например, 20 запросов) и более низкой постоянной скоростью (например, 5 токенов в секунду), чтобы агенты могли выполнять рабочие процессы, не допуская ошибок 429.
Начните разработку с botoi
150+ API-эндпоинтов для поиска, обработки текста, генерации изображений и утилит для разработчиков. Бесплатный тариф, без банковской карты.