Practici recomandate de logging LLM: 9 reguli pe care le urmăm în producție [2026]

Practici recomandate de logging LLM: 9 reguli pe care le urmăm în producție [2026]

Aceste nouă practici recomandate de logging LLM sunt regulile pe care stackul nostru de producție le respectă efectiv: logăm 1,2 milioane de cereri LLM pe lună, distribuite pe patru servicii, iar fiecare ajunge în Grafana Loki ca o singură linie JSON, cu model, tokenuri, latență, cost_usd și trace_id. structlog 25.4.0 scrie înregistrarea, Presidio elimină PII înainte, iar întregul pipeline este jumătatea de logging a stackului nostru de observabilitate.

Idei principale

• Loghează fiecare cerere LLM ca JSON structurat, cu cel puțin 14 câmpuri numite, niciodată text liber.
• Anonimizează PII înainte de scrierea logului, cu Presidio sau echivalent, nu după.
• Atașează atributele din convențiile semantice OpenTelemetry GenAI la fiecare trace.
• La 1 milion de cereri pe zi, aceleași 60 GB costă $108 pe lună în Datadog, $30 în Loki, $1,20 în ClickHouse.

Ce înseamnă de fapt loggingul LLM (și de ce „loghează totul" eșuează)

Loggingul LLM înseamnă captarea unei înregistrări structurate pentru fiecare cerere și fiecare răspuns al modelului: promptul, completarea, numărul de tokenuri, latența, costul și trace-ul care leagă totul de o sesiune de utilizator. Nu este logging de infrastructură. CPU-ul, memoria și repornirile de poduri aparțin stackului de metrici; acest articol acoperă doar înregistrarea la nivel de cerere, cea care îți permite să depanezi, să urmărești costurile și să auditezi comportamentul modelului.

Instinctul de „loghează totul" moare greu și este scump. Prompturile și completările complete, la 1 milion de cereri pe zi, produc aproximativ 60 GB de text pe lună, iar o bună parte din acel text sunt date PII ale clienților, pe care acum le stochezi pe termen nedeterminat. Principiul minimizării datelor din articolul 5 GDPR cere ca datele personale să fie „adecvate, relevante și limitate la ceea ce este necesar", iar un dump brut de prompturi pică acest test din prima zi. A loga totul nu este o strategie; este un risc cu factură lunară.

Care sunt cele 9 reguli de logging LLM?

Nouă reguli, în ordinea în care le-am implementa: loghează prompturile și răspunsurile complete, cu identificatori sub formă de hash, emite JSON structurat, capturează tokenurile și costul per cerere, atașează contextul de trace OpenTelemetry, anonimizează PII înainte de scriere, eșantionează la volume mari, stabilește niveluri de retenție, separă evenimentele de siguranță și fă rezultatul interogabil. Fiecare dintre ele vine mai jos cu codul sau tabelul care o impune.

Regula 1: Loghează promptul și răspunsul complete (cu hashuri, nu PII brut)

Loghează promptul complet și completarea completă pentru fiecare cerere, pentru că logurile parțiale sunt motivul pentru care ajungi să te uiți la un incident fără nicio înregistrare despre ce a văzut de fapt modelul. Singura excepție este identitatea: nu scrie niciodată ID-uri de utilizator, emailuri sau nume brute în înregistrare. Stochează în schimb un hash SHA-256 al ID-ului de utilizator. Un hash îți permite oricum să reconstruiești istoricul complet al sesiunii unui utilizator printr-o căutare offline, în timp ce linia de log rămâne inutilă pentru oricine nu ar trebui să o citească. Aceeași logică pentru prompturile de sistem: fă-le hash, loghează hashul și păstrează textul clar în registrul de prompturi, unde este oricum versionat.

Regula 2: Folosește JSON structurat: fiecare câmp numit, nimic text liber

Printre practicile recomandate de logging LLM în Python sau în orice alt limbaj, loggingul structurat în JSON este regula nenegociabilă: fiecare câmp numit, tipizat și interogabil, nimic aruncat ca șir formatat. O linie de text liber ca INFO called gpt-4o, took 812ms poate fi doar grep-uită. O înregistrare JSON poate fi agregată pe model, însumată pe cost și unită cu un trace. Chiar și recomandările de producție ale OpenAI împing aceeași idee: capturează metadate structurate la nivel de SDK, nu cu print-uri.

Iată schema pe care o emite fiecare serviciu Techsy, paisprezece câmpuri:

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

Trei câmpuri merită o notă. cost_usd este calculat în momentul cererii, din numărul de tokenuri și tariful publicat al modelului, niciodată completat ulterior de un job de noapte. Cele două câmpuri de hash sunt compromisul din Regula 1: corelabile offline, opace în log. Iar trace_id și span_id sunt valori W3C trace-context, exact despre ce este vorba în Regula 4.

Dacă patru servicii care apelează direct providerii sună ca patru locuri de instrumentat, un proxy LiteLLM centralizează totul: un singur hook de logging în fața fiecărui provider.

Regula 3: Capturează numărul de tokenuri și costul per cerere

Urmărirea consumului de tokenuri aparține liniei de log în sine, nu unui job de warehouse care rulează mâine. Fiecare provider întoarce numărul de tokenuri de intrare și de ieșire în răspuns; înmulțește cu tariful per token al modelului, la acel moment exact, și scrie cost_usd în înregistrare. Tarifele se schimbă și diferă pentru tokenuri de intrare cache-uite versus proaspete, deci a calcula costul mai târziu, cu un tabel static de prețuri, rescrie istoricul în tăcere. Cu costul pe fiecare linie, „care feature este scump?" devine o interogare de o linie, în loc de un proiect financiar, și alimentează direct efortul de a reduce cheltuielile cu API-ul LLM.

Regula 4: Atașează contextul de trace (semconv OpenTelemetry GenAI)

O linie de log fără trace ID este orfană: o poți citi, dar nu poți spune care retry, care pas RAG sau care tură de utilizator a produs-o. Soluția sunt convențiile semantice GenAI ale OpenTelemetry, numele standard de atribute pentru instrumentarea apelurilor de model. Emite logul în interiorul unui span activ, iar trace_id și span_id se atașează singure, astfel încât un singur click în Grafana te duce din cascada trace-ului direct la înregistrarea brută.

Atributele care merită setate pe fiecare span gen_ai:

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

Regula 5: Anonimizează PII înainte de scrierea logului

Anonimizarea PII trebuie să se întâmple înainte ca înregistrarea să fie scrisă, nu curățată după. Odată ce o adresă de email este în Loki, este și în backupurile din object storage, iar „am șters-o mai târziu" nu este un răspuns GDPR. În configurația noastră, Microsoft Presidio rulează ca procesor structlog și prinde 94% dintre emailuri și numere de telefon înainte să ajungă în Loki; ce scapă sunt aproape toate formatări ciudate, pe care le transformăm în recognizere personalizate pe măsură ce le descoperim.

Întregul hook are cincisprezece linii:

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

Anonimizarea stă în același nivel de pipeline ca filtrele de intrare și ieșire și ar trebui testată la fel. Pipeline-ul nostru de guardrail-uri tratează un email scăpat în log ca un eval eșuat, nu ca o notă de subsol de operațiuni.

Regula 6: Eșantionează inteligent la volume mari

Sub aproximativ 100.000 de cereri pe zi, loghează totul. Peste acest prag, loggingul la volum complet este o taxă de stocare pe date pe care nu le vei citi niciodată, iar eșantionarea este modul în care păstrezi înregistrările care contează. Capcana: eșantionarea aleatorie este cea mai proastă opțiune pentru traficul LLM, pentru că eșecurile, refuzurile și cererile de cinci dolari sunt rare prin definiție, deci o rată uniformă de 10% aruncă exact evenimentele pe care le depanezi. Eșantionează după rezultat, nu la întâmplare.

O configurație comună este bazată pe reguli la extreme (producție și tenanturi enterprise: loghează mereu), plus bazată pe coadă la mijloc. Unghiul specific loggingului în acest cadru: câmpurile guardrail_result și cost_usd sunt semnalele de eșantionare, deja prezente dacă ai urmat Regulile 2 și 8.

Regula 7: Stabilește o politică de retenție înainte să ai nevoie de ea

O politică de retenție a logurilor este o decizie pe care o iei când ești calm, pentru că alternativa este să o iei în timpul unei revizuiri de costuri, la volum dublu. Principiul limitării stocării din articolul 5 GDPR spune că datele personale ar trebui păstrate „nu mai mult decât este necesar", ceea ce în practică înseamnă retenție pe niveluri:

Hot răspunde la „ce s-a întâmplat acum zece minute?" rapid și scump; cold răspunde la „ce i-am spus acestui client în martie?" lent și ieftin. Șterge conform programului, automat, altfel nivelurile sunt doar o diagramă.

Regula 8: Loghează separat evenimentele de guardrail și de siguranță

Evenimentele de siguranță (blocări de guardrail, refuzuri, încălcări de politică) nu sunt telemetrie; sunt înregistrări de audit și aparțin propriului lor flux. Trei motive. Alertare: un vârf de injecții de prompt blocate ar trebui să trezească pe cineva, și nu poți regla acea alertă printre 1 milion de linii de rutină. Retenție: conformitatea poate cere ca înregistrările de siguranță să supraviețuiască logurilor de debugging cu ani de zile. Acces: auditorii primesc fluxul de siguranță, nu întregul tău firehose. Etichetează verdictul în înregistrarea principală (guardrail_result: "block") și rutează înregistrarea completă către fluxul separat. Ce contează ca eveniment de siguranță este acoperit în ghidul nostru despre evenimente de guardrail.

Regula 9: Fă logurile interogabile, nu doar stocate

Un log pe care nu îl poți interoga în sub un minut este un backup, nu un semnal de observabilitate. Interogabil înseamnă câmpuri indexate, un limbaj de interogare pe care echipa de gardă chiar îl stăpânește și dashboarduri construite înainte de incident. Noi rulăm Loki și îl interogăm de peste 30 de ori pe săptămână pentru anomalii de cost, regresii de latență și „arată-mi toate refuzurile tenantului X de ieri." Documentația Grafana Loki este referința pentru sintaxă; tiparul care își câștigă existența este filtrarea direct pe câmpurile JSON parsate:

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

Cinci linii, fără export într-un notebook. Dacă stocarea ta actuală nu poate face asta, aceasta este problema de rezolvat prima.

Ce logăm de fapt în producție

Destul cu teoria. Iată configurația anonimizată a pipeline-ului nostru AI SDR, serviciul din spatele cifrei de 1,2 milioane de cereri pe lună din introducere. Rulează structlog 25.4.0, care randează JSON, livrat către Grafana Cloud Loki prin Promtail. Modelul pe acest pipeline este claude-sonnet-4-20250514, iar fiecare apel trece exact prin lanțul de procesoare din Regulile 2 și 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()

Două cifre din primul trimestru cu această configurație. Ingestia lunară s-a stabilizat la 47 GB pe patru servicii, iar latența p95 de scriere a logurilor este de 3 ms, adică pipeline-ul nu adaugă nimic măsurabil la timpul cererii.

Schimbarea de configurație care s-a plătit singură: am adăugat cost_usd la fiecare intrare de log în martie 2026. Într-o săptămână am descoperit un template de prompt care ardea $340 pe lună în bucle de retry. O eroare API tranzitorie declanșa trei retry-uri, fiecare retrimitând contextul complet de 4.000 de tokenuri. Logurile au transformat asta într-o interogare de o linie; fără cost per cerere, ar fi apărut ca un rând neexplicat în următoarea revizuire trimestrială de buget.

Cât costă stocarea logurilor LLM la scară?

La 1 milion de cereri pe zi, stocarea logurilor LLM costă aproximativ între $1,20 și $108 pe lună pentru aceleași date, în funcție de stocare. Calculul: o înregistrare structurată completă are în medie circa 2 KB, deci 1 milion de cereri pe zi înseamnă 2 GB pe zi, sau 60 GB pe lună. Prețurile publicate de vendori mai jos (iulie 2026) arată cât costă acei 60 GB în trei backenduri comune.

Surse: prețurile Datadog, Grafana Loki și documentația de observabilitate ClickHouse.

Două precizări, pentru că acesta este calculul nostru pe baza tarifelor vendorilor, nu un benchmark rulat de noi. Primul: cifra Datadog presupune că indexezi totul; majoritatea echipelor indexează un subset și plătesc mult mai puțin, în timp ce Loki și ClickHouse taxează în principal ce stochezi. Al doilea: cei $1,20 ai ClickHouse self-hosted ascund o factură reală: compute-ul pentru a rula clusterul și orele de inginer pentru a-l opera. La 60 GB pe lună, un serviciu managed este aproape întotdeauna răspunsul mai ieftin per total. Self-hostingul începe să aibă sens peste aproximativ 1 TB pe lună, unde diferența per GB copleșește overheadul operațional.

Diferența este concluzia. La 1 milion de cereri pe zi, decalajul între Datadog indexat și ClickHouse self-hosted este de aproximativ 90x: $108 versus $1,20 pentru aceiași 60 GB. Alege stocarea la momentul arhitecturii, nu după ce vine factura.

Ce instrument de logging ar trebui să alegi?

Pentru majoritatea echipelor, alegerea se reduce la patru opțiuni: o platformă nativă LLM (Langfuse sau LangSmith), un instrument la nivel de proxy (Helicone) sau un pipeline OpenTelemetry simplu, în infrastructura pe care deja o rulezi. Tabelul acoperă punctele de decizie care chiar diferă; dashboardurile, playback-ul și versionarea prompturilor sunt cerințe de bază la toate patru.

Opinia noastră, pe șleau: noi rulăm OTel nativ plus Loki, pentru că aveam deja stackul Grafana pentru tot restul, iar adăugarea încă unei surse de date a bătut adoptarea unui al patrulea vendor. Dacă pornești de la zero, fără niciun stack de observabilitate, modelul de tracing al Langfuse și nivelul său gratuit sunt cea mai rapidă cale către util, iar opțiunea self-host ține ușa de ieșire deschisă. Dacă alegi între cei doi lideri nativi LLM, comparația noastră Langfuse vs LangSmith face analiza completă. Iar dacă loggingul este o piesă dintr-o decizie de monitorizare mai amplă, comparația completă a platformelor acoperă spectrul larg.

Care sunt cele mai frecvente greșeli de logging LLM?

Șase greșeli explică majoritatea configurațiilor de logging LLM defecte pe care le-am văzut. Fiecare este ieftin de evitat, dacă o prinzi înainte să o facă volumul de loguri:

• Logarea PII brut, fără anonimizare. Cea mai frecventă și cea mai scumpă. Un singur export de suport sau un bucket spart transformă logurile de prompturi într-un incident de protecție a datelor. Anonimizează înainte de scriere (Regula 5), nu la citire.
• Lipsa unei politici de retenție. Stocarea nedeterminată este implicită peste tot și îți dublează liniștit factura în fiecare an. Dacă nu ștergi niciodată, nu ai un sistem de logging; ai o arhivă cu deliruri de grandoare.
• Loguri de text nestructurat. Outputul de print pe care îl poți doar grep-ui funcționează la scară de demo și se prăbușește la 100.000 de cereri pe zi, când „găsește fiecare cerere eșuată pentru modelul X" devine o după-amiază de scripturi shell, în loc de o interogare.
• Logarea doar a erorilor. Cererile reușite sunt linia de bază față de care detectezi deriva și sunt materia primă a pipeline-ului tău de evaluare. Loghează și reușitele, eșantionat dacă volumul te forțează.
• Ignorarea câmpurilor de cost. Fără cost_usd per cerere nu ai alerte de cost, nicio atribuire pe feature, iar bucla de retry de $340 pe lună din secțiunea de producție de mai sus rămâne invizibilă până la factura trimestrială.
• Lipsa corelării cu trace-urile. Logurile deconectate de spanuri transformă debuggingul agenților cu mai mulți pași într-un joc de ghicit. Dacă liniei tale de log îi lipsește trace_id, Regula 4 este soluția.

Despre autor

Mert Batur este co-fondator al Techsy.io, unde echipa livrează agenți IA, sisteme de automatizare și pipeline-uri voice/SDR pentru clienți B2B. Scrie despre stackul de instrumente LLM pe care echipa Techsy îl folosește efectiv în producție. Îl găsești pe LinkedIn.

Întrebări frecvente

Ce ar trebui să loghezi pentru fiecare cerere LLM?

Minimul: promptul complet și completarea, cu PII anonimizat, numele modelului, numărul de tokenuri de intrare și de ieșire, latența, costul în USD, un identificator de utilizator sub formă de hash și ID-urile de trace și span OpenTelemetry. Adaugă ID-urile surselor RAG și verdictul guardrailului, dacă pipeline-ul tău are acele etape. Paisprezece câmpuri numite, o linie JSON per cerere.

Care este cel mai bun format pentru logurile LLM?

JSON structurat, un obiect per cerere, cu fiecare câmp numit explicit. Logurile de text liber pot fi doar grep-uite; înregistrările JSON pot fi agregate pe model, însumate pe cost și unite cu trace-uri. Emite înregistrarea cu un logger structurat, cum ar fi structlog în Python sau pino în Node, și randeaz-o cu un serializator JSON, niciodată cu formatare de șir.

Cum tratezi PII în logurile LLM?

Anonimizează înainte de scrierea logului, nu după. Trece promptul și completarea printr-un detector precum Microsoft Presidio, în interiorul pipeline-ului de logging, înlocuind numele, emailurile și numerele de telefon cu tokenuri precum <EMAIL_ADDRESS>. Odată ce PII brut ajunge în stocarea de loguri, este și în backupuri, iar ștergerea retroactivă satisface rar testul minimizării din GDPR.

Cât costă stocarea logurilor LLM la scară?

Pentru 1 milion de cereri pe zi, circa 60 GB pe lună la 2 KB per înregistrare, așteaptă-te la aproximativ $108 pe lună la prețurile indexate Datadog LLM Observability, $30 pe lună la Grafana Cloud Loki sau circa $1,20 pe lună în stocare S3 comprimată pentru ClickHouse self-hosted, plus compute. Acestea sunt tarifele publicate de vendori în iulie 2026; self-hostingul adaugă timp de inginerie pe deasupra.

Ce sunt convențiile semantice OpenTelemetry GenAI?

Sunt numele standard de atribute ale OpenTelemetry pentru instrumentarea apelurilor LLM: gen_ai.system pentru provider, gen_ai.request.model pentru model, gen_ai.usage.input_tokens și output_tokens pentru numărul de tokenuri și gen_ai.response.finish_reasons pentru motivul opririi generării. Folosirea lor înseamnă că orice backend compatibil OTel, de la Jaeger la Tempo la Langfuse, îți citește trace-urile fără parsere personalizate.

Cum eșantionezi logurile LLM la trafic ridicat?

Păstrează fiecare eroare, fiecare blocare de guardrail și fiecare cerere peste un prag de cost, apoi eșantionează restul. Această abordare bazată pe coadă păstrează evenimentele rare pe care chiar le depanezi, în timp ce eșantionarea aleatorie uniformă le aruncă în același ritm cu traficul obișnuit. Sub 100.000 de cereri pe zi, sari complet peste eșantionare și loghează totul.

Cât timp ar trebui să păstrezi logurile LLM?

Pe niveluri: 7 zile hot pentru debugging live, 30 de zile warm pentru revizuirea incidentelor și analiza costurilor și până la 1 an cold, în object storage comprimat, pentru conformitate și audituri. Principiul limitării stocării din GDPR interzice păstrarea datelor personale mai mult decât este necesar, deci asociază fiecărui nivel ștergerea automată, nu curățarea manuală.

Care este diferența dintre loggingul LLM și tracingul LLM?

Un log este o înregistrare plată a unui eveniment: această cerere s-a întâmplat, cu aceste câmpuri. Un trace este un arbore cauzal de spanuri, de-a lungul întregii căi a cererii, de exemplu retrieval, apoi apelul modelului, apoi două apeluri de instrumente. Logurile îți spun ce; trace-urile îți spun unde și de ce. Configurațiile de producție le emit pe ambele, unite prin trace_id.

Concluzie

Recapitulare: loghează fiecare cerere ca JSON cu câmpuri numite, calculează costul în momentul cererii, atașează contextul de trace OTel, anonimizează PII înainte de scriere, eșantionează după rezultat odată ce treci de 100.000 de cereri pe zi și alege o stocare pe care chiar o poți interoga. Cele nouă reguli sunt ordonate astfel încât să le adopți câte una pe sprint, iar Regulile 2, 4 și 5 sunt cele trei care se recuperează cel mai repede. Dacă alegi stackul de monitorizare mai amplu din jurul logurilor, începe cu sinteza noastră despre cele mai bune platforme de observabilitate AI. Iar dacă ai nevoie de ajutor să conectezi loggingul structurat pentru stackul tău LLM, primește o consultație gratuită.