Log storm ve disk dolma krizini nasıl önlerim?
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?
Cevap
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 ele almıştım.
Neden
-
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.
-
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.
-
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ı
-
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.
-
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.
-
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. -
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. -
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.
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.