Log storm ve disk dolma krizini nasıl önlerim?

Kısa cevap: Burada iki ayrı arıza var — uygulamada throttling yok, sunucuda sınır/rotasyon yok. Tek katmanı düzeltmek yetmez; ikisini birden kapatman lazım.

Asıl problem şu: tek bir kopuk bağımlılık saniyede 10.000 satır üretti, disk doldu ve işletim sistemi nefes alamayınca makine düştü. Yani seni öldüren şey hata değil, hatanın sınırsız loglanması.

1. Uygulamada tekrarlı logu throttle/sample et. Aynı hatayı 10.000 kez yazma; “Connection refused (60 saniyede ×10.000)” diye sayaçla tek satır yaz. Logu hata imzasına göre dedup’la; aynı imza tekrar gelirse satır üretme, sayacı artır.
2. Retry’a backoff koy ki hata oranı kendisi düşsün. Bağlantı her başarısız olduğunda anında yeniden deneme yapma; exponential backoff + jitter uygula. Bu hem hedefe yüklenmeyi azaltır hem de log üretim hızını doğal olarak kırar.
3. Sunucuda logrotate ile sert sınır koy. logrotate’i boyut ve dosya sayısı sınırıyla yapılandır (örn. size 100M, rotate 5). Log dosyası belli boyutu geçince döndür, eskiyi sil; toplam log alanının bir tavanı olsun.
4. Logu kök/işletim sistemi diskine yazma. /var/log’a ayrı bir volume ver. Böylece log diski dolsa bile işletim sistemi kök diskte çalışmaya devam eder ve makine düşmez. Bu tek başına senin yaşadığın çökmeyi engellerdi.
5. Filebeat’i sınırlı yerel spool ile çalıştır, erken alarm kur. Filebeat’in disk spool’una bir tavan koy; ve disk kullanımı %100’e gelmeden çok önce (%70-80’de) alarm al. Krizi %100’de değil, daha tepedeyken yakala.

Sonuç: Ben olsam uygulama tarafı throttling + ayrı log volume + rotasyonu birlikte kurardım. En önemlisi şu zihniyet değişikliği: sınırsız loglamayı bir özellik değil, bir bug olarak gör. Bu tip olayların disiplinli bir post-mortem ile nasıl işleneceğini sade.dev’de anlatıyorum.