Logging #

Dalam sistem teknologi informasi terdistribusi, terutama di lingkungan komputasi cloud, Logging adalah mata dan telinga kita. Setiap request HTTP yang masuk, setiap query database yang lambat, setiap kegagalan transaksi pembayaran, hingga crash sistem operasi — seluruh peristiwa ini terekam dalam bentuk baris log. Pada era server tunggal tradisional (single virtual private server), kita dapat dengan mudah melakukan koneksi SSH ke server dan membaca file log secara langsung menggunakan perintah tail -f. Namun, dalam arsitektur cloud modern yang melibatkan ratusan kontainer otomatis yang lahir dan mati secara dinamis, sistem logging tradisional tersebut tidak lagi memadai. Kita membutuhkan arsitektur logging terpusat (centralized logging) yang mampu mengumpulkan, menyaring, mengindeks, dan mencari jutaan baris log secara real-time. Log yang dirancang dengan struktur yang baik adalah penolong utama kita saat terjadi pemadaman sistem (incident outage), sedangkan log yang berantakan hanya akan menjadi data sampah yang memperlama waktu pemulihan (Mean Time to Resolution / MTTR).

Structured Logging vs Plain Text #

Perbedaan terbesar yang memisahkan arsitektur logging amatir dengan kelas enterprise adalah format penulisan log.

1. Plain Text Log (Tidak Terstruktur) #

Format log tradisional berupa teks biasa satu baris yang digabungkan secara manual menggunakan manipulasi string.

• ANTI-PATTERN: Menulis baris log sebagai kalimat biasa yang digabungkan dengan variabel data.
• Masalah: Log ini sangat sulit di-parse secara otomatis oleh mesin pengumpul log. Kita terpaksa harus menulis regular expression (Regex) yang sangat rumit dan rentan error untuk mengekstrak data seperti ID Pengguna (User ID) atau durasi pemrosesan. Jika seorang developer mengubah spasi atau tata bahasa kalimat tersebut di versi aplikasi terbaru, seluruh filter regex kita akan rusak seketika.

2. Structured Log (JSON Terstruktur) #

Format log modern di mana setiap baris log ditulis sebagai objek JSON satu baris (JSON Lines atau JSONL).

• BENAR: Mengemas seluruh metadata penting ke dalam key-value terstruktur.
• Keunggulan: Setiap mesin pencari log (seperti Elasticsearch, OpenSearch, atau Grafana Loki) dapat langsung melakukan indeksasi pada setiap key secara otomatis. Kita dapat dengan mudah melakukan filter pencarian kompleks seperti: “Tampilkan semua log dari layanan ‘payment-service’ dengan event ‘payment_failed’ di mana nominal di atas Rp 1.000.000 selama 1 jam terakhir”.

// ANTI-PATTERN: Plain Text Log (Kalimat tidak terstruktur)
2026-06-21 12:30:45 [ERROR] Gagal memproses transaksi order_id 98765 untuk user 12345. Error: Saldo tidak cukup. Durasi: 245ms.

// --- Separator ---

// BENAR: Structured JSON Log (Terstruktur & Mudah Diindeks)
{
  "timestamp": "2026-06-21T12:30:45.123Z",
  "level": "ERROR",
  "service": "payment-service",
  "event": "payment_failed",
  "user_id": "12345",
  "order_id": "98765",
  "duration_ms": 245,
  "error_code": "INSUFFICIENT_FUNDS",
  "error_message": "Saldo tidak cukup",
  "trace_id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
  "environment": "production"
}

Anatomi dan Skema Field Log Standar #

Untuk memastikan konsistensi pencarian di seluruh layanan mikro (microservices), seluruh tim pengembang wajib menyepakati skema field standar yang wajib ada di setiap baris JSON log:

1. Field Inti (Core Fields) #

• timestamp: Waktu presisi saat peristiwa terjadi di tingkat aplikasi. Format wajib menggunakan standar ISO 8601 UTC (contoh: 2026-06-21T12:30:45.123Z), bukan waktu lokal server, untuk mempermudah korelasi kronologis saat terjadi insiden lintas region.
• level: Kategori keparahan log (DEBUG, INFO, WARN, ERROR, FATAL).
• service: Nama microservice yang memicu log (misal: auth-service, cart-service).
• message: Deskripsi singkat yang mudah dibaca manusia mengenai peristiwa tersebut.

2. Field Kontekstual & Korelasi (Context Fields) #

• trace_id: ID unik yang diwariskan dari request awal pengguna saat melewati API Gateway hingga ke microservice paling ujung. Trace ID ini mengaitkan seluruh log yang tersebar di puluhan server berbeda untuk satu transaksi request yang sama.
• user_id / tenant_id: Mengidentifikasi pengguna atau klien korporasi yang terpengaruh oleh peristiwa tersebut.
• environment: Menandai asal lingkungan (development, staging, production).

3. Field Performa & Error (Telemetry Fields) #

• duration_ms: Durasi waktu pemrosesan operasi dalam milidetik.
• error_code & stack_trace: Kode kesalahan mesin dan dump tumpukan memori kode saat terjadi crash (hanya pada level ERROR dan FATAL).

// Contoh inisialisasi logger terstruktur di Node.js menggunakan Winston (BENAR)
const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json() // Otomatis mengonversi log ke format JSON
  ),
  defaultMeta: { service: 'order-service', environment: 'production' },
  transports: [
    new winston.transports.Console() // ✓ BENAR: Tulis ke Console (stdout)
  ]
});

// Cara penggunaan dalam kode
logger.error('Proses checkout order gagal', {
  order_id: '98765',
  user_id: '12345',
  error_code: 'STOCK_OUT',
  duration_ms: 120,
  trace_id: '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'
});

Disiplin Penggunaan Log Levels #

Pengelompokan tingkat keparahan (log levels) yang tidak disiplin akan memicu alarm palsu (alert fatigue) bagi tim operasional. Kita harus memisahkan level log sesuai dengan panduan berikut:

Arsitektur Pengiriman Log Terpusat #

Di lingkungan cloud, kontainer aplikasi kita bersifat sementara (ephemeral). Jika kontainer Kubernetes mengalami crash atau dihancurkan oleh proses auto-scaling, seluruh file log yang disimpan di disk lokal kontainer tersebut akan ikut lenyap selamanya.

Oleh karena itu, aplikasi kita wajib mematuhi aturan Twelve-Factor App: “Aplikasi tidak boleh mengelola file log-nya sendiri. Aplikasi hanya boleh menuliskan log ke output standar (stdout) dan error standar (stderr) sebagai event stream” tanpa memikirkan ke mana log tersebut akan dikirimkan.

flowchart TD
    subgraph PodContainer ["Pod Kontainer Aplikasi"]
        App["Kode Aplikasi (Write JSON ke stdout)"]
    end
    
    subgraph K8sNode ["Kubernetes Worker Node VM"]
        Engine["Container Engine (Docker/Containerd)"]
        LogFile["Disk Node Lokal (/var/log/containers/*.log)"]
        Agent["Log Shipper Agent (Fluent Bit / Vector / Filebeat)"]
        
        App -->|"stdout stream"| Engine
        Engine -->|"Simpan sementara"| LogFile
        Agent -->|"Tail & Read berkas secara non-blocking"| LogFile
    end

    subgraph Aggregator ["Centralized Log Analytics System"]
        SearchDB["Log Database (OpenSearch / Grafana Loki / Datadog)"]
        UI["Visualisasi Dashboard (Kibana / Grafana)"]
        
        Agent -->|"Kirim massal via HTTPS (Batch & Compress)"| SearchDB
        SearchDB --> UI
    end

Mekanisme Pipeline Pengiriman Log: #

1. stdout Capture: Kontainer menulis log JSON ke console (stdout). Sistem container engine (seperti containerd) menangkap output tersebut dan menyimpannya sebagai file teks sementara di disk lokal server host VM (/var/log/containers/).
2. Log Agent Tail: Sebuah agen log ringan (Log Shipper seperti Fluent Bit, Vector, atau Filebeat) berjalan sebagai daemon di server host VM. Agen ini membaca file log lokal secara non-blocking, menambahkan metadata tambahan (seperti nama Pod Kubernetes, ID kontainer, nama host VM, dan nama region cloud), lalu mengirimkannya ke database pusat.
3. Aggregation & Indexing: Database pusat terkelola (seperti OpenSearch, Datadog, atau Grafana Loki) menerima aliran log, melakukan kompresi data, mengindeks field-field JSON, dan menampilkannya pada dashboard visual (seperti Kibana atau Grafana) untuk di-query oleh tim insinyur kita.

Klasifikasi Data Sensitif: Apa yang Tidak Boleh Masuk Log #

Log adalah file teks biasa. Menyimpan informasi rahasia atau data sensitif pelanggan di dalam log adalah celah kebocoran data (data leakage) yang sangat fatal. Tim kepatuhan audit keamanan (seperti PCI-DSS atau HIPAA) dapat langsung mencabut sertifikasi keamanan perusahaan kita jika mereka menemukan data sensitif tersimpan di log.

Data yang Dilarang Keras Masuk Log: #

• Kredensial: Password teks biasa, access key, secret token, PIN, dan session token.
• Data Finansial: Nomor kartu kredit lengkap (PAN), tanggal kadaluwarsa kartu, dan nomor CVV/CVC.
• Data PII (Personally Identifiable Information): Nomor KTP/NIK, alamat rumah lengkap, dan nomor telepon seluler. Cukup gunakan user_id atau lakukan hashing satu arah (SHA-256) jika membutuhkan korelasi data.
• Data Medis: Rekam medis pasien, diagnosis penyakit, dan resep obat (pelanggaran undang-undang HIPAA).

// Contoh Middleware JavaScript untuk menyensor password secara otomatis sebelum menulis log (BENAR)
const maskSensitiveData = (data) => {
  const jsonString = JSON.stringify(data);
  
  // Regex untuk mencari key password, cvv, atau token dan menyensor nilainya
  const maskedString = jsonString.replace(
    /("(password|cvv|access_token)":\s*")([^"]+)(")/gi, 
    '$1[REDACTED]$4'
  );
  
  return JSON.parse(maskedString);
};

// Penggunaan dalam HTTP Request Logging
app.use((req, res, next) => {
  // Sensor request body sebelum menulis log
  const safeBody = maskSensitiveData(req.body);
  logger.info('HTTP Request received', {
    path: req.path,
    method: req.method,
    payload: safeBody // ✓ BENAR: Payload sudah bersih dari data sensitif
  });
  next();
});

Retensi Log dan Strategi Pengendalian Biaya #

Menyimpan seluruh data log selama bertahun-tahun di database pencarian cepat akan memicu pembengkakan biaya tagihan cloud (cloud bill explosion). Kita harus menerapkan kebijakan retensi bertingkat (multi-tiered retention):

Pembagian Tier Penyimpanan Log #

Strategi Pengurangan Biaya Logging: #

1. Sampling Log: Untuk request sukses berkapasitas sangat tinggi (seperti endpoint health-check load balancer yang mengembalikan status HTTP 200 setiap 5 detik), kita tidak perlu mencatat 100% log-nya. Cukup catat sampel 1% dari total request sukses, namun tetap catat 100% log jika request tersebut gagal (HTTP 5xx).
2. Filter Tingkat Keparahan: Pastikan log tingkat debug (DEBUG) tidak pernah lolos ke lingkungan produksi. Konfigurasikan agen log untuk membuang baris log di bawah level INFO sebelum dikirimkan ke jaringan.

Ringkasan #

• Structured Logging berbentuk JSON wajib diimplementasikan agar mesin pencari log dapat melakukan indeksasi otomatis dan query filter secara presisi.
• Aplikasi hanya boleh menulis log ke stdout/stderr sesuai prinsip Twelve-Factor App, membiarkan Log Shipper Agent yang mengelola pengiriman log.
• Timestamp wajib menggunakan format ISO 8601 UTC guna menyelaraskan sinkronisasi kronologis peristiwa saat terjadi insiden lintas server/region.
• Gunakan Log Level secara disiplin — Nonaktifkan DEBUG di produksi, batasi ERROR hanya untuk kegagalan transaksi bisnis, dan gunakan FATAL jika aplikasi crash.
• Terapkan sensor masking otomatis pada log tingkat middleware untuk mencegah kebocoran data rahasia, finansial, dan data PII pelanggan.
• Terapkan kebijakan retensi bertingkat (Hot, Warm, Cold) untuk menyeimbangkan kebutuhan operasional debugging dengan efisiensi biaya penyimpanan cloud.

← Sebelumnya: Zero Trust   Berikutnya: Metrics →