Loglama Kültürü

Modern yazılım projelerinde loglama, uzun süre “ekstra bir çıktı alma yöntemi” gibi görülmüştü. Oysa günümüzde loglar, bir uygulamanın nerede hata yaptığını, hangi akışın ne kadar sürdüğünü, hatta şüpheli bir davranışın ne zaman başladığını anlayabilmenin en kritik araçlarından biri haline geldi. Bu yazıda, loglamanın nasıl doğru uygulanacağını, hangi hataların sık yapıldığını ve modern projelerde tercih edilen yöntemleri ele alacağız.

 

Loglamanın Önemi

Loglama, yalnızca hata durumları için değil; sistemin genel davranışını anlamak ve beklenmeyen durumları erken fark etmek için de gereklidir. Güncel projelerde yaşanan birçok sorunun kaynağı, aslında çok basittir:

👉 “Uygulama hata verdi, ama neden verdiğini loglardan anlayamadık.”

Bu durum hem hata çözüm süresini uzatır hem de gereksiz maliyet yaratır. Doğru loglama, bu riskleri büyük ölçüde azaltır.

 

En Sık Yapılan Loglama Hataları

❌ 1. Her Şeyi Loglamak

Bazı ekipler “Ne olur ne olmaz” diyerek aşırı log üretir. Bu yaklaşım kısa sürede kaos yaratır, anlamlı veri gürültü içinde kaybolur.

❌ 2. Log seviyelerini kullanmamak

Tüm logların “Info” olması, tıpkı tüm e-postaların “Acil” diye işaretlenmesi gibidir: Öncelik kaybolur.

❌ 3. Debug loglarını production’da açık bırakmak

Bu durum hem maliyeti artırır hem de performansı etkiler.

❌ 4. Hata yakalanıp loglanmadan yutulan exception’lar

Sessiz hatalar, en tehlikeli hatalardır.

❌ 5. Duyarlı bilgileri loglamak

Token, şifre, kredi kartı, kimlik bilgileri… 2025 standartlarında bu tip loglar doğrudan güvenlik ihlalidir.

 

Doğru Loglama Nasıl Yapılır?

1) Log seviyelerini doğru kullanın

Logları sınıflandırmak, hem okunabilirliği hem de analiz kolaylığını artırır.

Seviye	Kullanım Amacı
Error	İşlem başarısız. Çözülmesi gereken bir durum.
Warning	Beklenmeyen ama kritik olmayan davranış.
Info	Normal süreçlerin kaydı.
Debug	Geliştirme aşamasında detaylı bilgi.

 

2) Yapılandırılmış log kullanın (JSON tercih nedeni)

Düz metin loglar artık yönetilebilir değil. JSON formatlı loglar ise analiz araçları tarafından kolayca işlenebilir.

Örnek:

{

  "event": "GetUser",

  "userId": 42,

  "status": "NotFound",

  "timestamp": "2025-11-15T22:21:05Z"

}

Bu yapı hem okunaklıdır hem de otomatik olarak işlenebilir.

 

3) Somut örnek: Doğru loglanmış bir metot

public User GetUser(int id)

{

    // Normal akış bilgisi

    _logger.LogInformation("GetUser çağrıldı. UserId={Id}", id);

    try

    { var user = _userRepository.GetById(id);

        if (user == null)

        {

               // Beklenmeyen durum

            _logger.LogWarning("Kullanıcı bulunamadı. UserId={Id}", id);

        }

        return user;

    }

    catch (Exception ex)

    {

        // Kritik hata → logda hem mesaj hem stack trace olmalı

        _logger.LogError(ex, "GetUser sırasında hata oluştu. UserId={Id}", id);

        throw;

    }

}

Neden etkili?

• Her bilgi seviyelendirilmiş.
• Gereksiz detay yok.
• Duyarlı veri yok.
• Hata sırasında yeterli bağlam sağlanmış.

 

💡 İpuçları

Log retention süresini belirleyin. Sonsuz saklanan loglar bütçeyi şişirir.

OpenTelemetry entegrasyonu ile dağıtık sistemlerde izleme daha kolay hale gelir.

Log sampling (örnekleme) yüksek trafikli sistemlerde ciddi maliyet düşürür.

Correlation ID kullanmak, mikroservislerde tek bir isteğin tüm akışını takip etmeyi kolaylaştırır.

 

Hangi araçlar tercih edilebilir?

2025’te en yaygın kullanılan loglama ve izleme araçları:

• ELK Stack (Elasticsearch – Logstash – Kibana)
• Grafana Loki
• Serilog / NLog (.NET için)
• Splunk
• Datadog Logging
• OpenTelemetry Collector

Bu araçlar yapılandırılmış loglarla çok daha verimli çalışır.

 

Log kültürü oluşturmak

Doğru loglama sadece teknik bir gereklilik değildir; ekip içinde bir kültürdür. Bu kültürün temel adımları:

• Ne zaman log yazılır?
• Ne yazılır, ne yazılmaz?
• Log seviyeleri nasıl kullanılır?
• Hangi bilgilerin loglanması yasaktır?

Bu sorulara net cevaplar olan ekiplerde debug süreci hızlı, sistem davranışı öngörülebilir ve bakım maliyeti düşük olur.