LLM Logging Best Practices: 9 Regels Die Wij in Productie Volgen [2026]

LLM Logging Best Practices: 9 Regels Die Wij in Productie Volgen [2026]

Deze negen LLM logging best practices zijn de regels waar onze productiestack daadwerkelijk op draait: we loggen 1,2 miljoen LLM-requests per maand via vier services, en elk request komt in Grafana Loki terecht als één JSON-regel met model, tokens, latency, cost_usd en trace_id. structlog 25.4.0 schrijft het record, Presidio verwijdert eerst de PII, en de hele pipeline is de logginghelft van onze observability-stack.

Belangrijkste punten

• Log elk LLM-request als gestructureerde JSON met 14+ benoemde velden, nooit vrije tekst.
• Masker PII vóór het schrijven van de log met Presidio of gelijkwaardig, niet erna.
• Koppel OpenTelemetry GenAI semantic convention-attributen aan elke trace.
• Bij 1 miljoen requests per dag kosten dezelfde 60GB $108 per maand in Datadog, $30 in Loki en $1,20 in ClickHouse.

Wat LLM-logging eigenlijk betekent (en waarom "alles loggen" niet werkt)

LLM-logging betekent het vastleggen van een gestructureerd record van elk modelrequest en elke response: de prompt, de completion, het aantal tokens, latency, kosten en de trace die alles aan een gebruikerssessie koppelt. Het is geen infrastructuurlogging. CPU, geheugen en pod-restarts horen in je metricsstack; dit artikel gaat alleen over het record op requestniveau waarmee je modelgedrag debugt, kost en audit.

De reflex om "maar alles te loggen" sterft hard, en is duur. Volledige prompts en completions bij 1 miljoen requests per dag produceren grofweg 60GB tekst per maand, en een deel van die tekst is klant-PII die je nu voor onbepaalde tijd opslaat. Het dataminimalisatiebeginsel uit artikel 5 van de AVG vereist dat persoonsgegevens "toereikend, ter zake dienend en beperkt tot wat noodzakelijk is" zijn, en een rauwe promptdump faalt op dag één voor die toets. Alles loggen is geen strategie; het is een risico met een maandfactuur.

Wat zijn de 9 LLM-loggingregels?

Negen regels, in de volgorde waarin we ze zouden implementeren: log volledige prompts en responses met gehashte identifiers, emit gestructureerde JSON, leg tokens en kosten per request vast, koppel OpenTelemetry-tracecontext, masker PII vóór het schrijven, sample bij hoog volume, stel bewaartermijnen in, scheid veiligheidsgebeurtenissen af en maak het resultaat doorzoekbaar. Bij elke regel hieronder hoort de code of tabel die hem afdwingt.

Regel 1: Log de volledige prompt en response (met hashes, geen rauwe PII)

Log de volledige prompt en de volledige completion van elk request, want met partiële logs sta je tijdens een incident zonder enig record van wat het model daadwerkelijk zag. De ene uitzondering is identiteit: schrijf nooit rauwe gebruikers-ID's, e-mailadressen of namen in het record. Sla in plaats daarvan een SHA-256-hash van de gebruikers-ID op. Met een hash kun je offline nog steeds de volledige sessiegeschiedenis van één gebruiker reconstrueren, terwijl de logregel zelf waardeloos blijft voor wie hem niet mag lezen. Dezelfde logica voor systeemprompts: hash ze, log de hash en bewaar de plaintext in je promptregistry, waar ze toch al versiebeheer hebben.

Regel 2: Gebruik gestructureerde JSON: elk veld benoemd, niets als vrije tekst

Voor LLM logging best practices in Python of elke andere taal is gestructureerd loggen in JSON de niet-onderhandelbare: elk veld benoemd, getypeerd en doorzoekbaar, niets gedumpt als geformatteerde string. Een vrije-tekstregel als INFO called gpt-4o, took 812ms kun je alleen greppen. Een JSON-record kun je aggregeren per model, optellen per kosten en joinen aan een trace. OpenAI's eigen production best practices drukken je op hetzelfde idee: leg gestructureerde metadata vast op de SDK-laag in plaats van met printstatements.

Dit is het schema dat elke Techsy-service emit, veertien velden:

{
  "request_id": "req_01J9XK4M7Q",
  "timestamp": "2026-07-18T09:24:31.482Z",
  "environment": "production",
  "model": "claude-sonnet-4-20250514",
  "prompt_tokens": 1284,
  "completion_tokens": 396,
  "latency_ms": 812,
  "cost_usd": 0.0098,
  "system_prompt_hash": "sha256:9f2c1a4e...",
  "user_id_hash": "sha256:b7e4d831...",
  "rag_sources": ["kb/pricing-2026.md", "kb/refund-policy.md"],
  "guardrail_result": "pass",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

Drie velden verdienen een toelichting. cost_usd wordt op requesttijd berekend uit het aantal tokens en het gepubliceerde tarief van het model, nooit achteraf aangevuld door een nachtelijke job. De twee hashvelden zijn het compromis van Regel 1: offline correleerbaar, ondoorzichtig in de log. En trace_id en span_id zijn W3C-tracecontextwaarden, wat precies is waar Regel 4 over gaat.

Als vier services die providers rechtstreeks aanroepen klinkt als vier plekken om te instrumenteren: een LiteLLM-proxy centraliseert het: één logginghook vóór elke provider.

Regel 3: Leg tokentellingen en kosten per request vast

Tokengebruik bijhouden hoort in de logregel zelf, niet in een warehouse-job die morgen draait. Elke provider geeft het aantal input- en outputtokens terug in de response; vermenigvuldig met het per-token-tarief van het model op dat exacte moment en schrijf cost_usd in het record. Tarieven veranderen, en verschillen voor gecachete versus verse inputtokens, dus later kosten berekenen met een statische prijstabel herschrijft stilletjes de geschiedenis. Met kosten op elke regel wordt "welke feature is duur?" een query van één regel in plaats van een financeproject, en het voedt direct het werk om je LLM-API-kosten te verlagen.

Regel 4: Koppel tracecontext (OpenTelemetry GenAI Semconv)

Een logregel zonder trace-ID is een wees: je kunt hem lezen, maar niet zien welke retry, welke RAG-stap of welke gebruikersbeurt hem produceerde. De oplossing is OpenTelemetry's GenAI semantic conventions, de standaard attribuutnamen voor het instrumenteren van modelaanroepen. Emit de log binnen een actieve span en de trace_id en span_id koppelen zichzelf, zodat één klik in Grafana je van de trace-waterval rechtstreeks naar het rauwe record brengt.

De attributen die het waard zijn om op elke gen_ai-span te zetten:

from opentelemetry import trace

tracer = trace.get_tracer("ai-sdr")

with tracer.start_as_current_span("chat.completion") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4-20250514")
    response = client.messages.create(**payload)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
    log.info("llm.request", cost_usd=cost)  # Rule 2 record, trace IDs auto-attached

Regel 5: Masker PII vóór het loggen

PII maskeren moet gebeuren vóórdat het record geschreven wordt, niet achteraf wegpoetsen. Zodra een e-mailadres in Loki staat, staat het ook in je objectstorage-backups, en "we hebben het later verwijderd" is geen AVG-antwoord. In onze setup draait Microsoft Presidio als structlog-processor en vangt 94% van de e-mails en telefoonnummers voordat ze Loki bereiken; de missers zijn bijna allemaal vreemde notatie, die we in custom recognizers patchen zodra we ze vinden.

De hele hook is vijftien regels:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

PII_ENTITIES = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD", "IBAN_CODE"]

def redact_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en", entities=PII_ENTITIES)
    return anonymizer.anonymize(text=text, analyzer_results=results).text

# In the structlog processor chain, before JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

Maskering zit in dezelfde pipeline-laag als je input- en outputfilters, en moet op dezelfde manier getest worden. Onze guardrail-pipeline behandelt een gelekt e-mailadres in een log als een falende eval, niet als een ops-voetnoot.

Regel 6: Sample slim bij hoog volume

Onder ruwweg 100K requests per dag log je alles. Daarboven is full-volume logging een opslagbelasting op data die je nooit leest, en is sampling hoe je de records houdt die ertoe doen. Het addertje: random sampling is de slechtste optie voor LLM-verkeer, want fouten, weigeringen en requests van vijf dollar zijn per definitie zeldzaam, dus een uniform 10%-tarief gooit precies de events weg die je debugt. Sample op uitkomst, niet op muntje.

Een veelgebruikte setup is regelgebaseerd aan de randen (productie- en enterprisetenants: altijd loggen) plus tail-based in het midden. De logspecifieke invalshoek van dit raamwerk: je guardrail_result- en cost_usd-velden zijn de samplingsignalen, al aanwezig als je Regels 2 en 8 volgde.

Regel 7: Stel een bewaartermijn in voordat je er een nodig hebt

Een bewaartermijn voor logs is een beslissing die je neemt terwijl je kalm bent, want het alternatief is hem nemen tijdens een kostenreview bij het dubbele volume. Het bewaarbeperkingsbeginsel uit artikel 5 van de AVG zegt dat persoonsgegevens bewaard moeten worden "niet langer dan noodzakelijk", wat in de praktijk neerkomt op getrapte retentie:

Hot beantwoordt "wat gebeurde er tien minuten geleden?" snel en duur; cold beantwoordt "wat hebben we deze klant in maart verteld?" langzaam en goedkoop. Verwijder op schema, automatisch, of de tiers zijn slechts een diagram.

Regel 8: Log guardrail- en veiligheidsgebeurtenissen apart

Veiligheidsgebeurtenissen (guardrail-blokkades, weigeringen, beleidsschendingen) zijn geen telemetrie; het zijn auditrecords, en ze horen in een eigen stream. Drie redenen. Alarmering: een piek in geblokkeerde prompt-injecties moet iemand pagen, en je kunt die alert niet afstemmen tegen 1 miljoen routineregels. Retentie: compliance kan eisen dat veiligheidsrecords debuglogs jaren overleven. Toegang: auditors krijgen de veiligheidsstream, niet je hele firehose. Tag het vonnis in het hoofdrecord (guardrail_result: "block") en routeer het volledige record naar de aparte stream. Wat telt als veiligheidsgebeurtenis staat in onze gids over guardrail-gebeurtenissen.

Regel 9: Maak logs doorzoekbaar, niet alleen opgeslagen

Een log die je niet binnen een minuut kunt doorzoeken is een backup, geen observability-signaal. Doorzoekbaar betekent geïndexeerde velden, een querytaal die je wachtdienst echt kent, en dashboards die gebouwd zijn vóór het incident. Wij draaien Loki en doorzoeken het 30+ keer per week op kostenanomalieën, latencyregressies en "toon me elke weigering voor tenant X gisteren". De Grafana Loki-docs zijn het referentiewerk voor de syntaxis; het patroon dat zich terugverdient is filteren direct op geparseerde JSON-velden:

{service="ai-sdr"} |= "llm.request" | json
  | model = "claude-sonnet-4-20250514"
  | cost_usd > 0.05
  | line_format "{{.timestamp}} {{.request_id}} ${{.cost_usd}} {{.latency_ms}}ms"

Vijf regels, geen export naar een notebook. Als je huidige store dat niet kan, is dat het probleem dat je eerst moet oplossen.

Wat we in productie echt loggen

Genoeg theorie. Hier is de geredigeerde config van onze AI SDR-pipeline, de service achter het getal van 1,2 miljoen requests per maand uit de intro. Hij draait structlog 25.4.0 die JSON rendert, verscheept naar Grafana Cloud Loki via Promtail. Het model op deze pipeline is claude-sonnet-4-20250514, en elke aanroep gaat door exact de processorketen uit Regels 2 en 5:

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Rule 5: Presidio, before serialization
        add_otel_trace_ids,  # Rule 4: trace_id + span_id from the active span
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

Twee getallen uit het eerste kwartaal met deze setup. De maandelijkse ingest stabiliseerde op 47GB over vier services, en p95 log-schrijflatency is 3ms, wat betekent dat de pipeline niets meetbaars aan de requesttijd toevoegt.

De configwijziging die zichzelf terugverdiende: we voegden in maart 2026 cost_usd toe aan elke logregel. Binnen een week vonden we één prompttemplate die $340 per maand verbrandde in retry-loops. Een tijdelijke API-fout triggerde drie retries, die elk de volledige 4.000-token context opnieuw verstuurden. De logs maakten er een query van één regel van; zonder kosten per request was het opgedoken als een onverklaarde post in de volgende kwartaalbudgetreview.

Hoeveel kost LLM-logopslag op schaal?

Bij 1 miljoen requests per dag kost LLM-logopslag grofweg $1,20 tot $108 per maand voor dezelfde data, afhankelijk van de store. De rekensom: een volledig gestructureerd record is gemiddeld zo'n 2KB, dus 1 miljoen requests per dag is 2GB per dag, of 60GB per maand. De door vendors gepubliceerde prijzen hieronder (juli 2026) zijn wat die 60GB kost in drie veelgebruikte backends.

Bronnen: Datadog-prijzen, Grafana Loki en de ClickHouse-observability-docs.

Twee kanttekeningen, want dit is onze berekening op basis van vendortarieven, geen benchmark die we draaiden. Ten eerste gaat het getal van Datadog ervan uit dat je alles indexeert; de meeste teams indexeren een subset en betalen veel minder, terwijl Loki en ClickHouse vooral rekenen voor wat je opslaat. Ten tweede verbergt het $1,20 van self-hosted ClickHouse een echte rekening: de compute om het cluster te draaien en de engineer-uren om het te beheren. Bij 60GB per maand is een managed service bijna altijd het goedkopere totaalantwoord. Self-hosting begint zinvol te worden vanaf ruwweg 1TB per maand, waar het per-GB-verschil de ops-overhead overweldigt.

De spreiding is de kern. Bij 1 miljoen requests per dag is het verschil tussen Datadog-geïndexeerd en self-hosted ClickHouse grofweg 90x: $108 versus $1,20 voor dezelfde 60GB. Kies de store op architectuurtijd, niet nadat de factuur komt.

Welke loggingtool moet je kiezen?

Voor de meeste teams komt de keuze neer op vier opties: een LLM-native platform (Langfuse of LangSmith), een proxy-laag-tool (Helicone), of een gewone OpenTelemetry-pipeline naar infrastructuur die je al draait. De tabel dekt de beslis-punten die echt verschillen; dashboards, playback en promptversiebeheer zijn vanzelfsprekend in alle vier.

Onze mening, zonder omhaal: wij draaien OTel-native plus Loki omdat we de Grafana-stack al hadden voor al het andere, en één databron toevoegen won van een vierde vendor adopteren. Als je vanaf nul begint zonder enige observability-stack, dan zijn Langfuse's tracingmodel en zijn gratis tier het snelste pad naar nuttig, en de self-host-optie houdt de uitgang open. Als je kiest tussen de twee LLM-native leiders, dan doet onze Langfuse vs LangSmith-vergelijking de volledige vergelijking. En als logging één stuk is van een grotere monitoringbeslissing, dan dekt de volledige platformvergelijking het bredere veld.

Wat zijn de meest gemaakte LLM-loggingfouten?

Zes fouten verklaren de meeste kapotte LLM-loggingsetups die we bekeken hebben. Elke is goedkoop te vermijden als je hem vangt voordat het logvolume dat doet:

• Rauwe PII loggen zonder maskering. De meest voorkomende en de duurste. Eén supportexport of één gelekt bucket maakt van promptlogs een databeschermingsincident. Masker vóór het schrijven (Regel 5), niet bij het lezen.
• Geen bewaartermijn. Oneindige opslag is overal de standaard, en verdubbelt stilletjes je rekening elk jaar. Als je nooit verwijdert, heb je geen loggingsysteem; je hebt een archief met grootheidswaan.
• Ongestructureerde tekstlogs. Printoutput die je alleen kunt greppen werkt op demoschaal en zakt in elkaar bij 100K requests per dag, wanneer "vind elk gefaald request voor model X" een shell-script-middag wordt in plaats van een query.
• Alleen fouten loggen. Succesvolle requests zijn de baseline waarmee je drift detecteert, en ze zijn de grondstof van je evaluatiesysteem. Log ook de wins, met sampling als het volume het dwingt.
• Kosten velden negeren. Geen cost_usd per request betekent geen kostenalerts, geen attributie per feature, en de retry-loop van $340 per maand uit de productiesectie hierboven blijft onzichtbaar tot de kwartaalfactuur.
• Geen trace-correlatie. Logs die losstaan van spans maken debugging van multi-step agents gokwerk. Als je logregel geen trace_id heeft, is Regel 4 de oplossing.

Veelgestelde vragen

Wat moet je voor elk LLM-request loggen?

Minimaal: de volledige prompt en completion met PII gemaskeerd, de modelnaam, het aantal input- en outputtokens, latency, kosten in USD, een gehashte gebruikersidentifier en de OpenTelemetry trace- en span-ID's. Voeg RAG-bron-ID's en het guardrail-vonnis toe als je pipeline die fasen heeft. Veertien benoemde velden, één JSON-regel per request.

Wat is het beste formaat voor LLM-logs?

Gestructureerde JSON, één object per request, met elk veld expliciet benoemd. Vrije-tekstlogs kun je alleen greppen; JSON-records kun je aggregeren per model, optellen per kosten en joinen aan traces. Emit het record met een gestructureerde logger zoals structlog in Python of pino in Node, en render het met een JSON-serializer, nooit met stringformatting.

Hoe ga je om met PII in LLM-logs?

Masker vóór het schrijven van de log, niet erna. Haal de prompt en completion door een detector zoals Microsoft Presidio binnen je loggingpipeline, en vervang namen, e-mailadressen en telefoonnummers door tokens zoals <EMAIL_ADDRESS>. Zodra rauwe PII je logstore bereikt, staat hij ook in je backups, en achteraf verwijderen voldoet zelden aan de minimalisatietoets van de AVG.

Hoeveel kost LLM-logopslag op schaal?

Voor 1 miljoen requests per dag, zo'n 60GB per maand bij 2KB per record, reken op grofweg $108 per maand op Datadog's geïndexeerde LLM Observability-prijzen, $30 per maand op Grafana Cloud Loki, of zo'n $1,20 per maand aan gecomprimeerde S3-opslag voor self-hosted ClickHouse plus compute. Dat zijn door vendors gepubliceerde tarieven per juli 2026; self-hosting voegt er engineer-tijd bovenop.

Wat zijn OpenTelemetry GenAI semantic conventions?

Het zijn OpenTelemetry's standaard attribuutnamen voor het instrumenteren van LLM-aanroepen: gen_ai.system voor de provider, gen_ai.request.model voor het model, gen_ai.usage.input_tokens en output_tokens voor het aantal tokens, en gen_ai.response.finish_reasons voor waarom de generatie stopte. Ze gebruiken betekent dat elke OTel-compatibele backend, van Jaeger tot Tempo tot Langfuse, je traces leest zonder custom parsers.

Hoe sample je LLM-logs bij veel verkeer?

Houd elke fout, elke guardrail-blokkade en elk request boven een kostendrempel, en sample de rest. Deze tail-based aanpak bewaart de zeldzame events die je daadwerkelijk debugt, terwijl uniform random sampling ze weggooit in hetzelfde tempo als saai verkeer. Onder 100K requests per dag sla je sampling helemaal over en log je alles.

Hoe lang moet je LLM-logs bewaren?

Trap het af: 7 dagen hot voor live debugging, 30 dagen warm voor incidentreview en kostenanalyse, en tot 1 jaar cold in gecomprimeerde object storage voor compliance en audits. Het bewaarbeperkingsbeginsel van de AVG verbiedt persoonsgegevens langer te bewaren dan noodzakelijk, dus koppel aan elke tier automatische verwijdering in plaats van handmatige opschoning.

Wat is het verschil tussen LLM-logging en LLM-tracing?

Een log is een plat record van één event: dit request gebeurde, met deze velden. Een trace is een causale boom van spans over een heel requestpad, zeg retrieval, dan de modelaanroep, dan twee toolaanroepen. Logs vertellen je wat; traces vertellen je waar en waarom. Productiesetups emitten beide, gejoined op trace_id.

Conclusie

Recap: log elk request als JSON met benoemde velden, bereken kosten op requesttijd, koppel OTel-tracecontext, masker PII vóór het schrijven, sample op uitkomst zodra je voorbij 100K requests per dag gaat, en kies een store die je echt kunt doorzoeken. De negen regels zijn zo gerangschikt dat je ze één per sprint kunt adopteren, en Regels 2, 4 en 5 zijn de drie die zich het snelst terugverdienen. Als je de bredere monitoringstack rond de logs kiest, begin dan bij ons overzicht van de beste AI-observability-platforms. En als je hulp nodig hebt om gestructureerd loggen voor je LLM-stack aan te sluiten, vraag dan een gratis consult aan.