Logrotate Yapılandırması: Linux Sistemlerde Log Yönetimi ve Disk Doluluğu Önleme Rehberi

Sistem yöneticilerinin karşılaştığı en yaygın ve en sinir bozucu krizlerden biri, sabah uyanıldığında gelen “Disk Doldu (No space left on device)” uyarılarıdır. Çoğu zaman bu sorunun arkasında, uygulama sunucularında kontrolsüz bir şekilde şişen log (günlük) dosyaları yer alır. Özellikle üretim (production) ortamlarında çalışan servisler, debug modunun açık kalması veya yoğun trafik nedeniyle saatler içinde gigabaytlarca log üretebilir.

Linux dünyasında bu kaosun önüne geçmek için standart olarak kullanılan araç Logrotate’tir. Bu rehberde, Logrotate’in çalışma mantığını, temel ve gelişmiş yapılandırma parametrelerini, yaygın senaryoları ve sahada sıklıkla yapılan hataları ele alacağız.

Logrotate Nedir ve Nasıl Çalışır?

Logrotate, sistemdeki log dosyalarının döndürülmesini (rotation), sıkıştırılmasını, silinmesini ve e-posta ile gönderilmesini otomatikleştiren bir sistem aracıdır. Temel mantığı basittir:

Mevcut log dosyası yeniden adlandırılır.
Yeni ve boş bir log dosyası oluşturulur.
Eski log dosyası sıkıştırılarak (genellikle gzip ile) saklanır veya belirlenen saklama süresi (retention) sonunda silinir.

Logrotate, kullanıcı tarafından manuel olarak çalıştırılabileceği gibi, genellikle cron (günlük olarak /etc/cron.daily/ dizini altından) aracılığıyla arka planda otomatik olarak çalışır.

Logrotate Nasıl Tetiklenir?

Sisteminizde Logrotate’in nasıl çalıştığını görmek için /etc/cron.daily/logrotate dosyasına göz atabilirsiniz. Bu betik, ana yapılandırma dosyası olan /etc/logrotate.conf dosyasını ve /etc/logrotate.d/ dizini altındaki tüm servis özelindeki yapılandırmaları okuyarak çalışır.

# Logrotate yapılandırmasını manuel ve test amaçlı çalıştırmak için:
logrotate -d /etc/logrotate.conf

-d parametresi debug modunu açar. Bu komut dosyaları gerçekten döndürmez, ancak yapılandırmanızda bir hata olup olmadığını adım adım görmenizi sağlar. Canlı ortamlarda yeni bir kural yazdıktan sonra mutlaka bu komutla test etmelisiniz.

Logrotate Yapılandırma Dosyalarının Anatomisi

Ana yapılandırma dosyası /etc/logrotate.conf genel varsayılanları belirler. Ancak en iyi pratik, her uygulama veya servis için /etc/logrotate.d/ dizini altında ayrı bir konfigürasyon dosyası oluşturmaktır.

Tipik bir Nginx logrotate yapılandırması şu şekildedir:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

Bu yapılandırmadaki her bir direktifin ne anlama geldiğini yakından inceleyelim:

daily: Log dosyalarının her gün döndürülmesini sağlar. Diğer seçenekler weekly, monthly veya yearly olabilir.
missingok: Log dosyası bulunamazsa hata vermez, sessizce sonraki dosyaya geçer. Özellikle silinmiş log dosyaları için hayat kurtarır.
rotate 14: Eski log dosyalarından kaç tanesinin saklanacağını belirtir. 14 seçilirse, 14 günlük log saklanır, 15. günün sonunda en eski log silinir.
compress: Döndürülen eski log dosyalarının sıkıştırılmasını (gzip formatında) sağlar.
delaycompress: Sıkıştırma işlemini bir sonraki döndürme döngüsüne erteler. Büyük log dosyalarında anlık I/O yükünü azaltmak için kritiktir. Örneğin, bugün dönen log hemen sıkıştırılmaz, yarınki rotasyonda sıkıştırılır.
notifempty: Log dosyası boşsa döndürme işlemini pas geçer.
create 0640 www-data adm: Yeni oluşturulacak log dosyasının izinlerini (0640), sahibi (www-data) ve grubunu (adm) belirler.
sharedscripts: Betiklerin (postrotate/prerotate) her dosya için ayrı ayrı değil, eşleşen tüm dosyalar için toplu olarak bir kez çalıştırılmasını sağlar.
postrotate ... endscript: Log dosyası döndürüldükten sonra çalıştırılacak komutları içerir. Nginx örneğinde, yeni log dosyasına yazmaya devam edebilmesi için süreç yeniden başlatılmadan sinyal (USR1) gönderilir.

Sahada Sık Yapılan Hatalar ve Çözümleri

Logrotate yapılandırmak ilk bakışta kolay görünse de, üretim ortamlarında yapılan bazı küçük ihmaller büyük kesintilere yol açabilir.

1. Log Dosyalarının Kilidinin Kopması (File Descriptor Issue)

En yaygın hata, log dosyası logrotate tarafından taşındıktan veya yeniden adlandırıldıktan sonra, çalışan uygulamanın hâlâ eski dosya tanımlayıcısına (file descriptor) yazmaya devam etmesidir. Uygulama, yeni oluşturulan boş dosyayı görmez ve disk alanı boşalmaz çünkü süreç eski dosyaya veri yazmayı sürdürür.

Çözüm: Mutlaka postrotate bloğu kullanarak ilgili servise sinyal göndermeli veya servisi yeniden başlatmalısınız.

Nginx için: kill -USR1 $(cat /var/run/nginx.pid)
Systemd servisleri için: systemctl reload my-app.service

2. Yanlış Dosya İzinleri (Permissions)

Logrotate yeni bir log dosyası oluşturduğunda (create direktifi ile), dosya izinleri yanlış ayarlanırsa uygulama log dosyasına yazamaz ve çöker veya hata fırlatır.

Çözüm: Üretim ortamında çalışan uygulamanın hangi kullanıcı (user ve group) ile çalıştığını kontrol edin. Örneğin Node.js uygulaması nodejs kullanıcısı ile çalışıyorsa, logrotate yapılandırmasındaki create satırı şu şekilde olmalıdır:

create 0644 app_user app_group

3. Tarih Uzantılarının Çakışması

Varsayılan olarak logrotate, döndürülen dosyalara .1, .2 gibi numaralar verir. Ancak dateext parametresi kullanılırsa, dosyalar access.log-20231024.gz şeklinde tarih uzantısı alır. Bu, log analizi yaparken çok büyük kolaylık sağlar.

dateext
dateformat -%Y%m%d

Ancak dikkat edin; aynı gün içinde birden fazla kez logrotate zorla (-f parametresiyle) çalıştırılırsa dosya adı çakışması yaşanabilir. Bu durumu önlemek için dateext kullanırken date=-\%Y-\%m-\%d-%s gibi saniye bazlı uzantılar tercih edilebilir.

Adım Adım Özel Bir Uygulama İçin Logrotate Senaryosu

Şirketinizde /var/log/custom-app/ dizini altında log yazan özel bir Python veya Node.js uygulamanız olduğunu varsayalım. Bu uygulama için sıfırdan güvenli bir Logrotate kuralı yazalım.

/etc/logrotate.d/custom-app dosyasını oluşturun:

sudo nano /etc/logrotate.d/custom-app

İçerisine aşağıdaki yapılandırmayı ekleyin:

/var/log/custom-app/*.log {
    daily
    rotate 30
    size 100M
    compress
    delaycompress
    missingok
    notifempty
    create 0660 appuser adm
    sharedscripts
    postrotate
        systemctl restart custom-app.service > /dev/null 2>&1 || true
    endscript
}

Bu yapılandırmadaki ek bir detay size 100M direktifidir. Bu direktif, günlük döngü saatini beklemeden, log dosyası 100 Megabayt boyutuna ulaştığı anda anında rotasyon yapılmasını tetikler. Yüksek trafikli sistemlerde disk doluluğunu önlemek için en etkili silahlardan biridir.

Yapılandırmanın geçerliliğini test edin:

sudo logrotate -f /etc/logrotate.d/custom-app

-f (force) parametresi, şartlar ne olursa olsun logrotate işlemini zorla hemen gerçekleştirir. Test aşamasında dosyaların doğru sıkıştırılıp sıkıştırılmadığını ve servisinizin sorunsuz yeniden başlayıp başlamadığını bu komutla doğrulayabilirsiniz.

Log Yönetiminde En İyi Pratikler

Disk İzleme (Monitoring): Logrotate hayat kurtarır ancak tek başına bir izleme stratejisi değildir. Disk doluluk oranları için mutlaka Prometheus/Grafana, Zabbix veya basit bir shell betiği ile uyarı mekanizmaları kurun (Örn: Disk %85’i geçerse alarm ver).
Saklama Süreleri (Retention): Yasal zorunluluklar veya güvenlik denetimleri (audit) yoksa logları sınırsız süre saklamayın. Çoğu web uygulaması için 14 ila 30 günlük log geçmişi fazlasıyla yeterlidir.
Merkezi Loglama: Eğer birden fazla sunucu yönetiyorsanız, logları sadece yerel diskte tutmak yerine Fluentd, Logstash, Loki veya Graylog gibi merkezi sistemlere aktarmayı, sunucu üzerindeki logları ise kısa sürede temizlemeyi düşünün.

Logrotate, doğru yapılandırıldığında sistem yöneticisinin en sessiz ve en güvenilir yardımcılarından biridir. Doğru parametreler, düzenli testler ve uygun izin yönetimi ile disk doluluğu kaynaklı gece yarısı acil durum çağrılarını tamamen ortadan kaldırabilirsiniz.

Bu yazı Gemini ile otomatik oluşturulmuştur.