Loglarımda WARN ile ERROR seviyelerini ne zaman kullanacağıma dair net bir kural nasıl belirlerim?

Kısa cevap: Seviyeyi “log satırının içeriği” değil, “birinin harekete geçmesi gerekiyor mu” sorusu belirlemeli. ERROR = kırdığınız bir söz; WARN = sistemin kendi kendine toparladığı beklenmedik bir durum.

1. Eksen aksiyon alınabilirliktir. ERROR, bir isteğin veya job’ın sizin hatanızla başarısız olduğu ve birinin bakması gereken durumdur. WARN ise beklenmedik ama sistemin tolere ettiği bir şeydir: retry tuttu, fallback devreye girdi, soft limit’e yaklaşıldı. “Bu satır gece 3’te fire olsa birini uyandırır mıyım?” sorusuna evet diyorsanız ERROR’dır.

2. Beklenen hatayı bug’dan ayırın. 404, validation hatası, kullanıcının yanlış girdisi — bunlar sizin kodunuzun kırılması değil, INFO ya da en fazla WARN’dır. Kaba kural: 4xx client’ın sorunudur, 5xx sizindir. ERROR’ı yalnızca kendi kodunuz verdiği sözü tutamadığında kullanın.

3. Retry ve fallback’i doğru sınıflayın. Tekrar denenecek tek bir başarısız deneme WARN’dır; geçici bir titreme aksiyon gerektirmez. Ama tüm retry’lar tükendiğinde veya mesaj dead-letter’a düştüğünde artık ERROR’dır — çünkü iş kalıcı olarak yarım kaldı.

4. Alert’i yalnızca ERROR’a bağlayın, onu da oranla. Uyarılarınız ERROR (ve fatal) üzerinden tetiklensin; tek satıra değil eşik/oran üzerinden (“5 dakikada 50 ERROR”). WARN dashboard’u besler, pager’ı değil.

5. Aynı hatayı beş kez loglamayın. Go’da her katmanda hem error return edip hem loglarsanız aynı başarısızlık beş satır olur. Kararın verildiği sınırda (handler) bir kez loglayın; alt katmanlar sadece error’ı wrap edip döndürsün. Laravel’de aynısı için Log::error’ı her yere serpmek yerine exception handler’daki report() seviyesini kullanın.

6. ERROR ile FATAL/critical’ı da ayırın ve her ERROR’ı aksiyon alınabilir yapın. FATAL, sürecin devam edemediği durumdur (config eksik, boot başarısız); ERROR ise bir isteğin/job’ın başarısızlığıdır, süreç ayaktadır. Ayrıca her ERROR satırı, birinin gecenin bir yarısı bakacağını varsayarak yeterli context taşımalı: request/trace id, ilgili kimlikler ve wrap’lenmiş hata zinciri. Aksiyon alınamayan bir ERROR zaten ERROR değildir.

Küçük bir örnek — seviyeyi satırın kaynağı değil sonucu belirlesin:

if err := publish(ctx, msg); err != nil {
    if attempt < maxRetries {
        log.Warn("publish failed, will retry", "attempt", attempt, "err", err)
        return retry
    }
    // retry'lar tükendi: artık gerçekten aksiyon gerekiyor
    log.Error("publish failed permanently, sent to DLQ", "err", err)
}

Sonuç: Ben olsam ekibe tek cümlelik bir kural verirdim: “Bu log gece 3’te fire olduğunda birinin uyanması gerekiyorsa ERROR, gerekmiyorsa WARN.” Buna ek olarak hatayı yalnızca sınırında bir kez loglama disiplinini koyar, alert’leri ERROR oranına bağlardım. Bu iki değişiklik gürültünün çoğunu tek başına eritir; kalanını da birkaç hafta boyunca yanlış seviyedeki logları düzelterek temizlersiniz. Amaç sıfır ERROR değil; her ERROR’ın gerçekten bir anlam taşıması.