logrotate: Disk dolmadan önce log rotasyonu

Sunucu diski %98'de kilitlenmiş, site açılmıyor ve df -h yazdığınızda /var'ın dolu olduğunu görüyorsunuz. Sonra du -sh /var/log/* | sort -h yazıyorsunuz ve gözünüzün önünde 12 gigabaytlık bir dosya var: aylardır kimsenin dokunmadığı syslog veya access.log. İşte tam da burada logrotate çalışması gerekiyordu ve çalışmadı.

logrotate, logları zamana veya boyuta göre döndüren, sıkıştıran ve eskileri silen bir komut satırı aracıdır. Neredeyse her Linux dağıtımında önceden kuruludur ve cron veya systemd timer aracılığıyla çalıştırılır. Sorun genellikle aracın kendisi değildir; ya var olmayan, ya yanlış yazılmış ya da varsayılan yolların dışında yeni bir log dosyası oluşturulmuş ve kimsenin kural yazmadığı bir yapılandırmadır.

logrotate sunucunuzda neden çalışmıyor

Herhangi bir değişiklik yapmadan önce rotasyonun neden yapılmadığını anlayın. Pratikte gördüğüm üç yaygın neden:

• logrotate servisi devre dışı. systemctl status logrotate.timer ile systemd timer durumunu kontrol edin. Eğer inactive (dead) ise, hiç çalıştırılmamış demektir.
• Log dosyası standart yolların dışında. Örneğin /home/deploy/app/logs/app.log içine yazan bir uygulama ve /etc/logrotate.d/ içinde onun için hiçbir dosya yok.
• Yapılandırma bozuk ve logrotate sessizce atlıyor. logrotate -d /etc/logrotate.conf ile debug modunda çalıştırın ve hangi dosyayı yok saydığını görün.

Debug modu çıktısı genellikle cevabı kendisi verir. error: skipping "/var/log/app.log" because parent directory has insecure permissions gibi bir satır görürseniz, sorun yapılandırma değil dizin izinleridir. logrotate varsayılan olarak grup veya diğerlerinin yazma izni olduğu dizinlere karşı hassastır ve rotasyondan atlar.

Gerçekten çalışan bir yapılandırma dosyası

Uygulamanızın /var/log/myapp/app.log içine yazdığını varsayalım. /etc/logrotate.d/myapp içinde yeni bir dosya oluşturun:

/var/log/myapp/app.log {
    daily
    rotate 14
    size 100M
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Çoğu kişinin gözden kaçırdığı nokta: hem daily hem de size koyduğunuzda, boyut koşulu kazanır. Yani dosya bir saatlik bile olsa, 100 megabayta ulaştığı anda döndürülür. Bu davranış logrotate.conf man sayfasında açıkça belirtilmiştir ancak pratikte göz ardı edilir.

create 0640 www-data adm satırı da önemlidir. Yeni dosyanın sahibini ve grubunu yanlış verirseniz, ilk rotasyondan sonra uygulama artık dosyaya yazamaz ve loglar sessizce kesilir. Bu sessiz hata en kötü arıza türüdür çünkü günler sonra kimse fark etmez.

copytruncate ile create: hangisini seçmeliyim

İşte en çok hatanın yapıldığı yer burası. Rotasyon için iki yöntem vardır ve aralarındaki seçim zevke değil, uygulamanın davranışına bağlıdır.

Uygulamanız log dosyasını açık tutuyorsa ve reload için bir yolu yoksa, copytruncate doğru seçimdir. Ancak maliyetini bilin: logrotate içeriği kopyaladığı an ile dosyayı truncate ettiği an arasında, uygulamanın yazdığı her satır kaybolur. İşlemsel loglar için bu kabul edilemez; debug logu için genellikle kabul edilebilir.

Kendi sunucumu yapılandırdığım vakaların %90'ında create seçtim çünkü servisler reload sinyalini anlıyor ve hiçbir veri kaybolmuyor. copytruncate'e yalnızca uygulama bir binary olduğunda ve kodu benim elimde olmadığında başvuruyorum.

İşte burada hata yapıyorlar: çoğu kişi copytruncate ile create'i aynı blokta birlikte koyuyor. logrotate bu kombinasyonu reddetmez ama sonuç öngörülemezdir; bazen yeni dosya oluşturulur ve uygulama hâlâ yeniden adlandırılmış dosyaya yazar. Belirtisi şudur: app.log.1 dosyası sürekli büyür ve app.log her zaman boş kalır. Bunu görürseniz, iki seçenekten birini kaldırın.

Yapılandırmayı bir hafta beklemeden test etme

Rotasyonun çalışıp çalışmadığını görmek için yarın sabahı beklemek zaman kaybıdır. -f ile rotasyonu zorla çalıştırabilirsiniz:

logrotate -vf /etc/logrotate.d/myapp

-v bayrağı logrotate'in verdiği her kararı yazdırır ve -f zaman koşuluna bakılmaksızın rotasyonun yapılmasını sağlar. Çalıştırdıktan sonra ls -lh /var/log/myapp/ yazın ve app.log.1 dosyasının oluşturulup oluşturulmadığını görün. delaycompress koyduysanız, .1 dosyası henüz sıkıştırılmamıştır ve .2.gz vardır.

Pratik bir not: production sunucusunda test etmeden önce, log dosyasını truncate -s 0 ile boşaltmayın. Uygulama dosyayı açık tutuyorsa, iç offset'i bozulur ve bir sonraki yeniden başlatmaya kadar hiçbir şey yazmaz. Test için geçici bir yolda yapay bir log dosyası oluşturun ve yapılandırmayı onun üzerinde deneyin.

Paylaşımlı veya yönetilen bir hosting üzerinde çalışıyorsanız ve root erişiminiz yoksa, logrotate genellikle ana servisler için önceden yapılandırılmıştır ve yalnızca kendi uygulamanızın logunu panelden yönetmeniz gerekir. WordPress hosting hizmetinde bu işlem panel araçları üzerinden yapılır ve /etc/logrotate.d/ dizinine dokunmanıza gerek yoktur.

Logları başka bir yere gönderdiğinizde

rsyslog veya journald kullanıyorsanız, logrotate journal dosyaları üzerinde çalışmaz. journald için journalctl --vacuum-size=500M veya /etc/systemd/journald.conf içinde SystemMaxUse= ayarını kullanmanız gerekir. Bu farkı çoğu kişi bilmez ve var olmayan bir logrotate yapılandırma dosyasını saatlerce arar.

Nginx ve Apache logları için, dağıtımın varsayılan yapılandırması genellikle yeterlidir ancak bir sunucuda çok sayıda alan adınız varsa, her alan adının ayrı bir log dosyası vardır ve wildcard deseninin doğru yazıldığından emin olmalısınız. /var/log/nginx/*.log gibi bir satır hepsini kapsar ancak sonradan yeni bir alan adı eklerseniz otomatik olarak dahil edilir. Bu, her yolu elle yazmaktan daha iyidir.

Hangi servisin log kaydından sorumlu olduğundan emin değilseniz, ServerNet'in dokümantasyon ve bilgi tabanı her servisin varsayılan yollarını listeler. Ayrıca dosyaların boyutunu ve erişimini hızlıca kontrol etmek için ücretsiz araçlar yardımcı olabilir.

Sık sorulan sorular

logrotate neden log dosyamı döndürmüyor?

Üç yaygın nedeni vardır: systemd timer devre dışıdır, log dosyası standart olmayan bir yoldadır ve onun için yapılandırma yazılmamıştır, ya da üst dizin izinleri uygun değildir ve logrotate rotasyondan atlar. logrotate -d /etc/logrotate.conf ile debug modunda tam olarak hangi dosyanın ve neden reddedildiğini görün.

logrotate'de copytruncate ile create arasındaki fark nedir?

create'de eski dosya yeniden adlandırılır ve yeni dosya oluşturulur; uygulama reload sinyali ile dosyayı yeniden açmalıdır. copytruncate'de içerik kopyalanır ve asıl dosya boşaltılır; uygulamanın reload'a ihtiyacı yoktur ancak kopyalama anında birkaç satır kaybolabilir.

logrotate'i yarını beklemeden nasıl test ederim?

logrotate -vf /etc/logrotate.d/yourconfig komutuyla rotasyonu zorla ve tam çıktıyla çalıştırın. -f bayrağı zaman koşulunu yok sayar ve -v her kararı yazdırır. Çalıştırdıktan sonra ls -lh ile döndürülmüş dosyanın varlığını doğrulayın.

logrotate journald üzerinde de çalışır mı?

Hayır. journald logları ikili formatta tutar ve logrotate onları döndüremez. Journal boyutunu sınırlamak için journalctl --vacuum-size veya /etc/systemd/journald.conf dosyasında SystemMaxUse ayarını kullanmanız gerekir.

Bugün bir kez logrotate -d /etc/logrotate.conf yazın ve çıktısını okuyun. Bir hata görürseniz, disk dolması sorununu gelecek aylar için tam orada çözmüş olursunuz.