Üretimde Log’a Ne Yazmalı, Ne Yazmamalı?

Üretimde log yazma konusundaki iki uç da aynı sonuca çıkar: kullanışsız log'lar. Bir uçta neredeyse hiçbir şey yazmayan sistemler vardır; bir sorun çıktığında elinizde yalnızca "bir şeyler ters gitti" satırı kalır. Diğer uçta her şeyi yazan sistemler vardır; saniyede binlerce satır üretilir, olay anında aradığınızı bulmak imkânsızlaşır ve saklama maliyeti şişer. İşe yarayan log, hacimle değil, sorulacak soruyu önceden tahmin etmekle kurulur.

Doğru soru: gece 03:00'te ne bilmek isterdiniz?

Log yazarken kendinize sormanız gereken soru, "bu bilgi ilginç mi?" değil, "bir olay sırasında bu satır bana ne söyler?" olmalıdır. Bu bakış açısı, hangi bilginin gerçekten gerekli olduğunu hızla ayıklar.

Pratikte olay anında sorulan sorular hep aynıdır: Hangi istek başarısız oldu? Hangi kullanıcıyı etkiledi? Hangi dış servis yanıt vermedi? İşlem nerede yarıda kaldı? Log'larınız bu dört soruyu cevaplayabiliyorsa yeterlidir; cevaplayamıyorsa hacim ne olursa olsun eksiktir.

Yapılandırılmış log: aranabilir olmak

Serbest metin log satırları insan için okunabilir ama makine için işe yaramaz. "Kullanıcı 4718 için ödeme başarısız oldu" satırında kullanıcı kimliğine göre filtreleme yapmak, düzenli ifadelerle uğraşmayı gerektirir. Aynı bilgi yapılandırılmış (genellikle JSON) yazıldığında doğrudan sorgulanabilir hâle gelir:

log_message('error', json_encode([
    'olay'        => 'odeme_basarisiz',
    'kullanici_id'=> 4718,
    'siparis_id'  => 90233,
    'saglayici'   => 'iyzico',
    'hata_kodu'   => 'INSUFFICIENT_FUNDS',
    'istek_id'    => $istekId,
], JSON_UNESCAPED_UNICODE));

Bu biçimde "son bir saatte INSUFFICIENT_FUNDS hatası alan kaç farklı kullanıcı var?" sorusu tek bir sorguya iner.

Korelasyon kimliği: dağınık satırları birleştirmek

Tek bir kullanıcı isteği, uygulamanın farklı katmanlarında onlarca log satırı üretir. Bunları birbirine bağlayan bir kimlik yoksa, olay incelemesi tahmin yürütmeye dönüşür. Çözüm basittir: her istek başında bir kimlik üretin, isteğin ömrü boyunca her log satırına ekleyin ve mümkünse yanıt başlığında kullanıcıya da döndürün. Böylece bir kullanıcı hata bildirdiğinde, o tek kimlikle bütün zinciri görebilirsiniz.

Log seviyeleri: gerçekte ne anlama gelmeli?

Seviyeler tutarlı kullanılmadığında anlamsızlaşır. İşleyen bir ayrım şudur:

• ERROR: Bir kullanıcı isteği başarısız oldu ve müdahale gerekebilir. Her ERROR satırı, birinin bakması gereken bir şey olmalıdır — aksi hâlde ekip bu seviyeyi görmezden gelmeye başlar.
• WARNING: Beklenmedik ama sistemin kendi başa çıktığı durumlar: yeniden denemeyle düzelen bir bağlantı, kullanılmayan eski bir uca gelen istek.
• INFO: İş açısından anlamlı olaylar: sipariş oluşturuldu, kullanıcı kaydoldu, toplu iş tamamlandı. Bunlar "sistem normal çalışıyor" resmini verir.
• DEBUG: Yalnızca geliştirme için. Üretimde sürekli açık bırakılması, hem maliyet hem gürültü üretir.

En sık yapılan hata, gerçekten hata olmayan durumları ERROR yazmaktır. Kullanıcının yanlış parola girmesi bir hata değil, beklenen bir akıştır; ERROR olarak yazıldığında panolar sürekli kırmızı görünür ve gerçek hatalar kaybolur.

Asla loglanmaması gerekenler

Bu bölüm, sonradan düzeltmesi en pahalı olanıdır — çünkü log'lar yedeklenir, kopyalanır ve uzun süre saklanır:

• Parolalar — özet (hash) hâlleri dahil.
• Oturum jetonları, API anahtarları ve yenileme jetonları. Log'a düşen bir jeton, sızmış bir jetondur.
• Kart numaraları ve güvenlik kodları.
• Kimlik numarası, tam adres, sağlık verisi gibi kişisel veriler. Kişisel veri işleme yükümlülükleri log'lar için de geçerlidir.
• Tam istek gövdeleri. Kolaylık olsun diye yazılır, ancak yukarıdaki tüm maddeleri fark edilmeden içerir.

Kimliği tamamen çıkarmak yerine maskeleme kullanmak pratik bir orta yoldur: kart numarasının yalnızca son dört hanesi, e-postanın yalnızca alan adı. Ayrıca hassas alanları otomatik temizleyen bir katman yazmak, tek tek geliştiricilerin dikkatine güvenmekten çok daha dayanıklıdır.

Hacmi kontrol altında tutmak

Log maliyeti sessizce büyür; hem depolama hem de aranabilir tutma tarafında. Üç önlem çoğu durumda yeterlidir: yüksek hacimli tekrar eden olayları örneklemek (her isteği değil, yüzde birini yazmak), saklama süresini kademelendirmek (yakın dönem sıcak, eskisi arşiv) ve DEBUG seviyesini üretimde kapalı tutmak. Bu kalemin bulut faturasındaki yeri için bulut maliyetleri yazımıza, dosya sistemini doldurma riski için disk dolma müdahalesi yazımıza bakabilirsiniz.

Zaman damgası tuzağı

Son ve çok sık karşılaşılan bir ayrıntı: log'ların zaman damgaları farklı zaman dilimlerinde yazıldığında, olay incelemesi tamamen yanlış sonuçlar üretebilir. Uygulama, veritabanı ve altyapı bileşenlerinin hepsinin UTC yazması ve görüntüleme aşamasında yerel saate çevrilmesi en güvenli yaklaşımdır. Bu tuzağın ayrıntıları için zaman dilimi tuzağı yazımıza bakın. Genel güvenlik çerçevesi için ise OWASP Top Ten başvurulabilir.

Sonuç

İyi log, çok log değildir. Değerli olan; yapılandırılmış, korelasyon kimliğiyle bağlanmış, seviyeleri tutarlı kullanılmış ve hassas veri içermeyen kayıtlardır. Bu dört özelliği sağlayan bir sistemde olay incelemesi dakikalar sürer; sağlamayan bir sistemde ise elinizde ne kadar veri olursa olsun saatler alır. Bugün küçük bir sınama yapın: son bir haftadaki ERROR satırlarınızı açın ve her birinin gerçekten müdahale gerektiren bir durum olup olmadığına bakın. Çoğu değilse, log seviyelerinizi gözden geçirme zamanı gelmiş demektir.