Sunucuda Log Rotation Rehberi: Disk Dolmasını Önleyin

Sunucuda en sık yaşanan arızalardan biri “disk doldu” durumudur. Bu çoğu zaman uygulama hatası değil, arka planda biriken logların kontrolsüz büyümesidir. Log rotation (log döndürme) doğru ayarlanmadığında; web sunucusu (Nginx/Apache), uygulama servisleri, veritabanı veya sistem günlükleri saniyeler içinde disk tüketebilir. Bu rehberde log rotation stratejisini disk kapasitesiyle eşleştirerek nasıl kuracağınızı, hangi log türlerinde hangi politikayı kullandığınızı ve kontrol adımlarını net bir şekilde öğreneceksiniz.

Log rotation neden disk dolmasını engeller?

Log rotation; belirli aralıklarla log dosyasını yeniden adlandırıp yeni log üretmeye, eski logları sıkıştırmaya (compress) ve gerekirse silmeye (prune) dayanır. Böylece disk, zaman içinde sınırsız büyüyen tek bir dosya yerine planlı bir “kayıt penceresi” tutar.

Logların büyümesini tetikleyen örnekler: - Trafik artışı (özellikle access log) - Hata fırtınası (4xx/5xx patlaması) - Yanlış ayarlı debug log (çoğu sistemde debug seviyesinde log yazımı performansı da düşürür) - Uygulamanın günlükleri aynı dosyaya sonsuz eklemesi - Çok büyük core dump / stack trace çıktıların loga düşmesi

Hangi loglar önceliklidir? (Önce doğru hedefi seçin)

Her log dosyası için aynı politika çalışmaz. Önce hangi logların hızlı büyüdüğünü saptayın. Aşağıdaki liste, tipik bir Linux sunucuda öncelikli hedefleri gösterir:

• /var/log/nginx/access.log: Trafiğe bağlı hızlı büyür.
• /var/log/nginx/error.log veya Apache error log: Hata durumlarında hızlı büyür.
• Uygulama logları: Örn. /var/log/myapp/*.log ya da systemd journal dışarı aktarımları.
• /var/log/syslog ve /var/log/messages: Sistem olayları birikir.
• Veritabanı logları: Örn. MySQL/MariaDB için /var/log/mysql/error.log ve yavaş sorgu logları.
• Denetim ve güvenlik logları: Fail2ban kayıtları, auth.log.

Hızlı tespit komutu: “Kim büyüyor?”

Aşağıdaki yaklaşım, log rotation yapmadan önce hedefleri netleştirir: - Sunucuda en büyük log dosyalarını bulma: - sudo du -ah /var/log | sort -rh | head -n 30 - En çok yazanları yaklaşık görme (dosya başına büyüme): - sudo find /var/log -type f -size +100M -exec ls -lh {} \;

Bu listeyi yaptıktan sonra, rotation ayarlarını sadece “kontrolsüz büyüyen” dosyalara yoğunlaştırmak daha doğru sonuç verir.

Log rotation stratejisinin temel parametreleri

Logrotate (log rotation aracı) genelde şu parametrelerle çalışır. Hedefiniz disk dolmasını engellemek olduğundan her parametreyi disk tüketimine bağlayın.

Saklama (retention) süresi: Disk penceresi

Temel karar: “Kaç günlük log saklayacağım?” - Erişim logu (access): 3–14 gün genelde yeterlidir. Daha uzun süre gerekiyorsa arşivleme (S3/obj storage) düşünün. - Hata logu (error): 7–30 gün arası daha yaygındır; ancak hata fırtınasında çok hızlı şişebileceği için boyut sınırı da düşünülür. - Sistem logu (syslog/messages): 7–30 gün.

Diski hesaplayarak karar vermek için basit formül: - Günlük ortalama log boyutu × saklama gün sayısı ≈ disk ihtiyacı

Örnek hesap (yaklaşık): - Nginx access log: günlük 20 GB - Saklama: 7 gün - Sadece access için: 140 GB Bu rakamın disk kotanızın (ör. 200 GB) dışında kalması disk dolmasına doğrudan yol açar.

Sıkıştırma: gzip ile disk düşürme

• Logrotate içinde compress kullanımı yaygındır.
• İyi pratik: access log gibi hacimli dosyalarda sıkıştırma şarttır.

“Yeni dosya oluştur” zamanlaması

• daily, weekly gibi periyotlar kullanılabilir.
• Trafik çok yüksekse günlük yerine daha sık dönüş (ör. hourly) gerekebilir.

Silme (prune) ve “sınırlı sayıda eski dosya”

• rotate N: En fazla N adet eski log dosyası tutulur.
• Saklama ihtiyacınız “gün” değil “adet” olarak düşünülüyorsa N üzerinden netleşir.

Örnek: - daily rotation + rotate 14 ⇒ yaklaşık 14 gün

Net bir yapı: /etc/logrotate.d ile düzen kurun

Birçok dağıtımda logrotate için ana yapı /etc/logrotate.conf ve dosya başına ayarların bulunduğu /etc/logrotate.d altında yönetilir. Kural olarak: - Dağıtımın varsayımlarını değiştirmek yerine, ayrı bir dosya ile kendi ayarlarınızı ekleyin.

Örnek: Nginx access log rotation

Aşağıdaki örnek; günlük dönüş, sıkıştırma ve 14 adet eski dosya mantığı kurar. Sunucunuzda dosya yolları farklıysa buna göre uyarlayın.

# /etc/logrotate.d/nginx
/var/log/nginx/access.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

Bu örnekte önemli noktalar: - delaycompress: Son dönen dosyayı hemen sıkıştırmak yerine bir sonraki döngüde sıkıştırır. Bazı servislerin dosya açık tutması durumunda daha stabil çalışır. - notifempty: Boş dosya için gereksiz işlem yapılmasını azaltır. - copytruncate: Nginx dosyayı açık tutuyorsa pratik bir yaklaşımdır. (Servisin reopen/pid davranışına göre farklı yöntemler tercih edilebilir.)

Örnek: Nginx error log rotation

Hata logu daha az hacimli olabilir ama hata patlamalarında çok büyüyebilir. Bu yüzden rotate sayısını ve/veya sıkıştırmayı koruyun.

# /etc/logrotate.d/nginx_error
/var/log/nginx/error.log {
    daily
    rotate 21
    compress
    delaycompress
    missingok
    notifempty
}

Uygulama logları için net kontrol: “log nerede bitiyor?”

Uygulama logları bazen: - Dosya olarak yazılır (ör. /var/log/myapp/app.log) - systemd journal üzerinden tutulur - container (Docker) log driver üzerinden tutulur

Dosyaya yazmıyorsa dosya temelli logrotate işe yaramaz. Bu durumda çözüm: - Uygulama loglarını dosyaya yönlendirmek (varsa) - ya da systemd journal için ayrı retention ayarı kullanmak (journalctl/Storage ayarları)

Disk dolmasını engellemek için hesap + doğrulama yöntemi

Log rotation ayarını yaptıktan sonra, “gerçekten disk tüketimi duruyor mu?” sorusunun cevabını doğrulamak gerekir.

1) Logrotate çalışıyor mu?

Komutla test: - sudo logrotate -f /etc/logrotate.conf

Varsayılan yapı, tüm dahil edilen dosyaları uygular. Belirli bir dosyayı çalıştırmak için ilgili dosyayı hedefleyin.

2) logrotate timer/cron aktif mi?

Dağıtıma göre: - cron: /etc/cron.daily/logrotate - systemd timer: logrotate.service/logrotate.timer

Kontrol: - systemctl status logrotate.timer 2>/dev/null || true - systemctl status cron 2>/dev/null || true

3) Disk büyümesi gerçekten yavaşladı mı?

Aşağıdaki kontrol, “rotation var ama pratikte disk temizlenmiyor” durumlarını yakalar: - log dizin boyutu trendi: - du -sh /var/log - belli bir dosyanın boyutu: - ls -lh /var/log/nginx/access.log

Doğru kurulumda: - Aktif log dosyası boyutu belirli bir aralıkta kalır. - Eski loglar .gz olarak artar, ancak rotate N ile bir süre sonra silinmeye başlar.

Log rotation tek başına yetmez: en sık kaçırılan 3 nokta

1) Servis dosyayı açık tutuyor (copytruncate veya reopen gerekiyor)

Bazı servisler logrotate sonrası yeni log dosyasına geçişi otomatik yapmayabilir. Sonuç: rotation var ama disk aynı dosyanın büyümesiyle şişmeye devam eder.

Çözüm yaklaşımı: - servis için uygun sinyal/yeniden açma (ör. Nginx için reload mantığı) - logrotate parametrelerini servis davranışına göre seçme (copytruncate / create ile izin yönetimi)

2) Container logları ayrı yönetiliyor

Docker/Podman logları dosya olarak /var/lib/docker/… altında büyüyebilir. Bu durumda /var/log/nginx gibi hedefler tek başına sorunu çözmez.

Kontrol için: - Docker disk ve log sürücüsü: - docker info --format '{{.Driver}}' - container log miktarı (yaklaşık): - docker system df

3) “Sıkışıyor ama silinmiyor” problemi

Sıkıştırma (compress) tek başına disk dolmasını durdurmaz. Eski log dosyalarının rotate N ile veya prune mekanizmasıyla silinmesi gerekir.

Parametreleri disk kapasitesiyle eşleştiren net karar tablosu

Aşağıdaki tablo, yaygın senaryolarda disk dolmasını engellemek için nasıl seçim yapmanız gerektiğini özetler.

“Disk dolmasın” hedefi için gerçekçi bir kontrol listesi

Kurulumdan sonra şu kontrol listesini uygulayın:

• [ ] du -sh /var/log değeri büyümesini durdurdu mu (1-3 gün izleyin)?
• [ ] logrotate -f /etc/logrotate.conf ile testte hata çıkıyor mu?
• [ ] rotate N ile eski loglar gerçekten siliniyor mu? (eski .gz sayısını gözlemleyin)
• [ ] log dosya izinleri (create/ownership) servis tarafından yazılabilir durumda mı?
• [ ] Nginx/Apache reload sonrası yeni loga yazım başladı mı? (aktif log dosyası büyüyor mu?)

Sonuç: Log rotation’ı “disk hesabı + doğrulama” ile kurun

Disk dolması sorununu kalıcı şekilde çözmek için log rotation sadece “bir config eklemek” değildir; saklama penceresini disk kapasitenize göre belirleyip sıkıştırma ve silme mantığını aynı anda çalıştırmanız gerekir. İlk adım olarak /var/log içinde en çok büyüyen 3 dosyayı bulun, ardından günlük/haftalık dönüş ve rotate değerlerini disk hesabıyla eşleştirin. Ayarları yaptıktan sonra logrotate -f ile test edin ve 1-3 gün boyunca /var/log toplam boyut trendini izleyin. Bu kontrolü kurduğunuzda disk dolması kaynaklı servis kesintisi riski belirgin biçimde düşer.