Uygulama Geliştirmede Log Level: Tanımı, Seviye Türleri ve Yapılandırma

Log Level Nedir?

Log Level, her günlük mesajının önemini ve işlenme aciliyetini belirleyen bir özelliktir. Modern iOS ve Android platformları, en ayrıntılıdan (Verbose/Trace) kritiğe (Error/Assert) kadar 6–7 seviyeli birleşik bir ölçeği destekler. Seviye seçimi, mesajın mevcut uygulama yapılandırmasıyla günlüğe yazılıp yazılmayacağını belirler.

Log Level kavramı kritiklik piramidi ilkesine dayanır: seviye ne kadar yüksekse, o seviyede o kadar az mesaj görüntülenir. Semaphore CI, 2024'e göre, bir üretim uygulamasında dağılım şu şekildedir: Info — mesajların %60'ı, Warn — %25'i, Error — %10'u, Debug — %5'i. Verbose mesajları üretimde tamamen devre dışı bırakılmalıdır.

Her platform Log Level'i kendi API'si aracılığıyla uygular. Android, v(), d(), i(), w(), e() yöntemleriyle android.util.Log'u kullanır. Apple, default, info, debug, error, fault seviyeleriyle OSLog'u kullanır. Timber ve CocoaLumberjack gibi kütüphaneler, bu standart API'lerin üzerine ek işlevsellik ekler.

Google I/O 2023'e göre, yanlış Log Level seçimi, üretimdeki performans sorunlarının %40'ının nedenidir. Geliştiriciler, sürüm yapılarında Debug günlüklerini bırakarak diskte aşırı yazmaya ve hızlandırılmış pil tüketimine yol açar.

Günlükleme Seviyelerinin Türleri: Verbose'tan Assert'e

Verbose (TRACE) — en ayrıntılı seviye, yalnızca geliştirme içindir. Bu seviyede, tüm ara hesaplamalar, döngü yinelemeleri ve algoritmanın her adımının sonuçları görüntülenir. Android'de bu seviye Log.v()'ye karşılık gelir, iOS'te — türü debug olan OSLog (iOS 14'ten önce os_trace kullanılıyordu).

Debug — geliştirme ve test sırasında kullanışlı hata ayıklama mesajları. Anahtar nesnelerin durumu, SQL sorgu sonuçları ve API çağrı parametreleri hakkında bilgi içerir. Verbose'un aksine, Debug mesajları yapılandırılmış ve anlamsal olarak anlamlıdır. iOS'te bu seviye OSLogType.debug'a karşılık gelir.

Info — SDK başlatma, başarılı kimlik doğrulama, ekran açma, sunucudan veri alma gibi normal uygulama olayları hakkında bilgilendirici mesajlar. Info mesajları kullanıcıların kişisel verilerini içermemeli ve üretim analizi için güvenli olmalıdır. iOS'te OSLogType.info kullanılır, Android'de — Log.i().

Warn — potansiyel sorunlar hakkında uyarılar. Uygulama çalışmaya devam eder, ancak durum dikkat gerektirir: önbellek boyutu sınıra yaklaşıyor, eski API sürümü, yavaş ağ yanıtı, bağlantıyı yeniden deneme. Android'de — Log.w(), iOS'te — OSLogType.default (uyarılar için).

Error — uygulamanın istenen işlemi gerçekleştiremediği ancak çalışmaya devam ettiği kritik hatalar: başarısız API isteği, bağlantı kaybı, veritabanı yazma hatası, izin eksikliği. iOS'te hatalar için OSLogType.error kullanılır, Android'de — Log.e().

Assert (WTF) — en yüksek seviye, “gerçekleşemez” durumunu belirtir. Sistemin temel değişmezlerini ihlal eden hataları günlüğe kaydetmek için kullanılır. Android'de Assert mesajları varsayılan olarak sürüm yapılarında görüntülenmez. iOS'te WTF (What a Terrible Failure), OSLogType.fault aracılığıyla işlenir.

Android'de Log Level Kullanımı

Android Log API — android.util.Log paketinden yerleşik günlükleme mekanizması. 6 statik yöntem sağlar: Log.v(), Log.d(), Log.i(), Log.w(), Log.e() ve Log.wtf(). Her yöntem bir tag (kaynak tanımlayıcı dize) ve msg (mesaj metni) alır.

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

    suspend fun loadUser(id: String): User {
        Log.d(TAG, "Kullanıcı $id ile yükleniyor")

        return try {
            val response = api.fetchUser(id)
            Log.i(TAG, "Kullanıcı başarıyla yüklendi")
            response.toUser()
        } catch (e: Exception) {
            Log.e(TAG, "Kullanıcı yüklenemedi: ${e.message}")
            throw e
        }
    }
}

Seviyelere göre filtreleme Android Logcat'te ADB aracılığıyla yapılır: adb logcat *:E yalnızca Error mesajlarını gösterir. Üretim yapılarında, küçültme etkinleştirildiğinde ProGuard/R8 tarafından tüm Log.v() ve Log.d() çağrıları kaldırılır. Log.i(), Log.w() ve Log.e() kalır, bu nedenle bu yöntemler aracılığıyla hassas veri çıkarmamak önemlidir.

Çalışma zamanında özel filtreleme için Android, Log.isLoggable(tag, level) — belirtilen seviyenin verilen tag için etkin olup olmadığını kontrol eden bir yöntem sağlar. Bu, uygulamayı yeniden derlemeden belirli bir modül için ayrıntılı günlüklemeyi dinamik olarak etkinleştirmeye olanak tanır.

iOS ve macOS'te Log Level Kullanımı

OSLog — Apple'ın kullanımdan kaldırılan NSLog'un yerini alan birleşik günlükleme sistemidir. OSLog 5 seviye sunar: debug, info, default (notice), error ve fault. Ana avantajı, biçimlendirilmiş dizeler ve konsol aracılığıyla dinamik filtreleme desteği ile yapılandırılmış günlüklemedir.

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

OSLog filtreleme sistemi işletim sistemi düzeyinde çalışır. Debug mesajları yalnızca hata ayıklayıcı bağlıyken veya -com.apple.CoreData.Logging.debug 1 bağımsız değişkeni etkinleştirildiğinde yazılır. Info mesajları cihaz belleğinde (512 KB'a kadar) toplanır ve Console.app aracılığıyla erişilebilir. Error ve fault mesajları sürekli olarak yazılır ve crash raporlama sistemleri aracılığıyla toplanabilir.

OSLog'un önemli bir özelliği: yer tutucularla biçimlendirilmiş dizeler. Seviyeden bağımsız olarak her zaman değerlendirilen Swift dize enterpolasyonu yerine OSLog, hassas verileri ayırt etmek için %{public}@ ve %{private}@ ile os_log biçimini kullanır. Özel parametreler üretim günlüklerinde maskelenir.

Production vs Debug: Seviye Filtrelemesi Nasıl Yapılandırılır

Temel kural — üretimde minimum seviye seti: Info, Warn, Error, Assert. Debug ve Verbose devre dışı bırakılmalıdır. Neden güvenlikten çok performanstır: mesaj görüntülenmese bile her günlük çağrısı, dizeyi biçimlendirmek için CPU süresi tüketir.

Tembel Dize Biçimlendirme

Kritik optimizasyon — günlük çağrılarında asla dize enterpolasyonu kullanmayın. log() çağrısından önce dize oluşturulursa, seviye devre dışı olsa bile CPU süresi boşa harcanır. Lambda veya koruma koşulları aracılığıyla tembel biçimlendirme kullanın.

Android'de Log.isLoggable() yöntemi bu amaca hizmet eder; OSLog'da yer tutucularla yerel biçimlendirilmiş dizeler desteklenir. Android için Timber, ağacın içinde seviye kontrolü ile timber.log.Tree aracılığıyla sorunu çözer.

Çalışırken Dinamik Seviye Değiştirme

Remote Log Level — Firebase Remote Config veya benzer bir hizmet aracılığıyla günlükleme seviyesinin sunucudan kontrol edildiği bir uygulamadır. Üretimde karmaşık bir hata oluşursa, geliştirici seçili bir kullanıcı grubunun cihazlarında belirli bir modül için uzaktan Debug günlüklemesini etkinleştirebilir.

Firebase, 2024'e göre, bu uygulama nadir hataların teşhis süresini %60 oranında azaltır ve bir hata ayıklama yapısı kurmadan sorunun tam resmini elde etmeyi sağlar. Ana sınırlama — günlükleme, yapılandırmayı aldıktan sonra uygulamanın bir sonraki başlatılmasında etkinleşir.

Yapı Türüne Göre Otomatik Filtreleme

Android'de BuildConfig.DEBUG ve Swift'te #if DEBUG, sürüm yapılarında hata ayıklama seviyelerini devre dışı bırakan standart koşullu derleme mekanizmalarıdır. Temiz mimari için, koşullu yönergelerle iş mantığını karmaşıklaştırmamak adına Log Level seçiminin bir DI kapsayıcısına veya logger fabrikasına taşınması önerilir.

Günlükleme Seviyesi Seçiminde En İyi Uygulamalar

Birinci kural — her günlük çağrısı “kim, ne, ne zaman” sorusunu yanıtlamalıdır. Kim — bileşen veya modül (Android'de tag, iOS'te category). Ne — belirli olay veya durum değişikliği. Ne zaman — günlükleme sistemi tarafından otomatik olarak eklenen zaman damgası.

İkinci kural — Info ve üzeri aracılığıyla hassas verileri günlüğe kaydetmeyin. Parolalar, tokenler, e-postalar, telefon numaraları, kesin coğrafi koordinatlar, üretime giden herhangi bir günlükte kesinlikle yasaktır. Gerekirse maskeleme kullanın: “email: us***@example.com.”

Üçüncü kural — Warn seviyesi geliştiricinin sorumluluğudur, Error — ekibin. Warn “burada potansiyel bir sorun var, göz kulak ol” anlamına gelir. Error “burada bir sorun var, düzelt” anlamına gelir. Beklenen ve işlenmiş durumlar için Error kullanmayın (örneğin, 404 API hatası).

Dördüncü kural — tutarlılık. Tüm proje, tag ve kategoriler için birleşik adlandırma kuralları kullanmalıdır. Android tag'leri için ClassName.methodName ve iOS kategorileri için module.subsystem önerilir. Bu, bileşene göre günlüklerin hızlı bir şekilde filtrelenmesini sağlar.

Beşinci kural — günlüklerinizi test edin. Birim testlerinde, belirli senaryolarda doğru Log Level'in çağrıldığını doğrulayın. Bu amaçla mock günlükleme kütüphaneleri mevcuttur: Android için Mockito, iOS için Cuckoo. Testlerde seviyeleri kontrol etmek, hata ayıklama mesajlarının üretime sızmasını önler.