Observability voor LLM-systemen: Metrieken, Traces, Logs en Testen in Productie

LLM-systemen falen op manieren die traditionele API-bewaking niet kan oppassen — wachtrijen vullen zich stil, GPU-geheugen wordt lang voor CPU-busigheid volledig gebruikt, en latentie explodeert op het batchlaag-niveau in plaats van op het applicatie-laag-niveau. Deze gids behandelt een eind-afwerking observabiliteitsstrategie voor LLM-inferentie en LLM-toepassingen: wat je moet meten, hoe je het moet instrumenteren met Prometheus, OpenTelemetry en Grafana, en hoe je de telemetriepijplijn op schaal moet implementeren.

TL;DR (uitvoeringsoverzicht)

LLM-systemen verslechteren op manieren die klassieke “HTTP-latentie + foutenpercentage”-bewaking niet kan verklaren. Productie-klare Observabiliteit voor LLM-systemen moet snel en verdedigbaar antwoorden op:

• Of de gebruikerservaring verslechtert (staartlatentie, tijd tot eerste token, inter-token latentie, fouten en afbrekingen).
• Waar de tijd wordt besteed (wachtrijen versus batchen versus modeluitvoering; ophalen/hulpmiddelen/safe filters versus inferentie).
• Wat als eerste verzadigd raakt (GPU-gebruik en geheugenbelasting, KV-cache/wachtrijbelasting, CPU-tokenisering).
• Hoe kosten en capaciteit verschuiven (tokens per aanvraag, tokens/sec per GPU, cache-hitratio, verspilde generaties).
• Of de telemetrie veilig opgeslagen kan worden (prompts kunnen PII bevatten; voorkom gevoelige lekken in logs/attributen).

De meest duurzame ontwerp is een meervoudig signaal-pijplijn:

• Metrieken voor snelle detectie en capaciteitsplanning (Prometheus + PromQL; optionele lange-termijnopslag via Thanos/Cortex/Mimir/VictoriaMetrics).
• Traces voor causale afhankelijkheid op aanvraagniveau (OpenTelemetry met OTLP; back-ends zoals Tempo/Jaeger/Zipkin/Elastic APM).
• Logs voor context, gekoppeld aan traces (Loki/Elastic/OpenSearch), ontworpen voor lage kaartelijkheid metadata.
• Profielen voor CPU/geheugen-hotspots en staartlatentie (Grafana Pyroscope).
• Synthetische + belastingstesten om regressies te detecteren voor gebruikers (Grafana k6; blackbox-stijl proeven).
• SLO’s om gebruikersuitkomsten te meten en actieve waarschuwingen te activeren (foutbudget; verbruikssnelheidstijl).

Wat maakt observabiliteit voor LLM-systemen anders

Omvangsnota: het doel LLM-framework is niet gespecificeerd. Voorbeelden in dit artikel behandelen veelvoorkomende servers/frameworks (Triton, vLLM, TGI, LangChain/LangSmith) en blijven van toepassing op andere stacks door gelijkwaardige metrieken en spans te vervangen.

LLM’s brengen operationele gedragingen met zich mee die verschillen van conventionele webdiensten:

• Variabele werk per aanvraag: tokenaantallen (invoer/uitvoer) variëren sterk, dus “aanvragen per seconde” kan stabiel lijken terwijl token doorvoer krimpt. TGI en vLLM exporteren expliciet token- en tokenlatentie-gerelateerde telemetrie om dit type bewaking te ondersteunen.
• Wachtrijen + continue batchen: doorvoer hangt af van batchen/wachtrij disciplines; wachtrijgrootte en batchgrootte worden eerste-klasindicatoren (TGI exporteert beide).
• Streaming gebruikerservaring: gebruikers letten op TTFT en inter-token latentie minstens zo veel als op volledige responsduur; OpenTelemetry standaardiseert zelfs server TTFT/time-per-token metrieken onder GenAI semantische conventies.
• GPU-pressie domineert faalmodi: GPU-gebruik en GPU-geheugen (inclusief gebruikt geheugen) zijn centraal voor betrouwbaarheid; NVIDIA’s DCGM exporter bestaat specifiek om GPU-telemetrie via een Prometheus /metrics endpoint te openen.
• Meervoudige pijplijnen: ophalen, tool-aanroepen, veiligheidsfilters en postverwerking betekent dat eind-afwerking latentie een samenstelling is van meerdere spans/wachtrijen—maak distribueerde tracing en zorgvuldige metriekontwerp essentieel.

Concreet voorbeelden van populaire inferentie-servers benadrukken dit:

• NVIDIA Triton Inference Server openbaart metrieken als platte tekst via /metrics (meestal :8002/metrics) en biedt vlaggen om metrieken in- en uit te schakelen en een metriekpoort te selecteren.
• vLLM openbaart een uitgebreide Prometheus /metrics endpoint met een vllm: voorvoegsel; zijn documentatie bevat tellers voor generatie tokens en histogrammen zoals tijd tot eerste token.
• Hugging Face TGI documenteert een /metrics endpoint met wachtrijgrootte, batchgrootte, eind-afwerking aanvraagduur, gegenereerde tokens en wachtrijduur.

Kern observabiliteits taken en vereiste LLM telemetrie

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

Metrieken: Voor online-serveringssystemen benadrukt Prometheus’ eigen instrumentatie richtlijnen queryaantal, fouten en latentie als sleutelmetrieken; LLM’s breiden dit uit met TTFT, per-token doorvoer/latentie, wachtrijlengte, batchgrootte en GPU-gebruik.

Traces: Traces zijn hoe je latentie en fouten attribueert over ophalen/hulpmiddelen/veiligheid/inferentie stappen; OpenTelemetry stelt traces/exporters voor als een leverancier-neutrale manier om telemetrie te uitzenden naar verzamelaars of back-ends.

Logs: Logs bieden leesbare context en “waar”, maar blijven op schaal alleen bruikbaar als je onbegrensde waarden indexeren vermijdt (voorbeeld: Loki indexeert alleen labels en slaat gecomprimeerde logblokken op in objectopslag).

Profielen: Continue profielen vangen productie CPU/geheugen gedrag met lage overhead sampling; Grafana Pyroscope is expliciet gericht op dit.

Synthetische tests en belastingstesten: Grafana k6 is een open-source belastingstesttool, en Grafana noemt Synthetische Bewaking aangedreven door k6 en uitgaat over eenvoudige protocollen checks.

SLO’s: Google’s SRE richtlijnen definiëren een SLO als doelwaarde/bereik voor een servicelevel gemeten door een SLI, en bieden richtlijnen voor waarschuwingen op SLO’s (precisie/herkennings/ detectietijd trade-offs).

Belangrijke LLM metriek blauwdruk

OpenTelemetry GenAI semantische conventies voor standaardisatie

OpenTelemetry biedt GenAI semantische conventies (status: “Ontwikkeling”) met standaard naamgeving voor GenAI metrieken 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 praktisch levertje voor draagbare “monitoring LLM modellen met OpenTelemetry” strategieën: één keer uitzenden en later dezelfde telemetrie naar OSS of leverancier back-ends routeren.

Ontwerpen van de telemetriepijplijn

Pull vs push

Prometheus is pull-first. Processen openbaren metrieken in een ondersteunde uitlegformaat, en Prometheus scant ze volgens geconfigureerde scrape taken.

Push is voor uitzonderingen. Prometheus’ “Wanneer het Pushgateway te gebruiken is” richtlijnen adviseren expliciet het Pushgateway alleen in beperkte gevallen (niet als algemene push vervanging), en de Pushgateway README benadrukt dat het “Prometheus niet in een push gebaseerde bewakingsysteem kan veranderen”.

LLM-specifieke praktische patroon:

• Gebruik pull voor inferentie-servers/exporters (Triton/vLLM/TGI metriek endpoints; DCGM exporter; node metrieken).
• Gebruik OTLP push voor traces/logs/OTel metrieken (OpenTelemetry Protocol definieert transport/encoding/delivery tussen bronnen, verzamelaars en back-ends).
• Gebruik remote write bij schaalbeheer buiten een enkele Prometheus (Prometheus biedt remote write tuning richtlijnen; Mimir/Thanos/Cortex bieden lange-termijn en/of HA opslagopties).

Agent vs sidecar vs gateway verzamelaars

OpenTelemetry documenteert een agent implementatiepatroon, waarbij telemetrie wordt gestuurd naar een Verzamelaar die naast de toepassing of op dezelfde host draait (sidecar/DaemonSet), en dan wordt geëxporteerd.

Voor Kubernetes ondersteunt sidecar injectie via de OpenTelemetry Operator (annotatiegebaseerde injectie).

Praktische regel van duim voor LLM-stacks:

• Gebruik een DaemonSet agent voor hostniveau verrijking en gedeelde pijplijnen over veel pods.
• Gebruik een sidecar wanneer je strikte per-werkbelasting isolatie of lokale filtering nodig hebt (vaak wanneer prompts gevoelige data bevatten).
• Gebruik een gateway verzamelaar voor gecentraliseerde staart sampling, batchen, herproberen en export fan-out.

Sampling en cardinaliteit controle

OpenTelemetry maakt duidelijk dat staart sampling sampling beslissingen toelaat met criteria afgeleid van een trace (niet mogelijk met kop sampling alleen).

Prometheus’ instrumentatie richtlijnen waarschuwen voor overgebruik van labels, bieden een regel van duim om cardinaliteit laag te houden en adviseren om metrieken te herontwerpen als potentieel cardinaliteit over ~100 gaat.

LLM-specifieke “cardinality valkuilen” om vroegtijdig te verbieden:

• Prompt tekst, respons tekst, conversatie-IDs, aanvraag-IDs als labels/attributen.
• Tool argumentblokken als span attributen.
• Onbegrensde “user_id” labels.

Voorkeur voor begrensde dimensies: model, model_family, endpoint, region, status_code, deployment, tenant (alleen als begrensd).

Vergelijking van LLM observabiliteits tools

Tools gemappt op observabiliteits taken

Grafana vs alternatieven voor visualisatie

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

Prometheus vs alternatieven voor metriek back-ends

• Prometheus lokale opslag standaard: als retentievlaggen niet zijn ingesteld, is retentie standaard 15d (plan retentie/kosten vroegtijdig).
• Grafana Mimir wordt beschreven als horizontaal schaalbaar, HA, multi-tenant lange-termijnopslag voor Prometheus en OpenTelemetry metrieken.
• Thanos wordt beschreven als een zeer beschikbare Prometheus setup met lange-termijnopslag mogelijkheden.
• Cortex beschrijft zichzelf als horizontaal schaalbaar, HA, multi-tenant lange-termijnopslagoplossing voor Prometheus en OpenTelemetry metrieken.
• VictoriaMetrics Cloud documenteert Prometheus remote write integratie voor lange-termijnopslag.
• Amazon Managed Service for Prometheus beschrijft een beheerde aanbieding die schaalt met inname/consult behoeften en ondersteunt PromQL en remote write.

Praktisch implementatie kookboek

Metrieknamen en types om vandaag te implementeren

OpenTelemetry GenAI semantische conventies (status: Ontwikkeling) definiëren metrieknamen 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

Serverzijde voorbeelden die je direct kunt scannen:

• vLLM’s Prometheus endpoint bevat counters (bijv. generatie tokens totaal) en histograms (TTFT) en documenteert een model_name labelstrategie.
• TGI documenteert metrieken inclusief wachtrijgrootte, aanvraagduur, gegenereerde tokens en gemiddelde tijd per token.
• Triton documenteert /metrics openbaart en metriektoggles.

PromQL voorbeelden voor LLM latentie en doorvoer dashboards

# p95 eind-afwerking latentie voor een applicatie histogram
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

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

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

# TGI wachtrijgrootte (meter)
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 richtlijnen leggen uit dat histogram quantielen worden berekend serverzijde vanuit buckets met histogram_quantile().

OpenTelemetry instrumentatie notities voor LLM-systemen

• OTLP is de OpenTelemetry Protocol die specificeert hoe telemetrie wordt gecodeerd/overgedragen tussen bronnen, verzamelaars en back-ends.
• OpenTelemetry SDK configuratie documenteert omgevingsvariabelen zoals OTEL_EXPORTER_OTLP_ENDPOINT (en protocolopties) voor het exporteren van telemetrie.
• OpenTelemetry Python contrib documenteert FastAPI instrumentatieondersteuning voor automatische en handmatige instrumentatie.
• GenAI semantische conventies bevatten een opt-in stabiliteitsmechanisme via OTEL_SEMCONV_STABILITY_OPT_IN voor GenAI conventies migratie.

Kort Python voorbeeld: metrieken + traces + logs

Het snippet hieronder demonstreert:

• Prometheus metriekexpositie (/metrics) voor “LLM inferentie bewaken met Prometheus”
• OpenTelemetry traces geëxporteerd via OTLP (leverancier-neutraal)
• Gestructureerde logs gekoppeld aan trace context, met een privacyveilige standaard (log geen onbewerkte prompts)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (pull-based metrieken)
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 Inferentie 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 metrieken ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "LLM aanvragen totaal",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Eind-afwerking LLM aanvraaglatentie (seconden)",
    ["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())  # configureer via OTEL_EXPORTER_OTLP_* omgevingsvariabelen
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "onbepaald"
    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 loggen van 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 actuele LLM oproep (Triton/vLLM/TGI client)
        time.sleep(0.15)
        output = "Hallo van het 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),
                # Voeg geen onbewerkte prompt/uitvoer toe tenzij beleid dit 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)

Implementatie, schaalbaarheid, beveiliging en probleemoplossing

Implementatieopties

Schaalbaarheid en retentie: praktische beperkingen

• Prometheus lokale opslag: zonder expliciete grootte/tijd vlaggen, is de retentietijd standaard 15d.
• Prometheus remote write: Prometheus documenteert remote write tuning voor schaalbaarheid buiten “sane defaults”.
• Grafana Tempo: positioneert als hoge-schaal tracing back-end en kan metrieken genereren vanuit spans met de metrics-generator (remote writes naar een Prometheus gegevensbron).
• Loki opslag: Loki’s documentatie benadrukt label-only indexing en gecomprimeerde chunk opslag (objectopslag), waardoor labelstrategie centraal staat voor schaalbaarheid en kosten.

Beveiliging en privacy: prompts kunnen PII bevatten

OpenTelemetry’s beveiligingsrichtlijnen benadrukken dat telemetrie verzameling onbedoeld gevoelige/persoonlijke informatie kan vangen; je bent verantwoordelijk om dit correct te behandelen.

Prometheus’ beveiligingsmodel waarschuwt dat Prometheus endpoints niet moeten worden blootgesteld aan openbare netwerken (zoals het internet) omdat ze informatie over bewakte systemen serveren.

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

• Standaard niet loggen van onbewerkte prompts/antwoorden; log tokenaantallen, modelnaam, latentie en trace-IDs in plaats daarvan.
• Verwijder/geen gevoelige attributen in verzamelaars/pijplijnen (Collector-niveau filtering is een veelvoorkomende aanpak over ecosystemen).
• Uitvoeren van RBAC en retentiebeleid voor logs/traces; overweeg gevoeligsdata scanners waar nodig (bijv. leveranciers documenteren scanners voor telemetrie).

Probleemoplossing checklist

Als je Grafana dashboard voor LLM latentie er verkeerd uitziet, debug in deze volgorde:

• Ingestie gezondheid
  • Prometheus: valideren scrape succes en config semantiek (Prometheus configuratie definieert scrape taken/instances).
  • OTLP: bevestigen exporter endpoint configuratie (SDKs gebruiken OTEL_EXPORTER_OTLP_ENDPOINT, protocolinstellingen).
• Schema mismatch
  • Dashboard verwacht model, maar je server emit model_name (vLLM documenteert expliciet model_name labels).
• Cardinaliteit explosie
  • Iemand gelabeld met aanvraag IDs/prompt hashes; Prometheus waarschuwt labelsets verhogen RAM/CPU/disk/netwerk kosten en biedt cardinaliteit richtlijnen.
• Histogram misbruik
  • Zorg ervoor dat je quantielen berekent vanaf _bucket series met rate() en le; Prometheus legt histogram quantile berekening trade-offs uit.
• Trace sampling gaps
  • Als je te agressief kop-samples, verdwijnen zeldzame traag/fout traces; staart sampling behoudt “belangrijke” traces op basis van volledige trace criteria.
• Tempo span-metriek problemen
  • Als je Tempo metrics-generator en span-metrieken gebruikt, bevestig dat het is ingeschakeld en afgestemd (Tempo documenteert metrics-generator en span-metriek processors; probleemoplossing bestaat voor generator problemen).
• GPU metrieken afwezig
  • Bevestig DCGM exporter is geïmplementeerd en /metrics is bereikbaar (DCGM exporter openbaart GPU metrieken over HTTP voor Prometheus).

Nuttige links

• Observabiliteit: Bewaking, Metrieken, Prometheus & Grafana Gids
• Prometheus Bewaking: Opzet & Beste Practijken
• LLM Prestaties: Benchmarks, Bottlenecks & Optimalisatie
• LLM Hosting: Lokale, Self-Hosted & Cloud Infrastructure Vergelijking
• RAG Stap-voor-stap Tutorial
• Prometheus configuratie 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