Observabilitet för LLM-system: Mätvärden, spårning, loggar och testning i produktion

LLM-system (storspråkmodeller) misslyckas på sätt som traditionell API-övervakning inte kan upptäcka — köer fylls tyst, GPU-minne mättas långt innan CPU ser ut att vara upptagen, och latens ökar explosionsartat vid batchlageret snarare än vid applikationslagret.

Den här guiden täcker en helhetsstrategi för observerbarhet för LLM-inferens och LLM-applikationer: vad som ska mätas, hur man instrumenterar det med Prometheus, OpenTelemetry och Grafana, samt hur man distribuerar telemetripipelinen i stor skala.

Fullständiga assistentstacker lägger till hämtning (retrieval), verktygsanrop och ruttning ovanpå rå inferens; AI-assistantarkitektur visar var observerbarhet passar in bland dessa lager.

TL;DR (Sammanfattning för beslutsfattare)

LLM-system försämras på sätt som klassisk övervakning av ”HTTP-latens + felrate” inte kan förklara. Produktionskvalitets Observerbarhet för LLM-system måste besvara följande snabbt och på ett försvarbart sätt:

• Om användarupplevelsen försämras (svanslatens, tid till första token, inter-token-latens, fel och avbrott).
• Var tiden ägnas (kö vs batching vs körning av modell; hämtning/verktyg/säkerhetsfilter vs inferens).
• Vad mättas först (GPU-utnyttjande och minnespress, KV-cache-/köpress, CPU-tokenisering).
• Hur kostnad och kapacitet förändras (token per förfrågan, token/sek per GPU, cache-täffrekvens, slöserade genereringar).
• Om telemetri är säker att lagra (prompter kan innehålla personliga uppgifter; förhindra läckage av känslig information till loggar/attribut).

Den mest resilienta designen är en pipeline med flera signaler:

• Mätvärden (Metrics) för snabb detektering och kapacitetsplanering (Prometheus + PromQL; valfritt långtidslagring via Thanos/Cortex/Mimir/VictoriaMetrics).
• Spår (Traces) för orsakssamband på begäran-nivå (OpenTelemetry med OTLP; backends som Tempo/Jaeger/Zipkin/Elastic APM).
• Loggar för kontext, korrelerade med spår (Loki/Elastic/OpenSearch), designade för metadata med låg kardinalitet.
• Profilering för CPU/minnes-hotspots och svanslatens (Grafana Pyroscope).
• Syntetiska + lasttester för att upptäcka regressioner innan användarna gör det (Grafana k6; blackbox-liknande probing).
• SLO:er för att mäta användarresultat och driva agerbar alarmering (felbudgetar; burn-rate-stil).

Vad som gör observerbarhet för LLM-system annorlunda

Omfattningsnotering: Mål-LLM-ramverket är opreciserat. Exempel i denna artikel täcker vanliga servrar/ramverk (Triton, vLLM, TGI, LangChain/LangSmith) och förblir tillämpliga på andra stackar genom att substituera motsvarande mätvärden och spans.

LLM:er introducerar operativa beteenden som skiljer sig från konventionella webbtjänster:

• Variabel arbetsbelastning per begäran: Tokenräkning (in/out) varierar kraftigt, så ”begäran per sekund” kan se stabil ut medan tokentransportkollapsen sker. TGI och vLLM exporterar explicit token- och token-latensrelaterad telemetri för att stödja denna typ av övervakning.
• Kö + kontinuerlig batching: Transportkapaciteten beror på batch-/ködiscipliner; köstorlek och batchstorlek blir förstaklassindikatorer (TGI exponerar båda).
• Strömningsbaserad UX: Användare bryr sig om TTFT (tid till första token) och inter-token-latens minst lika mycket som total svarstid; OpenTelemetry standardiserar till och med server-TTFT/tid-per-token-mätvärden under GenAI-semantiska konventioner.
• GPU-pressure dominerar misslyckandemöjligheter: GPU-utnyttjande och GPU-minne (inklusive använt minne) är centralt för tillförlitlighet; NVIDIA:s DCGM-exporter finns specifikt för att exponera GPU-telemetri vid en Prometheus /metrics-ändpunkt.
• Multistegspipelines: Hämtning, verktygsanrop, säkerhetsfilter och efterbehandling innebär att slut-i-slut-latens är en sammansättning av flera spans/köer — vilket gör distribuerad spårning och noggrann mätvärdesdesign essentiell.

Konkreta exempel från populära inferensservrar belyser detta:

• NVIDIA Triton Inference Server exponerar mätvärden som ren text via /metrics (vanligtvis :8002/metrics) och tillhandahåller flaggor för att aktivera/inaktivera mätvärden och välja mätvärdesport.
• vLLM exponerar en omfattande Prometheus /metrics-ändpunkt med ett vllm:-prefix; dess dokumentation inkluderar räknare för generationstoken och histogram som tid till första token.
• Hugging Face TGI dokumenterar en /metrics-ändpunkt med köstorlek, batchstorlek, slut-i-slut-begäranvaraktighet, genererade token och kövaraktighet.

Kärnuppgifter för observerbarhet och krävd LLM-telemetri

Observerbarhet för LLM-system är enklast att implementera när man kartlägger uppgifter → signaler → verktyg, och sedan begränsar kardinalitet och sampling från dag ett.

Mätvärden: För online-serveringssystem, lyfter Prometheus egna instrumenteringsriktlinjer fram frågeräknare, fel och latens som nyckelmätvärden; LLM:er expanderar detta med TTFT, per-token transport/latens, kölängd, batchstorlek och GPU-utnyttjande.

Spår: Spår är hur du tillskriver latens och fel över hämtning/verktyg/säkerhet/inferens-steg; OpenTelemetry beskriver spår/exportörer som ett leverantörsneutralt sätt att emitiera och skicka telemetri till samlare eller backends.

Loggar: Logger ger människoläsbar kontext och ”varför”, men förblir bara användbara i stor skala om man undviker indexerings av obegränsade värden (exempel: Loki indexerar endast etiketter och lagrar komprimerade logghugg i objekt-lagring).

Profilering: Kontinuerlig profilering fångar produktions-CPU/minnesbeteende med låg overhead-sampling; Grafana Pyroscope är explicit positionerad för detta.

Syntetiska tester och lasttester: Grafana k6 är ett open-source-verktyg för lasttestning, och Grafana noterar att Synthetic Monitoring drivs av k6 och sträcker sig bortom enkla protokollkontroller.

SLO:er: Googles SRE-riktlinjer definierar en SLO som ett mål-värde/område för en tjänstenivå mätt av en SLI, och ger riktlinjer för alarmering på SLO:er (avvägningar mellan precision/återkallning/detekteringstid).

Nyckel-LLM-mätvärdesblåprint

OpenTelemetry GenAI-semantiska konventioner för standardisering

OpenTelemetry tillhandahåller GenAI-semantiska konventioner (status: ”Utveckling”) med standardnamn för GenAI-mätvärden som:

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

Denna standardisering är en praktisk hävstång för portabla strategier för ”övervakning av LLM-modeller med OpenTelemetry”: emitiera en gång och routa samma telemetri till OSS- eller leverantörsbackends senare.

Designa telemetripipelinen

Pull vs push

Prometheus är pull-först. Processer exponerar mätvärden i ett supported exponeringsformat, och Prometheus skrapar dem enligt konfigurerade scrape-jobb.

Push är för undantag. Prometheus’ ”När ska man använda Pushgateway”-guide rekommenderar explicit Pushgateway endast i begränsade fall (inte som ett generellt push-ersättande), och Pushgateway README betonar att den inte kan ”göra Prometheus till ett push-baserat övervakningssystem”.

Praktiskt mönster specifikt för LLM:

• Använd pull för inferensservrar/exportörer (Triton/vLLM/TGI-mätvärdesändpunkter; DCGM-exporter; nodmätvärden).
• Använd OTLP push för spår/loggar/OTel-mätvärden (OpenTelemetry Protocol definierar transport/kodning/leverans mellan källor, samlare och backends).
• Använd remote write när man skalar bort från en enskild Prometheus (Prometheus tillhandahåller riktlinjer för justering av remote write; Mimir/Thanos/Cortex tillhandahåller långtids- och/eller HA-lagringsalternativ).

Agent vs sidecar vs gateway-samlare

OpenTelemetry dokumenterar ett agent-distributionsmönster, där telemetri skickas till en Collector som körs bredvid applikationen eller på samma värd (sidecar/DaemonSet), och sedan exporteras.

För Kubernetes stöds sidecar-injektion via OpenTelemetry Operator (injektion baserad på annotationer).

Pragmatisk tumregel för LLM-stacks:

• Använd en DaemonSet-agent för värd-nivå-berikning och delade pipelines över många pods.
• Använd en sidecar när du behöver strikt per-arbetslast-isolering eller dedikerad lokal filtrering (vanligt när prompter kan innehålla känsliga data).
• Använd en gateway-samlare för centraliserad tail-sampling, batching, återförsök och export fan-out.

Sampling och kardinalitetskontroll

OpenTelemetry förtydligar att tail-sampling möjliggör sampleslut baserade på kriterier härledda från ett spår (inte möjligt med endast head-sampling).

Prometheus’ instrumenteringsriktlinjer varnar för överanvändning av etiketter, ger en tumregel att hålla kardinaliteten låg, och råder att redesigna mätvärden om potentiell kardinalitet överskrider ~100.

LLM-specifika ”kardinalitetsfällor” att förbjuda tidigt:

• Prompttext, svartext, konversations-ID:n, begäran-ID:n som etiketter/attribut.
• Verktygsargumentblobbar som span-attribut.
• Obegränsade ”user_id”-etiketter.

Föredra begränsade dimensioner: model, model_family, endpoint, region, status_code, deployment, tenant (endast om begränsad).

Jämförelse av verktyg för LLM-observerbarhet

Verktyg mappade till observerbarhetsuppgifter

Grafana vs alternativ för visualisering

• Grafana-dashboards består av paneler som frågar datakällor (inklusive Loki och Mimir) för att producera diagram och visualiseringar.
• Kibana tillhandahåller dashboards/visualiseringar som UI-lagret inom Elastic Stack.
• OpenSearch Dashboards tillhandahåller datavisualiseringsverktyg för OpenSearch.
• InfluxData:s dokumentation positionerar Chronograf som visualiseringskomponenten inom Influx-ekosystemet.

Prometheus vs alternativ för mätvärdesbackends

• Prometheus lokal lagring standard: om retention-flaggor inte är inställda, defaultas retentionstiden till 15d (planera retention/kostnad tidigt).
• Grafana Mimir beskrivs som horisontellt skalbar, HA, multi-tenant långtidslagring för Prometheus- och OpenTelemetry-mätvärden.
• Thanos beskrivs som en hög tillgänglighet Prometheus-setup med långtidslagringskapacitet.
• Cortex beskriver sig själv som en horisontellt skalbar, HA, multi-tenant långtidslagringslösning för Prometheus- och OpenTelemetry-mätvärden.
• VictoriaMetrics Cloud dokumenterar Prometheus remote write-integration för långtidslagring.
• Amazon Managed Service for Prometheus beskriver en hanterad tjänst som skalar med inmatnings/frågebehov och stödjer PromQL och remote write.

Praktisk implementeringskokbok

Mätvärdesnamn och typer att implementera idag

OpenTelemetry GenAI-semantiska konventioner (status: Utveckling) definierar mätvärdesnamn du kan standardisera på omedelbart:

• 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

Exempel på serversida som du kan skrapa direkt:

• vLLM:s Prometheus-ändpunkt inkluderar räknare (t.ex. totalt antal generationstoken) och histogram (TTFT) och dokumenterar en model_name-etikettstrategi.
• TGI dokumenterar mätvärden inklusive köstorlek, begäranvaraktighet, genererade token och medeltid per token.
• Triton dokumenterar /metrics-exponering och mätvärdestoggles.

PromQL-exempel för LLM-latens- och transportkapacitetsdashboards

# p95 slut-i-slut-latens för ett applikationshistogram
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

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

# Token/sek (output) över alla modeller
sum(rate(llm_tokens_total{direction="out"}[5m]))

# TGI köstorlek (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’ histogramriktlinjer förklarar att histogramkvantiler beräknas serversida från bucketar med hjälp av histogram_quantile().

Noteringar om OpenTelemetry-instrumentering för LLM-system

• OTLP är OpenTelemetry Protocol som specificerar hur telemetri koder/överförs mellan källor, samlare och backends.
• OpenTelemetry SDK-konfigurationsdokument dokumenterar miljövariabler som OTEL_EXPORTER_OTLP_ENDPOINT (och protokollalternativ) för export av telemetri.
• OpenTelemetry Python contrib dokumenterar FastAPI-instrumenteringsstöd för automatisk och manuell instrumentering.
• GenAI-semantiska konventioner inkluderar en opt-in-stabilitetsmekanism via OTEL_SEMCONV_STABILITY_OPT_IN för GenAI-konventionsmigration.

Kort Python-exempel: mätvärden + spår + loggar

Avsnittet nedan demonstrerar:

• Prometheus-mätvärdesexponering (/metrics) för ”övervakning av LLM-inferens med Prometheus”
• OpenTelemetry-spår exporterade via OTLP (leverantörsneutrala)
• Strukturerade loggar korrelerade med spårkontext, med en sekretesssäker standard (logga inte råa prompter)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (pull-baserade mätvärden)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (OTLP-spår)
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 (sekretesssäker 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-mätvärden ---
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())  # konfigurera via OTEL_EXPORTER_OTLP_* miljövariabler
)
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:
        # Undvik att logga hela prompten; emitiera säker metadata
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Ersätt med faktisk LLM-anrop (Triton/vLLM/TGI-klient)
        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),
                # Inkludera INTE rå prompt/output om inte policy tillåter det.
            }
        )

        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)

Distribution, skalning, säkerhet och felsökning

Distributionsalternativ

Skalning och retention: praktiska begränsningar

• Prometheus lokal lagring: utan explicit storlek/tid-flaggor, defaultas retentionstiden till 15d.
• Prometheus remote write: Prometheus dokumenterar remote write-justering för skalning bort från ”sunda standardvärden”.
• Grafana Tempo: positioneras som en högskala spårningsbackend och kan generera mätvärden från spans med metrics-generator (remote writes till en Prometheus-datakälla).
• Loki-lagring: Loki:s dokument betonas etikett-endast-indexering och komprimerad chunk-lagring (objekt-lagring), vilket gör etikettstrategi central för skala och kostnad.

Säkerhet och sekretess: prompter kan innehålla personliga uppgifter

OpenTelemetry:s säkerhetsriktlinjer betonar att telemetrisamling kan ofrivilligt fånga känslig/personlig information; du är ansvarig för att hantera den lämpligt.

Prometheus’ säkerhetsmodell varnar för att Prometheus-ändpunkter inte bör exponeras för offentligt tillgängliga nätverk (som internet) eftersom de serverar information om övervakade system.

Operativa sekretesskontroller som håller ”observerbarhet för LLM-system” säker:

• Standard för inte logga råa prompter/responser; logga tokenräkning, modellnamn, latens och spår-ID:n istället.
• Radera/droppa känsliga attribut i samlare/pipelines (Collector-nivå-filtrering är ett vanligt tillvägagångssätt över ekosystem).
• Genomför RBAC och retentionpolicy för loggar/spår; överväg skannrar för känsliga data där det är lämpligt (t.ex. dokumenterar leverantörer skannrar för telemetri).

Felsökningschecklista

Om din Grafana-dashboard för LLM-latens ser fel ut, felsök i denna ordning:

• Inmatningshälsa
  • Prometheus: validera scrape-success och konfigurationsemantik (Prometheus-konfiguration definierar scrape-jobb/instanser).
  • OTLP: bekräfta exporter-ändpunktskonfiguration (SDK:er använder OTEL_EXPORTER_OTLP_ENDPOINT, protokollinställningar).
• Schemamiktmotsvarighet
  • Dashboard förväntar sig model, men din server emitierar model_name (vLLM dokumenterar explicit model_name-etiketter).
• Kardinalitetsexplosion
  • Någon etiketterade med begäran-ID/prompt-hashar; Prometheus varnar för att labelsets ökar RAM/CPU/disk/nätverkskostnader och tillhandahåller kardinalitetsriktlinjer.
• Histogrammissbruk
  • Se till att du beräknar kvantiler från _bucket-serier med rate() och le; Prometheus förklarar histogramkvantilberäkningsavvägningar.
• Spår-samplingluckor
  • Om du head-samplingar för aggressivt, försvinner sällsynta långsamma/fel-spår; tail-sampling behåller ”viktiga” spår baserat på fullständiga spårkriterier.
• Tempo span-mätvärdesproblem
  • Om du använder Tempo metrics-generator och span-mätvärden, bekräfta att det är aktiverat och justerat (Tempo dokumenterar metrics-generator och span-mätvärdesprocessor; felsökning finns för generatorproblem).
• GPU-mätvärden frånvarande
  • Bekräfta att DCGM-exporter är distribuerad och /metrics är nåbar (DCGM-exporter exponerar GPU-mätvärden över HTTP för Prometheus).

Användbara länkar

• Polling Agents in AI Assistants: 11 Implementation Patterns — observerbarhetschecklistasektionen täcker exakt vilka bakgrundsagentmätvärden, loggfält och adminvyer som ska instrumenteras för produktionsbaserade polling-system
• Observability: Monitoring, Metrics, Prometheus & Grafana Guide
• A2A vs MCP: Do AI Agents Really Need Both Protocols? — observerbarhets- och säkerhetssektionerna där täcker vad man ska spåra i multi-agentsystem som kombinerar båda protokollen
• Multi-Agent Orchestration Patterns — observerbarhetssektionen täcker distribuerade spårningskrav specifika för varje mönster: blackboard-replay för swarm, kostnadsattributering per agent, och konvergensövervakning för mesh
• Google A2A Protocol in 2026: Adoption, Hype, and Reality — säkerhets- och vanliga misstagssektionerna täcker exakt vilken observerbarhet du behöver när du distribuerar agenter över A2A-gränser
• What Is the A2A Protocol? Agent Cards and Tasks Explained — observerbarhetssektionen förklarar vad en cross-agent-uppgiftsspårning behöver fånga: uppgiftsstatistikförändringar, delegeringskedjor, artefakter och agent-to-agent-meddelanden
• 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