Dolu bir systemd Günlüğü Nasıl Düzeltilir

Systemd günlüğü, sunucunuzun ürettiği her günlüğü mesajını depolar ve küçük bir kök bölümüne sahip bir VPS'de, kullanılabilir disk alanınızı sessizce tüketebilir. Bu durumda, hizmetler başlatılamaz, yazma işlemleri durur ve neyin yanlış gittiğini anlamak için ihtiyacınız olan tanılama bilgilerini kaybedersiniz. Bu kılavuz, sorunun nasıl teşhis edileceğini, hemen yer açılmasını ve bunun bir daha olmaması için journald'ın nasıl yapılandırılacağını ele almaktadır.

Sorunun Teşhisi

Öncelikle, günlüğün ne kadar alan kullandığını kontrol edin:

journalctl --disk-usage

Bu, tüm aktif ve arşivlenmiş günlük dosyalarının toplam boyutunu gösterir. Bunu, df -h. 20 GB'lık bir kök bölümde, 2 GB'lık günlükler bile toplam diskin %10'undan fazlasını oluşturur ve bu da sorunlara neden olmak için yeterlidir.

Ardından, en fazla gürültü üreten hizmetlerin hangileri olduğunu bulun. Bu tek satırlık komut, son 24 saatteki en çok günlük üreten ilk 10 kaynağı sıralar:

journalctl --since "24 hours ago" | awk '{print $5}' | cut -d'[' -f1 | sort | uniq -c | sort -rn | head -10

Tek bir hizmetin çökme döngüsüne takılıp kalıp günlüğü doldurup doldurmadığını görmek için özellikle journalctl -p err -b komutunu kullanarak hataları filtreleyin ve tek bir hizmetin çökme döngüsüne takılıp kalarak günlüğü doldurup doldurmadığını kontrol edin. Ayrıca journald'ın herhangi bir hizmeti hız sınırlamasına tabi tutup tutmadığını da kontrol edebilirsiniz:

journalctl -u systemd-journald | grep -i "suppressed"

Bastırma mesajları, bir hizmetin 30 saniye içinde 10.000 girişlik varsayılan eşiği aştığı anlamına gelir. Suçlu budur.

VPS örneklerinde özellikle yaygın olan birkaç durum vardır. Storage=auto ayarlanmışsa ve /var/log/journal/ varsa, journald varsayılan olarak yaklaşık 4 GB sınırlı kalıcı depolama alanı kullanır. Küçük bir kök bölümünde bu alan hızla dolar. Düzgün olmayan kapatmalar da .journal~ . Bu dosyalar normal şekilde dönmez ve sürekli yer kaplar.

Günlükleri Güvenli Bir Şekilde Temizleme

Herhangi bir şeyi silmeden önce, aktif günlük dosyasını döndürerek mevcut günlüklerin korunmasını sağlayın:

journalctl --rotate

Ardından arşivlenmiş günlükleri temizleyin. Yaş, boyut veya dosya sayısına göre hedefleyebilirsiniz:

sudo journalctl --vacuum-time=1d
sudo journalctl --vacuum-size=100M
sudo journalctl --vacuum-files=5

İlki, 24 saatten eski günlükleri siler. İkincisi, toplam günlük boyutunu 100 MB'a indirir. Üçüncüsü, yalnızca en son arşivlenen beş dosyayı saklar. Durumunuza uygun olanı seçin.

Disk tamamen doluysa ve journalctl komutları yanıt vermiyorsa, günlük dosyalarını manuel olarak silmeniz gerekebilir:

sudo rm -rf /var/log/journal/*
sudo systemd-tmpfiles --create --prefix /var/log/journal

Bu son çare olarak kullanılmalıdır. Bu işlem, depolanan tüm günlükleri siler ve dizini doğru izinlerle yeniden oluşturur. Herhangi bir temizlik işleminden sonra, arka plan programını yeniden başlatın ve doğrulayın:

sudo systemctl restart systemd-journald
journalctl --disk-usage

Journald Boyut Sınırlarını Yapılandırma

Varsayılan journald ayarları oldukça cömerttir. Bir VPS'de ise bu ayarlar fazla cömerttir. Günlük depolama için katı sınırlar belirlemek üzere yapılandırmayı düzenleyin. Değişikliklerinizin paket güncellemelerinden etkilenmemesi için ana yapılandırmayı doğrudan düzenlemek yerine bir geçersiz kılma dosyası oluşturun:

sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/size-limits.conf

Önemli yönergeler:

Her ikisini de ayarlama SystemMaxUse ve SystemKeepFree ayarlamak size "kemer ve askı" yaklaşımı sağlar: günlükler sabit bir boyutta sınırlandırılır ve diskte başka ne olursa olsun sistem her zaman nefes alabilir.

Kalıcı ve Geçici Depolama

log Storage= yönergesi, günlüklerin nereye gideceğini kontrol eder. Storage=persistent yönetici /var/log/journal/ yazmak için ayarlayın. Üretim sunucuları için istediğiniz şey budur, çünkü günlükler yeniden başlatmalardan sonra da kalır ve çökmeleri sonradan inceleyebilirsiniz. Dizin yoksa, oluşturun:

sudo mkdir -p /var/log/journal

Alternatif olarak, Storage=volatileise, günlükleri RAM'de /run/log/journal/. Günlükler yeniden başlatma sırasında silinir. Bu, geçici konteynerler veya tüm günlükleri harici bir sisteme ileten sunucular için mantıklıdır.

Yüksek Trafikli Sunucularda Sıkıştırmayı Devre Dışı Bırakma

Journald, varsayılan olarak 512 bayttan büyük veri nesnelerini sıkıştırır. Yoğun günlük işleme hacmi olan sunucularda bu, CPU yükünü artırır. Günlükleri harici bir sisteme iletiyorsanız ve yerel depolama alanını en aza indirmenize gerek yoksa Compress=no ayarlayın. Ayrıca ForwardToConsole=no . Konsol iletimi eşzamanlıdır ve tıkanan bir sanal seri konsol, journald arka plan programını tamamen engelleyebilir.

Herhangi bir yapılandırma değişikliğinden sonra, hizmeti yeniden başlatın:

sudo systemctl restart systemd-journald

Günlük Bakımının Otomatikleştirilmesi

Manuel temizlik ölçeklenemez. Günlükleri belirli bir programa göre temizlemek için bir systemd zamanlayıcı oluşturun. /etc/systemd/system/journal-vacuum.service:

[Unit]
Description=Vacuum old journal logs
 
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d --vacuum-size=500M

Ardından, /etc/systemd/system/journal-vacuum.timer:

[Unit]
Description=Weekly journal vacuum
 
[Timer]
OnCalendar=Sun 02:00
Persistent=true
 
[Install]
WantedBy=timers.target

Bunu sudo systemctl enable --now journal-vacuum.timerZamanlayıcı her Pazar saat 02:00'de çalışır ve tek seferde hem zamana dayalı hem de boyuta dayalı saklama uygulamasını gerçekleştirir.

Zamanlayıcının yakalayamayacağı tek şey: bozuk günlük dosyalarıdır. Düzgün olmayan bir kapatmanın ardından, journald dosya adına ~ ekleyerek karantinaya alır. Bu .journal~ dosyalar disk kullanımına dahil edilir ancak otomatik olarak temizlenmez. Eski dosyaları düzenli olarak kontrol edip silin:

find /var/log/journal/ -name "*.journal~" -mtime +30 -delete

Günlükleri Harici Olarak Yönlendirme

Yerel depolama alanını artırmadan uzun süreli saklama gerektiren sunucular için, günlükleri merkezi bir sisteme yönlendirin. En basit yaklaşım, journald.conf:

ForwardToSyslog=yes

Tam meta verilere (PID, UID, birim adları) sahip yapılandırılmış günlükler için systemd-journal-remote komutunu kullanarak JSON biçimindeki girdileri bir günlük yönetim platformuna gönderin. Harici günlük depolama, yerel disk arızalandığında veya sunucu güvenliği ihlal edildiğinde denetim izinizi de korur.

Sonuç

Tam bir systemd günlüğü düzeltmesi basittir ve önlenmesi kolaydır. Önemli adımlar:

• Kullanımı journalctl --disk-usage ile kullanımı kontrol edin ve gürültülü hizmetleri belirleyin.
• Hemen journalctl --rotate komutunu kullanın --vacuum-size veya --vacuum-time.
• journald.conf geçersiz kılma dosyasında açık boyut sınırları belirleyin.
• Systemd zamanlayıcısıyla temizlemeyi otomatikleştirin.
• Uzun süreli saklama için günlükleri harici olarak iletin.

FDC'nin VPS ve özel sunucu planları, üretim günlük iş yükleri için gereken disk I/O ve depolama alanını sağlar.