Belajar Observability dengan LGTM Stack - Structured Logging Best Practices

#Pendahuluan

Loki bisa menyimpan log tak terstruktur, tapi kalian akan kesulitan menggali makna darinya. Structured logging — menulis log sebagai pasangan key-value atau JSON — adalah praktik yang mengubah log dari teks mentah menjadi data yang bisa diquery, diagregasi, dan dikorelasikan.

Episode ini membahas prinsip structured logging, apa yang harus dan tidak boleh dicatat, perbandingan library logging per bahasa, serta teknik korelasi log dengan TraceID. Kualitas log di episode 10 akan sangat ditentukan oleh praktik yang kalian pelajari sekarang.

#Prinsip Structured Logging

#Key-Value dan JSON

Log terstruktur selalu berbentuk field bernama. Setiap peristiwa menjadi satu objek JSON dengan timestamp, level, dan konteks:

{
  "ts": "2026-08-10T11:20:05Z",
  "level": "error",
  "service": "checkout",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "order_id": "ord-1042",
  "error": "payment gateway timeout",
  "retry_count": 3
}

Perhatikan konsistensi nama field: ts, level, service, trace_id dipakai di semua service agar query lintas service konsisten.

#Level Log yang Tepat

• DEBUG: detail untuk development, hindari di production.
• INFO: peristiwa bisnis penting yang bersifat rutin.
• WARN: kondisi yang tidak normal tapi belum gagal.
• ERROR: kegagalan yang membutuhkan perhatian.

Level yang berlebihan di production memperbesar volume log dan biaya storage tanpa nilai tambah.

#Apa yang Harus Dilog

Beberapa kategori peristiwa yang layak dicatat:

• Request dan response data: method, path, status code, durasi, dan user agent.
• Error messages dan stack traces: pesan error yang jelas beserta konteks tempat terjadinya.
• Business events: order dibuat, pembayaran berhasil, akun dibuat.
• Performance metrics: durasi langkah penting yang lambat.
• Security events: percobaan login gagal, akses mencurigakan, perubahan permission.

Contoh structured logging dengan structlog

import structlog
 
logger = structlog.get_logger()
 
def create_order(order_id):
    logger.info("order.created", order_id=order_id, total=150000)

Panggilan logger.info("order.created", ...) menghasilkan log JSON dengan field yang langsung bisa diquery di Loki.

#Apa yang Tidak Boleh Dilog

#Data Sensitif

Jangan pernah mencatat:

• PII: email, nomor telepon, alamat, data identitas pengguna.
• Credentials: token, password, API key, session cookie.
• Data pembayaran: nomor kartu dan detail transaksi sensitif.

{
  "ts": "2026-08-10T11:20:05Z",
  "level": "info",
  "event": "login.success",
  "password_hash": "jangan-pernah",
  "card_number": "4111-1111-1111-1111"
}

Field seperti password_hash di atas tidak boleh pernah muncul di log. Dampak kebocoran data ini akan dibahas lebih lanjut di episode 33.

#High-Cardinality dan Verbose Log

• High-cardinality values: jangan log ID unik sebagai label — simpan sebagai field isi baris.
• Excessive debug logs: jangan menyalakan DEBUG di production kecuali saat investigasi terarah.

#Library Logging per Bahasa

• Go: zap dan zerolog — keduanya cepat dan mendukung output JSON.
• Java: logback dan log4j2 dengan pattern encoder JSON.
• Python: structlog dan python-json-logger.
• Node.js: winston dan pino — pino terkenal sangat ringan.

pip install structlog

Setelah pip install structlog, kalian bisa langsung memakai contoh create_order di atas.

#Korelasi Log dengan TraceID

Nilai terbesar structured logging muncul saat log dikorelasikan dengan trace. Setiap service harus menyuntikkan TraceID ke dalam setiap baris log:

• Request IDs: ID unik per request, bisa dihasilkan di gateway.
• Trace IDs: dari OpenTelemetry context — dibahas di episode 14.
• User IDs dan session IDs: konteks pengguna bila relevan.
• Correlation headers: meneruskan ID antar service lewat header HTTP.

gateway -> orders -> payment -> loki
   trace_id="4bf92f..." menyatu di semua service

Dengan trace_id konsisten di semua log, kalian bisa menelusuri seluruh perjalanan sebuah request hanya dengan satu query di episode 18.

#Penutup

Di episode 12 ini kalian memahami prinsip structured logging dengan JSON dan nama field konsisten, apa yang layak dan tidak layak dilog, library terbaik per bahasa pemrograman, serta pentingnya korelasi log dengan TraceID dan Request ID.

Inti yang harus dibawa pulang:

• Log terstruktur adalah pasangan key-value yang bisa diquery mesin.
• Konsisten nama field: ts, level, service, trace_id.
• Jangan pernah melog PII, credentials, dan data pembayaran.
• Pilih library logging JSON yang sesuai bahasa tim.
• TraceID menghubungkan log ke trace di semua service.

Di episode 13 selanjutnya kita akan membahas distributed tracing dengan Tempo — backend trace berbasis object storage, arsitektur komponennya, konsep span dan sampling, serta perbandingan dengan Jaeger. Kini pillar ketiga observability mulai masuk panggung.