Düz metin loglar ("Sipariş oluşturuldu: 12345" gibi) küçük projelerde yeterli görünse de, prod ortamında binlerce log satırı arasından bir sorunu bulmaya çalışırken yetersiz kalıyor. Serilog ile yapılandırılmış (structured) loglamaya geçtiğimden beri, sorun tespiti çok daha hızlı.
Düz Metin Yerine Yapılandırılmış Alanlar
Log.Information("Siparis olusturuldu {OrderId} musteri {CustomerId}", orderId, customerId);Bu şekilde loglanan bir kayıt, sadece okunabilir bir metin değil, OrderId ve CustomerId gibi sorgulanabilir alanlara sahip bir veri noktası haline geliyor. Bu, log yönetim aracında (Seq, Elasticsearch gibi) "bu müşterinin tüm işlemlerini göster" gibi sorgular yazabilmemi sağlıyor.
Correlation ID ile İstek Takibi
Bir isteğin farklı servislerden/katmanlardan geçerken bıraktığı logları birbirine bağlamak için her isteğe bir correlation ID atıyorum ve bunu tüm loglara ekliyorum. Bu, dağıtık bir sistemde bir hatanın hangi isteğe ait olduğunu net şekilde takip etmemi sağlıyor.
Log Seviyelerini Doğru Kullanmak
Her şeyi Information seviyesinde loglamak, gerçekten önemli olayların gürültü içinde kaybolmasına sebep oluyor. Debug'ı geliştirme detayları için, Warning'i beklenmedik ama kritik olmayan durumlar için, Error'ı gerçek hatalar için ayırarak, prod ortamında hangi seviyeleri izleyeceğimi netleştiriyorum.
Hassas Veriyi Loglamamak
Şifre, kredi kartı numarası gibi hassas verilerin yanlışlıkla loglara sızmasını engellemek için, log çıktısına giden nesneleri dikkatli seçiyorum; bir DTO'yu doğrudan loglamak yerine, sadece güvenli alanları içeren özel bir log nesnesi oluşturuyorum.
Sonuç
İyi kurulmuş bir loglama stratejisi, prod ortamında "neden bu hata oluştu" sorusuna dakikalar içinde cevap verebilmemi sağlıyor. Bu yatırımın değeri, gerçek bir üretim sorunu yaşandığında ortaya çıkıyor.