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ız 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 sizi öldüren şey hata değil, hatanın sınırsız loglanması.

1. Uygulamada tekrarlı logu throttle/sample edin. Aynı hatayı 10.000 kez yazmayın; “Connection refused (60 saniyede ×10.000)” diye sayaçla tek satır yazın. Logu hata imzasına göre dedup’layın; aynı imza tekrar gelirse satır üretmeyin, sayacı artırın.
2. Retry’a backoff koyun ki hata oranı kendisi düşsün. Bağlantı her başarısız olduğunda anında yeniden deneme yapmayın; exponential backoff + jitter uygulayın. 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 koyun. logrotate’i boyut ve dosya sayısı sınırıyla yapılandırın (örn. size 100M, rotate 5). Log dosyası belli boyutu geçince döndürün, eskiyi silin; toplam log alanının bir tavanı olsun.
4. Logu kök/işletim sistemi diskine yazmayın. /var/log’a ayrı bir volume verin. Böylece log diski dolsa bile işletim sistemi kök diskte çalışmaya devam eder ve makine düşmez. Bu tek başına sizin yaşadığınız çökmeyi engellerdi.
5. Filebeat’i sınırlı yerel spool ile çalıştırın, erken alarm kurun. Filebeat’in disk spool’una bir tavan koyun ve disk kullanımı %100’e gelmeden çok önce (%70-80’de) alarm alın. Krizi %100’de değil, daha tepedeyken yakalayın.

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ün. Bu tip olayların disiplinli bir post-mortem ile nasıl işleneceğini sade.dev’de anlatıyorum.