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ünüz %100 dolar. Sistem yavaşlar, loglar yazılmayı durdurur ve kritik bir şey bozulmadan önce boş alan açmak için çaba harcarsınız. Ortamımda, günlük hacmini kontrol altında tutmak için systemd-journald’ın yerleşik hız sınırlama özelliğine güvenirim. /etc/systemd/journald.conf dosyasındaki RateLimitInterval ve Burst ayarlarını değiştirerek, tek bir hizmetin günlüğü doldurmasını ve disk alanını tüketmesini önleyebilirsiniz.
journald Hız Sınırlamasını Anlamak
systemd-journald, log giriş akışını kontrol etmek için iki temel ayar içerir: RateLimitInterval ve Burst. Bu iki ayar birlikte, belirli bir zaman penceresi içinde izin verilen log giriş sayısını tanımlar ve bu sınırı aşan mesajlar düşürülür. RateLimitInterval, zaman penceresini saniye cinsinden ayarlar; Burst ise bu pencere içinde izin verilen maksimum mesaj sayısını tanımlar. Bir hizmet bu sınırı aşarsa, journald daha fazla mesajı işlemeyi durdurur ve zaman penceresi sıfırlanana kadar bekler; bu sayede aşırı loglama diskin I/O ve depolama alanını tüketmesini önler.
Varsayılan olarak, bu değerler normal işleme izin vermek için konservatif olarak ayarlanmış ve aynı zamanda koruma sağlar. Ancak yoğun sistemlerde veya gürültülü uygulamalar hata ayıklanırken, varsayılan değerler çok izin verici olabilir. Ben, cron çalıştırmaları veya uygulama yeniden başlatmaları sırasında journal büyümesinde ani artışlar gözlemledikten sonra, çeşitli üretim sunucularında bu değerleri ayarladım.
Mevcut Günlük Kullanımını Kontrol Etme
Ayarlamalardan önce, günlüğün şu anda ne kadar alan kullandığını ve hız sınırlamasının zaten aktif olup olmadığını her zaman kontrol ederim. Disk kullanımını journalctl --disk-usage komutuyla görebilirsiniz. Bu komut, arşivlenmiş ve aktif günlüklerin tükettiği toplam alanı gösterir.
Mesajların hız sınırlaması nedeniyle düşürülüp düşürülmediğini görmek için, "Journal file /var/log/journal/... is full" gibi girişleri arayabilir veya hız sınırı sayaçlarını şu komutla kontrol edebilirsiniz:
journalctl --since "1 hour ago" | grep -i "rate limit"Sık sık düşürme görüyorsanız, bu mevcut ayarlarınızın düzenli olarak aşıldığı bir işaretidir. Bu her zaman sınırların artırılması gerektiği anlamına gelmez—bazen bir hizmetin çok ayrıntılı log tutması ve bu sorunun kaynaktan düzeltilmesi gerektiği anlamına gelebilir.
RateLimitInterval ve Burst Ayarları
/etc/systemd/journald.conf dosyasını root olarak düzenleyin. Çoğu sunucu için RateLimitInterval'i 30s ve Burst'i 5000 olarak ayarlarım. Bu, her 30 saniyede en fazla 5.000 mesajın kaydedilmesine izin verir—başlangıç veya log dönüşü sırasında ani artışlar için yeterli, ancak bir sürecin kontrolsüz çalışıp diski hızla doldurmasını önlemek için yeterli değildir.
# /etc/systemd/journald.conf
RateLimitInterval=30
RateLimitBurst=5000Dosyayı değiştirdikten sonra systemd-journald'i yeniden başlatın:
systemctl restart systemd-journaldArdından ayarların aktif olduğunu doğrulayın:
systemctl show systemd-journald --property=RateLimitInterval --property=RateLimitBurstAyarladığınız değerleri görmelisiniz. Görmezseniz, yapılandırma dosyasındaki yazım hatalarını veya sözdizimi hatalarını kontrol edin.
Günlük Taşmalarını İzleme
Rate limiting mevcut olsa bile, sorunları erken yakalamak için günlük büyümesini izliyorum. Kullanım sınırının %80'ini aşarsa uyarı veren basit bir kontrol, journalctl --disk-usage komutunu kullanarak bir cron betiğinde kurarım. Maksimum günlük boyutu, SystemMaxUse tarafından kontrol edilir; bu, dosya sisteminin %10'u olarak varsayılan olarak ayarlanır ancak ayarlanabilir.
İzleme betiğimde kullandığım bir kod parçacığı şu şekildedir:
#!/bin/bash
USAGE=$(journalctl --disk-usage | awk '/total/ {print $3}' | tr -d 'MB')
LIMIT=$(grep SystemMaxUse /etc/systemd/journald.conf | cut -d'=' -f2 | tr -d 'M')
if [ -z "$LIMIT" ]; then
LIMIT=1024 # örnek olarak 10G diskte %10'un varsayılan değeri
fi
PERCENT=$((USAGE * 100 / LIMIT))
if [ $PERCENT -gt 80 ]; then
echo "UYARI: Günlük kullanımı ${PERCENT}%" | systemd-cat -t journald-check -p warning
fiBu betik saatlik olarak çalışır ve kullanım yüksek olduğunda uyarıyı günlüğe kaydeder. İsterseniz, e-posta gönderme veya izleme sistemi uyarısı tetikleme gibi işlevleri de ekleyebilirsiniz.
Ne Zaman Ayarlamalı vs. Ne Zaman Kaynak Düzeltmeli
Rate limiting, bir güvenlik ağıdır, gürültülü loglamanın bir çözümü değildir. Sürekli burst limitine takılıyorsanız, nedenini sorun. Bir hizmet üretim ortamında INFO seviyesinde mi hata ayıklama yapıyor? Bir cron işi mi başarısız ve her dakika aynı hatayı logluyor? Bu gibi durumlarda, log ayrıntılığını azaltmak veya temel sorunu düzeltmek, sınırları sadece artırmaktan çok daha iyidir.
Bir takımı, uyarıları susturmak için Burst’i 20000’ye kadar çıkarttığını gördüm, ancak gerçek sorun kötüleştiğinde birkaç gün sonra diskleri doldu. Rate limiting’i bir tampon olarak ele alın, gürültü loglarını görmezden gelmek için bir lisans olarak değil.
Sonuç
systemd-journald.conf dosyasındaki RateLimitInterval ve Burst ayarlarını ayarlamak, disk tükenme riskini ortadan kaldırarak günlük artışlarını emmek için pratik bir yol sunar. Bu ayarlar, journalctl --disk-usage komutunu düzenli olarak kontrol etme alışkanlığıyla ve izlemeyle birleştirildiğinde, systemd çalıştıran herhangi bir Linux sunucusu için düşük çaba, yüksek etki sağlayan bir kontrol mekanizması haline gelir.
Önceden auditd ile /etc/passwd izleme konulu yazımda da belirttiğim gibi, proaktif günlük hijyeni daha büyük sorunların önüne geçer. Öncelikle konservatif sınırlar ile başlayın, kullanımı izleyin ve günlük fırtınasının kaynağını gerçekten anladığınızda sadece o zaman ayarları ayarlayın.
Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/5906903/photo-image-background-public-domain-technology