Observability voor LLM-systemen: Metingen, Traces, Logs en Testing in Productie

LLM-systemen falen op manieren die traditionele API-monitoring niet kan oppikken: wachtrijen vullen zich stilzwijgend, GPU-geheugen verzadigt lang voordat de CPU druk lijkt, en latentie explodeert op de batchlaar in plaats van op de applicatielaag.

Deze handleiding behandelt een end-to-end observabiliteitsstrategie voor LLM-inferentie en LLM-applicaties: wat er gemeten moet worden, hoe dit geïnstrumenteerd moet worden met Prometheus, OpenTelemetry en Grafana, en hoe de telemetrie-pipeline op schaal kan worden ingezet.

Volledige assistant-stacks voegen retrieval, tool-aanroepen en routing toe bovenop ruwe inferentie; AI Assistant Architecture toont aan waar observabiliteit past binnen die lagen.

TL;DR (Samenvatting)

LLM-systemen degraderen op manieren die klassieke monitoring op basis van “HTTP-latentie + foutpercentage” niet kan verklaren. Productie-klaar Observability voor LLM-systemen moet snel en onderbouwd antwoord geven op:

• Of de gebruikerservaring afneemt (tail-latentie, time-to-first-token, inter-token latentie, fouten en aborteringen).
• Waar de tijd wordt besteed (wachtrij vs. batching vs. modeluitvoering; retrieval/tools/safetyfilters vs. inferentie).
• Wat als eerste verzadigt (GPU-gebruik en geheugendruk, KV-cache/wachtrijdruk, CPU-tokenisatie).
• Hoe kosten en capaciteit afwijken (tokens per aanvraag, tokens/seconde per GPU, cache-hitrate, verspilde generaties).
• Of telemetrie veilig opgeslagen kan worden (prompts kunnen PII bevatten; voorkom lekkage van gevoelige gegevens naar logs/attributen).

Het meest veerkrachtige ontwerp is een multi-signal pipeline:

• Metingen voor snelle detectie en capaciteitsplanning (Prometheus + PromQL; optionele langdurige opslag via Thanos/Cortex/Mimir/VictoriaMetrics).
• Traces voor causaliteit op aanvraagniveau (OpenTelemetry met OTLP; backends zoals Tempo/Jaeger/Zipkin/Elastic APM).
• Logs voor context, gecorreleerd met traces (Loki/Elastic/OpenSearch), ontworpen voor metadata met lage cardinaliteit.
• Profiling voor CPU/geheugen-hots en tail-latentie (Grafana Pyroscope).
• Synthetische + belastingtests om regressies te detecteren voordat gebruikers dat doen (Grafana k6; blackbox-achtige probering).
• SLO’s om gebruikersresultaten te meten en actiegericht alarmeren (error budgets; burn-rate-stijl).

Wat maakt observabiliteit voor LLM-systemen anders

Bereikopmerking: het doel-LLM-framework is niet gespecificeerd. Voorbeelden in dit artikel dekken veelvoorkomende servers/frameworks (Triton, vLLM, TGI, LangChain/LangSmith) en blijven van toepassing op andere stacks door equivalente metingen en spans te substitueren.

LLM’s introduceren operationele gedragingen die verschillen van conventionele webdiensten:

• Variabele werklast per aanvraag: tokenaantallen (input/output) variëren sterk, waardoor “aanvragen per seconde” stabiel kan lijken terwijl de token-doorvoer instort. TGI en vLLM exporteren expliciet token- en token-latentiegerelateerde telemetrie om deze stijl van monitoring te ondersteunen.
• Wachtrijen + continue batching: doorstroom hangt af van batching/wachtrijdisciplines; wachtrijgrootte en batchgrootte worden eerste-klasse indicatoren (TGI exposeert beide).
• Streaming UX: gebruikers geven net zo veel om TTFT en inter-token latentie als om de totale responstijd; OpenTelemetry standardiseert zelfs server TTFT/time-per-token metingen onder GenAI-semantische conventies.
• GPU-druk domineert faalmodes: GPU-gebruik en GPU-geheugen (inclusief gebruikte geheugengrootte) zijn centraal voor betrouwbaarheid; NVIDIA’s DCGM-exporter bestaat specifiek om GPU-telemetrie te exposeren op een Prometheus /metrics-endpoint.
• Multi-step pipelines: retrieval, tool-aanroepen, safetyfilters en post-bewerkingen betekenen dat end-to-end latentie een compositie is van meerdere spans/wachtrijen—wat gedistribueerde tracing en zorgvuldige metingontwerp essentieel maakt.

Concrete voorbeelden van populaire inferentieservers benadrukken dit:

• NVIDIA Triton Inference Server exposeert metingen als platte tekst via /metrics (meestal :8002/metrics) en biedt vlaggen om metingen in/uit te schakelen en een metingpoort te selecteren.
• vLLM exposeert een uitgebreid Prometheus /metrics-endpoint met een vllm:-prefix; de documentatie bevat counters voor generatietokens en histogrammen zoals time to first token.
• Hugging Face TGI documenteert een /metrics-endpoint met wachtrijgrootte, batchgrootte, end-to-end aanvraagduur, gegenereerde tokens en wachtrijduratie.

Kernobservabiliteitstaken en vereiste LLM-telemetrie

Observabiliteit voor LLM-systemen is het eenvoudigst te implementeren wanneer je taken → signalen → tools mappt, en cardinaliteit en sampling vanaf dag één beperkt.

Metingen: Voor online-serving systemen benadrukt Prometheus’ eigen instrumentatie-richtlijn aantal queries, fouten en latentie als kernmetingen; LLM’s breiden dit uit met TTFT, per-token doorvoer/latentie, wachtrijlengte, batchgrootte en GPU-gebruik.

Traces: Traces zijn hoe je latentie en fouten toerekent over retrieval/tools/safety/inference-fases; OpenTelemetry framest traces/exporters als een vendor-neutrale manier om telemetrie te emitteren en te verzenden naar collectors of backends.

Logs: Logs bieden mens-leesbare context en “waarom”, maar blijven alleen op schaal bruikbaar als je indexering van onbegrensde waarden vermijdt (voorbeeld: Loki indexeert alleen labels en slaat gecomprimeerde log-chunks op in objectopslag).

Profiling: Continue profiling vangt productie-CPU/geheugen-gedrag op met lage-overhead sampling; Grafana Pyroscope is expliciet hiervoor gepositioneerd.

Synthetische tests en belastingtests: Grafana k6 is een open-source belastingtesttool, en Grafana merkt op dat Synthetic Monitoring wordt aangedreven door k6 en verder gaat dan eenvoudige protocolcontroles.

SLO’s: Google’s SRE-richtlijn definieert een SLO als een doelwaarde/bereik voor een serviceniveau, gemeten door een SLI, en biedt richtlijnen voor alarmeren op SLO’s (precision/recall/detectietijd trade-offs).

Kern LLM-metingen blauwdruk

• Batchgrootte en batchlimieten | tgi_batch_current_size ; tgi_batch_current_max_tokens | Gauge | Doorvoer–latentie trade-offs | TGI | | GPU-gebruik/geheugen | DCGM_* (door exporter geleverd) | Gauge | Verzadiging, OOM-risico, schalingstrigger | DCGM-exporter exposeert GPU-metingen op /metrics | | Inferentieserver telemetrie-endpoint | :8002/metrics (Triton standaard in docs/archives) | — | Standaard scrapedoel voor Prometheus | Triton docs |

OpenTelemetry GenAI semantische conventies voor standaardisatie

OpenTelemetry biedt GenAI-semantische conventies (status: “Ontwikkeling”) met standaardbenaming voor GenAI-metingen zoals:

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

Deze standaardisatie is een praktische hefboom voor portable “monitoring LLM-modellen met OpenTelemetry” strategieën: een keer emitteren en dezelfde telemetrie later routeren naar OSS of vendor backends.

Ontwerpen van de telemetiepipeline

Pull vs push

Prometheus is pull-first. Processen exposeren metingen in een ondersteund exposition-formaat, en Prometheus scraapt ze volgens geconfigureerde scrape jobs.

Push is voor uitzonderingen. Prometheus’ “When to use the Pushgateway”-handleiding adviseert expliciet de Pushgateway alleen in beperkte gevallen (niet als algemene push-vervanging), en de Pushgateway README benadrukt dat deze Prometheus niet kan “omtoveren tot een push-based monitoring-systeem”.

LLM-specifiek praktisch patroon:

• Gebruik pull voor inferentieservers/exporters (Triton/vLLM/TGI metingseindpunten; DCGM-exporter; node-metingen).
• Gebruik OTLP push voor traces/logs/OTel-metingen (OpenTelemetry Protocol definieert transport/encoding/levering tussen bronnen, collectors en backends).
• Gebruik remote write wanneer je schaalt beyond een enkele Prometheus (Prometheus biedt remote write afstelfiguur; Mimir/Thanos/Cortex bieden langdurige en/of HA-opslagopties).

Agent vs sidecar vs gateway collectors

OpenTelemetry documenteert een agent deployment pattern, waarbij telemetrie wordt verzonden naar een Collector die naast de applicatie draait of op dezelfde host (sidecar/DaemonSet), en vervolgens wordt geëxporteerd.

Voor Kubernetes is sidecar-injectie ondersteund via de OpenTelemetry Operator (annotatie-gebaseerde injectie).

Pragmatische vuistregel voor LLM-stacks:

• Gebruik een DaemonSet agent voor host-level verrijking en gedeelde pipelines over veel pods.
• Gebruik een sidecar wanneer je strikte per-workload isolatie of dedicated lokale filtering nodig hebt (vaak voorkomend wanneer prompts gevoelige gegevens kunnen bevatten).
• Gebruik een gateway collector voor gecentraliseerde tail sampling, batching, retries en export fan-out.

Sampling en cardinaliteitscontrole

OpenTelemetry verduidelijkt dat tail sampling het mogelijk maakt om sampling-beslissingen te nemen op basis van criteria afgeleid van een trace (niet mogelijk met alleen head sampling).

Prometheus’ instrumentatierichtlijn waarschuwt voor overgebruik van labels, geeft een vuistregel om cardinaliteit laag te houden, en adviseert herontwerp van metingen als potentiële cardinaliteit ~100 overschrijdt.

LLM-specifieke “cardinality-traps” om vroeg te verbannen:

• Prompt-tekst, respons-tekst, conversatie-ID’s, aanvraag-ID’s als labels/attributen.
• Tool-argumentblobs als span-attributen.
• Onbegrensde “user_id”-labels.

Vermijd gebonden dimensies: model, model_family, endpoint, region, status_code, deployment, tenant (alleen indien gebonden).

LLM observabiliteit tools vergelijking

Tools gemapped aan observabiliteitstaken

Grafana vs alternatieven voor visualisatie

• Grafana-dashboards bestaan uit panels die databronnen (inclusief Loki en Mimir) queryn om charts en visualisaties te produceren.
• Kibana biedt dashboards/visualisaties als de UI-laag binnen de Elastic Stack.
• OpenSearch Dashboards biedt datavisualisatietooling voor OpenSearch.
• InfluxData’s documentatie positioneert Chronograf als het visualisatiecomponent binnen de Influx-ecosysteem.

Prometheus vs alternatieven voor metingenbackends

• Prometheus lokale opslag standaarden: als retentievlaggen niet zijn ingesteld, is de retentie standaard 15d (plan retentie/kosten vroeg).
• Grafana Mimir wordt beschreven als horizontaal schaalbaar, HA, multi-tenant langdurige opslag voor Prometheus en OpenTelemetry-metingen.
• Thanos wordt beschreven als een hoog-beschikbaar Prometheus-setup met langdurige opslagmogelijkheden.
• Cortex beschrijft zichzelf als een horizontaal schaalbaar, HA, multi-tenant langdurige opslagoplossing voor Prometheus en OpenTelemetry-metingen.
• VictoriaMetrics Cloud documenteert Prometheus remote write-integratie voor langdurige opslag.
• Amazon Managed Service for Prometheus beschrijft een managed aanbod dat schaalt met ingestie/query-behoeften en PromQL en remote write ondersteunt.

Praktische implementatie cookbook

Metingsnamen en types om vandaag te implementeren

OpenTelemetry GenAI-semantische conventies (status: Ontwikkeling) definiëren metingsnamen die je direct kunt standaardiseren:

• 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

Server-side voorbeelden die je direct kunt scrapen:

• vLLM’s Prometheus-endpoint bevat counters (bijv. totale generatietokens) en histogrammen (TTFT) en documenteert een model_name-labelstrategie.
• TGI documenteert metingen inclusief wachtrijgrootte, aanvraagduur, gegenereerde tokens en gemiddelde tijd per token.
• Triton documenteert /metrics-expositie en metingschakelaars.

PromQL-voorbeelden voor LLM-latentie en doorvoer dashboards

# p95 end-to-end latentie voor een applicatiehistogram
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

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

# Tokens/seconde (output) over alle modellen
sum(rate(llm_tokens_total{direction="out"}[5m]))

# TGI wachtrijgrootte (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’ histogramrichtlijn legt uit dat histogram-percentielen server-side worden berekend uit buckets met behulp van histogram_quantile().

OpenTelemetry instrumentatienotities voor LLM-systemen

• OTLP is het OpenTelemetry Protocol dat specificeert hoe telemetrie wordt gecodeerd/gezonden tussen bronnen, collectors en backends.
• OpenTelemetry SDK-configuratie documenteert omgevingsvariabelen zoals OTEL_EXPORTER_OTLP_ENDPOINT (en protocolopties) voor het exporteren van telemetrie.
• OpenTelemetry Python contrib documenteert FastAPI-instrumentatie-ondersteuning voor automatische en handmatige instrumentatie.
• GenAI-semantische conventies bevatten een opt-in stabiliteitsmechanisme via OTEL_SEMCONV_STABILITY_OPT_IN voor GenAI-conventiesmigratie.

Kort Python-voorbeeld: metingen + traces + logs

Het onderstaande fragment demonstreert:

• Prometheus-metingenexposition (/metrics) voor “monitoring LLM-inferentie met Prometheus”
• OpenTelemetry-traces geëxporteerd via OTLP (vendor-neutraal)
• Gestructureerde logs gecorreleerd met trace-context, met een privacy-veilige standaard (log geen ruwe prompts)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (pull-based metingen)
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 Inference API", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Logging (privacy-veilige standaard) ---
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 metingen ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "LLM requests total",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "End-to-end LLM request latency (seconds)",
    ["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())  # configure via OTEL_EXPORTER_OTLP_* env vars
)
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:
        # Vermijd het loggen van de volledige prompt; emit veilige metadata
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Vervang met werkelijke LLM-aanroep (Triton/vLLM/TGI client)
        time.sleep(0.15)
        output = "Hello from the model."

        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),
                # Logge GEEN ruwe prompt/output tenzij beleid het toestaat.
            }
        )

        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)

Inzetting, schaling, veiligheid en probleemoplossing

Inzetopties

Schaling en retentie: praktische beperkingen

• Prometheus lokale opslag: zonder expliciete grootte/tijd-vlaggen, is de retentietijd standaard 15d.
• Prometheus remote write: Prometheus documenteert remote write-afstelling voor schaling beyond “sane defaults”.
• Grafana Tempo: gepositioneerd als high-scale tracing-backend en kan metingen genereren uit spans met behulp van de metrics-generator (remote writes naar een Prometheus-databron).
• Loki-opslag: Loki’s docs benadrukken label-only indexering en gecomprimeerde chunk-opslag (objectopslag), waardoor labelstrategie centraal staat voor schaal en kosten.

Veiligheid en privacy: prompts kunnen PII bevatten

OpenTelemetry’s veiligheidsrichtlijn benadrukt dat telemetieverzameling per ongeluk gevoelige/persoonlijke informatie kan vastleggen; jij bent verantwoordelijk voor het passende behandeling daarvan.

Prometheus’ veiligheidsmodel waarschuwt dat Prometheus-endpoints niet mogen worden blootgesteld aan publiek toegankelijke netwerken (zoals het internet) omdat ze informatie over gemonitorde systemen serveren.

Operationele privacycontroles die “observabiliteit voor LLM-systemen” veilig houden:

• Standaard niet loggen van ruwe prompts/responses; log tokenaantallen, modelnaam, latentie en trace-ID’s in plaats daarvan.
• Redacteer/drop gevoelige attributen in collectors/pipelines (Collector-level filtering is een veelvoorkomende aanpak in ecosystemen).
• Forceer RBAC en retentiebeleid voor logs/traces; overweeg gevoelige-gegevens-scanners waar passend (bijv. vendors documenteren scanners voor telemetrie).

Probleemoplossingscontrolelijst

Als je Grafana-dashboard voor LLM-latentie er niet goed uitziet, debug dan in deze volgorde:

• Ingestiegezondheid
  • Prometheus: valideer scrape-succes en config-semantiek (Prometheus-configuratie definieert scrape jobs/instances).
  • OTLP: bevestig exporter-endpointconfiguratie (SDK’s gebruiken OTEL_EXPORTER_OTLP_ENDPOINT, protocolinstellingen).
• Schemamismatch
  • Dashboard verwacht model, maar je server emitteert model_name (vLLM documenteert expliciet model_name-labels).
• Cardinality-explosie
  • Iemand labelde met aanvraag-ID’s/prompt-hashes; Prometheus waarschuwt dat labelsets RAM/CPU/disk/netwerk-kosten verhogen en biedt cardinaliteitsrichtlijnen.
• Histogrammisbruik
  • Zorg ervoor dat je percentielen berekent uit _bucket-series met rate() en le; Prometheus legt histogram-percentielberekeningstrade-offs uit.
• Trace-sampling lacunes
  • Als je te agressief head-samplet, verdwijnen zeldzame langzame/fout-traces; tail sampling behoudt “belangrijke” traces op basis van volledige trace-criteria.
• Tempo span-metingenproblemen
  • Als je Tempo metrics-generator en span-metingen gebruikt, bevestig dan dat deze zijn ingeschakeld en afgestemd (Tempo documenteert metrics-generator en span-metingenprocessors; probleemoplossing bestaat voor generatorproblemen).
• GPU-metingen afwezig
  • Bevestig dat DCGM-exporter is ingezet en /metrics bereikbaar is (DCGM-exporter exposeert GPU-metingen over HTTP voor Prometheus).

Nuttige links

• Polling Agents in AI Assistants: 11 Implementation Patterns — de observabiliteitscontrolelijstsectie dekt precies welke background-agent metingen, logvelden en admin-weergaven moeten worden geïnstrumenteerd voor productie polling-systemen
• Observability: Monitoring, Metrics, Prometheus & Grafana Guide
• A2A vs MCP: Do AI Agents Really Need Both Protocols? — de observabiliteit en beveiligingssecties daar dekken wat er getracet moet worden in multi-agent systemen die beide protocollen combineren
• Multi-Agent Orchestration Patterns — de observabiliteitssectie dekt gedistribueerde tracingvereisten specifiek voor elk patroon: blackboard replay voor swarm, kostenattributie per agent, en convergentiebewaking voor mesh
• Google A2A Protocol in 2026: Adoption, Hype, and Reality — de beveiligings- en veelgemaakte foutensecties dekken precies welke observabiliteit je nodig hebt bij het inzetten van agents over A2A-grenzen
• What Is the A2A Protocol? Agent Cards and Tasks Explained — de observabiliteitssectie legt uit wat een cross-agent taaktrace moet vastleggen: taakstatusveranderingen, delegatieketens, artefacten en agent-to-agent berichten
• Prometheus Monitoring: Setup & Best Practices
• LLM Performance: Benchmarks, Bottlenecks & Optimization
• LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared
• RAG Step-by-Step Tutorial
• Prometheus configuration docs
• Prometheus exposition formats
• Prometheus instrumentation best practices
• Prometheus metric naming
• Prometheus histograms and summaries
• Prometheus alerting rules
• Prometheus alerting overview
• Alertmanager configuration
• Grafana dashboard JSON model
• Grafana provisioning
• NVIDIA Triton Inference Server metrics
• TorchServe metrics API
• NVIDIA DCGM exporter
• kube-prometheus-stack Helm chart
• Prometheus Operator getting started
• OpenTelemetry Prometheus exporter spec
• Prometheus guide for receiving OTLP
• LangSmith tracing with OpenTelemetry