Üretimde loglama: hangi log işe yarar, hangisi sadece disk yer

Bir üretim hatasını araştırırken log dosyalarına bakıp hiçbir şey bulamamak, çoğu ekibin tanıdık deneyimi. Loglar var, hem de çok — ama işe yarayanı yok.

Faydalı log ile gürültü arasındaki fark, üç kuralda toplanıyor.

Kural 1: Log, bir olayı kaydeder; bir adımı değil

Şu satırlar gürültüdür:

İşleme başlanıyor
Kullanıcı doğrulanıyor
Veritabanına bağlanılıyor
Sorgu çalıştırılıyor
Sonuç dönüldü

Beş satır, sıfır bilgi. Her şey yolunda gittiğinde okunmuyor; yolunda gitmediğinde hangisinin nerede kaldığını söylemiyor.

Bunun yerine tek bir satır, sonuçla birlikte:

siparis_olusturuldu siparis_id=8842 kullanici_id=331 tutar=1250.00 sure_ms=87

Kural şu: log satırı, sonradan bir soruyu cevaplamalı. Cevaplayacağı soruyu yazarken bilmiyorsanız, o satır muhtemelen gereksiz.

Kural 2: Yapılandırılmış log, metin logundan üstündür

Serbest metin log, insan okuması için iyidir ama filtrelenemez. Anahtar-değer ya da JSON biçimindeki log, sorgulanabilir.

// zayıf
logger.info(`Kullanıcı ${id} siparişi ${siparisId} iptal etti`);

// güçlü
logger.info("siparis_iptal", { kullanici_id: id, siparis_id: siparisId, sebep: sebep });

İkincisinde "son 24 saatte hangi sebeple kaç iptal oldu" sorusunu bir sorguyla cevaplayabilirsiniz. Birincisinde düzenli ifade yazmanız gerekir ve mesaj metni değiştiği gün sorgunuz bozulur.

Kural 3: Her isteğin bir kimliği olmalı

Bu, tek başına diğer her şeyden daha fazla işe yarıyor. Uygulamaya giren her istek için bir kimlik üretin (istek_id), o istek boyunca ürettiğiniz her log satırına ekleyin, ve mümkünse istemciye de yanıt başlığında geri gönderin.

Faydası: müşteri "sipariş veremiyorum" dediğinde, ondan aldığınız tek bir kimlikle o isteğin bütün yolculuğunu görebiliyorsunuz. Bu olmadan, zaman damgasına göre tahmin yürütüyorsunuz.

Modern çalışma zamanlarında bu, isteğe bağlı bir bağlam nesnesiyle (Node.js'te AsyncLocalStorage, diğer dillerde eşdeğerleri) her çağrıya elle parametre geçirmeden yapılabiliyor.

Seviyeler: dördü yeter

• error — Müdahale gerektiren, bir kullanıcının işi yarım kalmış durum. Uyarı üretmeli.
• warn — Beklenmedik ama sistemin kendi başına toparladığı durum. Sıklığı izlenmeli.
• info — İş olayları: sipariş oluştu, ödeme alındı, kullanıcı kaydoldu. Az sayıda ve anlamlı.
• debug — Geliştirme sırasında; üretimde kapalı, gerektiğinde açılabilir.

Beşinci bir seviye eklemek isteği geldiğinde, aslında ihtiyacınız olan şey genelde bir metrik oluyor.

Log değil, metrik olması gerekenler

Sayılabilir şeyleri loglamayın, sayın. "Kaç kez oldu", "ne kadar sürdü", "kuyrukta kaç iş var" gibi sorular log ile değil metrik ile cevaplanır. Log kullanmak, bu soruları pahalı ve yavaş hâle getiriyor.

Kaba ayrım:

Soru	Araç
Ne oldu?	Log
Ne kadar sık / ne kadar sürüyor?	Metrik
Bu istek nereden nereye gitti?	İzleme (trace)

Loglanmaması gerekenler

Bu liste kısa ama pahalı:

• Parola, oturum anahtarı (token), API anahtarı — hiçbir seviyede
• Kart numarası, kimlik numarası, tam adres
• Tüm istek gövdesi (içinde yukarıdakiler olabilir)
• Tam yanıt gövdesi (disk yer, faydası az)

Pratik önlem: log kütüphanesine bir alan maskeleme kuralı tanımlayın (sifre, token, authorization gibi anahtarlar otomatik ***). Bunu "dikkat edelim" ile yürütmek mümkün değil; bir gün biri istek gövdesini loglar.

Saklama ve maliyet

Log maliyeti hacimle doğrusal artıyor. Makul bir varsayılan:

• error/warn: uzun süre sakla (aylar)
• info: birkaç hafta
• debug: birkaç gün, ya da yalnızca gerektiğinde aç

Ve bir kuralı baştan koyun: bir log satırı ekleyen her değişiklikte "bu satırı üç ay sonra kim, hangi soruyla arayacak?" sorusu sorulsun. Cevabı olmayan satır eklenmesin.

Son test

Loglama sisteminizin iyi olup olmadığını anlamanın tek gerçek yolu var: bir sonraki üretim hatasında, sorunun kaynağını yalnızca loglara bakarak bulabildiniz mi?

Bulamadıysanız, o olaydan çıkarılacak asıl ders hatanın kendisi değil; eksik olan log satırıdır. Onu hemen ekleyin — bir dahaki sefere aynı yerde durmayasınız.