AI エージェントが最も頻繁な呼び出し元である場合の API 可観測性

API ダッシュボードには、午前 3 時にトラフィックが 4 倍に急増していることが表示されます。 マーケティングキャンペーンはありません。 製品の発売はありません。 ハッカーニュースはありません ポスト。 AI エージェントが MCP サーバーを通じてエンドポイントを検出し、複数段階のセキュリティの実行を開始しました 監査; DNS ルックアップ、SSL チェック、ヘッダー分析、15 のエンドポイントを 2 秒バーストで 10 分ごとに実行します。

今ではこれが普通です。 Gartner は、API 需要の伸びの 30% 以上が LLM を利用したエージェントから来ると予測しています。 2026 年。シスコの調査によると、組織の 89% がすでに実稼働環境でのエージェントの動作を監視していることがわかりました。 の 交通はここにあります。 問題は、あなたの可観測性スタックが人間と人間の違いを見分けられるかどうかです。 午前 3 時に 12 ステップのワークフローを実行するエンドポイントとエージェントをテストする開発者。

従来の APM ツールは、エンドポイントごとにメトリクスを集約します。 彼らはそれをあなたに示します /v1/dns/lookup 500を獲得しました 過去 1 時間にリクエストがあったが、そのうち 480 件が 40 回のエージェント実行によるものであり、それぞれが呼び出したものであることはわかりません。 DNS ルックアップ、SSL チェック、ヘッダー分析を予測可能な順序で実行します。 その盲点があなたに損害を与えます。 できません 適切なレート制限を設定すると、エージェントの障害をデバッグできず、インフラストラクチャのコストを予測できません。

これを解決するには 5 つのパターンがあります。 それぞれが、標準の APM が提供するものと、APM が提供するものとの間の特定のギャップに対処します。 エージェントが最も頻繁な発信者である場合に必要です。

従来の APM がエージェント トラフィックを見逃す理由

人間の開発者は、1 つのエンドポイントを呼び出し、応答を読み取り、おそらく数分後に別のエンドポイントを呼び出します。 AI エージェントは 5 ～ 15 のエンドポイントを立て続けに呼び出し、すべての応答をプログラムで解析し、再試行します。 失敗すると次のワークフローに進みます。 これら 2 つのトラフィック形状はエンドポイントごとに同一に見えます レベルは異なりますが、運用にとって重要なあらゆる面で動作が異なります。

Datadog、New Relic、Grafana は、エンドポイントごとのレイテンシーのパーセンタイルとエラー率を表示します。 彼らはそうではありません 「エージェント実行 #a3f7 が 8 つのツールを順番に呼び出し、ツール 6 で失敗し、4 回再試行して、焼き付けられたことを示します」 タスクを完了するには 35 回の API 呼び出しが必要で、8 回かかります。」 そのためには専用のトレースが必要です。

パターン 1: エージェントの発信者を検出する

エージェントのトラフィックを観察するには、そのトラフィックを識別する必要があります。 3 つの信号が連携して動作します。 ユーザー エージェント文字列、リクエスト ケイデンス、および明示的なヘッダー。

ユーザーとエージェントのマッチング

エージェント フレームワークは、識別可能なユーザー エージェント文字列を設定します。 LangChain、CrewAI、AutoGen、および Anthropic SDK すべてのデフォルトのヘッダーにフレームワーク名が含まれています。 次のようなライブラリからの SDK 生成リクエスト axios、 node-fetch、 そして python-requests 非ブラウザーにもシグナルを送信する 交通。

リクエストのケイデンス検出

人間は 5 秒以内に 4 つの異なるエンドポイントを呼び出すことはできません。 サーバー側のケイデンス検出器がクライアントにフラグを立てる 短いウィンドウ内で複数の一意のエンドポイントにヒットします。

完全な検出ミドルウェア

両方の信号をミドルウェアに結合し、すべてのリクエストにエージェントまたは人間としてタグ付けします。 このタグはに流れます ロギング、メトリクス、レート制限レイヤー:

の X-Agent-Detected 応答ヘッダーにより、エージェント開発者はリクエストが以下であることを確認できます。 正しく分類されていること。 信頼レベルはアラート ルールに反映されます。 「高い」自信 検出 (明示的なヘッダー) は決定的ですが、「中」 (UA 一致) はケイデンスの確認が必要な場合があります。

パターン 2: OpenTelemetry を使用してマルチツール チェーンをトレースする

ドメインを監査するために Botoi の MCP サーバーを呼び出すエージェントがヒットします /v1/dns/lookup、 それから /v1/ssl-cert/certificate、 それから /v1/headers 数秒以内に。 標準では APM、これらは 3 つの別々の無関係なリクエストです。 共有で X-Agent-Run-ID ヘッダー と OpenTelemetry スパンでは、それらは 1 つの追跡可能なワークフローになります。

各エージェント ワークフローは親スパンを取得します。 各ツール呼び出しは、その下にネストされた子スパンになります。 で Yeter、Grafana Tempo、またはその他の OTEL 互換バックエンドでは、完全なチェーンが表示されます。DNS ルックアップには 45 ミリ秒かかりました。 SSL チェックには 120 ミリ秒、ヘッダーには 30 ミリ秒、合計ワークフロー時間は 210 ミリ秒かかりました。 ツール 6/8 が失敗し、 エージェントが 4 回再試行すると、個別のエンドポイント ログを探すのではなく、トレースにそれが表示されます。

パターン 3: バースト性ワークロードのレート制限

固定ウィンドウのレート制限によりエージェントが罰せられます。 エージェントは 2 秒間に 15 個のリクエストを送信して、 ワークフローが終了すると、58 秒間沈黙します。 「1 分あたり 60 リクエスト」の固定ウィンドウには十分な量があります ただし、「5 秒あたり 5 リクエスト」という固定ウィンドウにより、リクエスト 6 でエージェントがブロックされます。 ただし、持続速度は制限を大幅に下回っています。

トークンバケットはこれを解決します。 バケットの容量により、バースト サイズ (エージェントが送信できるリクエストの数) が制御されます。 バーストで発射）、補充速度は持続的なスループット（バケットがどれだけ速く回復するか）を制御します。 エージェントの動作方法にマップする 2 つのパラメーター。

重要な洞察: エージェントはより高いバースト容量と同等の持続速度を必要とします。 人間のユーザー 5 トークン バケットと 0.5 トークン/秒の補充レートを使用すると、5 つのクイック リクエストを実行し、その後 1 回ごとに 1 つを実行できます。 2秒。 20 トークン バケットと 2 トークン/秒の補充を持つエージェントは、15 エンドポイント ワークフローを起動できます 1 回のバーストでバケットを再充填し、10 秒後に次の実行に備えます。

これが、botoi の API が混合トラフィックを処理する方法です。 匿名リクエスト (API キーなし) は 5 リクエスト/分のバーストを取得します 1 日あたり 100 リクエストの上限があり、IP によって追跡されます。 有料プランの認証済みリクエストは Unkey のトークン バケットを使用します エッジでは、階層ごとのバースト制限と持続制限が高くなります。

パターン 4: 相関ヘッダーを使用したログツール使用コンテキスト

へのリクエスト /v1/dns/lookup 単独では、意図については何もわかりません。 と同じリクエスト 8 段階のセキュリティ監査のステップ 1 ですべてがわかります。 相関ヘッダーはこのギャップを埋めます。

2 つのヘッダーには、必要なすべてのコンテキストが含まれています。

• X-Agent-Run-ID: すべてのリクエストを単一のワークフローにグループ化する UUID
• X-Agent-Tool-Index: ツールチェーン内のこの呼び出しの位置 (1、2、3...)

クライアント側では、エージェントは両方のヘッダーをワークフロー内のすべてのリクエストに添付します。

サーバー側では、リクエストごとに両方のヘッダーをログに記録します。 エージェントが行ったことを再構築すると、 単一のクエリ: 「すべてのリクエストを表示する」 X-Agent-Run-ID = abc-123 によって注文されました X-Agent-Tool-Index." タイムスタンプの相関関係、IP の一致、推測は必要ありません。

エージェントが botoi の MCP サーバーを使用している場合、MCP プロトコルはすでにツール呼び出しをセッションにグループ化しています。 の MCP サーバー: api.botoi.com/mcp ヘッダーを介して API キーを転送し、拡張することができます これを使用して、利用可能な 49 個のツールすべてにわたって持続する実行 ID を渡します。

パターン 5: エージェント固有の異常に関するアラート

標準アラートは、HTTP エラー率と遅延パーセンタイルに応じて起動されます。 エージェント固有のアラートが発生する API ではなくエージェント自体に問題があることを示す動作パターン。

3 つのアラート タイプは、最も一般的なエージェントの障害をキャッチします。

• 予期しないツールの順序: エージェントが DNS ルックアップの前に SSL チェックを呼び出し、エージェントの計画ステップに論理的なバグがあることを示唆しています
• 再試行ループが検出されました: 1 回のエージェント実行で、同じエンドポイントが 10 秒間に 5 回以上ヒットしました。これは、エージェントがエラー応答を読み取っていないことを示しています。
• コストの高騰: エージェントの実行が 50 API 呼び出しを超えました。ループまたは幻覚が暴走した消費を引き起こしていることを意味します

再試行ループ アラートは、最も価値の高いシグナルです。 エージェントが 400 エラー (不正な入力) を受け取り、 同じリクエストを 20 回再試行すると、レート制限を超えてしまい、有用な出力が生成されません。 キャッチング これを数分ではなく数秒で行うことで、インフラストラクチャの予算とエージェントのオペレーターの両方を節約できます。 API クォータ。

まとめ: 混合トラフィックの可観測性スタック

以下は 5 つのパターンすべてをカバーするスタックです。

API として Datadog または Grafana をすでに実行している場合は、それらを置き換える必要はありません。 を追加します。 最上位の OTEL インストルメンテーション層、エージェントタグ付きトレースを専用ダッシュボードにパイプします。 エージェント固有の属性に基づいてアラート ルールを構築します。 既存のエンドポイントごとのメトリクスはそのまま残ります インフラストラクチャの監視に役立ちます。 新しいエージェント対応トレースは、あなたの質問に答えます。 オンコール エンジニアは午前 3 時に尋ねます。「このエージェントは何をしているのか、なぜ再試行するのか、私はどうすればよいでしょうか」 ブロックしますか？」

重要なポイント

• 最初に検出し、次に観察します。 すべてのリクエストをエージェントまたは人間としてタグ付けします。 ユーザー エージェント パターン、ケイデンス検出、および明示的なヘッダー。 すべては下流に依存します この分類について。
• エンドポイントではなく、ワークフローをトレースします。 エージェントの作業単位はマルチツールです 単一の API 呼び出しではなくチェーンです。 OpenTelemetry の親/子スパンによるエージェント ワークフローの作成 トレース バックエンドのファーストクラス オブジェクト。
• 固定ウィンドウ上のトークン バケット。 エージェントが爆発した。 トークンバケットはバーストに対応します 持続的な制限を強制しながら。 バケットの容量を、予想される最長のツール チェーンに合わせます。
• 相関ヘッダーは安価で強力です。 X-Agent-Run-ID そして X-Agent-Tool-Index 不透明なリクエストログを読み取り可能なエージェントワークフローに変える 単一のデータベースクエリで実行できます。
• 音量ではなく動作について警告します。 再試行ループ、予期しないツールの順序、および 暴走通話数により、実際の問題がインシデントになる前に検出されます。

Botoi's API handles both human and agent traffic across 150+ endpoints and a 49-tool MCP server. すべての応答には以下が含まれます X-RateLimit ヘッダー。 を呼び出すエージェントを構築している場合 外部 API を渡す場合は、 X-Agent-Run-ID ヘッダー、レート制限ヘッダーを尊重し、 give your API provider the signals they need to keep your agent running smoothly. 試してみてください インタラクティブ API ドキュメント または、AI アシスタントを経由して接続します。 MCPサーバー 見る 実際にはこれらのパターン。