Найкращі практики логування LLM: 9 правил, які ми застосовуємо в продакшені [2026]

Найкращі практики логування LLM: 9 правил, які ми застосовуємо в продакшені [2026]

Ці дев'ять найкращих практик логування LLM є правилами, за якими реально працює наш продакшн-стек: ми логуюмо 1,2 млн LLM-запитів на місяць у чотирьох сервісах, і кожен потрапляє у Grafana Loki як один JSON-рядок із полями model, tokens, latency, cost_usd і trace_id. Запис пише structlog 25.4.0, Presidio попередньо видаляє PII, а весь цей пайплайн є логувальною половиною нашого стека спостережності.

Головні висновки

• Логуйте кожен LLM-запит як структурований JSON з 14+ іменованими полями, ніколи як вільний текст.
• Редагуйте PII до запису в лог за допомогою Presidio чи аналога, а не після.
• Додавайте атрибути семантичних конвенцій OpenTelemetry GenAI до кожного трейса.
• За 1 млн запитів на день ті самі 60 ГБ коштують 108 доларів на місяць у Datadog, 30 доларів у Loki і 1,20 долара в ClickHouse.

Що насправді означає логування LLM (і чому «просто логуй усе» не працює)

Логування LLM означає захоплення структурованого запису про кожен запит і кожну відповідь моделі: промпт, компліт, кількість токенів, затримку, вартість і трейс, що пов'язує все це з користувацькою сесією. Це не інфраструктурне логування. CPU, пам'ять і рестарти подів належать до вашого стека метрик; ця стаття покриває лише записи рівня запитів, які дають змогу налагоджувати, рахувати вартість і аудитувати поведінку моделі.

Звичка «просто логуй усе» відмирає повільно й коштує дорого. Повні промпти та компліти за 1 млн запитів на день дають приблизно 60 ГБ тексту на місяць, і чимала частина цього тексту є PII клієнтів, які ви тепер зберігаєте нескінченно. Принцип мінімізації даних зі статті 5 GDPR вимагає, щоб персональні дані були «достатніми, релевантними та обмеженими необхідним», і сирий дамп промптів не проходить цю перевірку з першого ж дня. Логувати все це не стратегія, а зобов'язання з місячним рахунком.

Які ці 9 правил логування LLM?

Дев'ять правил у тому порядку, в якому ми б їх впроваджували: логуйте повні промпти й відповіді з хешованими ідентифікаторами, пишіть структурований JSON, фіксуйте токени й вартість кожного запиту, прикріплюйте контекст трейсів OpenTelemetry, редагуйте PII до запису, робіть вибірку на великих обсягах, налаштовуйте рівні зберігання, відокремлюйте події безпеки та робіть результат придатним до запитів. До кожного правила нижче є код або таблиця, що його забезпечує.

Правило 1: Логуйте повний промпт і компліт (з хешами, а не сирими PII)

Логуйте повний промпт і повний компліт для кожного запиту, бо саме через неповні логи ви зрештою сидите над інцидентом без жодного запису про те, що модель насправді бачила. Єдиний виняток: ідентифікація. Ніколи не пишіть у запис сирі ID користувачів, email-адреси чи імена. Зберігайте натомість SHA-256-хеш ID користувача. Хеш і далі дає змогу відновити повну історію сесії одного користувача через офлайн-пошук, тоді як сам рядок логу лишається марним для будь-кого, хто не повинен його читати. Та сама логіка для системних промптів: хешуйте їх, логуйте хеш, а відкритий текст тримайте у вашому реєстрі промптів, де він уже версіонується.

Правило 2: Структурований JSON, кожне поле з назвою, ніякого вільного тексту

Для найкращих практик логування LLM у Python чи будь-якій іншій мові структуроване логування в JSON є тією вимогою, яку не можна обійти: кожне поле має назву, тип і придатне до запитів, нічого не звалюється у відформатований рядок. Рядок вільного тексту на кшталт INFO called gpt-4o, took 812ms можна лише grep-ати. JSON-запис можна агрегувати за моделлю, сумувати за вартістю і з'єднувати з трейсом. Власні рекомендації OpenAI для продакшену просувають ту саму ідею: збирайте структуровані метадані на рівні SDK, а не через print-інструкції.

Ось схема, яку видає кожен сервіс Techsy, чотирнадцять полів:

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

Три поля варті примітки. cost_usd обчислюється під час запиту з кількості токенів і опублікованого тарифу моделі, ніколи не дописується нічним джобом. Два поля хешів є компромісом правила 1: корельовані офлайн, непрозорі в лозі. А trace_id і span_id це значення W3C trace-context, і саме про це правило 4.

Якщо чотири сервіси, що напряму викликають провайдерів, звучать як чотири місця для інструментування, проксі LiteLLM централізує це: один хук логування перед кожним провайдером.

Правило 3: Фіксуйте кількість токенів і вартість кожного запиту

Відстеження використання токенів належить до самого рядка логу, а не до джоба у сховищі, що запускається завтра. Кожен провайдер повертає кількість вхідних і вихідних токенів у відповіді; помножте на тариф моделі за токен саме в той момент і запишіть cost_usd у запис. Тарифи змінюються і відрізняються для кешованих і свіжих вхідних токенів, тож обчислення вартості пізніше за статичною таблицею цін тихо переписує історію. Коли вартість є в кожному рядку, «яка фіча дорога?» стає однорядковим запитом замість фінансового проєкту і безпосередньо живить роботу зі скорочення витрат на LLM API.

Правило 4: Прикріплюйте контекст трейсу (семантичні конвенції OpenTelemetry GenAI)

Рядок логу без trace ID — сирота: ви можете прочитати його, але не можете сказати, який ретрай, який RAG-крок чи який хід користувача його породив. Виправлення: семантичні конвенції OpenTelemetry GenAI, стандартні назви атрибутів для інструментування викликів моделі. Видавайте лог усередині активного спана, і trace_id зі span_id прикріпляться самі, тож один клік у Grafana перенесе вас від водоспаду трейсу прямо до сирого запису.

Атрибути, які варто встановлювати на кожному 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

Правило 5: Редагуйте PII до запису в лог

PII-редагування має відбуватися до того, як запис записано, а не витиратися після. Щойно email-адреса потрапила в Loki, вона також у ваших бекапах об'єктного сховища, і «ми видалили її пізніше» не є відповіддю для GDPR. У нашому сетапі Microsoft Presidio працює як процесор structlog і ловить 94% email-адрес і номерів телефонів до того, як вони влучать у Loki; промахи майже всі через дивне форматування, і ми додаємо їх у кастомні розпізнавачі, щойно знаходимо.

Весь хук складається з п'ятнадцяти рядків:

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

Редагування сидить у тому самому шарі пайплайну, що й ваші фільтри входу й виходу, і тестувати його треба так само. Наш пайплайн гардрейлів вважає витік email-адреси в лог проваленим евлом, а не приміткою в ops-звіті.

Правило 6: Розумна вибірка на великих обсягах

Приблизно до 100 тис. запитів на день логуйте все. Понад цю межу повне логування є податком на сховище за дані, які ви ніколи не прочитаєте, і вибірка це спосіб зберегти важливі записи. Пастка в тому, що випадкова вибірка є найгіршим варіантом для LLM-трафіку, бо збої, відмови й п'ятидоларові запити за означенням рідкісні, тож рівномірні 10% викидають саме ті події, які ви налагоджуєте. Робіть вибірку за результатом, а не підкиданням монети.

Поширений сетап: вибірка за правилами на краях (продакшн і корпоративні тенанти логуються завжди) плюс хвостова посередині. Специфіка логування в цій схемі: ваші поля guardrail_result і cost_usd є сигналами для вибірки, і вони вже на місці, якщо ви дотрималися правил 2 і 8.

Правило 7: Встановіть політику зберігання, поки вона не знадобилася

Політика зберігання логів це рішення, яке ухвалюють спокійним, бо альтернатива це ухвалювати його під час перегляду витрат при вдвічі більшому обсязі. Принцип обмеження зберігання зі статті 5 GDPR каже, що персональні дані слід зберігати «не довше, ніж необхідно», що на практиці означає рівневе зберігання:

Гарячий рівень відповідає на «що сталося десять хвилин тому?» швидко й дорого; холодний відповідає на «що ми казали цьому клієнту в березні?» повільно й дешево. Видаляйте за розкладом, автоматично, інакше рівні це просто діаграма.

Правило 8: Логуйте гардрейли та події безпеки окремо

Події безпеки (блокування гардрейлами, відмови, порушення політик) — це не телеметрія, це аудиторські записи, і їм місце в окремому потоці. Три причини. Алертинг: сплеск заблокованих промпт-ін'єкцій має когось розбудити, і ви не зможете налаштувати цей алерт на тлі 1 млн рутинних рядків. Зберігання: комплаєнс може вимагати, щоб записи безпеки жили довше за налагоджувальні логи на роки. Доступ: аудитори отримують потік безпеки, а не весь ваш вогняний шланг. Позначте вердикт в основному записі (guardrail_result: "block") і скеруйте повний запис в окремий потік. Що вважається подією безпеки, розібрано в нашому гайді про події гардрейлів.

Правило 9: Зробіть логи придатними до запитів, а не просто збереженими

Лог, за яким ви не можете зробити запит за хвилину, є бекапом, а не сигналом спостережності. «Придатний до запитів» означає індексовані поля, мову запитів, яку ваш черговий інженер справді знає, і дашборди, побудовані до інциденту. Ми працюємо з Loki і робимо запити 30+ разів на тиждень про аномалії вартості, регресії затримки та «покажи мені кожну відмову для тенанта X учора». Документація Grafana Loki є довідником із синтаксису; патерн, що відпрацьовує своє, це фільтрація безпосередньо за розпарсеними 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"

П'ять рядків, без експорту в ноутбук. Якщо ваше поточне сховище так не вміє, саме це проблема, яку треба виправити першою.

Що ми насправді логуюмо в продакшені

Досить теорії. Ось конфіг із редагованими даними з нашого пайплайну AI SDR, сервісу, що стоїть за цифрою 1,2 млн запитів на місяць зі вступу. Він працює на structlog 25.4.0, що рендерить JSON і відправляє у Grafana Cloud Loki через Promtail. Модель на цьому пайплайні це claude-sonnet-4-20250514, і кожен виклик проходить рівно той ланцюжок процесорів із правил 2 і 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()

Дві цифри з першого кварталу з цим сетапом. Місячний інгест стабілізувався на 47 ГБ у чотирьох сервісах, а p95-затримка запису логу становить 3 мс, тобто пайплайн не додає нічого вимірного до часу запиту.

Зміна конфіга, що окупила себе: ми додали cost_usd до кожного запису логу в березні 2026-го. За тиждень ми знайшли один шаблон промпта, що спалював 340 доларів на місяць у циклах ретраїв. Тимчасова помилка API запускала три ретраї, і кожен повторно надсилав повний контекст на 4000 токенів. Логи зробили з цього однорядковий запит; без вартості на кожен запит це спливло б як непояснений рядок у наступному квартальному перегляді бюджету.

Скільки коштує зберігання LLM-логів у масштабі?

За 1 млн запитів на день зберігання LLM-логів коштує приблизно від 1,20 до 108 доларів на місяць за ті самі дані, залежно від сховища. Арифметика: повний структурований запис у середньому близько 2 КБ, тож 1 млн запитів на день це 2 ГБ на день, або 60 ГБ на місяць. Опубліковані вендорами ціни нижче (липень 2026) показують, скільки коштують ці 60 ГБ у трьох поширених бекендах.

Джерела: прайсинг Datadog, Grafana Loki і документація ClickHouse зі спостережності.

Два застереження, бо це наш розрахунок з тарифів вендорів, а не бенчмарк, який ми прогнали. По-перше, цифра Datadog припускає, що ви індексуєте все; більшість команд індексують підмножину й платять значно менше, тоді як Loki і ClickHouse беруть переважно за те, що ви зберігаєте. По-друге, 1,20 долара self-hosted ClickHouse приховують реальний рахунок: обчислення для запуску кластера і години інженера на його обслуговування. За 60 ГБ на місяць managed-сервіс майже завжди дешевший за сукупною вартістю. Self-hosting починає мати сенс приблизно після 1 ТБ на місяць, де розрив у ціні за ГБ перекриває операційні накладні.

Розкид і є головним висновком. За 1 млн запитів на день прірва між Datadog з індексацією та self-hosted ClickHouse становить приблизно 90 разів: 108 доларів проти 1,20 за ті самі 60 ГБ. Обирайте сховище на етапі архітектури, а не після того, як прийде рахунок.

Який інструмент логування обрати?

Для більшості команд вибір зводиться до чотирьох варіантів: LLM-нативна платформа (Langfuse або LangSmith), інструмент проксі-шару (Helicone) або звичайний пайплайн OpenTelemetry в інфраструктуру, яку ви вже маєте. Таблиця покриває моменти рішення, що реально відрізняються; дашборди, відтворення та версіювання промптів є базовим набором в усіх чотирьох.

Наша думка прямо: ми використовуємо OTel-нативний підхід плюс Loki, бо в нас уже був стек Grafana для всього іншого, і додати ще одне джерело даних було краще, ніж брати четвертого вендора. Якщо ви починаєте з нуля без жодного стека спостережності, модель трейсингу Langfuse і її безплатний тариф є найшвидшим шляхом до користі, а опція self-host тримає двері для виходу відчиненими. Якщо обираєте між двома LLM-нативними лідерами, наш розбір Langfuse проти LangSmith робить повне порівняння. А якщо логування є частиною ширшого рішення про моніторинг, повне порівняння платформ покриває ширше поле.

Які найпоширеніші помилки логування LLM?

Шість помилок пояснюють більшість зламаних сетапів логування LLM, які ми бачили. Кожної дешево уникнути, якщо зловити її раніше, ніж це зробить обсяг логів:

• Логування сирих PII без редагування. Найпоширеніша і найдорожча. Один експорт підтримки чи один зламаний бакет перетворює логи промптів на інцидент захисту даних. Редагуйте до запису (правило 5), а не під час читання.
• Немає політики зберігання. Нескінченне зберігання є дефолтом усюди, і воно тихо подвоює ваш рахунок щороку. Якщо ви ніколи не видаляєте, у вас не система логування, а архів із манією величі.
• Неструктуровані текстові логи. Вивід print, який можна лише grep-ати, працює на масштабі демо і руйнується за 100 тис. запитів на день, коли «знайди кожен невдалий запит для моделі X» стає післяобідом зі shell-скриптом замість запиту.
• Логування лише помилок. Успішні запити є базовою лінією, відносно якої ви виявляєте дрейф, і вони є сировиною вашого пайплайну оцінювання. Логуйте й перемоги, з вибіркою, якщо обсяг змушує.
• Ігнорування полів вартості. Без cost_usd на запит немає алертів вартості, немає атрибуції за фічами, і цикл ретраїв на 340 доларів на місяць із продакшн-секції вище лишається невидимим до квартального рахунку.
• Немає кореляції з трейсами. Логи, відірвані від спанів, перетворюють налагодження багатоетапних агентів на вгадування. Якщо вашому рядку логу бракує trace_id, правило 4 є виправленням.

Про автора

Мерт Батур є співзасновником Techsy.io, де команда відвантажує AI-агентів, системи автоматизації та голосові/SDR-пайплайни для B2B-клієнтів. Він пише про стек LLM-інструментів, який команда Techsy реально використовує в продакшені. Підключайтеся в LinkedIn.

Часті запитання

Що саме логуювати для кожного LLM-запиту?

Щонайменше: повний промпт і компліт з редагованими PII, назву моделі, кількість вхідних і вихідних токенів, затримку, вартість у доларах, хешований ідентифікатор користувача та ID трейса й спана OpenTelemetry. Додайте ID джерел RAG і вердикт гардрейла, якщо ваш пайплайн має ці етапи. Чотирнадцять іменованих полів, один JSON-рядок на запит.

Який найкращий формат для LLM-логів?

Структурований JSON, один об'єкт на запит, з явними назвами кожного поля. Логи вільного тексту можна лише grep-ати; JSON-записи можна агрегувати за моделлю, сумувати за вартістю і з'єднувати з трейсами. Видавайте запис структурованим логером на кшталт structlog у Python чи pino у Node і рендеріть JSON-серіалізатором, ніколи форматуванням рядків.

Як поводитися з PII в LLM-логах?

Редагуйте до запису в лог, а не після. Проганяйте промпт і компліт через детектор на кшталт Microsoft Presidio всередині вашого пайплайну логування, замінюючи імена, email-адреси й номери телефонів токенами як-от <EMAIL_ADDRESS>. Щойно сирі PII потрапляють у ваше сховище логів, вони також у ваших бекапах, і ретроспективне видалення рідко задовольняє тест GDPR на мінімізацію.

Скільки коштує зберігання LLM-логів у масштабі?

Для 1 млн запитів на день, приблизно 60 ГБ на місяць за 2 КБ на запис, очікуйте приблизно 108 доларів на місяць за індексованим прайсом Datadog LLM Observability, 30 доларів на місяць у Grafana Cloud Loki або близько 1,20 долара на місяць у стиснутому сховищі S3 для self-hosted ClickHouse плюс обчислення. Це опубліковані вендорами тарифи станом на липень 2026; self-hosting додає зверху час інженерів.

Що таке семантичні конвенції OpenTelemetry GenAI?

Це стандартні назви атрибутів OpenTelemetry для інструментування викликів LLM: gen_ai.system для провайдера, gen_ai.request.model для моделі, gen_ai.usage.input_tokens і output_tokens для кількості токенів, gen_ai.response.finish_reasons для причини зупинки генерації. Їхнє використання означає, що будь-який OTel-сумісний бекенд, від Jaeger до Tempo й Langfuse, читає ваші трейси без кастомних парсерів.

Як робити вибірку LLM-логів за високого трафіку?

Зберігайте кожну помилку, кожне блокування гардрейлом і кожен запит понад поріг вартості, а для решти робіть вибірку. Цей хвостовий підхід зберігає рідкісні події, які ви справді налагоджуєте, тоді як рівномірна випадкова вибірка викидає їх із тією самою частотою, що й нудний трафік. За обсягу нижче 100 тис. запитів на день пропустіть вибірку взагалі й логуйте все.

Як довго зберігати LLM-логи?

Розкладіть на рівні: 7 днів гарячого для живого налагодження, 30 днів теплого для розбору інцидентів й аналізу вартості та до 1 року холодного в стиснутому об'єктному сховищі для комплаєнсу й аудитів. Принцип обмеження зберігання GDPR забороняє тримати персональні дані довше, ніж необхідно, тож поєднайте кожен рівень з автоматичним видаленням, а не ручним прибиранням.

У чому різниця між логуванням LLM і трейсингом LLM?

Лог — це плаский запис однієї події: цей запит стався, з такими полями. Трейс — це причинно-наслідкове дерево спанів уздовж усього шляху запиту, скажімо, пошук, потім виклик моделі, потім два виклики інструментів. Логи кажуть що; трейси кажуть де і чому. Продакшн-сетапи видають обидва, з'єднані за trace_id.

Підсумок

Повторимо: логуйте кожен запит як JSON з іменованими полями, обчислюйте вартість під час запиту, прикріплюйте контекст трейсу OTel, редагуйте PII до запису, робіть вибірку за результатом, коли перетнули 100 тис. запитів на день, і обирайте сховище, за яким ви справді можете робити запити. Дев'ять правил упорядковані так, щоб ви могли впроваджувати по одному на спринт, і правила 2, 4 та 5 — три, що окуповуються найшвидше. Якщо ви обираєте ширший стек моніторингу навколо логів, почніть з нашого огляду найкращих платформ AI-спостережності. А якщо вам потрібна допомога з налаштуванням структурованого логування для вашого LLM-стека, отримайте безкоштовну консультацію.