# 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://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.

## Kısa cevap

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ı. Log hattının kendi dayanıklılığını, yani üretimi tüketimden ayıran ara katmanı [log hattına buffer koyma kaydında](/tr/sor-bakalim/loglari-opensearch-e-gonderirken-araya-kafka-buffer-koymali-miyim/) ele almıştım.

## Neden

1. **Sınırsız loglama bir özellik değil, bir bug'dır.** Hiçbir hata, üretim hızıyla orantısız bir çıktı üretmemeli.

2. **Backoff'suz retry, log üretimini de katlar.** Her başarısız denemede anında yeniden denemek hem hedefe yüklenir hem satır sayısını çarpar.

3. **Log ile işletim sistemi aynı diski paylaşmamalı.** Log diski dolduğunda makinenin de düşmesi, bir yerleşim kararının sonucudur.

## Ne yapmalı

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.

2. **Retry'a backoff koyun ki hata oranı kendisi düşsün.** Exponential backoff + jitter uygulayın; bu hem hedefe yüklenmeyi azaltır hem 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`); 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. 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.** Disk spool'una tavan koyun ve disk kullanımı %100'e gelmeden çok önce (%70-80'de) alarm alı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://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://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://muhammetsafak.com/tr/sor-bakalim/felaket-kurtarma-rto-rpo-ve-aktif-pasif-senaryo/) — Sor Bakalım