Een observability-dashboard voor je LLM-calls

Klassieke Application Performance Monitoring (APM) schiet fundamenteel tekort zodra een softwarearchitectuur afhankelijk wordt van externe taalmodellen. Waar traditionele microservices falen met duidelijke HTTP-statuscodes zoals 500 Internal Server Error of direct zichtbare pieken in servergeheugen en CPU-belasting, faalt een LLM-integratie vrijwel altijd geruisloos. Een API-endpoint van een provider retourneert zonder morren een keurige statuscode 200 OK, terwijl de reactietijd ondertussen oploopt tot vijftien seconden, het tokenverbruik door een promptwijziging verdrievoudigt en de semantische kwaliteit van de gegenereerde tekst volledig instort.

Wie uitsluitend kijkt naar binaire uptime of generieke latency-gemiddelden, mist de cruciale signalen van operationele degradatie. Dit artikel valt binnen de pijler kwaliteitsborging en wijzigingsbeheer (A7); voor de onderliggende datamodellen en het vastleggen van spans en traces verwijzen we naar het ankerartikel over observability en logging voor LLM-toepassingen waarin de fundamenten van gestructureerde logging worden behandeld. In deze gids bouwen we die concepten uit naar een operationeel observability-dashboard waarmee engineeringteams realtime inzicht krijgen in elke individuele interactie met een modelprovider.

De vier pijlers van LLM-telemetrie: TTTR

Een doeltreffend dashboard voor LLM-aanroepen structureert zijn meetwaarden rond vier specifieke assen: Traces, Tokens, Tijd en Tarieven (samengevat als TTTR). In tegenstelling tot conventionele API's zijn deze vier variabelen bij AI-modellen onlosmakelijk met elkaar verweven. Een toename in het aantal invoertokens verhoogt immers niet alleen direct de variabele kosten, maar verlengt ook de verwerkingstijd van het model en vergroot de kans op netwerk-timeouts.

Een dashboard mag nooit blijven steken in eenrichtingsgrafieken. Het primaire ontwerpdoel is interactieve trace-correlatie: wanneer een team in een grafiek ziet dat de P99-latentie om 14:00 uur piekt naar twintig seconden, moet een klik op die piek direct de onderliggende traces tonen inclusief de exacte modelversie, het tokenaantal en eventuele mislukte tool-aanroepen.

Span-architectuur en distributed tracing in meertraps pipelines

In moderne AI-systemen staat een LLM-aanroep zelden op zichzelf. Een verzoek van een gebruiker activeert vaak een complexe keten: eerst worden vector-embeddings berekend om documenten op te halen, vervolgens genereert het model een JSON-structuur voor een databasequery, waarna een tweede LLM-aanroep het uiteindelijke antwoord formuleert. Zonder distributed tracing is het bij een trage reactie onmogelijk te achterhalen welke schakel faalde.

Wanneer een architectuur gebruikmaakt van een centrale proxy om aanvragen over meerdere backends te verdelen, injecteert de gateway tracing-headers in elke netwerkstap. Lees de uitleg over LLM API-aggregators om te zien hoe een centrale routeringslaag helpt bij het standaardiseren van metadata en foutafhandeling over verschillende leveranciers. Door traceparent-headers conform de W3C Trace Context-standaard mee te sturen, blijft de samenhang tussen frontend, applicatieserver en modelproxy volledig behouden.

{
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "parent_span_id": "5fb397be34d23b0f",
  "name": "llm.chat.completions",
  "start_time_unix_nano": 1786800000000000000,
  "end_time_unix_nano": 1786800001850200000,
  "attributes": {
    "gen_ai.system": "openai",
    "gen_ai.request.model": "gpt-4o",
    "gen_ai.response.model": "gpt-4o-2024-08-06",
    "gen_ai.usage.prompt_tokens": 1420,
    "gen_ai.usage.completion_tokens": 285,
    "gen_ai.usage.cached_tokens": 1024,
    "http.status_code": 200,
    "llm.ttft_ms": 420.5,
    "llm.total_duration_ms": 1850.2,
    "app.tenant_id": "tenant-corp-92",
    "app.environment": "production"
  }
}

Het bovenstaande fragment hanteert de OpenTelemetry Semantic Conventions voor generatieve AI. Door deze open standaarden strikt te volgen in plaats van propriëtaire vendor-formaten, kan het dashboard direct queries uitvoeren op uniforme attributen zoals gen_ai.usage.prompt_tokens, ongeacht of de onderliggende provider OpenAI, Anthropic of een lokaal draaiend open source model via vLLM is.

Latentiemetingen ontleed: TTFT, ITL en queueing delays

Het meten van uitsluitend de totale verwerkingstijd (end-to-end latency) geeft een vertekend beeld van de gebruikerservaring. Bij streaming responses via Server-Sent Events (SSE) ervaart een gebruiker een applicatie al als responsief zodra de eerste woorden binnen een halve seconde op het scherm verschijnen, zelfs als de totale tekstgeneratie tien seconden duurt. Het dashboard dient de tijdmeting daarom op te splitsen in drie componenten:

• Time To First Token (TTFT): De tijdsduur tussen het verzenden van de HTTP-request en de ontvangst van de allereerste streaming chunk. Dit omvat de netwerklatentie, TLS-handshake, eventuele wachtrijtijd bij de provider en de prefill-berekening over de volledige prompt.
• Inter-Token Latency (ITL): De gemiddelde tijd tussen opeenvolgende tokens tijdens de decodeerfase. Een stabiele ITL van 20 tot 30 milliseconden per token zorgt voor een vloeiende tekststroom (33 tot 50 tokens per seconde).
• Queueing Delay: De tijd dat een request op de provider-infrastructuur heeft gewacht voordat er rekenkracht op GPU-clusters werd toegewezen. Providers geven dit soms door via response headers.

Wanneer de TTFT plotseling verdubbelt terwijl het aantal prompt-tokens gelijk is gebleven, wijst dit vrijwel altijd op piekbelasting of wachtrijen bij de provider. Stijgt de ITL plotseling, dan duidt dit op throttling van de rekenkracht. Door percentielen (P50, P90, P99) voor beide metrieken gescheiden weer te geven, worden infrastructurele knelpunten direct herleidbaar.

Tokenbeheer, contextgroei en caching-ratio's bewaken

Ongecontroleerde groei van het contextvenster is een van de meest voorkomende oorzaken van oplopende rekeningen en vertraagde applicaties. In chatinterfaces of autonome agent-loops worden eerdere interacties vaak zonder restricties herhaaldelijk meegestuurd. Hierdoor groeit de prompt exponentieel bij elke gespreksronde, totdat de contextlimiet wordt bereikt of de kosten per interactie onrendabel worden.

Het dashboard moet tokenstatistieken uitsplitsen in prompt-tokens, gegenereerde completion-tokens en herbruikte cache-tokens. Grote AI-leveranciers bieden substantiële kortingen (vaak 50% tot 80%) wanneer statische systeemprompts in het geheugen van het cluster bewaard blijven. Door de cache-hit-ratio realtime te visualiseren, ziet het engineeringteam direct of een prompt-herstructurering daadwerkelijk geld bespaart.

Foutanalyse, applicatieve faalmodi en kwaliteitsbewaking

Bij het monitoren van LLM's vertelt de HTTP-statuscode slechts een fractie van de waarheid. Fouten zoals HTTP 429 (Rate Limit Exceeded) of HTTP 503 (Service Unavailable) zijn eenvoudig op te vangen met alerts. Veel gevaarlijker zijn applicatieve fouten waarbij de API een HTTP 200 retourneert, maar de inhoud onbruikbaar is. Denk aan het schenden van een JSON-schema, het hallucineren van niet-bestaande feiten, of een weigering van het model door overijverige veiligheidsfilters.

Om semantische degradatie te detecteren, combineert een dashboard kwantitatieve statusdata met kwalitatieve evaluatiescores. Voor bewezen methodes om gegenereerde antwoorden systematisch te toetsen op feitelijke juistheid en bronconsistentie, zie het praktische stappenplan over AI-antwoorden factchecken op ons gids-platform. Door periodieke steekproeven (bijvoorbeeld 2% van alle productie-antwoorden) asynchroon te laten scoren door een kleiner evaluatiemodel op metrieken zoals faithfulness en schema compliance, ontstaat een historische kwaliteitsgrafiek.

# Prometheus PromQL query voorbeelden voor LLM-monitoring

# 1. Percentage applicatieve fouten (HTTP fouten + ongeldige JSON payloads)
(
  sum(rate(llm_requests_total{status=~"error|invalid_schema"}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
) * 100

# 2. P95 Time To First Token (TTFT) per model in seconden
histogram_quantile(0.95, sum(rate(llm_ttft_seconds_bucket[5m])) by (le, model))

# 3. Realtime geschatte kosten per minuut per tenant
sum(rate(llm_estimated_cost_usd_total[5m])) by (tenant_id) * 60

# 4. Prompt Caching efficiëntie (percentage tokens uit cache)
(
  sum(rate(llm_tokens_total{type="cached"}[5m]))
  /
  sum(rate(llm_tokens_total{type="prompt"}[5m]))
) * 100

Data-sanitisatie, privacy en PII-masking in de pipeline

Het integraal loggen van volledige gebruikersprompts en gegenereerde antwoorden creëert aanzienlijke juridische en infrastructurele risico's. Prompts bevatten regelmatig privacygevoelige gegevens (PII), medische details, interne broncode of vertrouwelijke financiële cijfers. Wanneer deze ongefilterd worden opgeslagen in een centrale elastic- of ClickHouse-cluster, ontstaat een kwetsbaar doelwit voor datalekken en een overtreding van de AVG-principes rondom dataminimalisatie.

Een veilige observability-pipeline implementeert data-sanitisatie direct aan de rand van de applicatie (edge processing), voordat spans worden doorgestuurd naar de centrale opslag. Dit geldt eveneens voor de configuratie van authenticatiesleutels: raadpleeg de gids over het veilig beheren van API-sleutels om te voorkomen dat geheime tokens per ongeluk in trace-attributen of foutrapportages terechtkomen.

In een volwassen productieomgeving hanteert men daarom een getrapte data-opslagstrategie:

• Metadatamodus (100% van het verkeer): Tokens, responstijden, modelnamen, tenant-ID's en berekende kosten worden permanent opgeslagen voor dashboards en facturatie. De tekstvelden (prompt en response) blijven leeg.
• Sampling voor foutanalyse (100% van de fouten, 1% van het succes): Alleen bij gefaalde requests of een zeer kleine willekeurige steekproef worden tekstpayloads tijdelijk bewaard, met een harde automatische TTL (Time To Live) van bijvoorbeeld 72 uur.
• PII-masking via regex of lokaal NER-model: Voordat een span de applicatieserver verlaat, vervangen sanitisatie-filters e-mailadressen, BSN-nummers, creditcardgegevens en IP-adressen door generieke tokens zoals [REDACTED_EMAIL].

Architectuur voor een zelfgehoste telemetry-stack

Voor het inrichten van een enterprise-grade observability-dashboard is geen kostbare SaaS-dienst vereist. Met een combinatie van open source bouwstenen kan een schaalbare stack worden opgezet die miljoenen spans per dag verwerkt zonder dat vertrouwelijke data het eigen netwerk verlaat.

De architectuur bestaat uit vier modulaire lagen:

1. Instrumentatie-laag: De applicatiecode of API-gateway gebruikt de OpenTelemetry SDK om spans aan te maken rondom elke LLM-call. Metadata zoals tokens, latency en tenant-ID's worden als standaardattributen toegevoegd.
2. OpenTelemetry Collector: Een centrale collector ontvangt de traces via OTLP (gRPC of HTTP). De collector draait processors voor batching, PII-filtering en sampling voordat de data wordt doorgestuurd.
3. Opslag-backends: Een combinatie van ClickHouse voor analytische traces en gestructureerde logs, en Prometheus (of Mimir) voor snelle tijdreeksmetrieken en alarmeringen. ClickHouse biedt superieure compressie en razendsnelle query-mogelijkheden op willekeurige JSON-attributen.
4. Grafana Visualisatie: Het centrale dashboard waarin Grafana-panelen worden gekoppeld aan ClickHouse en Prometheus. Hier worden realtime kostenmeters, latency-heatmaps en foutoverzichten overzichtelijk gecombineerd.

Concrete alerting-drempels en operationele storingspatronen

Een dashboard is pas waardevol als het team tijdig wordt gewaarschuwd voordat eindgebruikers hinder ondervinden. Waar traditionele alerting vaak leunt op statische foutpercentages, vereist LLM-monitoring dynamische drempelwaarden die rekening houden met tokenvolumes en financiële budgetten.

Vier kritieke alert-regels die direct op het dashboard en via notificatiesystemen moeten worden geconfigureerd:

• Budget Burn-rate Alert: Activeer een P1-melding zodra de geschatte uitgaven over een rollend venster van 1 uur meer dan 300% bedragen van het historische uurgemiddelde. Dit voorkomt dat een oneindige agent-loop in korte tijd duizenden euro's aan API-credits verbruikt.
• TTFT P95 Degradatie: Sla alarm wanneer de 95e percentiel van de Time To First Token gedurende 5 opeenvolgende minuten boven de 3500 milliseconden uitkomt. Dit wijst op overbelasting bij de provider en triggert een automatische failover naar een secundair model.
• Structurele Schemavalidatiefouten: Trigger een waarschuwing zodra meer dan 2% van de requests resulteert in niet-parsbare JSON. Dit duidt op een gewijzigd instructiebegrip na een provider-update of een ondeugdelijke prompttemplate.
• Token Context Spikes: Waarschuw wanneer het gemiddelde prompt-tokenverbruik per gebruiker binnen een kwartier met meer dan 50% toeneemt, wat wijst op een falend context-reductiealgoritme.

Conclusie en operationele borging

Het opzetten van een doordacht observability-dashboard transformeert het beheer van LLM-toepassingen van blind vertrouwen naar een beheersbare, meetbare discipline. Door systematisch te sturen op Time To First Token, token-efficiëntie, cache-benutting en applicatieve foutpercentages krijgen engineeringteams de controle terug over externe AI-afhankelijkheden.

In een technologisch landschap waarin providers regelmatig modellen updaten, rekenquota wijzigen en latentie fluctueert, vormt continue telemetrie het enige betrouwbare kompas. Met gestandaardiseerde OpenTelemetry-instrumentatie, robuuste data-sanitisatie en realtime visualisatie blijft een AI-integratie betrouwbaar, snel en binnen het gestelde budget functioneren.