Birden fazla kez karşılaştım: hatalı davranan bir hizmet journal'i doldurmak yerine spam yapmaya başlar ve aniden /var/log/journal dakikalar içinde gigabayt seviyesine ulaşır. Kontrol edilmezse, bu kök dosya sistemini doldurabilir ve hizmetleri durdurabilir. Ortamımda, günlük hacimlerini tahmin edilebilir tutmak için systemd-journald'ın yerleşik hız sınırlama mekanizmasını kullanıyorum. Bu, logları susturmamakla ilgili değil — kendi günlük alt sisteminizin hizmet reddi yapmasını önlemekle ilgilidir.
journald Hız Sınırlamasını Anlama
systemd-journald, aşırı günlük girdilerini sınırlamak için iki temel yönerge içerir: RateLimitInterval ve RateLimitBurst. Bu iki ayar birlikte, belirli bir zaman penceresinde kaç mesajın izin verileceğini tanımlar; bu sınır aşılırsa daha fazla mesaj atılır (kaydedilmez, ancak sayılır). Bu, günlük kaydının diski tüketmesini önlerken, hızı sınırlandırmanın gerçekleştiği konusunda hâlâ farkındalık sağlar.
Varsayılan olarak, journald 30 saniyede en fazla 1000 mesaja izin verir. Bir hizmet bu limiti aşarsa, fazladan mesajlar aralık sıfırlanana kadar görmezden gelinir. Bu durum gerçekleştiğinde, “journal has been rotated due to exceeding rate limit” gibi bir bildirim görürsünüz — bu, bir şeylerin davranışının bozuk olduğu bir sinyalidir.
RateLimitInterval ve Burst Ayarlarını Yapılandırma
Bu ayarları /etc/systemd/journald.conf dosyasında veya /etc/systemd/journald.conf.d/ altında bir drop-in dosyasıyla yaparsınız. Drop-in dosyalarını tercih ederim çünkü yükseltmeler özel değerleri üzerine yazmaz.
Örnek: 60 saniyede 200 mesajla sınırlama:
# /etc/systemd/journald.conf.d/rate-limit.conf
[Journal]
RateLimitInterval=60s
RateLimitBurst=200Değişiklik yaptıktan sonra systemd-journald'ı yeniden yükleyin:
sudo systemctl restart systemd-journaldArdından ayarların aktif olduğunu doğrulayın:
sudo systemctl show systemd-journald --property=RateLimitInterval --property=RateLimitBurstÇıktı yeni değerlerinizi göstermelidir:
RateLimitInterval=60
RateLimitBurst=200Sınırları Ne Zaman Daraltmak veya Hafifletmek Gerektiği
Üretim sistemlerinde — özellikle /var alanı sınırlı olan konteynerler veya VM'lerde — konservatif bir şekilde başlarım. Gürültü oluştururken çalışan uygulamalar (hata ayıklama ağırlıklı Java uygulamaları veya yanlış yapılandırılmış cron işleri gibi) için önce kaynağı araştırırım. Ancak uygulamayı hemen düzeltebilmiyorsam, hız sınırlaması zaman kazandırır.
Hız sınırlamasını ayarlamak kullanışlı olan senaryolar:
- Küçük /var bölümlere sahip sistemler (bulut örneklerinde yaygın)
- Logların uzun süre saklanmadığı geçici konaklar
- stdout/stderr'ye log yazan yüksek frekanslı cron işleri
- Tekrarlayan sağlık kontrolü logları üreten Containerd veya Docker daemon'ları
Tersine, hata ayıklama sunucularında veya geçici sorunları araştırırken, hız sınırlamasını geçici olarak devre dışı bırakabilirim:
RateLimitInterval=0Interval'i 0 olarak ayarlamak daraltmayı devre dışı bırakır — ancak sadece kısa süreli ve izleme yapılarak yapılmalıdır.
Rate Limiting Olaylarını İzleme
Journalde düşürülen günlükleri görmezsiniz, ancak journald kendi aktivitesini kaydeder. Rate limit isabetlerini şu komutla kontrol edin:
sudo journalctl -u systemd-journald | grep -i "rate limit"Aşağıdaki gibi satırlara bakın:
systemd-journald[123]: Journal started
systemd-journald[456]: Suppressed 1245 messages from /system.slice/myapp.serviceBu "Suppressed" sayısı, mevcut önyüklemede düşürülen mesaj sayısını gösterir. Bu sayı sürekli artıyorsa, rate limitiniz çok sıkı olabilir veya temel sorun giderilmesi gerekebilir.
Bu kontrolü disk kullanımı kontrolleriyle birleştirin:
sudo journalctl --disk-usageRate limiting uygulanıyor olsa da kullanım artıyorsa, journald.conf dosyasında Storage= veya SystemMaxUse= ayarlarını ayarlayarak toplam journal boyutunu sınırlamayı düşünün.
Diğer Korumalarla Birleştirme
Rate limiting, doğru log rotasyonu veya uzakta gönderme için bir alternatif değildir — ancak kritik ilk savunma hattıdır. Benim kurulumumda, bunu şunlarla birleştiriyorum:
- Critical logları ForwardToSyslog=yes sayesinde merkezi bir syslog sunucusuna iletme
- Journal boyutunu sınırlamak için SystemMaxUse=50M ayarlama
- Daha önce bahsettiğim gibi, systemd slice’leri kullanarak log yoğunluğunda olan hizmetlerin G/Ç’ni izolasyonu
Daha önce systemd slice rehberiminde de belirttiğim gibi, log baskısını izole etmek, bir gürültülü hizmetin diğer hizmetlerin disk bant genişliğinden mahrum kalmasını önler.
Son Düşünceler
Journald’nin diski doldurmasını önlemek için karmaşık araçlara ihtiyacın yok. RateLimitInterval ve RateLimitBurst, systemd içinde yerleşik olan basit ve etkili iki ayardır. Bu değerleri, servisinizin normal günlük hacmine göre ayarla, baskılama olaylarını izle ve bunları boyut sınırlarıyla birleştir.
Bu, 3 sabah pagera sebep olabilecek bir durumu önleyen küçük bir yapılandırma ayarıdır — çünkü istediğin son şey, /var/log/journal kök bölümü ele geçirerek izleme sisteminin başarısız olmasıdır.
Kapak görseli: Anita Peeples · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/guy-man-DO1KKRFQMB