Sunucuda log rotation ile disk dolmasını engelleme rehberi

Sunucuda günlük trafiğin bir sonucu olarak loglar büyür. Yanlış yapılandırılmış bir log rotation (log döndürme) diskin dolmasına, uygulamanın yazma işlemlerinin yavaşlamasına ya da servislerin hatayla çalışmayı durdurmasına kadar gidebilir. Bu rehberde, Linux tabanlı sunucularda logları kontrol altına almayı; döndürme sıklığı, saklama (retention) süresi, sıkıştırma, silme ve izleme adımlarını net bir planla anlatıyorum. Hedefiniz, disk dolması yaşadığınızda “hangi log şişti?” sorusuna saniyeler içinde cevap verebileceğiniz bir düzene geçmek.

Log rotation neden disk dolmasını durdurur?

Log rotation, log dosyalarının belirli bir boyuta veya zamana ulaştığında otomatik olarak arşivlenmesini ve eski logların saklama politikasına göre silinmesini sağlar. Böylece: - Tek bir dosya sınırsız büyümez. - Arşivlenen loglar sıkıştırılarak depolama maliyeti düşürülür. - Eski loglar retention süresi dolunca temizlenir.

Disk dolması genellikle iki senaryoda olur: 1) Uygulama logları (ör. Nginx, Apache, PHP-FPM, uygulama logları) döndürülmeden büyür. 2) Döndürme var sanılır ama yanlış çalışır: izin problemi, yanlış dosya yolu, log dosyası adı uymuyor, reload süreci tetiklenmiyor veya sıkıştırma/temizleme devreye girmiyor.

Hangi logları kontrol etmeli? (net kontrol listesi)

Her sunucuda log seti farklıdır; ancak pratikte ilk bakılacaklar şunlardır:

1) Web sunucusu logları

• Nginx: /var/log/nginx/access.log, /var/log/nginx/error.log
• Apache: /var/log/apache2/access.log, /var/log/apache2/error.log

2) Uygulama ve servis logları

• PHP-FPM: genelde /var/log/php*-fpm.log veya systemd journal üzerinden
• Uygulama: kendi dizininde (ör. /var/log/myapp/*.log)
• Systemd journal: journalctl ile

3) Sistem logları

• /var/log/syslog, /var/log/messages (dağıtıma göre)
• Auth: /var/log/auth.log

Hızlı teşhis: disk dolmadan önce şişeni bulma

Disk dolmaya başlamış bir VDS/VPS/Dedicated sunucuda ilk yapılacak işlem log kaynaklarını netleştirmektir: - du -ah /var/log | sort -hr | head -n 30 - ls -lh /var/log | tail -n +1 - Uygulama logları için proje dizininde benzer du sorgusu

Buradan “hangi dosya/klasör büyüyor?” sorusuna doğrudan yanıt alırsınız.

Log rotation için pratik politika: sıklık, boyut, retention

Log rotation ayarı çoğunlukla logrotate ile yapılır (Linux’ta standart yaklaşım). En kritik seçimler şunlardır:

• Sıklık (schedule): günlük (daily) veya saatlik (hourly) gibi.
• Boyut tabanlı tetikleme: size 100M gibi. Büyük trafik yaşayan sitelerde zaman tabanlı yerine boyut tabanlı daha stabil olur.
• Saklama süresi (retention): ör. 14 gün, 30 gün, 90 gün.
• Sıkıştırma: compress ile arşiv dosyaları .gz olur.
• Eksik güncellemeler için “missingok”: dosya yoksa hata üretmesin.
• Kompleks servislerde postrotate: servis log dosyası tutuyorsa yeniden yükleme gerekir.

Aşağıdaki tablo, tipik üretim senaryolarında net politika örneklerini özetler. Bu değerleri sunucunuzun trafik ve hata yoğunluğuna göre ayarlayın.

logrotate yapılandırmasını doğru kurma (örnek dosya)

Linux dağıtımlarında genellikle /etc/logrotate.conf ana ayar ve /etc/logrotate.d/ altında servis bazlı dosyalar bulunur. Kendi uygulama loglarınız için ayrı bir konfigürasyon dosyası oluşturmanız önerilir.

Aşağıdaki örnek Nginx logları için; dosya yolları ve servis adı dağıtıma göre değişebilir.

Hedef: 100 MB olunca döndür, 30 gün sakla

/etc/logrotate.d/nginx benzeri bir dosyaya şu mantıkla başlayın:

• log dosyası yolu doğru olmalı
• size ile tetiklenmeli
• compress kullanılmalı
• retention belirlenmeli
• postrotate içinde ilgili servisin reload edilmesi gerekir

Örnek konsept (gerçek dosyadaki yol/komutları kendi sunucunuza uyarlayın):

/var/log/nginx/*.log {
  daily
  size 100M
  rotate 30
  missingok
  notifempty
  compress
  delaycompress
  sharedscripts
  postrotate
    # Nginx logları tutuyorsa yeniden yükle
    systemctl reload nginx > /dev/null 2>&1 || true
  endscript
}

Bu politikanın mantığı: - daily günlük denetim getirir. - size 100M tek günde aşırı büyüme olursa daha erken döndürmeyi sağlar. - rotate 30 30 dönüşüm saklar (retention mantığı olarak düşünün). - delaycompress ile yeni döndürülen dosya hemen sıkıştırılmaz; servis yeniden yazma başlarken sorun yaşanmasını azaltır. - notifempty boş dosyalarda gereksiz döndürmeyi engeller.

Uygulama logları için ayrı konfigürasyon

Uygulama logları genelde /var/log/uygulama/ altında yaşar. Burada şu detaylar önemlidir: - Uygulamanın log yazdığı dosya adı logrotate glob’larına birebir uymalıdır. - Uygulama log tutuyor ve dosya ismini değiştirmeden yazmaya devam ediyorsa postrotate içinde uygulamanın reload komutu gerekir. - Uygulama “saatlik” veya “buffer’lı” çalışıyorsa test şarttır.

Test etme: yanlış konfigürasyon disk dolmasına yol açmadan yakalanmalı

Log rotation ayarını kaydetmeden önce test edin. logrotate iki önemli mod sunar: - konfigürasyonu doğrulama ve “ne yapacağını görme” - hataları anında yakalama

Komut örneği:

• sudo logrotate -d /etc/logrotate.d/nginx
• Tüm sistem için: sudo logrotate -d /etc/logrotate.conf

Buradaki amaç: - Hangi dosyalar dönecek, hangi arşivler oluşacak, silme (rotate) ne zaman olacak - postrotate adımının çalışıp çalışmayacağı

İpucu: Test çıktısında “skipping” veya “error” benzeri mesajlar görüyorsanız önce bunu çözün. Disk dolması riskinde, beklenmedik şekilde hiç döndürmeyen konfigürasyonlar en kötü senaryodur.

“postrotate” atlanırsa ne olur? (en yaygın hata)

Birçok servis log dosyasını açık tutar. Dosya adı değiştirilince (logrotate bunu yapar), servis hâlâ eski file descriptor üzerinden yazabilir. Sonuçlar: - Yeni log oluşur gibi görünür ama servis eski dosyayı büyütmeye devam eder. - Siz arşivleri doğru saklarken disk yine de dolabilir.

Bu yüzden: - Nginx/Apache gibi servislerde systemctl reload ... veya servis uyumlu reload komutunu koyun. - Uygulamanız systemd ile yönetiliyorsa doğru birim adını kullanın. - postrotate komutu başarısız olursa uygulama loglarında davranış değişebilir; mümkünse || true ile logrotate’ın akmasını sağlayın ama gerçek hatayı ayrıca izleyin.

İzleme ve doğrulama: rotation çalışıyor mu, disk niye doluyor?

Log rotation kurduktan sonra “işliyor mu?” doğrulaması şarttır.

1) Döndürme zamanını gözleyin

• Arşiv dosyalarının oluşumu: ör. access.log.1.gz gibi
• Dosya boyutlarının düşüp düşmediğini kontrol edin
• logrotate çalışınca ilgili servis reload loglarını doğrulayın

2) logrotate çalışmasını zamanlamayla eşleştirin

Bazı sistemlerde cron ile çalışır, bazılarında systemd timers devrededir. Şunlara bakın: - systemctl status logrotate.timer (timer varsa) - cron işlerini kontrol edin

3) “rotation var ama disk yine doluyor” için kontrol sırası

1) Şişen dosya gerçekten /var/log altında mı? (du sorgusu) 2) logrotate şişen dosya için konfigürasyona dahil mi? (dosya yolu ve glob) 3) postrotate reload doğru servis mi? (komut) 4) Dosya izinleri doğru mu? (logrotate, ilgili logları okuyabiliyor olmalı) 5) Uygulama farklı bir yerde log mu tutuyor? (environment/config)

Disk dolmasını tamamen bitirmek için ek önlemler

Log rotation tek başına “tam çözüm” değil; özellikle yüksek trafik veya saldırı dalgalarında tek gün içinde beklenenden fazla log üretebilirsiniz. Şu ek önlemler pratikte fark yaratır:

1) Disk kotası veya uyarı sistemi

• Dosya sistemi doluluğu için otomatik uyarı kurun.
• Basit bir eşik: %80 dolulukta bildirim, %90’da aksiyon.

2) Log seviyelerini düzenleyin

Üretimde gereksiz debug logları disk tüketimini büyütür. Uygulamada: - debug seviyesini üretimde kapatın - hata ve bilgi (error/warn/info) seviyelerini koruyun

3) Web katmanında gereksiz istekleri azaltın

Nginx’te erişim logu bazen çok agresif olabilir. İstek sayısı aşırıysa: - Doğru erişim log formatı - Gereksiz endpoint’lerin loglanmasını azaltma

4) Yedekleme (backup) ile karıştırmayın

Bazı ekipler “yedekleme yerine logları arşivleyeyim” yaklaşımıyla retention’ı uzatır. Bu, log şişmesi probleminde aynı sonucu üretir. Loglar için retention ayrı, yedekleme ayrı olmalıdır.

Sonuç: Aksiyon planı (30 dakikada netleştirme)

Disk dolmasını engellemek için bir “tek seferlik kurulum” değil, doğrulanabilir bir rutin gerekir. Şu sırayla ilerleyin: 1) du -ah /var/log | sort -hr | head ile şişen logu bulun. 2) logrotate için doğru dosya yollarını ve glob’ları belirleyin. 3) Trafiğe göre net bir politika seçin: ör. size 100M, rotate 30, compress, delaycompress. 4) Servisin log dosyasını tutma ihtimaline karşı postrotate ile reload ekleyin. 5) logrotate -d ... ile test edin, ardından dönüşüm oluşumunu gözleyin.

Bu adımları tamamladıktan sonra loglar belirli bir sınırı aşmadan döner ve disk dolması riski ciddi şekilde düşer. Eğer mevcut sistemde zaten disk dolduysa, önce şişen dosyayı izole edin, ardından rotasyon politikasını devreye alıp test ederek kalıcı hale getirin.