LLM-logging beste praksis: 9 regler vi følger i produksjon [2026]

LLM-logging beste praksis: 9 regler vi følger i produksjon [2026]

Disse ni reglene for LLM-logging er det produksjonsstacken vår faktisk kjører: Vi logger 1,2M LLM-forespørsler i måneden på tvers av fire tjenester, og hver eneste ender opp i Grafana Loki som én JSON-linje med modell, tokens, latenstid, cost_usd og trace_id. structlog 25.4.0 skriver posten, Presidio fjerner PII først, og hele pipeline-en er logg-halvparten av observabilitetsstacken vår.

Nøkkelpunkter

• Logg hver LLM-forespørsel som strukturert JSON med 14+ navngitte felter, aldri fri tekst.
• Masker PII før logg-skrivingen med Presidio eller tilsvarende, ikke etterpå.
• Legg OpenTelemetry GenAI semantiske konvensjons-attributter på hvert spor.
• Ved 1M forespørsler/dag koster de samme 60GB 108$/måned i Datadog, 30$ i Loki og 1,20$ i ClickHouse.

Hva LLM-logging egentlig betyr (og hvorfor «bare logg alt» feiler)

LLM-logging betyr å fange en strukturert post av hver modellforespørsel og hvert svar: prompten, svaret, token-antall, latenstid, kostnad og sporet som binder alt til en brukersesjon. Det er ikke infrastrukturlogging. CPU, minne og pod-omstarter hører hjemme i metrikk-stacken din; denne artikkelen dekker bare posten på forespørselsnivå som lar deg feilsøke, kostnadsberegne og revidere modellatferd.

«Bare logg alt»-instinktet sitter dypt, og det er dyrt. Fulle prompter og svar ved 1M forespørsler om dagen produserer omtrent 60GB tekst i måneden, og en god del av den teksten er kunde-PII som du nå lagrer på ubestemt tid. GDPRs artikkel 5-prinsipp om dataminimering krever at persondata er «tilstrekkelig, relevant og begrenset til det som er nødvendig», og en rå prompt-dump stryker på den testen fra dag én. Å logge alt er ikke en strategi; det er en forpliktelse med en månedlig faktura.

Hva er de 9 LLM-loggreglene?

Ni regler, i rekkefølgen vi ville implementert dem: logg fulle prompter og svar med hashede identifikatorer, send ut strukturert JSON, fang tokens og kostnad per forespørsel, legg ved OpenTelemetry spor-kontekst, masker PII før skrivingen, sample ved høy volum, sett bevaringstrinn, skill ut sikkerhetshendelser og gjør resultatet søkbart. Hver regel nedenfor kommer med koden eller tabellen som håndhever den.

Regel 1: Logg full prompt og fullt svar (med hasher, ikke rå PII)

Logg den komplette prompten og det komplette svaret for hver forespørsel, fordi delvise logger er slik du ender opp med å stirre på en hendelse uten noen oversikt over hva modellen faktisk så. Det ene unntaket er identitet: Skriv aldri rå bruker-ID-er, e-poster eller navn inn i posten. Lagre en SHA-256-hash av bruker-ID-en i stedet. En hash lar deg fortsatt rekonstruere én brukers fulle sesjonshistorikk med et offline-oppslag, mens selve logglinjen forblir ubrukelig for alle som ikke burde lese den. Samme logikk for systemprompter: hash dem, logg hashen og behold klarteksten i prompt-registeret ditt der den allerede er versjonskontrollert.

Regel 2: Bruk strukturert JSON: Hvert felt navngitt, ingenting som fri tekst

For LLM-logging beste praksis i Python eller ethvert annet språk er strukturert logging i JSON det ene ikke-forhandlbare: hvert felt navngitt, typet og søkbart, ingenting dumpet som en formatert streng. En fri-tekst-linje som INFO called gpt-4o, took 812ms kan bare greppes. En JSON-post kan aggregeres etter modell, summeres etter kostnad og joines til et spor. OpenAIs egne produksjonsbeste-praksiser driver samme idé: fang strukturert metadata på SDK-laget heller enn med print-setninger.

Her er skjemaet hver Techsy-tjeneste sender ut, fjorten felter:

{
  "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"
}

Tre felter fortjener en merknad. cost_usd beregnes på forespørselstidspunktet ut fra token-antallene og modellens publiserte pris, aldri etterfylt av en nattlig jobb. De to hash-feltene er Regel 1-kompromisset: korrelerbare offline, ugjennomsiktige i loggen. Og trace_id og span_id er W3C trace-context-verdier, som er nøyaktig hva Regel 4 handler om.

Hvis fire tjenester som kaller leverandører direkte høres ut som fire steder å instrumentere, sentraliserer en LiteLLM-proxy det: én logg-hook foran hver leverandør.

Regel 3: Fang token-antall og kostnad per forespørsel

Token-brukssporing hører hjemme i selve logglinjen, ikke i en warehouse-jobb som kjører i morgen. Hver leverandør returnerer input- og output-token-antall i svaret; multipliser med modellens per-token-pris på det nøyaktige tidspunktet og skriv cost_usd inn i posten. Priser endres, og varierer for bufrede versus ferske input-tokens, så å beregne kostnad senere med en statisk pristabell omskriver historien i stillhet. Med kostnad på hver linje blir «hvilken funksjon er dyr?» en ett-linjes spørring i stedet for et finansprosjekt, og det mater direkte inn i arbeidet med å redusere LLM API-utgiftene dine.

Regel 4: Legg ved spor-kontekst (OpenTelemetry GenAI Semconv)

En logglinje uten en trace-ID er foreldreløs: du kan lese den, men du kan ikke si hvilket retry, hvilket RAG-steg eller hvilken brukerrunde som produserte den. Fixen er OpenTelemetrys GenAI semantiske konvensjoner, standardattributtnavnene for instrumentering av modellkall. Send ut loggen inne i en aktiv span, så fester trace_id og span_id seg selv, slik at ett klikk i Grafana tar deg fra spor-fossen rett til den rå posten.

Attributtene det er verdt å sette på hver gen_ai-span:

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 før logg-skrivingen

PII-maskering må skje før posten skrives, ikke vaskes etterpå. Når en e-postadresse først er i Loki, er den i objektlagringsbackup-ene dine også, og «vi slettet den senere» er ikke et GDPR-svar. I oppsettet vårt kjører Microsoft Presidio som en structlog-prosessor og fanger 94 % av e-poster og telefonnumre før de treffer Loki; bommertene er nesten alle merkelig formatering, som vi lapper inn i custom recognizers etter hvert som vi finner dem.

Hele hooken er femten linjer:

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"])

Maskeringen sitter i samme pipeline-lag som input- og output-filtrene dine, og den bør testes på samme måte. Guardrail-pipelinen vår behandler en lekket e-post i en logg som en feilende eval, ikke en ops-fotnote.

Regel 6: Sample intelligent ved høy volum

Under omtrent 100K forespørsler om dagen, logg alt. Over det er full-volum-logging en lagringsskatt på data du aldri vil lese, og sampling er slik du beholder postene som betyr noe. Haken: tilfeldig sampling er det verste alternativet for LLM-trafikk, fordi feil, avvisninger og fem-dollar-forespørsler er sjeldne per definisjon, så en uniform 10 %-rate forkaster nøyaktig hendelsene du feilsøker. Sample etter utfall, ikke etter myntkast.

Et vanlig oppsett er regelbasert i kantene (produksjon og enterprise-leietakere: logg alltid) pluss hale-basert i midten. Logg-spesifikke vinklingen på dette rammeverket: guardrail_result- og cost_usd-feltene dine er sampling-signalene, allerede til stede hvis du fulgte Regel 2 og 8.

Regel 7: Sett en bevaringspolicy før du trenger en

En loggbevaringspolicy er en beslutning du tar mens du er rolig, fordi alternativet er å ta den under en kostnadsgjennomgang på dobbelt volum. GDPRs artikkel 5-prinsipp om lagringsbegrensning sier at persondata ikke bør beholdes «lenger enn nødvendig», som i praksis betyr trinnvis bevaring:

Hot besvarer «hva skjedde for ti minutter siden?» raskt og dyrt; cold besvarer «hva fortalte vi denne kunden i mars?» sakte og billig. Slett etter skjema, automatisk, ellers er trinnene bare et diagram.

Regel 8: Logg guardrail- og sikkerhetshendelser separat

Sikkerhetshendelser (guardrail-blokkeringer, avvisninger, policy-brudd) er ikke telemetri; de er revisjonsposter, og de hører hjemme i sin egen strøm. Tre grunner. Alarmering: en topp i blokkerte prompt-injections bør tilkalle noen, og du kan ikke stille inn den alarmen mot 1M rutinelinjer. Bevaring: compliance kan kreve at sikkerhetsposter overlever feilsøkingslogger med år. Tilgang: revisorer får sikkerhetsstrømmen, ikke hele brannslangen din. Merk dommen i hovedposten (guardrail_result: "block") og rut den fulle posten til den separate strømmen. Hva som teller som en sikkerhetshendelse er dekket i guiden vår til guardrail-hendelser.

Regel 9: Gjør logger søkbare, ikke bare lagret

En logg du ikke kan søke i på under ett minutt er en backup, ikke et observabilitetssignal. Søkbar betyr indekserte felter, et spørringsspråk som vakten din faktisk kan, og dashboards bygget før hendelsen. Vi kjører Loki og spør i det 30+ ganger i uken for kostnadsanomalier, latenstid-regresjoner og «vis meg hver avvisning for leietaker X i går.» Grafana Loki-dokumentasjonen er referansen for syntaksen; mønsteret som forsvarer seg er å filtrere på parsede JSON-felter direkte:

{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"

Fem linjer, ingen eksport til en notebook. Hvis din nåværende lagring ikke kan gjøre det, er det problemet som må fikses først.

Hva vi faktisk logger i produksjon

Nok teori. Her er den maskerte config-en fra AI SDR-pipelinen vår, tjenesten bak 1,2M-forespørsler-i-måneden-tallet i introen. Den kjører structlog 25.4.0 som renderer JSON, skipet til Grafana Cloud Loki via Promtail. Modellen på denne pipelinen er claude-sonnet-4-20250514, og hvert kall går gjennom nøyaktig prosessorkjeden fra Regel 2 og 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()

To tall fra første kvartal med dette oppsettet. Månedlig ingest landet på 47GB på tvers av fire tjenester, og p95 logg-skrive-latens er 3ms, som betyr at pipelinen ikke legger til noe målbart på forespørselstiden.

Config-endringen som betalte for seg selv: vi la til cost_usd på hver loggpost i mars 2026. Innen en uke fant vi én prompt-mal som brente 340$/måned i retry-løkker. En forbigående API-feil utløste tre retries, som hver sendte den fulle 4 000-token konteksten på nytt. Loggene gjorde det til en ett-linjes spørring; uten per-forespørsel kostnad ville det ha dukket opp som en uforklart linjepost i neste kvartalsvise budsjettgjennomgang.

Hvor mye koster LLM-logglagring i stor skala?

Ved 1M forespørsler om dagen koster LLM-logglagring mellom omtrent 1,20$ og 108$ per måned for de samme dataene, avhengig av lagringen. Regnestykket: en full strukturert post er i gjennomsnitt omtrent 2KB, så 1M forespørsler om dagen er 2GB om dagen, eller 60GB i måneden. De leverandørpubliserte prisene nedenfor (juli 2026) er hva de 60GB koster i tre vanlige backends.

Kilder: Datadog-prising, Grafana Loki og ClickHouse observabilitetsdokumentasjonen.

To forbehold, fordi dette er beregningen vår fra leverandørpriser, ikke en benchmark vi kjørte. For det første antar Datadogs tall at du indekserer alt; de fleste team indekserer en delmengde og betaler langt mindre, mens Loki og ClickHouse tar betalt hovedsakelig for det du lagrer. For det andre skjuler selv-hostet ClickHouse sine 1,20$ en reell regning: compute-en for å kjøre klyngen og ingeniørtimene for å drive den. Ved 60GB i måneden er en administrert tjeneste nesten alltid det billigste totale svaret. Selv-hosting begynner å gi mening forbi omtrent 1TB i måneden, der per-GB-gapet overvelmer driftsoverhead-en.

Spredningen er poenget. Ved 1M forespørsler per dag er gapet mellom Datadog-indeksert og selv-hostet ClickHouse omtrent 90x: 108$ mot 1,20$ for de samme 60GB. Velg lagringen på arkitekturtidspunktet, ikke etter at fakturaen ankommer.

Hvilket logging-verktøy bør du velge?

For de fleste team koker valget ned til fire alternativer: en LLM-native plattform (Langfuse eller LangSmith), et proxy-lag-verktøy (Helicone) eller en ren OpenTelemetry-pipeline inn i infrastruktur du allerede kjører. Tabellen dekker beslutningspunktene som faktisk skiller seg; dashboards, avspilling og prompt-versjonering er grunnkrav i alle fire.

Vår mening, rett ut: vi kjører OTel-native pluss Loki fordi vi allerede hadde Grafana-stacken for alt annet, og å legge til én datakilde til slo å ta i bruk en fjerde leverandør. Hvis du starter fra null uten noen observabilitetsstack i det hele tatt, er Langfuses sporingsmodell og gratisnivået dens den raskeste veien til nyttig, og selv-host-alternativet holder utgangsdøren åpen. Hvis du velger mellom de to LLM-native lederne, kjører Langfuse vs LangSmith-gjennomgangen vår den fulle sammenligningen. Og hvis logging er én brikke av en større overvåkingsbeslutning, dekker den fulle plattformsammenligningen det bredere feltet.

Hva er de vanligste LLM-logging-feilene?

Seks feil står for det meste av de ødelagte LLM-logging-oppsettene vi har sett på. Hver enkelt er billig å unngå hvis du fanger den før loggvolumet gjør det:

• Logge rå PII uten maskering. Den vanligste og den dyreste. Én støtteeksport eller én lekket bucket gjør prompt-logger til en databeskyttelseshendelse. Masker før skrivingen (Regel 5), ikke ved lesing.
• Ingen bevaringspolicy. Ubegrenset lagring er standarden overalt, og den dobler stille regningen din hvert år. Hvis du aldri sletter, har du ikke et loggingsystem; du har et arkiv med storhetsvanvidd.
• Ustrukturerte tekstlogger. Print-output du bare kan greppe fungerer på demo-skala og kollapser ved 100K forespørsler om dagen, når «finn hver feilede forespørsel for modell X» blir en shell-skript-ettermiddag i stedet for en spørring.
• Bare logge feil. Vellykkede forespørsler er baseline-en du oppdager drift mot, og de er råmaterialet i evalueringspipelinen din. Logg seirene også, samplet hvis volumet tvinger det.
• Ignorere kostnadsfelter. Ingen cost_usd per forespørsel betyr ingen kostnadsalarmer, ingen per-funksjon attribusjon, og 340$/måned retry-løkken fra produksjonsseksjonen ovenfor forblir usynlig til den kvartalsvise regningen.
• Ingen spor-korrelasjon. Logger koblet fra spans gjør feilsøking av flertrinns agenter til gjetning. Hvis logglinjen din mangler en trace_id, er Regel 4 fixen.

Ofte stilte spørsmål

Hva bør du logge for hver LLM-forespørsel?

Som minimum: full prompt og fullt svar med PII maskert, modellnavnet, input- og output-token-antall, latenstid, kostnad i USD, en hashet brukeridentifikator og OpenTelemetry trace- og span-ID-er. Legg til RAG-kilde-ID-er og guardrail-dommen hvis pipelinen din har de stadiene. Fjorten navngitte felter, én JSON-linje per forespørsel.

Hva er det beste formatet for LLM-logger?

Strukturert JSON, ett objekt per forespørsel, med hvert felt eksplisitt navngitt. Fri-tekst-logger kan bare greppes; JSON-poster kan aggregeres etter modell, summeres etter kostnad og joines til spor. Send ut posten med en strukturert logger som structlog i Python eller pino i Node, og render den med en JSON-serializer, aldri strengformatering.

Hvordan håndterer du PII i LLM-logger?

Masker før logg-skrivingen, ikke etter. Kjør prompten og svaret gjennom en detektor som Microsoft Presidio inne i loggingspipelinen din, og erstatt navn, e-poster og telefonnumre med tokens som <EMAIL_ADDRESS>. Når rå PII først når logglagringen din, er den også i backup-ene dine, og etterfølgende sletting tilfredsstiller sjelden GDPRs minimeringstest.

Hvor mye koster LLM-logglagring i stor skala?

For 1M forespørsler om dagen, omtrent 60GB i måneden ved 2KB per post, forvent omtrent 108$/måned på Datadogs indekserte LLM Observability-prising, 30$/måned på Grafana Cloud Loki, eller omtrent 1,20$/måned i komprimert S3-lagring for selv-hostet ClickHouse pluss compute. Det er leverandørpubliserte priser per juli 2026; selv-hosting legger til ingeniørtid på toppen.

Hva er OpenTelemetry GenAI semantiske konvensjoner?

De er OpenTelemetrys standardattributtnavn for instrumentering av LLM-kall: gen_ai.system for leverandøren, gen_ai.request.model for modellen, gen_ai.usage.input_tokens og output_tokens for token-antall, og gen_ai.response.finish_reasons for hvorfor genereringen stoppet. Å bruke dem betyr at enhver OTel-kompatibel backend, fra Jaeger til Tempo til Langfuse, leser sporene dine uten custom parsere.

Hvordan sampler du LLM-logger ved høy trafikk?

Behold hver feil, hver guardrail-blokkering og hver forespørsel over en kostnadsterskel, og sample resten. Denne hale-baserte tilnærmingen bevarer de sjeldne hendelsene du faktisk feilsøker, mens uniform tilfeldig sampling forkaster dem i samme rate som kjedelig trafikk. Under 100K forespørsler om dagen, hopp over sampling helt og logg alt.

Hvor lenge bør du bevare LLM-logger?

Trinn det: 7 dager hot for live feilsøking, 30 dager warm for hendelsesgjennomgang og kostnadsanalyse, og opptil 1 år cold i komprimert objektlagring for compliance og revisjoner. GDPRs lagringsbegrensningsprinsipp forbyr å beholde persondata lenger enn nødvendig, så koble hvert trinn til automatisk sletting heller enn manuell opprydding.

Hva er forskjellen mellom LLM-logging og LLM-tracing?

En logg er en flat post av én hendelse: denne forespørselen skjedde, med disse feltene. Et spor er et kausalt tre av spans på tvers av en hel forespørselsvei, si retrieval, så modellkallet, så to verktøykall. Logger forteller deg hva; spor forteller deg hvor og hvorfor. Produksjonsoppsett sender ut begge, joinet med trace_id.

Konklusjon

Oppsummert: logg hver forespørsel som JSON med navngitte felter, beregn kostnad på forespørselstidspunktet, legg ved OTel spor-kontekst, masker PII før skrivingen, sample etter utfall når du passerer 100K forespørsler om dagen, og velg en lagring du faktisk kan søke i. De ni reglene er ordnet slik at du kan ta i bruk én per sprint, og Regel 2, 4 og 5 er de tre som betaler seg raskest. Hvis du velger den bredere overvåkingsstacken rundt loggene, start med oppsummeringen vår av de beste AI-observabilitetsplattformene. Og hvis du trenger hjelp til å koble opp strukturert logging for LLM-stacken din, få en gratis konsultasjon.