Bu bölümü çok kez gördüm: davranışı bozuk bir hizmet günlüğüyle spam yapmaya başlar ve aniden kök bölümü %100 dolar. Hizmetler çöker, izleme uyarıları akar gibi gelir ve kullanıcılar fark etmeden önce boş alanı açmak için çaba gösterirsiniz. İyi haber şu: systemd-journald, bu senaryonun tam olarak önlenmesi için yerleşik hız sınırlama özelliğine sahiptir. Bir hizmetin zaman içinde ne kadar günlük kaydı yapabileceğini yapılandırarak, gerçek sorunlardan haberdar kalmadan disk alanını koruyabilirsiniz.
Rate Limiting'in journald'te Önemi Nedir?
Journald, tüm hizmetlerden günlükleri toplar ve ikili formatta /var/log/journal/ altında saklar. Varsayılan olarak, disk kullanım sınırına ulaşana kadar (genellikle bölümün %10'u veya 4GB, hangisi daha küçükse o) yazmaya devam eder. Tek bir hatalı hizmet—örneğin bir cron job'daki sıkı döngü veya yanlış yapılandırılmış bir uygulama—bu tahsisi dakikalar içinde tüketebilir. Bir kez, bir DNS çözümleyici, yoğun bir özyinelemeli sunucuda debug seviyesinde her sorguyu kaydetti ve bir saat içinde 20GB doldurdu. Sistem hemen çökmedi, ancak günlük döndürmesi durdu, yedeklemeler başarısız oldu ve gürültüde kaybolan gerçek bir güvenlik uyarısını kaçırmak üzere kaldım.
Rate limiting, sorunları gizlemekle ilgili değildir; günlükleme mekanizmasının kendisinin bir hizmet reddi (DoS) vektörü haline gelmesini önlemekle ilgilidir. Hala sorunu teşhis etmek için ilk N mesajı alırsınız, ancak bundan sonra journald, fazladan girişleri düşürmeye başlar ve atlananları periyodik olarak özetler.
Hizmet Başına Oran Sınırlarını Yapılandırma
Temel ayarlar /etc/systemd/journald.conf dosyasında veya /etc/systemd/journald.conf.d/ klasöründeki drop-in dosyalarında bulunur. Ana dosyayı düzenlemenize gerek yok; satıcı varsayılanlarını ezmekten kaçınmak için özel bir drop-in oluşturmayı tercih ederim.
İlk olarak mevcut ayarları kontrol edin:
systemd-analyze cat-config systemd/journald.confRateLimitInterval ve RateLimitBurst ayarlarını arayın. Bunlar, oran sınırlamasının devreye girmesinden önceki pencereyi (saniye cinsinden) ve bu pencerede izin verilen maksimum mesaj sayısını tanımlar.
Küresel olarak katı sınırlar uygulamak için bir drop-in oluşturun:
mkdir -p /etc/systemd/journald.conf.dArdından /etc/systemd/journald.conf.d/rate-limit.conf dosyasını şu içeriğiyle oluşturun:
[Journal]
RateLimitInterval=30s
RateLimitBurst=1000Bu, tek bir kaynaktan her 30 saniyede en fazla 1000 günlük girdisinin olabileceği anlamına gelir. Bir hizmet bu sınırı aşarsa, journald daha fazla mesajı bastırır ve aralık sıfırlandığında bir satır şu şekilde çıkar:
Message suppressed, or lost due to rate limitingBu satırı journal'i sorguladığınızda göreceksiniz, böylece kör uçuş yapmazsınız.
Yüksek Hacimli Ama Meşru Hizmetler İçin Ayarlama
Bazı hizmetler doğal olarak yüksek günlük hacmi üretir—örnek olarak proxy'ler, DNS çözümleyicileri veya toplu işlemciler düşünülebilir. Küresel 1000/30s sınırını bu hizmetlerde uygulamak, faydalı verileri gizleyebilir. Bunun yerine, journalctl filtrelerini _SYSTEMD_UNIT ile kullanarak drop-in'ler üzerinden birim bazlı geçersiz kılmalar ayarlayabilirsiniz, ancak journald, yapılandırmasında birim bazlı hız sınırlamasını doğrudan desteklemez.
Benim yaptığım şey, mümkün olduğunca hizmet seviyesinde günlük ayrıntı seviyesini ayarlamaktır. Örneğin, nginx çok konuşuyorsa, access_log veya error_log seviyesini düşürürüm. Eğer bu yeterli olmazsa, küresel hız sınırlamasını bir güvenlik ağı olarak kullanmaya devam ederim ve bilinmeyen yoğun birimler için patlama (burst) değerini hafifçe artırırım—örneğin, bir önbellek proxy için 5000/30s—kullanırken küresel varsayılanı daha düşük tutarım.
journald.conf dosyasını değiştirdikten sonra, servisi yeniden başlatın:
systemctl restart systemd-journaldEtkin olduğunu doğrulayın:
systemctl status systemd-journaldSonra bir ekran veya tmux oturumunda logger komutu ile spam testi yapın:
for i in {1..2000}; do logger -t ratelimit-test "This is test message $i"; doneTest sonrası günlüğü kontrol edin:
journalctl -t ratelimit-test | tail -5İlk patlama mesajlarını görmeniz gerekiyor, ardından bastırma (suppression) bildirimleri görünmelidir.
Rate Limit Olaylarını İzleme
Rate limiting'i sadece bir şey bozulduğunda keşfetmek istemezsiniz. İzleme sistemime basit bir kontrol ekliyorum:
journalctl _TRANSPORT=journal | grep -c "suppressed" || echo 0Bu sayaç artmaya başlarsa, bir şeyin sınırlara takıldığı anlamına gelir. Sorumlu olan birimi bulmak için birim bazlı bir ayrıntıya ekleyebilirsiniz:
journalctl | grep "suppressed" | awk -F'[' '{print $2}' | awk -F']' '{print $1}' | sort | uniq -c | sort -nr | head -5Bu komut, en çok suppressed mesajı üreten birimleri gösterir. Buradan sonra, hizmeti düzeltmeyi, günlük kaydını ayarlamayı veya hacmi legitimi ancak ani artış gösteriyorsa rate limitini ayarlamayı düşünebilirsiniz.
Güvenlik ve Görünürlük Dengesi
Rate limiting, son savunma hattıdır, doğru günlük hijyeni yerine geçmez. Hala şunları öneriyorum:
- Servislerde uygun günlük seviyeleri ayarlamak (üretimde debug kullanmamak)
- Geleneksel günlükler için uygun olduğunda logrotate kullanmak
- Günlükleri uzak bir syslog veya Loki/Graylog gibi merkezi sistemlere yönlendirerek tutmak
Ama bir güvenlik ağı olarak, journald’in rate limiting özelliği birden fazla kez bana yardımcı oldu. Hafif, ek agent gerektirmez ve sistem I/O baskısı nedeniyle diğer yollar çalışmazsa bile çalışır.
Linux sunucularınızı çalıştırıyorsanız—özellikle genel trafik veya otomatik iş akışları işliyorsanız—journald yapılandırmanızı kontrol etmek için on dakika ayırın. Makul bir burst ve interval ayarlayın, baskılama olaylarını izleyin ve çekirdeğin throttling işini yapmasını sağlayın, böylece siz yapmayın.
Kernel CPU sorun giderme kılavuzumda daha önce de belirttiğim gibi, bazen en iyi çözüm, belirtiyi sistemin üstesinden gelmesini önlemekle ilk adımda önlemektir.