Latency Monitoring fuer Agenten

Idee in 30 Sekunden

Latency monitoring fuer KI-Agenten zeigt, wo das System langsamer wird: in LLM-Schritten, Tools, Queues oder wiederholten Iterationen.

Ohne das ist schwer zu verstehen, warum Nutzer laenger warten, auch wenn der Run formal erfolgreich endet.

Hauptproblem

Ein Run kann korrekt enden, aber fuer Production zu langsam sein.

Zwei Anfragen mit derselben Antwort koennen unterschiedliche latency haben: wegen laengerer reasoning-Kette, langsamem Tool oder retries. Ohne latency monitoring sieht man das meist erst nach Nutzerbeschwerden.

Als Naechstes schauen wir, wie man diese Signale liest und findet, was einen Run verlangsamt.

In Production sieht das oft so aus:

• durchschnittliche latency wirkt normal, aber p95 waechst bereits;
• ein Tool wird unbemerkt zum Bottleneck;
• retries addieren Sekunden ohne sichtbares Traffic-Wachstum;
• das Team sieht das Problem erst nach partiellem Ausfall.

Darum sollte der Latency-Layer separat ueberwacht werden und nicht nur ueber allgemeine Run-Metriken.

Wie es funktioniert

Latency monitoring basiert auf zwei Signaltypen:

• runtime signals (queue_time, step_latency, tool_latency, ttft);
• service signals (run_latency_p50/p95/p99, timeout_rate, retry_overhead_ms).

Diese Metriken beantworten die Frage, "wo und warum das System mit der Zeit langsamer wird". Logs und Tracing werden gebraucht, um einen konkreten langsamen Run zu erklaeren.

Latency != user experience. Nutzer spueren nicht den Durchschnitt - sie spueren p95/p99. Langsame Anfragen praegen die Wahrnehmung. Latency haengt oft direkt mit cost zusammen. Laengere Runs bedeuten mehr Tokens, mehr Tool-Calls und mehr retries, was cost direkt erhoeht.

Typische Production-Latency-Metriken

run_latency_p95 und run_latency_p99 werden meistens auf Dashboard-/Query-Ebene berechnet, nicht als separater Counter im Code.

Damit Metriken praktisch bleiben, werden sie meist nach release, model, tool und workflow-Typ segmentiert.

Wichtig: keine hoch-kardinalen Felder (run_id, request_id, user_id) in Labels aufnehmen, sonst wird das Metrik-Storage schnell ueberlastet.

Wie man den Latency-Layer liest

Wo Verzoegerung entsteht -> wie sich der Agent verhaelt -> was den Run konkret verlangsamt. Diese drei Ebenen sollte man immer zusammen ansehen.

Wichtig sind Trends ueber Zeit und Unterschiede zwischen Releases, nicht Einzelwerte.

Jetzt zu Signal-Kombinationen:

• run_latency_p95 up + tool_latency_p95 up -> Bottleneck in externen Tools;
• run_latency_p95 up + step_count up -> Agent macht zu viele Iterationen;
• ttft_p95 up + tool_latency_p95 ~= stabil -> Problem im LLM-Layer, nicht in Tools;
• timeout_rate up + retry_overhead_ms up -> retries maskieren Instabilitaet und erhoehen latency;
• queue_time_p95 up + run_count up -> dem System fehlt Capacity.

Wann einsetzen

Vollstaendiges latency monitoring ist nicht immer noetig.

Fuer einfache Prototypen reicht manchmal die Basis-Antwortzeit.

Detailliertes Latency-Monitoring wird aber kritisch, wenn:

• das System bereits in Production ist und SLO/SLA fuer Geschwindigkeit hat;
• der Agent mehrere externe Tools und Abhaengigkeiten nutzt;
• Releases haeufig sind und latency-Regressionen sichtbar sein muessen;
• im workflow Queues, retries oder mehrstufige reasoning-Loops vorkommen.

Implementierungsbeispiel

Unten ist ein vereinfachtes Prometheus-Beispiel fuer Latency-Metrik-Instrumentierung. Das Beispiel zeigt Basis-Kontrolle: Run-Latency, Schritte, Tools, Timeouts und Retry-Overhead.

import time
from prometheus_client import Counter, Histogram

# perf_counter() wird statt time.time() genutzt,
# um praezise monotone Latency-Messungen zu bekommen
RUN_TOTAL = Counter(
    "agent_run_total",
    "Total number of agent runs",
    ["status", "stop_reason", "release"],
)

RUN_LATENCY_MS = Histogram(
    "agent_run_latency_ms",
    "Run latency in milliseconds",
    ["release"],
    buckets=(100, 250, 500, 1000, 2000, 5000, 10000, 20000),
)

STEP_LATENCY_MS = Histogram(
    "agent_step_latency_ms",
    "Latency by step type in milliseconds",
    ["step_type", "release"],
    buckets=(20, 50, 100, 250, 500, 1000, 2000, 5000),
)

TOOL_LATENCY_MS = Histogram(
    "agent_tool_latency_ms",
    "Tool latency in milliseconds",
    ["tool", "release"],
    buckets=(20, 50, 100, 250, 500, 1000, 2000, 5000),
)

QUEUE_TIME_MS = Histogram(
    "agent_queue_time_ms",
    "Queue wait time before run start",
    ["release"],
    buckets=(0, 20, 50, 100, 250, 500, 1000, 2000),
)

TTFT_MS = Histogram(
    "agent_ttft_ms",
    "Time to first token in milliseconds",
    ["model", "release"],
    buckets=(50, 100, 200, 400, 800, 1500, 3000),
)

TIMEOUT_TOTAL = Counter(
    "agent_timeout_total",
    "Total timeout errors by layer",
    ["layer", "release"],
)

RETRY_OVERHEAD_MS = Histogram(
    "agent_retry_overhead_ms",
    "Added latency from retries",
    ["release"],
    buckets=(0, 50, 100, 250, 500, 1000, 2000, 5000),
)


def run_agent(agent, task, queue_time_ms=0, release="2026-03-22"):
    run_status = "ok"
    stop_reason = "max_steps"
    started_at = time.perf_counter()

    if queue_time_ms > 0:
        QUEUE_TIME_MS.labels(release=release).observe(queue_time_ms)

    try:
        for step in agent.iter(task):
            step_type = step.type
            step_started_at = time.perf_counter()

            try:
                result = step.execute()
            except TimeoutError:
                run_status = "error"
                if step_type == "tool_call":
                    stop_reason = "tool_timeout"
                elif step_type == "llm_generate":
                    stop_reason = "llm_timeout"
                else:
                    stop_reason = "step_timeout"
                layer = (
                    "tool"
                    if step_type == "tool_call"
                    else "llm"
                    if step_type == "llm_generate"
                    else "runtime"
                )
                TIMEOUT_TOTAL.labels(layer=layer, release=release).inc()
                raise
            except Exception:
                run_status = "error"
                if step_type == "tool_call":
                    stop_reason = "tool_error"
                elif step_type == "llm_generate":
                    stop_reason = "llm_error"
                else:
                    stop_reason = "step_error"
                raise
            finally:
                step_latency_ms = (time.perf_counter() - step_started_at) * 1000
                STEP_LATENCY_MS.labels(step_type=step_type, release=release).observe(step_latency_ms)
                if step_type == "tool_call":
                    TOOL_LATENCY_MS.labels(
                        tool=getattr(step, "tool_name", "unknown"),
                        release=release,
                    ).observe(step_latency_ms)
                # retry overhead kann auch bei fehlgeschlagenem Schritt auftreten
                retry_overhead_ms = float(getattr(step, "retry_overhead_ms", 0) or 0)
                if retry_overhead_ms > 0:
                    RETRY_OVERHEAD_MS.labels(release=release).observe(retry_overhead_ms)

            if step_type == "llm_generate":
                model = getattr(step, "model", "unknown")
                ttft_ms = float(getattr(result, "ttft_ms", 0) or 0)
                if ttft_ms > 0:
                    TTFT_MS.labels(model=model, release=release).observe(ttft_ms)

            if result and result.is_final:
                stop_reason = "completed"
                break
    finally:
        run_latency_ms = (time.perf_counter() - started_at) * 1000
        RUN_LATENCY_MS.labels(release=release).observe(run_latency_ms)
        RUN_TOTAL.labels(status=run_status, stop_reason=stop_reason, release=release).inc()

# run_latency_p95 und run_latency_p99 werden meist auf Dashboard-Ebene berechnet:
# histogram_quantile(...) ueber agent_run_latency_ms bucket-Metriken.

So koennen diese Metriken zusammen in einem realen Dashboard aussehen:

Investigation

Wenn ein Latency-Alert ausloest:

1. Segment mit Anomalie finden (release, tool, model);
2. langsame Runs im Tracing ansehen;
3. retries, timeout und stop_reason in Logs pruefen;
4. root cause finden (Tool, LLM, Queue, Agent-Logik, externer Service).

Typische Fehler

Auch wenn Latency-Metriken vorhanden sind, bringen sie oft wenig wegen typischer Fehler unten.

Es wird nur die durchschnittliche latency beobachtet

Der Durchschnitt versteckt Degradation haeufig. Fuer Production sind p50 und p95 Minimum, bei kritischen Szenarien auch p99.

Keine Aufteilung der latency nach tools und step type

Ohne das ist schwer zu verstehen, was langsam ist: LLM, Tool oder Agent-Loop selbst. In so einer Lage ist schnelle Lokalisierung von Tool-Ausfall schwer.

Queue time wird ignoriert

Ein Run kann bereits vor Start langsam sein. Ohne queue_time_p95 verpasst man Capacity-Probleme leicht.

Keine timeout-rate- und retry-overhead-Metriken

Retries koennen Instabilitaet maskieren und latency kuenstlich aufblasen. Das tritt oft zusammen mit Tool-Spam auf.

Keine Alerts auf p95/p99 und Timeout-Spikes

Ohne Alerts erfaehrt das Team zu spaet von Problemen, wenn SLO bereits verletzt ist.

Selbstcheck

Unten ist eine kurze Checkliste fuer Basis-Latency-Monitoring vor Release.

FAQ

Q: Worin unterscheidet sich latency monitoring von normalem API-Speed-Monitoring?
A: Bei Agenten muss man nicht nur Gesamt-Antwortzeit monitoren, sondern auch interne Schritte: reasoning, tools, retries, queue time.

Q: Welches Minimum an Latency-Metriken braucht man zum Start?
A: Starte mit run_latency_p50/p95, tool_latency_p95, timeout_rate und queue_time_p95.

Q: Warum ist p95 wichtiger als durchschnittliche latency?
A: Weil p95 zeigt, was mit langsamen Requests passiert, die Nutzer am staerksten merken.

Q: Wie trennt man Tool-Latency-Probleme von LLM-Latency-Problemen?
A: Vergleiche tool_latency_p95 und ttft_p95: waechst nur Tool-Latency, liegt der Bottleneck in Tools; waechst ttft, liegt das Problem im LLM-Layer.

Verwandte Seiten

Weiter zum Thema:

• Agent-Metriken — Gesamtmodell fuer Metriken in Agentensystemen.
• Tool-Usage-Metriken — wie man latency auf Tool-Ebene isoliert.
• Cost Monitoring fuer Agenten — wie latency mit cost zusammenhaengt.
• Agent Tracing — wie man den langsamen Schritt in einem konkreten Run findet.
• Alerting in KI-Agenten — wie man fruehe Benachrichtigungen baut.