Observabilität für LLM-Systeme: Metriken, Spuren, Logs und Testing in der Produktion

LLM-Systeme scheitern auf Weisen, die herkömmliche API-Überwachung nicht aufdecken kann – Warteschlangen füllen sich schweigend, die GPU-Speicherbelegung erreicht den Sättigungspunkt lange bevor der CPU beschäftigt aussieht und Latenz explodiert in der Batch-Schicht anstatt in der Anwendungsschicht. Dieser Leitfaden behandelt eine End-to-End- Überwachungsstrategie für LLM-Abduktion und LLM-Anwendungen: Was gemessen werden sollte, wie man es mit Prometheus, OpenTelemetry und Grafana instrumentiert und wie man die Telemetrie-Pipeline im großen Maßstab bereitstellt.

TL;DR (Executive summary)

LLM-Systeme verschlechtern sich auf Weisen, die klassische „HTTP-Latenz + Fehlerquote“-Überwachung nicht erklären kann. Produktionsreife Überwachung für LLM-Systeme muss schnell und verteidigbar folgende Fragen beantworten:

• Ob die Benutzererfahrung sich verschlechtert (Schwanzlatenz, time-to-first-token, Inter-Token-Latenz, Fehler und Abbrüche).
• Wo die Zeit verbracht wird (Warteschlange vs. Batchung vs. Modellausführung; Retrieval/Tools/Sicherheitsfilter vs. Inferenz).
• Was zuerst gesättigt wird (GPU-Nutzung und Speicherdruck, KV-Cache/Warteschlangendruck, CPU-Tokenisierung).
• Wie Kosten und Kapazität sich verändern (Tokens pro Anfrage, Tokens/sec pro GPU, Cache-Hit-Rate, verschwendete Generierungen).
• Ob Telemetriedaten sicher gespeichert werden können (Prompts können personenbezogene Daten enthalten; verhindere sensible Leckage in Logs/Attributen).

Der robusteste Entwurf ist ein Multi-Signal-Pipeline:

• Metriken für schnelle Erkennung und Kapazitätsplanung (Prometheus + PromQL; optionaler langer Speicher über Thanos/Cortex/Mimir/VictoriaMetrics).
• Traces für Ursachen auf Anfrageebene (OpenTelemetry mit OTLP; Backend-Systeme wie Tempo/Jaeger/Zipkin/Elastic APM).
• Logs für Kontext, korreliert mit Traces (Loki/Elastic/OpenSearch), konzipiert für geringe Kardinalität von Metadaten.
• Profiling für CPU/Speicher-Hotspots und Schwanzlatenz (Grafana Pyroscope).
• Synthetische + Lasttests zur Erkennung von Regressionen vor Benutzern (Grafana k6; blackbox-artige Prüfung).
• SLOs zur Messung von Benutzerergebnissen und zur Antriebskraft für handlungsorientierte Alarmierung (Fehlerbudgets; Burn-Rate-Style).

Was macht die Observability für LLM-Systeme anders

Hinweis zum Umfang: Das Ziel-LLM-Framework ist nicht spezifiziert. Beispiele in diesem Artikel behandeln gängige Server/Stacks (Triton, vLLM, TGI, LangChain/LangSmith) und bleiben für andere Stacks anwendbar, indem entsprechende Metriken und Spans ersetzt werden.

LLMs führen operatives Verhalten ein, das sich von herkömmlichen Webdiensten unterscheidet:

• Variable Arbeit pro Anfrage: Token-Zahlen (Eingabe/Ausgabe) variieren stark, daher kann „Anfragen pro Sekunde“ stabil aussehen, während die Token-Durchsatzrate kollabiert. TGI und vLLM exportieren bewusst token- und token-latency-bezogene Telemetriedaten, um diesen Überwachungsstil zu unterstützen.
• Warteschlange + kontinuierliche Batchung: Durchsatz hängt von Batch-/Warteschlangen-Disziplinen ab; Warteschlangengröße und Batchgröße werden zu ersten-Klasse-Indikatoren (TGI exportiert beide).
• Streaming UX: Benutzer kümmern sich mindestens so sehr um TTFT und Inter-Token-Latenz wie um die vollständige Antwortzeit; OpenTelemetry standardisiert sogar Server TTFT/time-per-token-Metriken unter GenAI semantischen Konventionen.
• GPU-Druck dominiert Fehlmodi: GPU-Nutzung und GPU-Speicher (einschließlich genutzter Speicher) sind zentral für Zuverlässigkeit; NVIDIA’s DCGM-Exporter existiert speziell, um GPU-Telemetriedaten über einen Prometheus /metrics-Endpunkt zu exponieren.
• Multi-Step-Pipelines: Retrieval, Tool-Aufrufe, Sicherheitsfilter und Nachverarbeitung bedeuten, dass die End-to-End-Latenz eine Komposition mehrerer Spans/Warteschlangen ist – was verteilte Tracing und sorgfältiges Metrikdesign unerlässlich macht.

Konkrete Beispiele aus beliebten Inferenzservern unterstreichen dies:

• NVIDIA Triton Inferenzserver exponiert Metriken als Klartext über /metrics (häufig :8002/metrics) und bietet Flags, um Metriken zu aktivieren/deaktivieren und einen Metriken-Port auszuwählen.
• vLLM exponiert einen umfangreichen Prometheus /metrics-Endpunkt mit einem vllm: Präfix; seine Dokumentation enthält Zähler für generierte Tokens und Histogramme wie time to first token.
• Hugging Face TGI dokumentiert einen /metrics-Endpunkt mit Warteschlangengröße, Batchgröße, End-to-End-Anfragedauer, generierte Tokens und Warteschlangendauer.

Kernobservability-Aufgaben und erforderliche LLM-Telemetriedaten

Observability für LLM-Systeme ist am einfachsten umzusetzen, wenn Sie Aufgaben → Signale → Tools abbilden und Kardinalität und Sampling von Anfang an einschränken.

Metriken: Für Online-Dienstsysteme betont die eigene Instrumentierungshinweise von Prometheus Anzahl der Abfragen, Fehler und Latenz als Schlüsselmetriken; LLMs erweitern dies mit TTFT, Token-Durchsatz/Latenz pro Token, Warteschlangenlänge, Batchgröße und GPU-Nutzung.

Traces: Traces sind die Art und Weise, wie Sie Latenz und Fehler über Retrieval/Tools/Sicherheit/Inferenz-Stufen zuordnen; OpenTelemetry fasst Traces/Exporter als herstellerneutrale Art und Weise, Telemetriedaten zu emittieren und an Sammler oder Backend zu senden.

Logs: Logs liefern menschenlesbaren Kontext und „warum“, bleiben aber erst bei Skalierung nutzbar, wenn man unbeschränkte Werte indiziert (Beispiel: Loki indiziert nur Labels und speichert komprimierte Log-Blöcke in Objekt-Speicher).

Profiling: Kontinuierliches Profiling erfasst Produktions-CPU/Speicher-Verhalten mit geringem Overhead-Sampling; Grafana Pyroscope ist explizit für dies konzipiert.

Synthetische Tests und Lasttests: Grafana k6 ist ein Open-Source-Lasttest-Tool, und Grafana bemerkt, dass synthetische Überwachung von k6 angetrieben wird und über einfache Protokoll-Prüfungen hinausgeht.

SLOs: Googles SRE-Hinweise definieren ein SLO als Zielwert/Range für einen Servicelevel gemessen durch einen SLI und geben Hinweise für Alarmierung auf SLOs (Präzision/Erkennungsgeschwindigkeit/Erkennungszeit-Handel).

Schlüssel-LLM-Metriken-Blueprint

OpenTelemetry GenAI semantische Konventionen für Standardisierung

OpenTelemetry bietet GenAI semantische Konventionen (Status: „Entwicklung“) mit standardisierten Namen für GenAI-Metriken wie:

• gen_ai.client.token.usage und gen_ai.client.operation.duration
• gen_ai.server.request.duration, gen_ai.server.time_per_output_token, und gen_ai.server.time_to_first_token

Diese Standardisierung ist ein praktischer Hebel für tragbare „Monitoring von LLM-Modellen mit OpenTelemetry“-Strategien: einmal emittieren und später dieselben Telemetriedaten an OSS- oder Hersteller-Backends routen.

Designing the telemetry pipeline

Pull vs push

Prometheus ist pull-first. Prozesse exponieren Metriken in einem unterstützten Expositionsformat, und Prometheus scrapet sie gemäß konfigurierten Scrap-Jobs.

Push ist für Ausnahmen. Der „When to use the Pushgateway“-Leitfaden von Prometheus empfiehlt den Pushgateway nur in begrenzten Fällen (nicht als allgemeiner Push-Ersatz), und der Pushgateway README betont, dass er „Prometheus in ein push-basiertes Monitoring-System“ nicht umwandeln kann.

LLM-spezifisches praktisches Muster:

• Verwenden Sie pull für Inferenzserver/Exporter (Triton/vLLM/TGI-Metriken-Endpunkte; DCGM-Exporter; node-Metriken).
• Verwenden Sie OTLP push für Traces/Logs/OTel-Metriken (OpenTelemetry Protocol definiert Transport/Encoding/Lieferung zwischen Quellen, Sammlern und Backend).
• Verwenden Sie remote write, wenn Sie über einen einzelnen Prometheus hinaus skaliert (Prometheus bietet remote write Tuning-Richtlinien; Mimir/Thanos/Cortex bieten langfristige und/oder HA-Speicheroptionen).

Agent vs sidecar vs gateway Sammler

OpenTelemetry dokumentiert ein Agent-Deployment-Muster, bei dem Telemetriedaten an einen Sammler gesendet werden, der neben der Anwendung oder auf demselben Host (Sidecar/DaemonSet) läuft, und dann exportiert wird.

Für Kubernetes wird Sidecar-Einjektion über den OpenTelemetry Operator unterstützt (Annotation-basierte Einjektion).

Pragmatische Faustregel für LLM-Stacks:

• Verwenden Sie einen DaemonSet-Agenten für Host-basierte Bereicherung und gemeinsame Pipelines über viele Pods.
• Verwenden Sie einen Sidecar, wenn Sie strikte Isolierung pro Workload oder lokale Filterung benötigen (häufig, wenn Prompts sensible Daten enthalten).
• Verwenden Sie einen Gateway-Sammler für zentrale Schwanzabtastung, Batchung, Wiederholungen und Export-Verzweigung.

Sampling und Kardinalitätskontrolle

OpenTelemetry klärt auf, dass Schwanzabtastung Abtastungsentscheidungen ermöglicht, die sich aus einem Trace ableiten (nicht möglich mit Kopf-Abtastung allein).

Prometheus’ Instrumentierungshinweise warnen vor zu großem Label-Verbrauch, geben eine Faustregel, um Kardinalität niedrig zu halten, und raten, Metriken umzuentwerfen, wenn potenzielle Kardinalität ~100 überschreitet.

LLM-spezifische „Kardinalitätsfallen“, die früh verboten werden sollten:

• Prompttext, Antworttext, Konversations-IDs, Anfrage-IDs als Labels/Attribute.
• Tool-Argument-Blöcke als Span-Attribute.
• Unbeschränkte „user_id“-Labels.

Vorzugsweise begrenzte Dimensionen: model, model_family, endpoint, region, status_code, deployment, tenant (nur wenn begrenzt).

LLM-observability-Tools-Vergleich

Tools gemappt auf Observability-Aufgaben

Grafana vs Alternativen für Visualisierung

• Grafana-Dashboards bestehen aus Panels, die Datenquellen (einschließlich Loki und Mimir) abfragen, um Diagramme und Visualisierungen zu erstellen.
• Kibana bietet Dashboards/Visualisierungen als UI-Schicht innerhalb des Elastic Stack.
• OpenSearch Dashboards bietet Visualisierungstools für OpenSearch.
• InfluxData-Dokumentation positioniert Chronograf als Visualisierungskomponente innerhalb des Influx-Ökosystems.

Prometheus vs Alternativen für Metrik-Backends

• Prometheus lokale Speicherstandard: wenn keine Retentionsflags gesetzt sind, beträgt die Retentionsdauer standardmäßig 15d (planen Sie Retention/Kosten frühzeitig).
• Grafana Mimir wird als horizontal skalierbar, HA, mehrere Mieter langfristige Speicherung für Prometheus und OpenTelemetry-Metriken beschrieben.
• Thanos wird als hochverfügbarer Prometheus-Setup mit langfristigen Speicherungsfähigkeiten beschrieben.
• Cortex beschreibt sich selbst als horizontal skalierbar, HA, mehrere Mieter langfristige Speicherungslösung für Prometheus und OpenTelemetry-Metriken.
• VictoriaMetrics Cloud dokumentiert Prometheus remote write Integration für langfristige Speicherung.
• Amazon Managed Service for Prometheus beschreibt sich als verwaltete Lösung, die sich mit der Eingabe/Abfrage-Notwendigkeit skaliert und PromQL und remote write unterstützt.

Praktischer Umsetzungskochbuch

Metriknamen und Typen, die heute implementiert werden sollten

OpenTelemetry GenAI semantische Konventionen (Status: Entwicklung) definieren Metriknamen, die Sie sofort standardisieren können:

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

Serverseitige Beispiele, die Sie sofort abfragen können:

• vLLMs Prometheus-Endpunkt enthält Zähler (z. B. generierte Token insgesamt) und Histogramme (TTFT) und dokumentiert eine model_name-Labelstrategie.
• TGI dokumentiert Metriken, einschließlich Warteschlangengröße, Anfragedauer, generierte Token und Mittelwert der Zeit pro Token.
• Triton dokumentiert /metrics-Exposition und Metrik-Wechsler.

PromQL-Beispiele für LLM-Latenz- und Durchsatz-Dashboards

# p95 End-to-End-Latenz für ein Anwendungs-Histogramm
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Fehlerquote in Prozent (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Tokens/sec (Ausgabe) über alle Modelle
sum(rate(llm_tokens_total{direction="out"}[5m]))

# TGI-Warteschlangengröße (Gauge)
max(tgi_queue_size) by (instance)

# vLLM TTFT p95
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

Prometheus’ Histogram-Richtlinien erklären, dass Histogram-Quantile serverseitig aus Buckets mit histogram_quantile() berechnet werden.

OpenTelemetry-Instrumentierungsnotizen für LLM-Systeme

• OTLP ist das OpenTelemetry-Protokoll, das definiert, wie Telemetriedaten zwischen Quellen, Sammlern und Backend kodiert/übertragen werden.
• OpenTelemetry SDK-Konfigurationsdokumentation dokumentiert Umgebungsvariablen wie OTEL_EXPORTER_OTLP_ENDPOINT (und Protokolloptionen) für die Exportierung von Telemetriedaten.
• OpenTelemetry Python contrib dokumentiert Unterstützung für FastAPI-Instrumentierung, sowohl automatisch als auch manuell.
• GenAI semantische Konventionen enthalten einen opt-in-Stabilitätsmechanismus über OTEL_SEMCONV_STABILITY_OPT_IN für GenAI-Konventionenmigration.

Kurzes Python-Beispiel: Metriken + Traces + Logs

Der folgende Snippet demonstriert:

• Prometheus-Metriken-Exposition (/metrics) für „Monitoring von LLM-Inferenz mit Prometheus“
• OpenTelemetry-Traces über OTLP exportiert (herstellerneutral)
• Strukturierte Logs, korreliert mit Trace-Kontext, mit einer privatsicherheitsfreien Standard (keine Roh-Prompts protokollieren)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (pull-basierte Metriken)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (OTLP Traces)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="LLM Inferenz API", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Logging (privatsicherheitsfreier Standard) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Prometheus-Metriken ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "LLM-Anfragen insgesamt",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "End-to-End-LLM-Anfragen-Latenz (Sekunden)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- OpenTelemetry-Tracer-Provider ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # konfiguriere über OTEL_EXPORTER_OTLP_* Umgebungsvariablen
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "unspecified"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    model: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    route = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # Vermeiden Sie das Protokollieren des vollständigen Prompts; emittieren Sie sichere Metadaten
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Ersetzen Sie durch tatsächliche LLM-Aufruf (Triton/vLLM/TGI-Client)
        time.sleep(0.15)
        output = "Hallo vom Modell."

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(route=route, model=req.model).observe(latency_s)
        LLM_REQUESTS.labels(route=route, status_code="200", model=req.model).inc()

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # Fügen Sie nicht den Roh-Prompt/Ausgabe hinzu, es sei denn, die Richtlinie erlaubt es.
            }
        )

        return GenerateResponse(model=req.model, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Deployment, Skalierung, Sicherheit und Fehlerbehebung

Deployment-Optionen

Skalierung und Retention: praktische Einschränkungen

• Prometheus lokale Speicherung: Ohne explizite Größe/Zeit-Flags beträgt die Retentionszeit standardmäßig 15d.
• Prometheus remote write: Prometheus dokumentiert remote write Tuning für Skalierung über „sane defaults“.
• Grafana Tempo: Positioniert als hochskalierbares Tracing-Backend und kann Metriken aus Spans generieren, mit metrics-generator (remote writes zu einer Prometheus-Datenquelle).
• Loki-Speicherung: Loki-Dokumentation betont Label-only-Indizierung und komprimierte Chunk-Speicherung (Objekt-Speicher), wodurch Label-Strategie zentral für Skalierung und Kosten ist.

Sicherheit und Privatsphäre: Prompts können personenbezogene Daten enthalten

OpenTelemetry Sicherheitsrichtlinien betonen, dass Telemetrieerfassung versehentlich sensible/personenbezogene Informationen erfassen kann; Sie sind dafür verantwortlich, sie entsprechend zu behandeln.

Prometheus Sicherheitsmodell warnt, dass Prometheus-Endpunkte nicht in öffentlich zugängliche Netzwerke (wie das Internet) exponiert werden sollten, da sie Informationen über überwachte Systeme bereitstellen.

Operative Privatsphäre-Kontrollen, die „Observability für LLM-Systeme“ sicher halten:

• Standardmäßig keine Protokollierung von Roh-Prompts/Antworten; protokollieren Sie Tokenzahlen, Modellname, Latenz und Trace-IDs stattdessen.
• Reduzieren/entfernen sensible Attribute in Sammlern/Pipelines (Collector-level-Filterung ist ein gängiger Ansatz in Ökosystemen).
• Enzwingen Sie RBAC und Retention-Policen für Logs/Traces; erwägen Sie sensible-Daten-Scanners wo angebracht (z. B. Hersteller dokumentieren Scanners für Telemetriedaten).

Fehlerbehebungs-Checkliste

Wenn Ihr Grafana-Dashboard für LLM-Latenz falsch aussieht, debuggen Sie in dieser Reihenfolge:

• Ingestion-Gesundheit
  • Prometheus: Validieren Sie Scrap-Erfolg und Konfigurationssemantik (Prometheus-Konfiguration definiert Scrap-Jobs/Instanzen).
  • OTLP: Bestätigen Sie Exporter-Endpunkt-Konfiguration (SDKs verwenden OTEL_EXPORTER_OTLP_ENDPOINT, Protokoll-Einstellungen).
• Schema-Mismatch
  • Dashboard erwartet model, aber Ihr Server emittiert model_name (vLLM dokumentiert explizit model_name-Labels).
• Kardinalitäts-Explosion
  • Jemand hat nach Anfrage-IDs/Prompt-Hashes gelabelt; Prometheus warnt, dass Labelsets RAM/CPU/Disk/Netzwerk-Kosten erhöhen und bietet Kardinalitäts-Richtlinien.
• Histogram-Missbrauch
  • Stellen Sie sicher, dass Sie Quantile aus _bucket-Reihen mit rate() und le berechnen; Prometheus erklärt Handelsgeschäfte bei Histogram-Quantilberechnung.
• Trace-Sampling-Lücken
  • Wenn Sie zu aggressiv head-sample, verschwinden seltene langsamen/Fehler-Traces; tail-sample behält „wichtige“ Traces basierend auf vollständigen Trace-Kriterien.
• Tempo span-metrics-Probleme
  • Wenn Sie Tempo metrics-generator und span-metrics verwenden, bestätigen Sie, dass es aktiviert und abgestimmt ist (Tempo dokumentiert metrics-generator und span-metrics-Prozessoren; Fehlerbehebung besteht für Generator-Probleme).
• GPU-Metriken fehlen
  • Bestätigen Sie, dass DCGM Exporter bereitgestellt und /metrics erreichbar ist (DCGM Exporter exponiert GPU-Metriken über HTTP für Prometheus).

Nützliche Links

• Observability: Monitoring, Metrics, Prometheus & Grafana Guide
• Prometheus-Monitoring: Setup & Best Practices
• LLM-Performance: Benchmarks, Bottlenecks & Optimization
• LLM-Hosting: Lokal, Selbstgehostet & Cloud-Infrastruktur Vergleich
• RAG Schritt-für-Schritt-Tutorial
• Prometheus-Konfigurationsdokumentation
• Prometheus-Expositionsformate
• Prometheus-Instrumentierungsbest Practices
• Prometheus-Metrikennamen
• Prometheus-Histogramme und Zusammenfassungen
• Prometheus-Alarmierungsregeln
• Prometheus-Alarmierungsübersicht
• Alertmanager-Konfiguration
• Grafana-Dashboard JSON-Modell
• Grafana-Providing
• NVIDIA Triton Inferenzserver-Metriken
• TorchServe-Metriken-API
• NVIDIA DCGM Exporter
• kube-prometheus-stack Helm-Chart
• Prometheus Operator Getting Started
• OpenTelemetry Prometheus Exporter Spezifikation
• Prometheus Guide für Empfangen von OTLP
• LangSmith Tracing mit OpenTelemetry