Najlepsze praktyki logowania LLM: 9 zasad z produkcji [2026]

Najlepsze praktyki logowania LLM: 9 zasad z produkcji [2026]

Te dziewięć najlepszych praktyk logowania LLM to zasady, według których naprawdę działa nasz stos produkcyjny: logujemy 1,2 mln żądań LLM miesięcznie w czterech serwisach i każde z nich trafia do Grafana Loki jako pojedyncza linia JSON z polami model, tokens, latency, cost_usd i trace_id. structlog 25.4.0 zapisuje rekord, Presidio najpierw usuwa dane PII, a cały potok to logująca połowa naszego stosu obserwowalności.

Najważniejsze wnioski

• Każde żądanie LLM loguj jako strukturalny JSON z co najmniej 14 nazwanymi polami, nigdy jako swobodny tekst.
• Anonimizuj PII przed zapisem logu za pomocą Presidio lub odpowiednika, a nie po fakcie.
• Do każdego śladu dołączaj atrybuty konwencji semantycznej OpenTelemetry GenAI.
• Przy 1 mln żądań dziennie te same 60 GB kosztuje 108 $/miesiąc w Datadogu, 30 $ w Loki i 1,20 $ w ClickHouse.

Co właściwie oznacza logowanie LLM (i dlaczego podejście „loguj wszystko" się nie sprawdza)

Logowanie LLM polega na przechwytywaniu strukturalnego rekordu każdego żądania i odpowiedzi modelu: promptu, odpowiedzi, liczby tokenów, opóźnienia, kosztu oraz śladu spinającego wszystko z sesją użytkownika. To nie jest logowanie infrastruktury. CPU, pamięć i restarty podów należą do stosu metryk; ten artykuł dotyczy wyłącznie rekordu na poziomie żądania, który pozwala debugować, rozliczać i audytować zachowanie modelu.

Odruch „loguj wszystko" trudno wykorzenić, a słono kosztuje. Pełne prompty i odpowiedzi przy 1 mln żądań dziennie to około 60 GB tekstu miesięcznie, a spora część tego tekstu to dane PII klientów, które przechowujesz teraz bezterminowo. Zasada minimalizacji danych z art. 5 RODO wymaga, by dane osobowe były „adekwatne, stosowne oraz ograniczone do tego, co niezbędne", a surowy zrzut promptów oblewa ten test już pierwszego dnia. Logowanie wszystkiego to nie strategia; to zobowiązanie z comiesięczną fakturą.

Jak brzmi 9 zasad logowania LLM?

Dziewięć zasad, w kolejności, w jakiej byśmy je wdrażali: loguj pełne prompty i odpowiedzi ze skróconymi identyfikatorami, emituj strukturalny JSON, przechwytuj tokeny i koszt każdego żądania, dołączaj kontekst śledzenia OpenTelemetry, anonimizuj PII przed zapisem, próbkuj przy dużym wolumenie, ustaw poziomy retencji, wydziel zdarzenia bezpieczeństwa i spraw, by wynik dało się odpytywać. Do każdej zasady poniżej dołączamy kod lub tabelę, które ją egzekwują.

Zasada 1: Loguj pełny prompt i pełną odpowiedź (ze skrótami, nie surowymi PII)

Loguj kompletny prompt i kompletną odpowiedź dla każdego żądania, bo niekompletne logi to przepis na sytuację, w której siedzisz nad incydentem bez żadnego zapisu tego, co model faktycznie zobaczył. Jeden wyjątek: tożsamość. Nigdy nie zapisuj w rekordzie surowych identyfikatorów użytkowników, maili ani imion. Zamiast tego przechowuj skrót SHA-256 identyfikatora użytkownika. Skrót wciąż pozwala odtworzyć pełną historię sesji jednego użytkownika przez wyszukiwanie offline, podczas gdy sama linia logu pozostaje bezużyteczna dla każdego, kto nie powinien jej czytać. Ta sama logika dotyczy promptów systemowych: poskracaj je, loguj skrót, a pełny tekst trzymaj w rejestrze promptów, gdzie i tak podlega kontroli wersji.

Zasada 2: Używaj strukturalnego JSON: każde pole nazwane, zero swobodnego tekstu

Jeśli chodzi o najlepsze praktyki logowania LLM w Pythonie czy jakimkolwiek innym języku, logowanie strukturalne w JSON to warunek nienegocjowalny: każde pole nazwane, typowane i odpytywalne, nic zrzucane jako sformatowany string. Linię swobodnego tekstu w stylu INFO called gpt-4o, took 812ms da się jedynie przegrepować. Rekord JSON można agregować według modelu, sumować po koszcie i łączyć ze śladem. Własne rekomendacje produkcyjne OpenAI idą w tym samym kierunku: przechwytuj strukturalne metadane na warstwie SDK, a nie przez print.

Oto schemat, który emituje każdy serwis Techsy, czternaście pól:

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

Trzy pola zasługują na komentarz. cost_usd jest wyliczane w momencie żądania z liczby tokenów i opublikowanej stawki modelu, nigdy uzupełniane wstecznie przez nocny job. Dwa pola ze skrótami to kompromis z zasady 1: korelowalne offline, nieprzezroczyste w logu. A trace_id i span_id to wartości trace-context W3C, czym dokładnie zajmuje się zasada 4.

Jeśli cztery serwisy wołające dostawców bezpośrednio brzmią jak cztery miejsca do instrumentacji, proxy LiteLLM centralizuje to: jeden hook logujący przed każdym dostawcą.

Zasada 3: Przechwytuj liczbę tokenów i koszt każdego żądania

Śledzenie zużycia tokenów należy do samej linii logu, nie do joba w hurtowni, który odpali się jutro. Każdy dostawca zwraca w odpowiedzi liczbę tokenów wejściowych i wyjściowych; pomnóż ją przez stawkę za token modelu w dokładnie tym momencie i zapisz cost_usd w rekordzie. Stawki się zmieniają i różnią dla tokenów buforowanych oraz świeżych, więc liczenie kosztu po czasie ze statycznej tabeli cen po cichu przepisuje historię. Gdy koszt jest w każdej linii, pytanie „która funkcja jest droga?" staje się jednolinijkowym zapytaniem zamiast projektem finansowym i zasila bezpośrednio prace nad redukcją wydatków na API LLM.

Zasada 4: Dołączaj kontekst śledzenia (semantyka OpenTelemetry GenAI)

Linia logu bez trace_id to sierota: da się ją przeczytać, ale nie sposób stwierdzić, które ponowienie, który krok RAG czy która tura użytkownika ją wygenerowała. Rozwiązaniem są konwencje semantyczne GenAI OpenTelemetry, standardowe nazwy atrybutów do instrumentacji wywołań modelu. Emituj log wewnątrz aktywnego spanu, a trace_id i span_id dołączą się same, więc jedno kliknięcie w Grafanie przenosi z wodospadu śladu prosto do surowego rekordu.

Atrybuty warte ustawienia na każdym spanie 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

Zasada 5: Anonimizuj PII przed zapisem logu

Anonimizacja PII musi zajść przed zapisaniem rekordu, a nie przez czyszczenie po fakcie. Gdy adres mailowy trafi do Loki, jest też w kopiach zapasowych object storage, a „usunęliśmy to później" to żadna odpowiedź na RODO. W naszej konfiguracji Microsoft Presidio działa jako procesor structlog i wyłapuje 94% maili i numerów telefonów, zanim dotrą do Loki; przepuszczone przypadki to niemal zawsze nietypowe formatowanie, które łatamy do niestandardowych recognizerów w miarę odkrywania.

Cały hook to piętnaście 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"])

Anonimizacja siedzi w tej samej warstwie potoku co filtry wejścia i wyjścia i powinna być testowana tak samo. Nasz potok guardraili traktuje wyciekły w logu adres mailowy jako oblany eval, a nie przypis w sekcji ops.

Zasada 6: Próbkuj inteligentnie przy dużym wolumenie

Poniżej mniej więcej 100 tys. żądań dziennie loguj wszystko. Powyżej tej granicy logowanie pełnego wolumenu to podatek od przechowywania danych, których nigdy nie przeczytasz, a próbkowanie to sposób na zachowanie rekordów, które się liczą. Haczyk: losowe próbkowanie to najgorsza opcja dla ruchu LLM, bo błędy, odmowy i żądania za pięć dolarów są z definicji rzadkie, więc jednolita stawka 10% wyrzuca dokładnie te zdarzenia, które debugujesz. Próbkuj według wyniku, nie rzutem monetą.

Częsta konfiguracja to regułowa na obrzeżach (produkcja i klienci enterprise: loguj zawsze) plus końcówkowa w środku. Logowy akcent tego schematu: pola guardrail_result i cost_usd są sygnałami próbkowania, obecnymi już, jeśli zastosowałeś zasady 2 i 8.

Zasada 7: Ustal politykę retencji, zanim będzie potrzebna

Polityka retencji logów to decyzja, którą podejmuje się na spokojnie, bo alternatywą jest podejmowanie jej podczas przeglądu kosztów przy dwukrotnie większym wolumenie. Zasada ograniczenia przechowywania z art. 5 RODO mówi, że dane osobowe nie powinny być przechowywane „dłużej niż to konieczne", co w praktyce oznacza retencję poziomą:

Gorący odpowiada szybko i drogo na pytanie „co stało się dziesięć minut temu?"; zimny odpowiada wolno i tanio na „co powiedzieliśmy temu klientowi w marcu?". Usuwaj zgodnie z harmonogramem, automatycznie, bo inaczej poziomy to tylko diagram.

Zasada 8: Loguj zdarzenia guardraili i bezpieczeństwa osobno

Zdarzenia bezpieczeństwa (bloki guardraili, odmowy, naruszenia polityk) to nie telemetria; to rekordy audytowe i należą do własnego strumienia. Trzy powody. Alerty: skok zablokowanych wstrzyknięć promptu powinien kogoś obudzić, a takiego alertu nie da się dostroić na tle miliona rutynowych linii. Retencja: compliance może wymagać, by rekordy bezpieczeństwa przeżyły logi debugowe o lata. Dostęp: audytorzy dostają strumień bezpieczeństwa, nie cały wąż strażacki. Oznaczaj werdykt w głównym rekordzie (guardrail_result: "block") i kieruj pełny rekord do osobnego strumienia. Co liczy się jako zdarzenie bezpieczeństwa, opisujemy w przewodniku po zdarzeniach guardraili.

Zasada 9: Spraw, by logi dało się odpytywać, a nie tylko przechowywać

Log, którego nie odpytasz w mniej niż minutę, to kopia zapasowa, a nie sygnał obserwowalności. Odpytywalny oznacza indeksowane pola, język zapytań, który dyżurny faktycznie zna, i dashboardy zbudowane przed incydentem. Używamy Loki i odpytujemy je ponad 30 razy w tygodniu o anomalie kosztowe, regresje opóźnień i „pokaż każdą odmowę dla klienta X z wczoraj". Dokumentacja Grafana Loki to źródło składni; wzorzec, który na siebie zarabia, to filtrowanie bezpośrednio po sparsowanych polach JSON:

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

Pięć linii, bez eksportu do notatnika. Jeśli twój obecny magazyn tego nie potrafi, to jest problem do naprawienia w pierwszej kolejności.

Co faktycznie logujemy na produkcji

Dość teorii. Oto zanonimizowana konfiguracja z naszego potoku AI SDR, serwisu stojącego za liczbą 1,2 mln żądań miesięcznie ze wstępu. Działa na structlog 25.4.0 renderującym JSON, wysyłanym do Grafana Cloud Loki przez Promtail. Modelem w tym potoku jest claude-sonnet-4-20250514, a każde wywołanie przechodzi dokładnie przez łańcuch procesorów z zasad 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()

Dwie liczby z pierwszego kwartału z tą konfiguracją. Miesięczny ingest ustabilizował się na 47 GB w czterech serwisach, a opóźnienie p95 zapisu logu wynosi 3 ms, czyli potok nie dokłada nic mierzalnego do czasu żądania.

Zmiana konfiguracji, która się zwróciła: w marcu 2026 dodaliśmy cost_usd do każdego wpisu logu. W ciągu tygodnia znaleźliśmy jeden szablon promptu wypalający 340 $/miesiąc w pętlach ponowień. Przejściowy błąd API wyzwalał trzy ponowienia, z których każde wysyłało ponownie pełny kontekst o długości 4000 tokenów. Logi sprowadziły to do jednolinijkowego zapytania; bez kosztu per żądanie sprawa wypłynęłaby jako niewyjaśniona pozycja w następnym kwartalnym przeglądzie budżetu.

Ile kosztuje przechowywanie logów LLM w dużej skali?

Przy 1 mln żądań dziennie przechowywanie logów LLM kosztuje od około 1,20 do 108 $ miesięcznie za te same dane, zależnie od magazynu. Matematyka: pełny rekord strukturalny to średnio około 2 KB, więc 1 mln żądań dziennie to 2 GB dziennie, czyli 60 GB miesięcznie. Opublikowane przez dostawców ceny poniżej (lipiec 2026) mówią, ile te 60 GB kosztuje w trzech popularnych backendach.

Źródła: cennik Datadog, Grafana Loki i dokumentacja obserwowalności ClickHouse.

Dwa zastrzeżenia, bo to nasze wyliczenie ze stawek dostawców, a nie benchmark, który przeprowadziliśmy. Po pierwsze, liczba dla Datadogu zakłada, że indeksujesz wszystko; większość zespołów indeksuje podzbiór i płaci znacznie mniej, podczas gdy Loki i ClickHouse liczą głównie za to, co przechowujesz. Po drugie, 1,20 $ za własny ClickHouse ukrywa realny rachunek: compute do uruchomienia klastra i roboczogodziny inżynierów na jego utrzymanie. Przy 60 GB miesięcznie usługa zarządzana niemal zawsze jest tańsza w całkowitym rozrachunku. Własny hosting zaczyna mieć sens powyżej mniej więcej 1 TB miesięcznie, gdzie różnica na GB przytłacza narzut operacyjny.

Rozstrzał to sedno sprawy. Przy 1 mln żądań dziennie różnica między indeksowanym Datadogiem a własnym ClickHouse wynosi około 90x: 108 $ kontra 1,20 $ za te same 60 GB. Wybieraj magazyn na etapie architektury, a nie po nadejściu faktury.

Które narzędzie do logowania wybrać?

W przypadku większości zespołów wybór sprowadza się do czterech opcji: platforma natywna dla LLM (Langfuse lub LangSmith), narzędzie warstwy proxy (Helicone) albo zwykły potok OpenTelemetry do infrastruktury, którą już masz. Tabela obejmuje punkty decyzyjne, które faktycznie się różnią; dashboardy, odtwarzanie i wersjonowanie promptów to standard we wszystkich czterech.

Nasza opinia wprost: używamy natywnego OTel plus Loki, bo i tak mieliśmy już stos Grafany do wszystkiego innego, a dodanie kolejnego źródła danych wygrało z przyjmowaniem czwartego dostawcy. Jeśli zaczynasz od zera bez żadnego stosu obserwowalności, model śledzenia Langfuse i jego darmowy poziom to najszybsza droga do użyteczności, a opcja własnego hostingu zostawia otwarte drzwi wyjściowe. Jeśli wybierasz między dwoma liderami natywnymi dla LLM, nasze porównanie Langfuse i LangSmith przeprowadza pełną analizę. A jeśli logowanie to jeden element większej decyzji monitoringowej, pełne porównanie platform obejmuje szersze pole.

Najczęstsze błędy logowania LLM

Sześć błędów odpowiada za większość zepsutych konfiguracji logowania LLM, które widzieliśmy. Każdy z nich da się tanio uniknąć, jeśli wyłapiesz go, zanim wolumen logów zrobi to za ciebie:

• Logowanie surowych PII bez anonimizacji. Najczęstsze i najdroższe. Jeden eksport dla supportu albo jeden przełamany bucket zamienia logi promptów w incydent ochrony danych. Anonimizuj przed zapisem (zasada 5), nie przy odczycie.
• Brak polityki retencji. Przechowywanie bezterminowe jest wszędzie domyślne i po cichu podwaja twój rachunek co roku. Jeśli nigdy nie usuwasz, nie masz systemu logowania; masz archiwum z urojeniami wielkości.
• Niestrukturalne logi tekstowe. Wyjście z print, które da się tylko grepować, działa w skali demo i załamuje się przy 100 tys. żądań dziennie, gdy „znajdź każde nieudane żądanie dla modelu X" staje się popołudniem ze skryptem powłoki zamiast zapytaniem.
• Logowanie tylko błędów. Udane żądania to baza, względem której wykrywasz dryf, i surowiec twojego potoku ewaluacji. Loguj też sukcesy, próbkowane, jeśli wolumen zmusza.
• Ignorowanie pól kosztowych. Brak cost_usd per żądanie oznacza brak alertów kosztowych, brak atrybucji per funkcja, a pętla ponowień za 340 $/miesiąc z sekcji produkcyjnej powyżej pozostaje niewidoczna do kwartalnego rachunku.
• Brak korelacji ze śladami. Logi odłączone od spanów zamieniają debugowanie wieloetapowych agentów w zgadywankę. Jeśli twojej linii logu brakuje trace_id, zasada 4 jest rozwiązaniem.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i potoki głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa na produkcji. Połącz się na LinkedIn.

Często zadawane pytania

Co logować dla każdego żądania LLM?

Minimum: pełny prompt i odpowiedź z zanonymizowanymi PII, nazwę modelu, liczbę tokenów wejściowych i wyjściowych, opóźnienie, koszt w USD, skrócony identyfikator użytkownika oraz identyfikatory śladu i spanu OpenTelemetry. Dodaj identyfikatory źródeł RAG i werdykt guardraila, jeśli twój potok ma te etapy. Czternaście nazwanych pól, jedna linia JSON na żądanie.

Jaki jest najlepszy format logów LLM?

Strukturalny JSON, jeden obiekt na żądanie, z każdym polem jawnie nazwanym. Logi swobodnego tekstu da się tylko grepować; rekordy JSON można agregować według modelu, sumować po koszcie i łączyć ze śladami. Emituj rekord strukturalnym loggerem, takim jak structlog w Pythonie lub pino w Node, i renderuj serializatorem JSON, nigdy formatowaniem stringów.

Jak obsługiwać PII w logach LLM?

Anonimizuj przed zapisem logu, nie po. Przepuść prompt i odpowiedź przez detektor taki jak Microsoft Presidio wewnątrz potoku logowania, zastępując imiona, maile i numery telefonów tokenami w rodzaju <EMAIL_ADDRESS>. Gdy surowe PII dotrą do magazynu logów, są też w kopiach zapasowych, a usuwanie wsteczne rzadko spełnia test minimalizacji RODO.

Ile kosztuje przechowywanie logów LLM w dużej skali?

Dla 1 mln żądań dziennie, około 60 GB miesięcznie przy 2 KB na rekord, spodziewaj się mniej więcej 108 $/miesiąc po cenach indeksowanego LLM Observability Datadoga, 30 $/miesiąc w Grafana Cloud Loki lub około 1,20 $/miesiąc w skompresowanym przechowywaniu S3 dla własnego ClickHouse plus compute. To stawki opublikowane przez dostawców na lipiec 2026; własny hosting dokłada na wierzch czas inżynierów.

Czym są konwencje semantyczne OpenTelemetry GenAI?

To standardowe nazwy atrybutów OpenTelemetry do instrumentacji wywołań LLM: gen_ai.system dla dostawcy, gen_ai.request.model dla modelu, gen_ai.usage.input_tokens i output_tokens dla liczby tokenów oraz gen_ai.response.finish_reasons dla powodu zakończenia generowania. Ich użycie oznacza, że każdy backend kompatybilny z OTel, od Jaegera przez Tempo po Langfuse, odczyta twoje ślady bez niestandardowych parserów.

Jak próbkować logi LLM przy dużym ruchu?

Zachowuj każdy błąd, każdą blokadę guardraila i każde żądanie powyżej progu kosztowego, a resztę próbkuj. To podejście końcówkowe zachowuje rzadkie zdarzenia, które faktycznie debugujesz, podczas gdy jednolite losowe próbkowanie wyrzuca je w tym samym tempie co nudny ruch. Poniżej 100 tys. żądań dziennie pomiń próbkowanie całkowicie i loguj wszystko.

Jak długo przechowywać logi LLM?

Poziomowo: 7 dni gorących do bieżącego debugowania, 30 dni ciepłych do przeglądu incydentów i analizy kosztów oraz do 1 roku zimnych w skompresowanym object storage do compliance i audytów. Zasada ograniczenia przechowywania RODO zabrania trzymania danych osobowych dłużej niż to konieczne, więc sparuj każdy poziom z automatycznym usuwaniem, a nie ręcznym sprzątaniem.

Jaka jest różnica między logowaniem LLM a śledzeniem LLM?

Log to płaski rekord jednego zdarzenia: to żądanie zaszło, z tymi polami. Ślad to przyczynowe drzewo spanów wzdłuż całej ścieżki żądania, powiedzmy pobranie, potem wywołanie modelu, potem dwa wywołania narzędzi. Logi mówią, co; ślady mówią, gdzie i dlaczego. Konfiguracje produkcyjne emitują oba, połączone przez trace_id.

Podsumowanie

Przypomnienie: loguj każde żądanie jako JSON z nazwanymi polami, licz koszt w momencie żądania, dołączaj kontekst śladu OTel, anonimizuj PII przed zapisem, próbkuj według wyniku po przekroczeniu 100 tys. żądań dziennie i wybieraj magazyn, który faktycznie da się odpytywać. Dziewięć zasad jest ułożonych tak, by przyjmować po jednej na sprint, a zasady 2, 4 i 5 to trzy, które zwracają się najszybciej. Jeśli wybierasz szerszy stos monitoringowy wokół logów, zacznij od naszego zestawienia najlepszych platform obserwowalności AI. A jeśli potrzebujesz pomocy przy wdrożeniu logowania strukturalnego dla twojego stosu LLM, umów się na bezpłatną konsultację.