Praktik Terbaik Logging LLM: 9 Aturan yang Kami Jalankan di Produksi [2026]

Praktik Terbaik Logging LLM: 9 Aturan yang Kami Jalankan di Produksi [2026]

Sembilan praktik terbaik logging LLM ini adalah aturan yang benar-benar berjalan di stack produksi kami: kami mencatat 1,2 juta request LLM per bulan di empat layanan, dan semuanya masuk ke Grafana Loki sebagai satu baris JSON dengan model, token, latency, cost_usd, dan trace_id. structlog 25.4.0 menulis record-nya, Presidio menghapus PII lebih dulu, dan seluruh pipeline ini adalah separuh logging dari stack observabilitas kami.

Poin Penting

• Catat setiap request LLM sebagai JSON terstruktur dengan 14+ field bernama, jangan pernah teks bebas.
• Redaksi PII sebelum log ditulis, pakai Presidio atau yang setara, bukan sesudahnya.
• Tempelkan atribut semantic convention OpenTelemetry GenAI ke setiap trace.
• Di 1 juta request/hari, 60GB yang sama biaya $108/bulan di Datadog, $30 di Loki, $1,20 di ClickHouse.

Apa Sebenarnya Logging LLM Itu (dan Kenapa "Catat Saja Semua" Gagal)

Logging LLM berarti menangkap record terstruktur dari setiap request dan respons model: prompt, completion, jumlah token, latency, biaya, dan trace yang mengikat semuanya ke sesi pengguna. Ini bukan logging infrastruktur. CPU, memori, dan restart pod masuk ke stack metrik kamu; artikel ini hanya membahas record level-request yang memungkinkan kamu debug, menghitung biaya, dan mengaudit perilaku model.

Insting "catat saja semua" memang susah hilang, dan mahal. Prompt dan completion penuh di 1 juta request per hari menghasilkan sekitar 60GB teks per bulan, dan sebagian dari teks itu adalah PII pelanggan yang sekarang kamu simpan tanpa batas. Prinsip minimisasi data Pasal 5 GDPR mensyaratkan data pribadi harus "cukup, relevan, dan terbatas pada yang diperlukan," dan dump prompt mentah gagal memenuhi syarat itu sejak hari pertama. Mencatat semuanya bukan strategi; itu liabilitas dengan tagihan bulanan.

Apa Saja 9 Aturan Logging LLM?

Sembilan aturan, dalam urutan yang akan kami terapkan: catat prompt dan respons penuh dengan identifier ter-hash, hasilkan JSON terstruktur, tangkap token dan biaya per request, tempelkan konteks trace OpenTelemetry, redaksi PII sebelum penulisan, sampling di volume tinggi, tetapkan tier retensi, pisahkan event keselamatan, dan buat hasilnya bisa di-query. Setiap aturan di bawah dilengkapi kode atau tabel yang menegakkannya.

Aturan 1: Catat Prompt dan Respons Penuh (Dengan Hash, Bukan PII Mentah)

Catat prompt lengkap dan completion lengkap untuk setiap request, karena log parsial adalah alasan kamu berakhir menatap insiden tanpa catatan apa yang sebenarnya dilihat model. Satu pengecualian: identitas. Jangan pernah menulis user ID mentah, email, atau nama ke dalam record. Simpan hash SHA-256 dari user ID sebagai gantinya. Hash tetap memungkinkan kamu merekonstruksi riwayat sesi penuh satu pengguna dengan lookup offline, sementara baris log itu sendiri tetap tidak berguna bagi siapa pun yang tidak seharusnya membacanya. Logika yang sama untuk system prompt: hash, catat hash-nya, dan simpan plaintext di prompt registry kamu yang sudah di-version-control.

Aturan 2: Gunakan JSON Terstruktur: Setiap Field Bernama, Tidak Ada Teks Bebas

Untuk praktik terbaik logging LLM di Python atau bahasa lain, structured logging dalam JSON adalah yang tidak bisa ditawar: setiap field bernama, bertipe, dan bisa di-query, tidak ada yang dibuang sebagai string terformat. Baris teks bebas seperti INFO called gpt-4o, took 812ms hanya bisa di-grep. Record JSON bisa diagregasi per model, dijumlahkan per biaya, dan di-join ke trace. Praktik terbaik produksi OpenAI sendiri mendorong ide yang sama: tangkap metadata terstruktur di layer SDK, bukan dengan print statement.

Berikut skema yang dihasilkan setiap layanan Techsy, empat belas field:

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

Tiga field perlu catatan. cost_usd dihitung saat request dari jumlah token dan tarif publik model, tidak pernah diisi ulang oleh job malam hari. Dua field hash adalah kompromi Aturan 1: bisa dikorelasi offline, opak di log. Dan trace_id serta span_id adalah nilai trace-context W3C, yang persis menjadi topik Aturan 4.

Kalau empat layanan yang memanggil provider langsung terdengar seperti empat tempat untuk instrumentasi, proxy LiteLLM memusatkannya: satu hook logging di depan setiap provider.

Aturan 3: Tangkap Jumlah Token dan Biaya per Request

Pelacakan penggunaan token masuk di baris log itu sendiri, bukan di job warehouse yang jalan besok. Setiap provider mengembalikan jumlah token input dan output di respons; kalikan dengan tarif per-token model saat itu juga dan tulis cost_usd ke record. Tarif berubah, dan berbeda untuk token input cached versus baru, jadi menghitung biaya nanti dengan tabel harga statis secara diam-diam menulis ulang sejarah. Dengan biaya di setiap baris, "fitur mana yang mahal?" jadi query satu baris, bukan proyek keuangan, dan langsung memberi masukan ke upaya mengurangi pengeluaran API LLM kamu.

Aturan 4: Tempelkan Konteks Trace (OpenTelemetry GenAI Semconv)

Baris log tanpa trace ID adalah anak yatim: kamu bisa membacanya, tapi tidak bisa tahu retry mana, langkah RAG mana, atau giliran pengguna mana yang menghasilkannya. Solusinya adalah semantic convention GenAI OpenTelemetry, nama atribut standar untuk instrumentasi panggilan model. Hasilkan log di dalam span aktif dan trace_id serta span_id menempel sendiri, jadi satu klik di Grafana membawa kamu dari waterfall trace langsung ke record mentah.

Atribut yang layak diset di setiap 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)  # Record Aturan 2, trace ID otomatis menempel

Aturan 5: Redaksi PII Sebelum Log Ditulis

Redaksi PII harus terjadi sebelum record ditulis, bukan dibersihkan sesudahnya. Begitu alamat email masuk ke Loki, dia juga ada di backup object-storage kamu, dan "kami hapus nanti" bukan jawaban GDPR. Di setup kami, Microsoft Presidio berjalan sebagai prosesor structlog dan menangkap 94% email dan nomor telepon sebelum masuk Loki; yang lolos hampir semua format aneh, yang kami tambahkan ke custom recognizer begitu ketemu.

Seluruh hook-nya lima belas baris:

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

# Di rantai prosesor structlog, sebelum JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

Redaksi duduk di layer pipeline yang sama dengan filter input dan output kamu, dan harus diuji dengan cara yang sama. Pipeline guardrail kami memperlakukan email yang bocor di log sebagai eval yang gagal, bukan catatan kaki ops.

Aturan 6: Sampling Cerdas di Volume Tinggi

Di bawah sekitar 100 ribu request per hari, catat semuanya. Di atas itu, logging volume penuh adalah pajak penyimpanan untuk data yang tidak akan pernah kamu baca, dan sampling adalah cara kamu menyimpan record yang penting. Masalahnya: sampling acak adalah opsi terburuk untuk traffic LLM, karena kegagalan, penolakan, dan request lima dolar itu langka secara definisi, jadi rate 10% seragam membuang persis event yang kamu debug. Sampling berdasarkan hasil, bukan lempar koin.

Setup umum adalah berbasis aturan di tepi (produksi dan tenant enterprise: selalu catat) plus berbasis ekor di tengah. Sudut pandang spesifik logging untuk framework ini: field guardrail_result dan cost_usd kamu adalah sinyal sampling, sudah ada kalau kamu mengikuti Aturan 2 dan 8.

Aturan 7: Tetapkan Kebijakan Retensi Sebelum Kamu Butuh

Kebijakan retensi log adalah keputusan yang kamu buat saat tenang, karena alternatifnya adalah membuatnya saat review biaya di volume dua kali lipat. Prinsip pembatasan penyimpanan Pasal 5 GDPR mengatakan data pribadi harus disimpan "tidak lebih lama dari yang diperlukan," yang dalam praktiknya berarti retensi bertingkat:

Hot menjawab "apa yang terjadi sepuluh menit lalu?" dengan cepat dan mahal; cold menjawab "apa yang kami bilang ke pelanggan ini di bulan Maret?" dengan lambat dan murah. Hapus sesuai jadwal, otomatis, atau tier-nya cuma diagram.

Aturan 8: Catat Event Guardrail dan Keselamatan Secara Terpisah

Event keselamatan (blok guardrail, penolakan, pelanggaran kebijakan) bukan telemetri; mereka adalah record audit, dan masuk ke stream sendiri. Tiga alasan. Alerting: lonjakan prompt injection yang diblok harus mem-page seseorang, dan kamu tidak bisa menyetel alert itu terhadap 1 juta baris rutin. Retensi: kepatuhan bisa menuntut record keselamatan bertahan lebih lama dari log debug bertahun-tahun. Akses: auditor dapat stream keselamatan, bukan seluruh firehose kamu. Tandai verdict di record utama (guardrail_result: "block") dan rutekan record lengkap ke stream terpisah. Apa yang dihitung sebagai event keselamatan dibahas di panduan kami tentang event guardrail.

Aturan 9: Buat Log Bisa Di-Query, Bukan Sekadar Tersimpan

Log yang tidak bisa kamu query dalam satu menit adalah backup, bukan sinyal observabilitas. Bisa di-query berarti field terindeks, bahasa query yang on-call kamu benar-benar tahu, dan dashboard yang dibangun sebelum insiden. Kami menjalankan Loki dan query 30+ kali seminggu untuk anomali biaya, regresi latency, dan "tunjukkan semua penolakan untuk tenant X kemarin." Dokumentasi Grafana Loki adalah referensi untuk sintaksnya; pola yang layak dipertahankan adalah filter langsung di field JSON yang di-parse:

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

Lima baris, tanpa ekspor ke notebook. Kalau store kamu sekarang tidak bisa melakukan itu, itu masalah yang harus diperbaiki lebih dulu.

Yang Sebenarnya Kami Catat di Produksi

Cukup teorinya. Berikut config yang sudah diredaksi dari pipeline AI SDR kami, layanan di balik angka 1,2 juta request per bulan di intro. Menjalankan structlog 25.4.0 merender JSON, dikirim ke Grafana Cloud Loki via Promtail. Model di pipeline ini adalah claude-sonnet-4-20250514, dan setiap panggilan melewati persis rantai prosesor dari Aturan 2 dan 5:

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Aturan 5: Presidio, sebelum serialisasi
        add_otel_trace_ids,  # Aturan 4: trace_id + span_id dari span aktif
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

Dua angka dari kuartal pertama dengan setup ini. Ingest bulanan stabil di 47GB di empat layanan, dan latency tulis log p95 adalah 3ms, artinya pipeline tidak menambahkan apa pun yang terukur ke waktu request.

Perubahan config yang balik modal: kami menambahkan cost_usd ke setiap entri log di Maret 2026. Dalam seminggu kami menemukan satu template prompt yang membakar $340/bulan di loop retry. Error API transien memicu tiga retry, masing-masing mengirim ulang konteks 4.000 token penuh. Log membuatnya jadi query satu baris; tanpa biaya per request, itu akan muncul sebagai pos anggaran tak terjelaskan di review anggaran kuartal berikutnya.

Berapa Biaya Penyimpanan Log LLM di Skala Besar?

Di 1 juta request per hari, penyimpanan log LLM biaya antara sekitar $1,20 dan $108 per bulan untuk data yang sama, tergantung store-nya. Perhitungannya: record terstruktur penuh rata-rata sekitar 2KB, jadi 1 juta request per hari adalah 2GB per hari, atau 60GB per bulan. Harga yang dipublikasikan vendor di bawah (Juli 2026) adalah biaya 60GB itu di tiga backend umum.

Sumber: Harga Datadog, Grafana Loki, dan dokumentasi observabilitas ClickHouse.

Dua catatan, karena ini perhitungan kami dari tarif vendor, bukan benchmark yang kami jalankan. Pertama, angka Datadog mengasumsikan kamu mengindeks semuanya; kebanyakan tim mengindeks subset dan bayar jauh lebih sedikit, sementara Loki dan ClickHouse menagih terutama untuk yang kamu simpan. Kedua, $1,20 ClickHouse self-hosted menyembunyikan tagihan nyata: komputasi untuk menjalankan cluster dan jam engineer untuk mengoperasikannya. Di 60GB per bulan, layanan managed hampir selalu jawaban total yang lebih murah. Self-hosting mulai masuk akal di atas sekitar 1TB per bulan, di mana selisih per-GB mengalahkan overhead ops.

Selisihnya adalah intinya. Di 1 juta request per hari, jarak antara Datadog terindeks dan ClickHouse self-hosted sekitar 90x: $108 versus $1,20 untuk 60GB yang sama. Pilih store-nya saat arsitektur, bukan setelah tagihan datang.

Tool Logging Mana yang Harus Kamu Pilih?

Untuk kebanyakan tim, pilihannya mengerucut ke empat opsi: platform native-LLM (Langfuse atau LangSmith), tool layer-proxy (Helicone), atau pipeline OpenTelemetry biasa ke infrastruktur yang sudah kamu jalankan. Tabel mencakup poin keputusan yang benar-benar berbeda; dashboard, playback, dan versioning prompt adalah standar di keempatnya.

Pendapat kami, terus terang: kami menjalankan OTel-native plus Loki karena kami sudah punya stack Grafana untuk semuanya, dan menambah satu sumber data lagi mengalahkan mengadopsi vendor keempat. Kalau kamu mulai dari nol tanpa stack observabilitas sama sekali, model tracing Langfuse dan tier gratisnya adalah jalur tercepat ke berguna, dan opsi self-host menjaga pintu keluar tetap terbuka. Kalau kamu memilih di antara dua pemimpin native-LLM, perbandingan Langfuse vs LangSmith kami menjalankan perbandingan lengkap. Dan kalau logging adalah satu bagian dari keputusan monitoring yang lebih besar, perbandingan platform lengkap mencakup bidang yang lebih luas.

Apa Kesalahan Logging LLM yang Paling Umum?

Enam kesalahan menyumbang sebagian besar setup logging LLM rusak yang pernah kami lihat. Masing-masing murah untuk dihindari kalau kamu menangkapnya sebelum volume log yang menangkapmu:

• Mencatat PII mentah tanpa redaksi. Yang paling umum dan paling mahal. Satu ekspor support atau satu bucket yang bocor mengubah log prompt jadi insiden perlindungan data. Redaksi sebelum tulis (Aturan 5), bukan saat baca.
• Tidak ada kebijakan retensi. Penyimpanan tanpa batas adalah default di mana-mana, dan diam-diam menggandakan tagihan kamu setiap tahun. Kalau kamu tidak pernah menghapus, kamu tidak punya sistem logging; kamu punya arsip dengan delusi kebesaran.
• Log teks tidak terstruktur. Output print yang hanya bisa di-grep bekerja di skala demo dan runtuh di 100 ribu request per hari, saat "cari semua request gagal untuk model X" jadi sore shell-script, bukan query.
• Hanya mencatat error. Request sukses adalah baseline yang kamu pakai untuk mendeteksi drift, dan bahan mentah pipeline evaluasi kamu. Catat yang sukses juga, sampling kalau volume memaksa.
• Mengabaikan field biaya. Tanpa cost_usd per request berarti tanpa alert biaya, tanpa atribusi per fitur, dan loop retry $340/bulan dari bagian produksi di atas tetap tak terlihat sampai tagihan kuartalan.
• Tanpa korelasi trace. Log yang terputus dari span membuat debugging agen multi-langkah jadi tebak-tebakan. Kalau baris log kamu tidak punya trace_id, Aturan 4 adalah solusinya.

Tentang Penulis

Mert Batur adalah Co-Founder Techsy.io, tempat timnya mengirim agen AI, sistem otomasi, dan pipeline voice/SDR untuk klien B2B. Dia menulis tentang stack tooling LLM yang benar-benar digunakan tim Techsy di produksi. Terhubung di LinkedIn.

Pertanyaan yang Sering Diajukan

Apa yang harus dicatat untuk setiap request LLM?

Minimal: prompt dan completion penuh dengan PII yang sudah diredaksi, nama model, jumlah token input dan output, latency, biaya dalam USD, identifier pengguna ter-hash, dan ID trace serta span OpenTelemetry. Tambahkan ID sumber RAG dan verdict guardrail kalau pipeline kamu punya tahap itu. Empat belas field bernama, satu baris JSON per request.

Apa format terbaik untuk log LLM?

JSON terstruktur, satu objek per request, dengan setiap field bernama eksplisit. Log teks bebas hanya bisa di-grep; record JSON bisa diagregasi per model, dijumlahkan per biaya, dan di-join ke trace. Hasilkan record dengan logger terstruktur seperti structlog di Python atau pino di Node, dan render dengan serializer JSON, jangan pernah formatting string.

Bagaimana menangani PII di log LLM?

Redaksi sebelum log ditulis, bukan sesudahnya. Jalankan prompt dan completion melalui detektor seperti Microsoft Presidio di dalam pipeline logging kamu, ganti nama, email, dan nomor telepon dengan token seperti <EMAIL_ADDRESS>. Begitu PII mentah mencapai store log kamu, dia juga ada di backup, dan penghapusan retroaktif jarang memenuhi uji minimisasi GDPR.

Berapa biaya penyimpanan log LLM di skala besar?

Untuk 1 juta request per hari, sekitar 60GB per bulan di 2KB per record, perkirakan sekitar $108/bulan di harga LLM Observability terindeks Datadog, $30/bulan di Grafana Cloud Loki, atau sekitar $1,20/bulan di penyimpanan S3 terkompresi untuk ClickHouse self-hosted plus komputasi. Itu tarif publikasi vendor per Juli 2026; self-hosting menambahkan waktu engineering di atasnya.

Apa itu semantic convention GenAI OpenTelemetry?

Itu adalah nama atribut standar OpenTelemetry untuk instrumentasi panggilan LLM: gen_ai.system untuk provider, gen_ai.request.model untuk model, gen_ai.usage.input_tokens dan output_tokens untuk jumlah token, dan gen_ai.response.finish_reasons untuk kenapa generasi berhenti. Menggunakannya berarti backend kompatibel OTel mana pun, dari Jaeger ke Tempo ke Langfuse, membaca trace kamu tanpa parser kustom.

Bagaimana sampling log LLM di traffic tinggi?

Simpan setiap error, setiap blok guardrail, dan setiap request di atas ambang biaya, lalu sampling sisanya. Pendekatan berbasis ekor ini melestarikan event langka yang benar-benar kamu debug, sementara sampling acak seragam membuangnya di rate yang sama dengan traffic membosankan. Di bawah 100 ribu request per hari, lewati sampling sepenuhnya dan catat semuanya.

Berapa lama harus menyimpan log LLM?

Bertingkat: 7 hari hot untuk debugging live, 30 hari warm untuk review insiden dan analisis biaya, dan sampai 1 tahun cold di object storage terkompresi untuk kepatuhan dan audit. Prinsip pembatasan penyimpanan GDPR melarang menyimpan data pribadi lebih lama dari yang diperlukan, jadi pasangkan setiap tier dengan penghapusan otomatis, bukan pembersihan manual.

Apa perbedaan antara logging LLM dan tracing LLM?

Log adalah record datar dari satu event: request ini terjadi, dengan field ini. Trace adalah pohon kausal dari span di seluruh jalur request, misalnya retrieval, lalu panggilan model, lalu dua panggilan tool. Log memberitahu kamu apa; trace memberitahu kamu di mana dan kenapa. Setup produksi menghasilkan keduanya, digabungkan oleh trace_id.

Kesimpulan

Rekap: catat setiap request sebagai JSON field bernama, hitung biaya saat request, tempelkan konteks trace OTel, redaksi PII sebelum tulis, sampling berdasarkan hasil begitu kamu melewati 100 ribu request per hari, dan pilih store yang benar-benar bisa kamu query. Sembilan aturan diurutkan supaya kamu bisa mengadopsinya satu per sprint, dan Aturan 2, 4, dan 5 adalah tiga yang balik modal paling cepat. Kalau kamu memilih stack monitoring yang lebih luas di sekitar log, mulai dari rangkuman kami tentang platform observabilitas AI terbaik. Dan kalau kamu butuh bantuan memasang structured logging untuk stack LLM kamu, dapatkan konsultasi gratis.