Ubuntu Server ortamlarında sistem loglarını etkin bir şekilde yönetmek, performans optimizasyonu ve depolama alanı tasarrufu açısından kritik öneme sahiptir. Systemd tabanlı journal log sistemi, varsayılan ayarlarıyla log verilerini sınırsız bir şekilde biriktirebilir ve bu durum disk alanını hızla tüketebilir. Bu makalede, journal log limitlerini ayarlayarak sunucunuzun istikrarını korumanın pratik yollarını ele alacağız. Journald konfigürasyonunu düzenleyerek log boyutunu sınırlamak, hem güvenlik hem de operasyonel verimliliği artırır. Aşağıdaki adımları takip ederek, bu ayarları güvenle uygulayabilirsiniz.
Journal Log Sisteminin Temel Kavramları
Systemd-journald, Ubuntu Server’ın varsayılan log toplama mekanizmasıdır ve binary formatta verileri saklar. Bu sistem, kernel mesajlarından uygulama loglarına kadar geniş bir yelpazeyi kapsar. Varsayılan olarak, loglar /var/log/journal dizininde tutulur ve boyutları sistem kaynaklarına göre otomatik olarak büyür. Ancak, yoğun trafik altında bu büyüme kontrolsüz hale gelebilir, bu da OOM (Out of Memory) durumlarına veya disk doluluğuna yol açar.
Journal log limitlerini anlamak için temel parametreleri bilmek şarttır. SystemMaxUse, toplam journal boyutunu belirlerken; RuntimeMaxUse, geçici (volatile) loglar için geçerlidir. Persistent modda loglar kalıcı hale gelir ve yeniden başlatmalarda korunur. Bu ayarlar, /etc/systemd/journald.conf dosyasında tanımlanır. Örneğin, bir üretim sunucusunda log boyutunu 500MB ile sınırlamak, depolama baskısını azaltır ve eski logların otomatik silinmesini sağlar.
Log Depolama Modları
Journald, üç depolama modu sunar: volatile (RAM tabanlı), persistent (disk tabanlı) ve none (devre dışı). Persistent mod, en yaygın kullanılanıdır ve /var/log/journal/volatile ile /var/log/journal/ dizinlerini içerir. Bu modda Storage=persistent ayarı ile etkinleştirilir. Volatile mod ise /run/log/journal/ altında tutulur ve yeniden başlatmada silinir. Üretim ortamlarında persistent tercih edilmelidir, çünkü hata ayıklama için tarihsel verilere ihtiyaç duyulur. Mod değiştirirken, mevcut logları journalctl –vacuum-time=2weeks ile temizleyin.
Otomatik Temizleme Mekanizmaları
Journald, SystemKeepFree ve RuntimeKeepFree parametreleriyle disk alanı korur. Örneğin, RuntimeKeepFree=10% ayarı, /run dizininde %10 boş alan bırakır. Benzer şekilde, SystemKeepFree=5G ile kök dizinde 5GB boşluk sağlanır. Bu mekanizmalar, log büyümesini otomatik frenler. Uygulamada, df -h komutuyla disk kullanımını izleyin ve vacuum işlemini cron job ile periyodik çalıştırın: journalctl –vacuum-size=100M.
Journal Log Limitlerini Yapılandırma Adımları
Limit ayarlarını uygulamak için root erişimiyle /etc/systemd/journald.conf dosyasını düzenleyin. nano veya vim editörü kullanın. Temel ayarlar arasında SystemMaxUse=1G (toplam 1GB limit), ForwardToSyslog=no (yalnızca journal kullan) ve Compress=yes (sıkıştırma etkin) yer alır. Değişiklikleri kaydettikten sonra systemctl daemon-reload ve systemctl restart systemd-journald komutlarını çalıştırın. Bu işlem, yeni ayarları anında uygular.
- Dosyayı açın: sudo nano /etc/systemd/journald.conf
- Aşağıdaki satırları ekleyin veya düzenleyin:
[Journal]
Storage=persistent
SystemMaxUse=500M
RuntimeMaxUse=100M
SystemKeepFree=2G
RuntimeKeepFree=500M - Servisleri yenileyin: sudo systemctl restart systemd-journald
- Log boyutunu kontrol edin: journalctl –disk-usage
Bu yapılandırma, orta ölçekli bir sunucuda logları 500MB ile sınırlarken, 2GB boş disk alanı korur. Büyük ölçekli ortamlarda SystemMaxUse=2G’ye çıkarabilirsiniz, ancak depolama kapasitesini göz önünde bulundurun.
İleri Düzey Parametreler
MaxFileSec=1week ile her log dosyasının 1 haftalık tutulmasını sağlayın. RateLimitIntervalSec=30m ve RateLimitBurst=1000 ile flood saldırılarını önleyin. SyncIntervalSec=5m, verilerin periyodik senkronizasyonunu sağlar. Bu parametreler, yüksek yük altında journald’nin stabil kalmasını güvence altına alır. Test ortamında ayarları simüle edin ve production’a geçmeden journalctl –verify ile bütünlüğü kontrol edin.
Güvenlik Odaklı Ayarlar
Seal=yes ile log dosyalarını dijital olarak mühürleyin, bu tampering’i engeller. ReadOnly=yes modunda yazma işlemleri kısıtlanır. Audit modülü entegrasyonu için ForwardToKMsg=yes kullanın. Güvenlik açısından, log erişimini sudo journalctl ile sınırlayın ve /etc/sudoers’ta yetkilendirin. Bu adımlar, uyumluluk standartlarını (örneğin GDPR) karşılamaya yardımcı olur.
Ayarların Doğrulanması ve Bakım İpuçları
Ayarlar uygulandıktan sonra, journalctl –disk-usage ile toplam boyutu görüntüleyin. –vacuum-size=200M komutuyla manuel temizlik yapın. Cron ile otomatize edin: 0 2 * * * /usr/bin/journalctl –vacuum-time=2weeks –vacuum-size=500M. Performans izleme için journalctl –since “1 hour ago” | grep error ile hataları filtreleyin. Log rotasyonu, rsyslog ile entegre edilebilir ancak journald öncelikli olmalıdır.
Ortak Sorunlar ve Çözümleri
Disk dolu hatası alırsanız, journalctl –flush ile tamponları boşaltın. Servis yeniden başlatılamıyorsa, systemctl status systemd-journald ile logları inceleyin. Çok fazla log varsa, –rotate ve –vacuum-files=5 ile dosya sayısını sınırlayın. Bu çözümler, %90 oranında downtime’ı önler ve sunucu uptime’ını artırır. Düzenli bakım, log analiz araçlarıyla (örneğin jq ile JSON filtreleme) birleştirilmelidir.
Uzun Vadeli Yönetim Stratejileri
Logları dış depolamaya aktarmak için journalctl –export > backup.journal kullanın. ELK Stack entegrasyonu düşünün, ancak journald limitleri temel katman olmalıdır. Aylık inceleme raporu oluşturun: journalctl –since “1 month ago” –until “today” | wc -l ile satır sayısını hesaplayın. Bu strateji, ölçeklenebilirlik sağlar ve operasyonel maliyetleri düşürür.
Journal log limit ayarlarını doğru uygulamak, Ubuntu Server’ınızın uzun ömürlü ve verimli çalışmasını temin eder. Bu konfigürasyonları test ederek başlayın, üretimde dikkatli izleyin ve ihtiyaçlara göre uyarlayın. Düzenli bakım ile sistem güvenliğinizi pekiştirin, böylece odak noktanızı kritik iş süreçlerine kaydırabilirsiniz.