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

> Tekrarlı logu uygulamada sayaçla tek satıra indirin, retry'a backoff koyun, logrotate'e boyut ve sayı sınırı verin, `/var/log`'u kök diskten ayırın.

- Soruldu: 2026-05-30
- Yanıtlandı: 2026-06-02
- Soran: Serkan
- Etiketler: dayaniklilik, observability, altyapi
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/log-storm-ve-disk-dolma-krizini-onlemek/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Üretimdeki bir mikroservis, harici bağlantı koptuğu için saniyede 10.000 "Connection Refused" hata logu üretmeye başladı. Loglar yerel diske yazılıp Filebeat ile Logstash'e aktarılıyor.

10 dakikada disk %100 doldu ve işletim sistemi temel işlevlerini yapamayınca sunucu düştü. Sunucu seviyesinde logrotate ve uygulama seviyesinde log throttling'i bu tekrarlanmasın diye nasıl yapılandırırım?


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.

## İlgili Yazılar

- [Hata oranı artınca otomatik rollback yapan (self-healing) deploy altyapısını nasıl tasarlarım?](https://www.muhammetsafak.com.tr/sor-bakalim/hata-artisinda-otomatik-rollback-ve-kendi-kendini-iyilestiren-deploy/) — Sor Bakalım
- [Health check tasarımı: Liveness ve Readiness ayrımını nasıl yaparım?](https://www.muhammetsafak.com.tr/sor-bakalim/health-check-tasarimi-liveness-ve-readiness-ayrimi/) — Sor Bakalım
- [Felaket kurtarma: RTO ve RPO'ya göre aktif-pasif senaryoyu nasıl kurgularım?](https://www.muhammetsafak.com.tr/sor-bakalim/felaket-kurtarma-rto-rpo-ve-aktif-pasif-senaryo/) — Sor Bakalım