API-Beobachtbarkeit, wenn KI-Agenten Ihre häufigsten Anrufer sind

Ihr API-Dashboard zeigt um 3 Uhr morgens eine 4-fache Traffic-Spitze. Keine Marketingkampagne. Keine Produkteinführung. Keine Hacker-News Beitrag. Ein KI-Agent hat Ihre Endpunkte über Ihren MCP-Server entdeckt und mit der Ausführung einer mehrstufigen Sicherheit begonnen Audits; DNS-Suchen, SSL-Prüfungen, Header-Analyse, 15 Endpunkte in 2-Sekunden-Bursts, alle 10 Minuten.

Das ist jetzt normal. Gartner prognostiziert, dass 30 % oder mehr des API-Nachfragewachstums von LLM-basierten Agenten ausgehen werden 2026. Eine Umfrage von Cisco ergab, dass 89 % der Unternehmen bereits das Agentenverhalten in der Produktion überwachen. Die Der Verkehr ist hier. Die Frage ist, ob Ihr Observability Stack den Unterschied zwischen einem Menschen erkennen kann Entwickler testet einen Endpunkt und ein Agent führt um 3 Uhr morgens einen 12-Schritte-Workflow aus.

Herkömmliche APM-Tools aggregieren Metriken pro Endpunkt. Das zeigen sie dir /v1/dns/lookup Habe 500 Anfragen in der letzten Stunde, aber sie werden Ihnen nicht sagen, dass 480 davon von 40 Agentenläufen stammten, von denen jeder anrief DNS-Suche, SSL-Prüfung und Header-Analyse in einer vorhersehbaren Reihenfolge. Dieser blinde Fleck kostet Sie; Du kannst nicht Wenn Sie geeignete Ratengrenzen festlegen, können Sie Agentenausfälle nicht debuggen und Infrastrukturkosten nicht vorhersagen.

Fünf Muster beheben dieses Problem. Jedes davon behebt eine spezifische Lücke zwischen dem, was Standard-APM bietet, und dem, was Sie bieten brauchen, wenn Agenten Ihre häufigsten Anrufer sind.

Warum dem herkömmlichen APM der Agentenverkehr entgeht

Ein menschlicher Entwickler ruft einen Endpunkt auf, liest die Antwort und ruft möglicherweise ein paar Minuten später einen anderen auf. Ein KI-Agent ruft in schneller Folge 5 bis 15 Endpunkte an, analysiert jede Antwort programmgesteuert und versucht es erneut Bei einem Fehler wird mit dem nächsten Workflow fortgefahren. Diese beiden Verkehrsformen sehen am Endpunkt identisch aus verhalten sich jedoch in jeder für den Betrieb wichtigen Hinsicht anders.

Datadog, New Relic und Grafana zeigen Ihnen Latenzperzentile und Fehlerraten pro Endpunkt. Das tun sie nicht zeige dir: „Agent-Lauf #a3f7 hat 8 Tools nacheinander aufgerufen, ist bei Tool 6 fehlgeschlagen, hat es viermal erneut versucht und ist gebrannt.“ durch 35 API-Aufrufe, um eine Aufgabe abzuschließen, die 8 dauern sollte. Dafür benötigen Sie eine speziell entwickelte Ablaufverfolgung.

Muster 1: Agentenanrufer erkennen

Bevor Sie den Agentenverkehr beobachten können, müssen Sie ihn identifizieren. Drei Signale wirken zusammen: User-Agent-Strings, Anforderungsrhythmus und explizite Header.

User-Agent-Matching

Agent-Frameworks legen identifizierbare Benutzer-Agent-Zeichenfolgen fest. LangChain, CrewAI, AutoGen und das Anthropic SDK Alle enthalten Framework-Namen in ihren Standardheadern. SDK-generierte Anfragen von Bibliotheken wie axios, node-fetch, Und python-requests auch Nicht-Browser signalisieren Verkehr.

Trittfrequenzerkennung anfordern

Menschen rufen nicht innerhalb von 5 Sekunden 4 verschiedene Endpunkte an. Ein serverseitiger Trittfrequenzdetektor markiert Clients die in einem kurzen Zeitfenster mehrere eindeutige Endpunkte treffen:

Vollständige Erkennungs-Middleware

Kombinieren Sie beide Signale in einer Middleware, die jede Anfrage als Agent oder Mensch markiert. Dieses Tag fließt hinein Ihre Protokollierungs-, Metrik- und Ratenbegrenzungsebenen:

Der X-Agent-Detected Mit dem Antwortheader können Agentenentwickler bestätigen, dass ihre Anfragen vorliegen richtig klassifiziert werden. Die Konfidenzniveaus fließen in Ihre Alarmierungsregeln ein; ein „hohes“ Vertrauen Die Erkennung (expliziter Header) ist definitiv, während „Medium“ (UA-Übereinstimmung) möglicherweise eine Bestätigung der Kadenz erfordert.

Muster 2: Multi-Tool-Ketten mit OpenTelemetry verfolgen

Ein Agent, der den MCP-Server von botoi anruft, um eine Domäne zu prüfen, wird getroffen /v1/dns/lookup, Dann /v1/ssl-cert/certificate, Dann /v1/headers innerhalb von Sekunden. Im Standard APM, das sind drei separate, nicht zusammenhängende Anfragen. Mit einem geteilten X-Agent-Run-ID Kopfzeile und OpenTelemetry-Bereiche werden zu einem nachvollziehbaren Workflow.

Jeder Agent-Workflow erhält einen übergeordneten Bereich. Jeder Tool-Aufruf wird zu einem untergeordneten Bereich, der darunter verschachtelt ist. In Jaeger, Grafana Tempo oder ein beliebiges OTEL-kompatibles Backend, Sie sehen die vollständige Kette: Die DNS-Suche dauerte 45 ms, Die SSL-Prüfung dauerte 120 ms, die Header benötigten 30 ms und die gesamte Workflow-Zeit 210 ms. Wenn Werkzeug 6 von 8 ausfällt und das Wenn der Agent es viermal wiederholt, sehen Sie es im Trace, anstatt separate Endpunktprotokolle zu durchsuchen.

Muster 3: Ratenbegrenzung für stoßartige Arbeitslasten

Eine Ratenbegrenzung mit festem Fenster bestraft Agenten. Ein Agent sendet in 2 Sekunden 15 Anfragen, um a abzuschließen Workflow, dann wird für 58 Sekunden stumm geschaltet. Ein festes Fenster von „60 Anfragen pro Minute“ reicht aus Platz, aber ein festes Fenster von „5 Anfragen pro 5 Sekunden“ blockiert den Agenten bei Anfrage sogar 6 obwohl die Dauerrate deutlich unter dem Grenzwert liegt.

Der Token-Bucket löst dieses Problem. Die Bucket-Kapazität steuert die Burst-Größe (wie viele Anfragen ein Agent bearbeiten kann). Feuer in einem Feuerstoß), und die Nachfüllrate steuert den anhaltenden Durchsatz (wie schnell sich der Eimer erholt). Zwei Parameter, die sich auf die Arbeitsweise von Agenten auswirken.

Die wichtigste Erkenntnis: Agenten benötigen eine höhere Burst-Kapazität und eine vergleichbare Dauerrate. Ein menschlicher Benutzer Mit einem 5-Token-Eimer und einer Nachfüllrate von 0,5 Token/Sekunde können 5 schnelle Anfragen gestellt werden und dann jeweils eine 2 Sekunden. Ein Agent mit einem 20-Token-Bucket und 2 Tokens/Sekunde Nachfüllung kann einen Workflow mit 15 Endpunkten auslösen in einem Durchgang und lassen Sie den Eimer 10 Sekunden später für den nächsten Lauf wieder auffüllen.

So geht die API von botoi mit gemischtem Datenverkehr um. Anonyme Anfragen (kein API-Schlüssel) erhalten einen Burst von 5 Anforderungen/Minute mit einer Obergrenze von 100 Anforderungen/Tag, nach IP verfolgt. Authentifizierte Anfragen bei kostenpflichtigen Plänen verwenden den Token-Bucket von Unkey am Rand mit höheren Burst- und Dauerlimits pro Stufe.

Muster 4: Tool-Nutzungskontext mit Korrelationsheadern protokollieren

Eine Bitte an /v1/dns/lookup isoliert sagt Ihnen nichts über die Absicht. Die gleiche Anfrage wie Schritt 1 eines 8-stufigen Sicherheitsaudits sagt Ihnen alles. Korrelationsheader schließen diese Lücke.

Zwei Header enthalten den gesamten Kontext, den Sie benötigen:

• X-Agent-Run-ID: eine UUID, die alle Anfragen in einem einzigen Workflow gruppiert
• X-Agent-Tool-Index: die Position dieses Aufrufs in der Toolkette (1, 2, 3...)

Auf der Clientseite hängt der Agent beide Header an jede Anfrage in einem Workflow an:

Auf der Serverseite protokollieren Sie bei jeder Anfrage beide Header. Die Rekonstruktion dessen, was ein Agent getan hat, wird eine einzelne Abfrage: „Zeige mir alle Anfragen mit X-Agent-Run-ID = abc-123 bestellt von X-Agent-Tool-Index.“ Keine Zeitstempelkorrelation, kein IP-Abgleich, kein Rätselraten.

Wenn Ihre Agenten den MCP-Server von botoi verwenden, gruppiert das MCP-Protokoll Toolaufrufe bereits in Sitzungen. Die MCP-Server unter api.botoi.com/mcp leitet den API-Schlüssel über Header weiter, und Sie können ihn erweitern Es ermöglicht die Übergabe einer Lauf-ID, die für alle 49 verfügbaren Tools bestehen bleibt.

Muster 5: Warnung bei agentenspezifischen Anomalien

Standardwarnungen werden bei HTTP-Fehlerraten und Latenzperzentilen ausgelöst. Agentenspezifische Warnungen werden ausgelöst Verhaltensmuster, die darauf hinweisen, dass etwas mit dem Agenten selbst und nicht mit Ihrer API nicht stimmt.

Drei Alarmtypen fangen die häufigsten Agentenausfälle ab:

• Unerwartete Werkzeugreihenfolge: Ein Agent namens „SSL-Prüfung vor DNS-Suche“, was auf einen logischen Fehler im Planungsschritt des Agenten hindeutet
• Wiederholungsschleife erkannt: Derselbe Endpunkt wurde bei einer Agentenausführung innerhalb von 10 Sekunden fünfmal oder öfter getroffen, was darauf hindeutet, dass der Agent keine Fehlerantworten liest
• Kostenspitze: Bei einem Agentenlauf wurden mehr als 50 API-Aufrufe ausgeführt, was bedeutet, dass eine Schleife oder Halluzination zu einem außer Kontrolle geratenen Verbrauch führt

Die Wiederholungsschleifenwarnung ist das Signal mit dem höchsten Wert. Ein Agent, der einen 400-Fehler (fehlerhafte Eingabe) erhält und Wiederholt die gleiche Anfrage 20 Mal, überschreitet die Geschwindigkeitsbegrenzungen und erzeugt keine brauchbare Ausgabe. Fangen Dies geschieht in Sekunden statt in Minuten und schont sowohl Ihr Infrastrukturbudget als auch das des Agentenbetreibers API-Kontingent.

Zusammengefasst: ein Observability Stack für gemischten Verkehr

Hier ist der Stapel, der alle fünf Muster abdeckt:

Wenn Sie Datadog oder Grafana bereits für Ihre API ausführen, müssen Sie diese nicht ersetzen. Fügen Sie die hinzu OTEL-Instrumentierungsebene oben, mit Agenten markierte Spuren an ein spezielles Dashboard weiterleiten und Erstellen Sie Warnregeln für die agentenspezifischen Attribute. Die vorhandenen Endpunktmetriken bleiben erhalten nützlich für die Infrastrukturüberwachung. Die neuen agentenbewussten Traces beantworten Ihre Fragen Der Bereitschaftstechniker fragt um 3 Uhr morgens: „Was macht dieser Agent, warum versucht er es noch einmal und sollte ich?“ blockieren?"

Wichtige Erkenntnisse

• Zuerst erkennen, dann beobachten. Kennzeichnen Sie jede Anfrage als Agent oder Mensch User-Agent-Muster, Trittfrequenzerkennung und explizite Header. Alles stromabwärts hängt davon ab zu dieser Klassifizierung.
• Verfolgen Sie Arbeitsabläufe, nicht Endpunkte. Die Arbeitseinheit eines Agenten ist ein Multitool Kette, kein einziger API-Aufruf. Übergeordnete/untergeordnete OpenTelemetry-Spans ermöglichen Agenten-Workflows erstklassige Objekte in Ihrem Tracing-Backend.
• Token-Bucket über festem Fenster. Agenten platzen. Der Token-Bucket nimmt Bursts auf bei gleichzeitiger Durchsetzung nachhaltiger Grenzen. Passen Sie die Schaufelkapazität an Ihre längste erwartete Werkzeugkette an.
• Korrelationsheader sind kostengünstig und leistungsstark. X-Agent-Run-ID Und X-Agent-Tool-Index Verwandeln Sie undurchsichtige Anforderungsprotokolle in lesbare Agenten-Workflows mit einer einzigen Datenbankabfrage.
• Warnung nach Verhalten, nicht nach Lautstärke. Wiederholungsschleifen, unerwartete Werkzeugreihenfolge usw Runaway Call Counts erkennen echte Probleme, bevor sie zu Zwischenfällen werden.

Die API von Botoi verarbeitet sowohl den menschlichen als auch den Agentenverkehr über mehr als 150 Endpunkte und einen MCP-Server mit 49 Tools. Jede Antwort beinhaltet X-RateLimit Kopfzeilen. Wenn Sie einen Agenten aufbauen, der anruft Externe APIs, übergeben Sie an X-Agent-Run-ID Beachten Sie die Ratenbegrenzungsheader und Geben Sie Ihrem API-Anbieter die Signale, die er benötigt, damit Ihr Agent reibungslos läuft. Probieren Sie es aus interaktive API-Dokumente oder verbinden Sie Ihren KI-Assistenten über das MCP-Server zu sehen diese Muster in der Praxis.