Log Level dalam pengembangan aplikasi: apa itu, jenis level dan konfigurasi

Apa itu Log Level?

Log Level — adalah atribut dari setiap pesan log yang menentukan kepentingan dan urgensi pemrosesannya. Platform modern iOS dan Android mendukung skala terpadu 6–7 level: dari yang paling detail (Verbose/Trace) hingga kritis (Error/Assert). Pemilihan level menentukan apakah pesan akan ditulis ke log pada konfigurasi aplikasi saat ini.

Konsep Log Level didasarkan pada prinsip piramida keparahan: semakin tinggi levelnya, semakin sedikit pesan yang ditampilkan di level tersebut. Menurut data Semaphore CI, 2024, dalam aplikasi produksi distribusinya terlihat seperti ini: Info — 60% pesan, Warn — 25%, Error — 10%, Debug — 5%. Pesan Verbose harus sepenuhnya dinonaktifkan di produksi.

Setiap platform mengimplementasikan Log Level melalui API-nya sendiri. Android menggunakan android.util.Log dengan metode v(), d(), i(), w(), e(). Apple — OSLog dengan level default, info, debug, error, fault. Pustaka seperti Timber dan CocoaLumberjack membangun fungsionalitas tambahan di atas API standar ini.

Menurut data Google I/O 2023, pemilihan Log Level yang salah adalah penyebab 40% masalah performa di produksi. Pengembang meninggalkan log Debug di build release, yang menyebabkan penulisan berlebihan ke disk dan pengosongan baterai yang dipercepat.

Jenis level logging: dari Verbose hingga Assert

Verbose (TRACE) — level paling detail, ditujukan khusus untuk pengembangan. Pada level ini, semua perhitungan antara, iterasi loop, hasil setiap langkah algoritma ditampilkan. Di Android level ini sesuai dengan Log.v(), di iOS — OSLog dengan tipe debug (sebelum iOS 14 digunakan os_trace).

Debug — pesan debugging yang berguna selama pengembangan dan pengujian. Berisi informasi tentang status objek kunci, hasil kueri SQL, parameter panggilan API. Tidak seperti Verbose, pesan Debug terstruktur dan bermakna secara semantik. Di iOS level ini sesuai dengan OSLogType.debug.

Info — pesan informatif tentang peristiwa normal aplikasi: inisialisasi SDK, otorisasi berhasil, pembukaan layar, penerimaan data dari server. Pesan Info tidak boleh mengandung data pribadi pengguna dan harus aman untuk analisis produksi. Di iOS digunakan OSLogType.info, di Android — Log.i().

Warn — peringatan tentang potensi masalah. Aplikasi terus berjalan, tetapi situasi memerlukan perhatian: ukuran cache mendekati batas, versi API yang usang, respons jaringan yang lambat, percobaan ulang koneksi. Di Android — Log.w(), di iOS — OSLogType.default (untuk peringatan).

Error — kesalahan kritis di mana aplikasi tidak dapat melakukan operasi yang diminta, tetapi tetap berjalan: permintaan gagal ke API, kehilangan koneksi, kesalahan penulisan ke database, kurangnya izin. Di iOS untuk kesalahan digunakan OSLogType.error, di Android — Log.e().

Assert (WTF) — level tertinggi, yang menunjukkan situasi “ini tidak mungkin terjadi”. Digunakan untuk mencatat bug yang melanggar invariant fundamental sistem. Di Android pesan Assert tidak ditampilkan di build release secara default. Di iOS WTF (What a Terrible Failure) diproses melalui OSLogType.fault.

Menggunakan Log Level di Android

Android Log API — mekanisme logging bawaan dari paket android.util.Log. Menyediakan 6 metode statis: Log.v(), Log.d(), Log.i(), Log.w(), Log.e() dan Log.wtf(). Setiap metode menerima tag (string identifikasi sumber) dan msg (teks pesan).

class UserRepository {
    companion object {
        private val TAG = "UserRepo"
    }

    suspend fun loadUser(id: String): User {
        Log.d(TAG, "Memuat pengguna dengan id: $id")

        return try {
            val response = api.fetchUser(id)
            Log.i(TAG, "Pengguna berhasil dimuat")
            response.toUser()
        } catch (e: Exception) {
            Log.e(TAG, "Gagal memuat pengguna: ${e.message}")
            throw e
        }
    }
}

Pemfilteran berdasarkan level di Android Logcat dilakukan melalui ADB: adb logcat *:E akan menampilkan hanya pesan Error. Di build produksi, semua panggilan Log.v() dan Log.d() dihapus oleh ProGuard/R8 saat minifikasi diaktifkan. Log.i(), Log.w() dan Log.e() tetap ada, jadi penting untuk tidak mengeluarkan data sensitif melalui metode ini.

Untuk pemfilteran kustom saat runtime, Android menyediakan Log.isLoggable(tag, level) — metode yang memeriksa apakah level yang ditentukan diaktifkan untuk tag tertentu. Ini memungkinkan pengaktifan logging terperinci secara dinamis untuk modul tertentu tanpa membangun ulang aplikasi.

Menggunakan Log Level di iOS dan macOS

OSLog — sistem logging terpadu Apple, yang menggantikan NSLog yang sudah usang. OSLog menyediakan 5 level: debug, info, default (notice), error dan fault. Keunggulan utamanya adalah logging terstruktur dengan dukungan untuk string terformat dan pemfilteran dinamis melalui konsol.

import OSLog

let logger = Logger(
    subsystem: "com.example.app",
    category: "network"
)

func fetchData(from url: URL) {
    logger.debug("Starting request to \(url.absoluteString)")

    do {
        let data = try Data(contentsOf: url)
        logger.info("Received \(data.count) bytes")
    } catch {
        logger.error("Request failed: \(error.localizedDescription)")
    }
}

Sistem pemfilteran OSLog bekerja di tingkat sistem operasi. Pesan Debug hanya ditulis saat debugger terhubung atau saat argumen -com.apple.CoreData.Logging.debug 1 diaktifkan. Pesan Info dikumpulkan di memori perangkat (hingga 512 KB) dan dapat diakses melalui Console.app. Error dan fault ditulis secara konstan dan tersedia untuk dikumpulkan melalui sistem pelaporan crash.

Fitur penting OSLog: string terformat dengan placeholder. Alih-alih interpolasi string Swift (yang selalu dihitung, terlepas dari levelnya), OSLog menggunakan format os_log dengan %{public}@ dan %{private}@ untuk membedakan data sensitif. Parameter private disembunyikan di log produksi.

Produksi vs Debug: cara mengatur pemfilteran level

Aturan dasar — set level minimum di produksi: Info, Warn, Error, Assert. Debug dan Verbose harus dinonaktifkan. Alasannya bukan hanya keamanan, melainkan performa: setiap panggilan log menghabiskan waktu CPU untuk memformat string, bahkan jika pesan tidak ditampilkan.

Pemformatan string malas

Optimasi kritis — jangan pernah menggunakan interpolasi string dalam panggilan log. Jika string dibentuk sebelum panggilan log(), waktu CPU terbuang bahkan saat level dinonaktifkan. Gunakan pemformatan malas melalui lambda atau kondisi penjaga.

Di Android, metode Log.isLoggable() melayani tujuan ini, di OSLog — dukungan native untuk string terformat dengan placeholder. Timber untuk Android memecahkan masalah melalui timber.log.Tree dengan pemeriksaan level di dalam pohon.

Perubahan level secara dinamis saat berjalan

Remote Log Level — praktik di mana level logging dikendalikan dari server melalui Firebase Remote Config atau layanan serupa. Jika terjadi kesalahan kompleks di produksi, pengembang dapat mengaktifkan logging Debug dari jarak jauh untuk modul tertentu di perangkat kelompok pengguna yang dipilih.

Menurut data Firebase, 2024, praktik ini mengurangi waktu diagnosis bug langka hingga 60% dan memungkinkan mendapatkan gambaran lengkap masalah tanpa menginstal build debug. Batasan utamanya adalah log hanya aktif pada startup aplikasi berikutnya setelah menerima konfigurasi.

Pemfilteran otomatis berdasarkan tipe build

BuildConfig.DEBUG di Android dan #if DEBUG di Swift — mekanisme kompilasi bersyarat standar yang menonaktifkan level debugging di build release. Untuk arsitektur yang bersih, disarankan untuk memindahkan pemilihan Log Level ke kontainer DI atau pabrik logger, agar tidak membebani logika bisnis dengan arahan bersyarat.

Praktik terbaik dalam memilih level logging

Aturan pertama — setiap panggilan log harus menjawab pertanyaan „siapa, apa, kapan”. Siapa — komponen atau modul (tag di Android, category di iOS). Apa — peristiwa spesifik atau perubahan status. Kapan — stempel waktu, yang ditetapkan secara otomatis oleh sistem logging.

Aturan kedua — jangan mencatat data sensitif melalui Info dan level di atasnya. Kata sandi, token, email, nomor telepon, koordinat geografis yang tepat — dilarang keras dalam log apa pun yang masuk ke produksi. Jika perlu, gunakan penyamaran: „email: us***@example.com”.

Aturan ketiga — level Warn adalah zona tanggung jawab pengembang, Error — tim. Warn berarti „di sini ada potensi masalah, pantau”. Error — „di sini ada masalah, perbaiki”. Jangan gunakan Error untuk situasi yang diharapkan dan ditangani (misalnya, kesalahan API 404).

Aturan keempat — konsistensi. Seluruh proyek harus menggunakan konvensi penamaan yang seragam untuk tag dan kategori. Disarankan ClassName.methodName untuk tag Android dan module.subsystem untuk kategori iOS. Ini memungkinkan pemfilteran log cepat berdasarkan komponen.

Aturan kelima — uji log. Dalam pengujian unit, periksa bahwa dalam skenario tertentu Log Level yang benar dipanggil. Untuk tujuan ini, ada pustaka logging mock: Mockito untuk Android, Cuckoo untuk iOS. Pemeriksaan level dalam pengujian mencegah kebocoran pesan debugging ke produksi.