Nejlepší postupy LLM logování: 9 pravidel, která dodržujeme v produkci [2026]

Nejlepší postupy LLM logování: 9 pravidel, která dodržujeme v produkci [2026]

Těchto devět nejlepších postupů LLM logování jsou pravidla, podle kterých náš produkční stack skutečně běží: měsíčně logujeme 1,2M LLM požadavků napříč čtyřmi službami a každý z nich skončí v Grafana Loki jako jeden řádek JSON s poli model, tokens, latency, cost_usd a trace_id. structlog 25.4.0 zapisuje záznam, Presidio nejprve odstraní PII a celá pipeline je logovací polovinou našeho stacku observability.

Klíčové poznatky

• Logujte každý LLM požadavek jako strukturovaný JSON se 14+ pojmenovanými poli, nikdy jako volný text.
• Anonymizujte PII před zápisem do logu pomocí Presidio nebo ekvivalentu, ne až dodatečně.
• Ke každé trase připojte atributy sémantických konvencí OpenTelemetry GenAI.
• Při 1M požadavků denně stojí stejných 60GB $108/měsíc v Datadogu, $30 v Loki a $1,20 v ClickHouse.

Co LLM logování skutečně znamená (a proč „proste logujte vše" nefunguje)

LLM logování znamená zachycení strukturovaného záznamu každého požadavku a odpovědi modelu: prompt, dokončení, počty tokenů, latence, náklady a trasu, která vše svazuje s uživatelskou relací. Nejedná se o logování infrastruktury. CPU, paměť a restarty podů patří do vašeho metrického stacku; tento článek se zabývá výhradně záznamem na úrovni požadavku, který umožňuje ladění, kalkulaci nákladů a audit chování modelu.

Instinkt „proste logujte vše" se těžko překonává a je drahý. Plné prompty a dokončení při 1M požadavků denně vyprodukují přibližně 60GB textu měsíčně a značná část tohoto textu jsou zákaznické PII, které nyní ukládáte na neurčito. Článek 5 GDPR o zásadě minimalizace údajů vyžaduje, aby osobní údaje byly „přiměřené, relevantní a omezené na nezbytnou míru" a surový výpis promptů tento test nesplní hned první den. Logovat vše není strategie; je to závazek s měsíční fakturou.

Jakých je 9 pravidel LLM logování?

Devět pravidel v pořadí, ve kterém bychom je implementovali: logujte plné prompty a odpovědi s hashovanými identifikátory, emitujte strukturovaný JSON, zachycujte tokeny a náklady na požadavek, připojte kontext trasy OpenTelemetry, anonymizujte PII před zápisem, vzorkujte při vysokém objemu, nastavte retenční úrovně, oddělte bezpečnostní události a zajistěte dotazovatelnost výsledku. Každé pravidlo níže je doplněno kódem nebo tabulkou, která ho vynucuje.

Pravidlo 1: Logujte plný prompt a odpověď (s hashemi, ne surovými PII)

Logujte kompletní prompt a kompletní dokončení pro každý požadavek, protože částečné logy jsou důvod, proč skončíte u incidentu bez záznamu o tom, co model skutečně viděl. Jediná výjimka se týká identity: nikdy nezapisujte surová uživatelská ID, e-maily ani jména do záznamu. Místo toho uložte SHA-256 hash uživatelského ID. Hash vám stále umožní rekonstruovat celou historii relace jednoho uživatele pomocí offline vyhledání, zatímco samotný řádek logu zůstává pro kohokoli nepovolaného bezcenný. Stejná logika platí pro systémové prompty: hashujte je, logujte hash a plaintext uchovávejte v registru promptů, kde už je verzován.

Pravidlo 2: Používejte strukturovaný JSON: každé pole pojmenované, nic volného textu

Pro nejlepší postupy LLM logování v Pythonu nebo jakémkoli jiném jazyce je strukturované logování v JSON tím nepostradatelným: každé pole pojmenované, typované a dotazovatelné, nic nevypsané jako formátovaný řetězec. Řádek volného textu jako INFO called gpt-4o, took 812ms lze pouze grepovat. JSON záznam lze agregovat podle modelu, sčítat podle nákladů a propojit s trasou. Vlastní produkční osvědčené postupy OpenAI prosazují stejnou myšlenku: zachycujte strukturovaná metadata na úrovni SDK, nikoli pomocí print příkazů.

Zde je schéma, které emituje každá služba Techsy, čtrnáct polí:

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

Tři pole si zaslouží poznámku. cost_usd se vypočítává v čase požadavku z počtu tokenů a publikované sazby modelu, nikdy se nedoplňuje nočním úkolem. Dvě hashovací pole jsou kompromisem Pravidla 1: korelovatelná offline, neprůhledná v logu. A trace_id a span_id jsou hodnoty W3C trace-context, což je přesně to, o čem je Pravidlo 4.

Pokud čtyři služby volající providery přímo zní jako čtyři místa k instrumentaci, proxy LiteLLM to centralizuje: jeden logovací hák před každým providerem.

Pravidlo 3: Zachycujte počty tokenů a náklady na požadavek

Sledování spotřeby tokenů patří přímo do řádku logu, ne do úlohy ve skladu, která poběží zítra. Každý provider vrací v odpovědi počty vstupních a výstupních tokenů; vynásobte je sazbou modelu za token v daný okamžik a zapište cost_usd do záznamu. Sazby se mění a liší se pro cachované versus čerstvé vstupní tokeny, takže výpočet nákladů později se statickou cenovou tabulkou tiše přepisuje historii. S náklady na každém řádku se „která funkce je drahá?" stane jednořádkovým dotazem místo finančního projektu a přímo to navazuje na práci na snížení výdajů za LLM API.

Pravidlo 4: Připojte kontext trasy (OpenTelemetry GenAI Semconv)

Řádek logu bez trace ID je sirotek: můžete ho přečíst, ale nedokážete určit, který pokus, který krok RAG nebo které uživatelské kolo ho vyprodukovalo. Řešením jsou sémantické konvence OpenTelemetry GenAI, standardní názvy atributů pro instrumentaci volání modelů. Emitujte log uvnitř aktivního spanu a trace_id a span_id se připojí samy, takže jedno kliknutí v Grafaně vás přenese z vodopádu trasy přímo k surovému záznamu.

Atributy, které stojí za nastavení na každém gen_ai spanu:

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

Pravidlo 5: Anonymizujte PII před zápisem do logu

Anonymizace PII musí proběhnout před zápisem záznamu, ne dodatečným čištěním. Jakmile je e-mailová adresa v Loki, je i ve vašich zálohách objektového úložiště a „smazali jsme to později" není odpověď pro GDPR. V našem nastavení běží Microsoft Presidio jako procesor structlog a zachytí 94 % e-mailů a telefonních čísel dříve, než dorazí do Loki; uniklé případy jsou téměř vždy podivné formátování, které opravujeme do vlastních rozpoznávačů, jak je nacházíme.

Celý hák má patnáct řádků:

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

Anonymizace sedí ve stejné vrstvě pipeline jako vaše vstupní a výstupní filtry a měla by se testovat stejným způsobem. Naše guardrail pipeline považuje uniklý e-mail v logu za selhání evaluace, ne za provozní poznámku pod čarou.

Pravidlo 6: Vzorkujte inteligentně při vysokém objemu

Pod zhruba 100K požadavků denně logujte vše. Nad touto hranicí je logování plného objemu daň z úložiště za data, která nikdy nepřečtete, a vzorkování je způsob, jak si ponechat záznamy, na kterých záleží. Háček: náhodné vzorkování je pro LLM provoz tou nejhorší volbou, protože selhání, odmítnutí a pětidolarové požadavky jsou z definice vzácné, takže jednotná 10% míra zahodí přesně ty události, které ladíte. Vzorkujte podle výsledku, ne hodem mincí.

Běžné nastavení je pravidlové na okrajích (produkční a podnikoví tenanti: vždy logovat) plus tail-based uprostřed. Logovací úhel pohledu na tento rámec: vaše pole guardrail_result a cost_usd jsou vzorkovací signály, už přítomné, pokud jste dodrželi Pravidla 2 a 8.

Pravidlo 7: Nastavte retenční politiku dříve, než ji budete potřebovat

Retenční politika logů je rozhodnutí, které činíte v klidu, protože alternativou je činit ho během revize nákladů při dvojnásobném objemu. Článek 5 GDPR o zásadě omezení doby uložení říká, že osobní údaje by měly být uchovávány „ne déle, než je nezbytné", což v praxi znamená odstupňovanou retenci:

Hot odpovídá na „co se stalo před deseti minutami?" rychle a draze; cold odpovídá na „co jsme řekli tomuto zákazníkovi v březnu?" pomalu a levně. Mazte podle plánu, automaticky, jinak jsou úrovně jen diagram.

Pravidlo 8: Logujte guardrail a bezpečnostní události odděleně

Bezpečnostní události (blokování guardrailem, odmítnutí, porušení politik) nejsou telemetrie; jsou to auditní záznamy a patří do vlastního streamu. Tři důvody. Alertování: nárůst blokovaných prompt injection by měl někoho vyvolat a tento alert nelze ladit proti 1M rutinních řádků. Retence: compliance může vyžadovat, aby bezpečnostní záznamy přežily ladící logy o roky. Přístup: auditoři dostanou bezpečnostní stream, ne celý váš firehose. Označte verdikt v hlavním záznamu (guardrail_result: "block") a směrujte plný záznam do odděleného streamu. Co se počítá jako bezpečnostní událost, je popsáno v našem průvodci guardrail událostmi.

Pravidlo 9: Udělejte logy dotazovatelné, ne jen uložené

Log, který nedokážete dotazovat pod minutu, je záloha, ne signál observability. Dotazovatelný znamená indexovaná pole, dotazovací jazyk, který váš on-call skutečně zná, a dashboardy postavené před incidentem. Provozujeme Loki a dotazujeme ho 30+krát týdně na nákladové anomálie, regrese latence a „ukaž mi každé odmítnutí pro tenanta X včera." Dokumentace Grafana Loki je referencí pro syntaxi; vzor, který se osvědčí, je filtrování přímo na parsovaných JSON polích:

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

Pět řádků, žádný export do notebooku. Pokud to vaše současné úložiště nedokáže, je to problém, který je třeba vyřešit jako první.

Co skutečně logujeme v produkci

Dost teorie. Zde je anonymizovaná konfigurace z naší AI SDR pipeline, služby stojící za číslem 1,2M požadavků měsíčně z úvodu. Běží structlog 25.4.0 vykreslující JSON, odesílaný do Grafana Cloud Loki přes Promtail. Model na této pipeline je claude-sonnet-4-20250514 a každé volání prochází přesně řetězcem procesorů z Pravidel 2 a 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()

Dvě čísla z prvního čtvrtletí s tímto nastavením. Měsíční ingest se ustálil na 47GB napříč čtyřmi službami a p95 latence zápisu logu je 3ms, což znamená, že pipeline nepřidává k času požadavku nic měřitelného.

Změna konfigurace, která se zaplatila: v březnu 2026 jsme přidali cost_usd do každého záznamu logu. Do týdne jsme našli jednu šablonu promptu, která pálila $340/měsíc ve smyčkách opakování. Přechodná chyba API spouštěla tři opakování, každé znovu odesílalo plný 4 000tokenový kontext. Logy z toho udělaly jednořádkový dotaz; bez nákladů na požadavek by se to projevilo jako nevysvětlená položka v příští čtvrtletní revizi rozpočtu.

Kolik stojí úložiště LLM logů ve velkém měřítku?

Při 1M požadavků denně stojí úložiště LLM logů přibližně $1,20 až $108 měsíčně za stejná data, v závislosti na úložišti. Výpočet: plný strukturovaný záznam má v průměru asi 2KB, takže 1M požadavků denně je 2GB denně, neboli 60GB měsíčně. Ceny publikované výrobci níže (červenec 2026) ukazují, kolik tě 60GB stojí ve třech běžných backendech.

Zdroje: ceník Datadog, Grafana Loki a dokumentace ClickHouse observability.

Dvě upozornění, protože toto je náš výpočet ze sazeb výrobců, ne benchmark, který jsme provedli. Zaprvé, číslo Datadogu předpokládá, že indexujete vše; většina týmů indexuje podmnožinu a platí výrazně méně, zatímco Loki a ClickHouse účtují hlavně za to, co uložíte. Zadruhé, $1,20 vlastního hostování ClickHouse skrývá skutečný účet: výpočetní výkon pro běh clusteru a inženýrské hodiny pro jeho provoz. Při 60GB měsíčně je spravovaná služba téměř vždy celkově levnější odpovědí. Vlastní hosting začne dávat smysl zhruba nad 1TB měsíčně, kde rozdíl na GB převáží provozní režii.

Rozpětí je to hlavní. Při 1M požadavků denně je rozdíl mezi Datadogem s indexací a vlastním ClickHouse přibližně 90násobný: $108 versus $1,20 za stejných 60GB. Vyberte úložiště v čase architektury, ne po doručení faktury.

Který logovací nástroj si vybrat?

Pro většinu týmů se volba zúží na čtyři možnosti: LLM-nativní platforma (Langfuse nebo LangSmith), nástroj proxy vrstvy (Helicone), nebo čistá OpenTelemetry pipeline do infrastruktury, kterou už provozujete. Tabulka pokrývá rozhodovací body, které se skutečně liší; dashboardy, přehrávání a verzování promptů jsou základní výbavou všech čtyř.

Náš názor, otevřeně: provozujeme OTel-native plus Loki, protože jsme už měli Grafana stack pro vše ostatní a přidání dalšího zdroje dat porazilo přijetí čtvrtého dodavatele. Pokud začínáte od nuly bez jakéhokoli stacku observability, trasovací model Langfuse a jeho bezplatná úroveň jsou nejrychlejší cestou k užitečnosti a možnost vlastního hostingu nechává otevřené dveře. Pokud vybíráte mezi dvěma LLM-nativními lídry, naše srovnání Langfuse vs LangSmith provádí plné srovnání. A pokud je logování jedním dílem většího rozhodnutí o monitorování, plné srovnání platforem pokrývá širší pole.

Jaké jsou nejčastější chyby LLM logování?

Šest chyb tvoří většinu rozbitých nastavení LLM logování, která jsme viděli. Každá je levná na vyhnutí, pokud ji zachytíte dříve, než to udělá objem logů:

• Logování surových PII bez anonymizace. Nejčastější a nejdražší. Jeden export podpory nebo jeden uniklý bucket změní logy promptů na incident ochrany údajů. Anonymizujte před zápisem (Pravidlo 5), ne při čtení.
• Žádná retenční politika. Neomezené úložiště je výchozí všude a tiše zdvojnásobuje váš účet každý rok. Pokud nikdy nemažete, nemáte logovací systém; máte archiv s megalomanskými představami.
• Neformátované textové logy. Výstup printu, který lze pouze grepovat, funguje v měřítku dema a hroutí se při 100K požadavků denně, kdy „najdi každý selhaný požadavek pro model X" se stane odpolednem se shellovým skriptem místo dotazem.
• Logování pouze chyb. Úspěšné požadavky jsou základna, proti které detekujete drift, a jsou surovinou vaší evaluační pipeline. Logujte i úspěchy, vzorkované, pokud to objem vynutí.
• Ignorování nákladových polí. Žádné cost_usd na požadavek znamená žádné nákladové alerty, žádnou atribuci podle funkce a smyčka opakování za $340/měsíc z produkční sekce výše zůstává neviditelná až do čtvrtletní faktury.
• Žádná korelace s trasami. Logy odpojené od spanů dělají z ladění vícekrokových agentů hádání. Pokud vašemu řádku logu chybí trace_id, Pravidlo 4 je náprava.

O autorovi

Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku LLM nástrojů, který tým Techsy skutečně používá v produkci. Spojte se na LinkedIn.

Často kladené otázky

Co byste měli logovat pro každý LLM požadavek?

Minimálně: plný prompt a dokončení s anonymizovanými PII, název modelu, počty vstupních a výstupních tokenů, latenci, náklady v USD, hashovaný identifikátor uživatele a OpenTelemetry trace a span ID. Přidejte ID zdrojů RAG a verdikt guardrailu, pokud vaše pipeline tyto fáze má. Čtrnáct pojmenovaných polí, jeden řádek JSON na požadavek.

Jaký je nejlepší formát pro LLM logy?

Strukturovaný JSON, jeden objekt na požadavek, s každým polem explicitně pojmenovaným. Logy volného textu lze pouze grepovat; JSON záznamy lze agregovat podle modelu, sčítat podle nákladů a propojit s trasami. Emitujte záznam strukturovaným loggerem jako structlog v Pythonu nebo pino v Node a vykreslete ho JSON serializérem, nikdy formátováním řetězce.

Jak zpracováváte PII v LLM logách?

Anonymizujte před zápisem do logu, ne po něm. Prožeňte prompt a dokončení detektorem jako Microsoft Presidio uvnitř vaší logovací pipeline a nahraďte jména, e-maily a telefonní čísla tokeny jako <EMAIL_ADDRESS>. Jakmile se surové PII dostanou do vašeho logovacího úložiště, jsou i ve vašich zálohách a zpětné smazání zřídka splňuje test minimalizace GDPR.

Kolik stojí úložiště LLM logů ve velkém měřítku?

Pro 1M požadavků denně, asi 60GB měsíčně při 2KB na záznam, počítejte přibližně $108/měsíc na indexovaném ceníku Datadog LLM Observability, $30/měsíc na Grafana Cloud Loki nebo asi $1,20/měsíc v komprimovaném úložišti S3 pro vlastní ClickHouse plus výpočty. To jsou sazby publikované výrobci k červenci 2026; vlastní hosting přidává inženýrský čas navrch.

Co jsou sémantické konvence OpenTelemetry GenAI?

Jsou to standardní názvy atributů OpenTelemetry pro instrumentaci volání LLM: gen_ai.system pro provider, gen_ai.request.model pro model, gen_ai.usage.input_tokens a output_tokens pro počty tokenů a gen_ai.response.finish_reasons pro důvod ukončení generování. Jejich použití znamená, že jakýkoli OTel-kompatibilní backend, od Jaegeru po Tempo po Langfuse, přečte vaše trasy bez vlastních parserů.

Jak vzorkujete LLM logy při vysokém provozu?

Ponechte každou chybu, každé blokování guardrailem a každý požadavek nad nákladovým prahem, pak vzorkujte zbytek. Tento tail-based přístup zachovává vzácné události, které skutečně ladíte, zatímco jednotné náhodné vzorkování je zahodí stejnou mírou jako nudný provoz. Pod 100K požadavků denně vzorkování zcela vynechte a logujte vše.

Jak dlouho byste měli uchovávat LLM logy?

Odstupňujte: 7 dní hot pro živé ladění, 30 dní warm pro revizi incidentů a analýzu nákladů a až 1 rok cold v komprimovaném objektovém úložišti pro compliance a audity. Zásada omezení doby uložení GDPR zakazuje uchovávat osobní údaje déle, než je nezbytné, takže ke každé úrovni přiřaďte automatické mazání, ne ruční úklid.

Jaký je rozdíl mezi LLM logováním a LLM trasováním?

Log je plochý záznam jedné události: tento požadavek se stal, s těmito poli. Trasa je kauzální strom spanů napříč celou cestou požadavku, řekněme retrieval, pak volání modelu, pak dvě volání nástrojů. Logy vám říkají co; trasy vám říkají kde a proč. Produkční nastavení emitují obojí, propojené přes trace_id.

Závěr

Shrnutí: logujte každý požadavek jako JSON s pojmenovanými poli, vypočítejte náklady v čase požadavku, připojte kontext trasy OTel, anonymizujte PII před zápisem, vzorkujte podle výsledku, jakmile překročíte 100K požadavků denně, a vyberte úložiště, které skutečně dokážete dotazovat. Devět pravidel je seřazeno tak, abyste je mohli přijímat jedno za sprint, a Pravidla 2, 4 a 5 jsou tři, která se vrátí nejrychleji. Pokud vybíráte širší monitorovací stack kolem logů, začněte naším přehledem nejlepších platforem AI observability. A pokud potřebujete pomoc s nastavením strukturovaného logování pro váš LLM stack, získejte bezplatnou konzultaci.