Structured Logging — esensi, format data dan prinsip kerja dalam aplikasi

Apa itu Structured Logging

Structured Logging adalah metode pencatatan log di mana setiap pesan berisi bidang bernama dengan nilai yang diketik. Alih-alih string seperti User 42 logged in from device ABC log terstruktur terlihat sebagai kumpulan bidang: user_id=42, event=login, device_id=ABC, timestamp=2026-07-04T10:30:00Z.

Keunggulan utama log terstruktur dibandingkan log teks adalah kemungkinan pemrosesan terprogram. Penguraian log teks memerlukan ekspresi reguler dan asumsi tentang format string. Log terstruktur diurai tanpa kehilangan: setiap bidang memiliki tipe dan nama yang diketahui, memungkinkan pembuatan kueri seperti temukan semua kesalahan otorisasi dalam satu jam terakhir untuk pengguna 42 tanpa pemrosesan tambahan.

Menurut data Honeycomb.io (2023), tim yang menggunakan structured logging dalam produksi mendeteksi insiden rata-rata 4 kali lebih cepat dibandingkan tim yang mengandalkan log teks dan grep.

Format log terstruktur

Structured Logging mendukung beberapa format serialisasi. Pemilihan format tergantung pada infrastruktur: JSON nyaman untuk integrasi dengan Elasticsearch dan sistem cloud, logfmt — untuk tampilan konsol melalui tail dan grep, Protocol Buffers — untuk sistem berkinerja tinggi dengan keterbatasan bandwidth.

JSON — format universal

JSON adalah format paling umum untuk log terstruktur. Didukung secara native oleh semua sistem pengumpulan: Logstash, Fluentd, Amazon CloudWatch, Google Cloud Logging. Log JSON mudah dibaca manusia dan diurai oleh bahasa pemrograman apa pun tanpa pustaka tambahan. Kekurangan utama — redundansi: setiap pasangan kunci-nilai memerlukan tanda kutip dan titik dua, yang meningkatkan volume data yang disimpan sebesar 30–50% dibandingkan logfmt.

Logfmt — format ringkas

Logfmt dikembangkan di Heroku untuk visibilitas konsol. Lebih ringkas dari JSON, mempertahankan keterbacaan manusia dan mudah dipotong dengan cut dan awk. Contoh: ts=2026-07-04T10:30:00Z level=error module=api status=500. Logfmt tidak memerlukan escaping sebagian besar karakter dan cocok untuk logging stdout dalam kontainer.

Mengapa Structured Logging diperlukan dalam pengembangan mobile

Dalam aplikasi mobile, Structured Logging menyelesaikan tiga tugas utama: menemukan penyebab crash tanpa reproduksi di perangkat, melacak sesi pengguna, dan menganalisis kinerja berdasarkan versi aplikasi.

Log teks di perangkat mobile hampir tidak berguna — pengembang tidak dapat melakukan grep pada log di perangkat pengguna. Log terstruktur dikirim ke sistem cloud (Firebase, Sentry, Datadog) dan diindeks di sana. Dapat dibuat kueri: tampilkan semua crash di iOS 17.4, versi aplikasi 3.2, di modul checkouts — dan mendapatkan pilihan tepat dalam beberapa detik.

Menurut data Sentry (2024), aplikasi yang menggunakan structured breadcrumbs memiliki 60% lebih banyak konteks di setiap laporan crash dibandingkan aplikasi yang hanya mencatat teks kesalahan. Ini secara langsung mempengaruhi kecepatan perbaikan bug.

Alat pengumpulan dan analisis

ELK Stack — Elasticsearch, Logstash, Kibana — tetap menjadi infrastruktur standar untuk bekerja dengan log terstruktur. Logstash menerima log dalam JSON, mengubah dan mengirim ke Elasticsearch untuk diindeks, Kibana menyediakan antarmuka visual untuk kueri dan dashboard.

Untuk aplikasi mobile, solusi cloud populer: Firebase Crashlytics dengan log khusus, Sentry dengan breadcrumbs, Datadog dengan pelacakan APM. Mereka menerima log terstruktur langsung dari SDK mobile dan tidak memerlukan deployment backend sendiri. Firebase menawarkan paket gratis untuk laporan crash, Sentry menambahkan distributed tracing, dan Datadog terintegrasi dengan APM untuk pelacakan kinerja permintaan secara simultan di klien dan server.

Grafana Loki — alternatif Elasticsearch, dioptimalkan untuk log. Loki secara default tidak mengindeks konten pesan, melainkan menggunakan label untuk filtering. Ini jauh lebih murah dalam penyimpanan dan lebih cepat untuk kueri berdasarkan kumpulan bidang tetap.

// Structured logging melalui Swift Logger ke JSON
struct StructuredLog {
    let event: String
    let attributes: [String: Any]
    let level: String

    func serialize() -> String {
        var base = "event=\(event) level=\(level)"
        for (key, value) in attributes {
            base += " \(key)=\(value)"
        }
        return base
    }
}

Praktik terbaik Structured Logging

Aturan pertama logging terstruktur: setiap pesan harus berisi ID permintaan atau sesi. Tanpa konteks, satu log tidak berguna — tidak mungkin memahami pengguna atau permintaan mana yang dimaksud. Tambahkan correlation ID di awal sesi dan kirimkan melalui semua lapisan aplikasi.

Aturan kedua: pengetikan bidang. Bidang numerik (duration_ms, status_code, retry_count) harus dikirim sebagai angka, bukan string. Elasticsearch dan sistem serupa mengindeks angka dan string secara berbeda: angka dapat dikenai agregasi (rata-rata, median, persentil), string — pencarian teks lengkap. Pengetikan yang salah menghilangkan kemungkinan membangun dashboard analitik.

Aturan ketiga: hindari objek bersarang. Log JSON dengan kedalaman bersarang lebih dari 2 level sulit difilter dan divisualisasikan. Alih-alih {"user": {"name": "Alice", "role": "admin"}} gunakan kunci datar: user_name=Alice user_role=admin.

// Structured logging di Android melalui Timber + logfmt
class StructuredTree : Timber.Tree() {
    override fun log(priority: Int, tag: String?,
                  message: String?, t: Throwable?) {
        val level = priorityToLevel(priority)
        val logfmt = "level=$level tag=$tag message=$message"
        sendToRemote(logfmt)
    }
}

Bidang mana yang wajib

Set bidang minimum untuk setiap pesan terstruktur: timestamp dalam ISO 8601, level (debug/info/warn/error/fatal), logger (nama modul atau kelas), message (deskripsi peristiwa yang dapat dibaca manusia). Tambahan: correlation_id, user_id (jika diketahui), version (versi aplikasi), platform (iOS/Android), environment (dev/staging/prod).

Tanpa correlation_id log terstruktur berubah menjadi kumpulan catatan terpisah yang tidak dapat dihubungkan dalam satu skenario pengguna. Hasilkan UUID setiap kali aplikasi dijalankan dan tambahkan ke semua log sesi. Dalam praktiknya, correlation_id harus dikirim melalui semua lapisan: dari peristiwa UI hingga permintaan jaringan dan tugas latar belakang — jika tidak, sebagian log akan tetap tanpa konteks dan tidak berpartisipasi dalam analitik. Dalam pelacakan ujung-ke-ujung, satu UUID memungkinkan pengumpulan gambaran lengkap jalur pengguna.

Contoh logging terstruktur di Swift dan Kotlin

Di iOS, logging terstruktur dapat diimplementasikan melalui wrapper di atas os_log yang menserialisasi bidang ke format logfmt. Di Android — melalui Timber dengan Tree khusus yang mengubah pesan menjadi JSON atau logfmt sebelum dikirim ke server.

import OSLog

struct StructuredLogger {
    let subsystem: String
    let category: String

    func log(level: OSLogType,
              event: String,
              context: [String: Any]) {
        let oslogger = Logger(
            subsystem: subsystem,
            category: category
        )
        let fields = context.map {
            "\($0.key)=\($0.value)"
        }.joined(separator: " ")
        oslogger.log(level: level,
                     "\(event) \(fields)")
    }
}

Structured vs Unstructured: perbandingan pendekatan

Pilihan antara log terstruktur dan teks tergantung pada tahap proyek. Pada tahap awal pengembangan, log teks lebih sederhana dan lebih cepat — pengembang menulis pesan langsung tanpa wrapper tambahan. Tetapi begitu proyek melampaui batas satu tim atau satu server, log terstruktur menjadi wajib.