Skip to content
Bloga dön
Rehber Linux Logrotate Sistem Yönetimi DevOps Log Yönetimi

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

Linux sunucularda disk doluluğu kaynaklı kesintileri önlemek için logrotate aracının detaylı yapılandırılması, pratik senaryolar ve üretim ortamı en iyi uygulamaları.

Caner Serbest

Sistem ve Altyapı

5 dk okuma

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, gece yarısı gelen “disk alanı tükendi” (Disk Full) alarmıdır. Çoğu zaman bu durumun sebebi, günlerce, aylarca hatta yıllarca sınır tanımadan büyüyen log dosyalarıdır. Uygulamalarınız çalıştığı sürece konsola veya dosyalara çıktı üretir. Bu çıktılar bir süre sonra gigabaytlarca hatta terabaytlarca boyuta ulaşarak kök dizini (/) veya /var bölümünü tamamen doldurabilir. Disk dolduğunda ise veritabanları yazma işlemlerini durdurur, servisler çöker ve kullanıcılar sisteminize erişemez hale gelir.

Linux dünyasında bu kaosun önüne geçmek için standart olarak kullanılan araç logrotate’dir. Bu yazıda, logrotate aracının nasıl çalıştığını, temel ve gelişmiş yapılandırma parametrelerini, üretim ortamında sık yapılan hataları ve adım adım pratik bir senaryoyu ele alacağız.


Logrotate Nasıl Çalışır?

Logrotate, Linux işletim sistemlerinde log dosyalarının boyutunu veya yaşını yönetmek, sıkıştırmak (compress), silmek ve e-posta ile göndermek için tasarlanmış bir sistem aracıdır. Genellikle cron (çoğunlukla /etc/cron.daily/logrotate yoluyla) aracılığıyla günde bir kez otomatik olarak çalıştırılır.

Çalışma mantığı temel olarak şu adımlardan oluşur:

  1. Rotation (Döndürme): Mevcut log dosyası yeniden adlandırılır (örneğin access.log yerine access.log.1 yapılır).
  2. Creation (Oluşturma): Uygulamanın yazmaya devam edebilmesi için yeni ve boş bir log dosyası oluşturulur.
  3. Compression (Sıkıştırma): Eski log dosyası diskte yer kazanmak için .gz formatında sıkıştırılır.
  4. Cleanup (Temizlik): Belirlenen saklama süresini (retention) aşan eski loglar sistemden silinir.

Bu süreçte en kritik nokta, çalışan uygulamanın yeni log dosyasını nasıl fark edeceği ve eski dosya tıkandığında açık dosya tanımlayıcısının (file descriptor) nasıl güncelleneceğidir.


Temel Yapılandırma Dosyaları ve Yapısı

Logrotate’in ana yapılandırma dosyası /etc/logrotate.conf’tur. Bu dosya sistem genelindeki varsayılan ayarları barındırır. Ancak en iyi pratik, ana dosyayı değiştirmek yerine /etc/logrotate.d/ dizini altında her uygulama veya servis için ayrı bir konfigürasyon dosyası oluşturmaktır.

Örnek bir Nginx logrotate konfigürasyonuna (/etc/logrotate.d/nginx) yakından bakalım:

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

Bu konfigürasyonda yer alan her bir parametrenin ne anlama geldiğini inceleyelim:

  • daily: Logların her gün döndürülmesini sağlar. Diğer seçenekler weekly, monthly veya size şeklindedir.
  • missingok: Log dosyası bulunamazsa hata vermez, sessizce sonraki dosyaya geçer.
  • rotate 14: En fazla 14 adet eski log dosyasının saklanmasını sağlar. 15. günün sonunda en eski log silinir.
  • compress: Döndürülen eski log dosyalarının gzip ile sıkıştırılmasını sağlar.
  • delaycompress: Sıkıştırma işlemini bir sonraki döngüye erteler. Özellikle uygulamanın hemen kapanmadığı ve bir süre daha eski log dosyasına yazmaya devam ettiği durumlarda kritik önem taşır.
  • notifempty: Log dosyası boşsa döndürme işlemi yapmaz.
  • create 0640 nginx adm: Döndürme işleminden hemen sonra yeni bir log dosyası oluşturur. Bu dosyanın izinlerini 0640, sahibini nginx ve grubunu adm yapar.
  • sharedscripts: Belirtilen dizindeki tüm log dosyaları işlendiğinde, postrotate bloğunun tüm liste için sadece bir kez çalıştırılmasını sağlar.
  • postrotate / endscript: Log döndürme işlemi tamamlandıktan sonra çalıştırılacak komutları barındırır. Nginx örneğinde, yeni log dosyasına yazmaya başlaması için süreç sinyali (USR1) gönderilir.

Üretim Ortamında Sık Yapılan Hatalar ve Çözümleri

Logrotate basit görünse de, yanlış yapılandırıldığında uygulamaların log yazmayı durdurmasına veya disklerin dolmaya devam etmesine yol açabilir. Sahada en sık karşılaşılan hatalar şunlardır:

1. copytruncate Direktifinin Bilinçsiz Kullanımı

Bazı uygulamalar, logrotate dosyayı yeniden adlandırdığında (rename) açık olan dosya tanımlayıcısını kaybetmez ve logları eski dosyaya yazmaya devam eder. Bunu çözmek için postrotate ile servisi yeniden başlatmak gerekir. Eğer servisi yeniden başlatamıyorsanız veya bilmiyorsanız, copytruncate direktifi kullanılır:

copytruncate

Bu parametre, mevcut log dosyasının içeriğini yeni dosyaya kopyalar ve ardından orijinal log dosyasını sıfırlar.

  • Risk: Çok büyük log dosyalarında (örneğin 10 GB) kopyalama işlemi sırasında anlık CPU ve I/O yükü artışına neden olabilir. Ayrıca kopyalama ile sıfırlama anı arasında gerçekleşen çok kısa sürede bazı log satırları kaybolabilir.

2. İzin ve Yetki Hataları (Permission Denied)

Logrotate, varsayılan olarak root kullanıcı yetkileriyle çalışır. Eğer create parametresi ile doğru dosya izinlerini ve sahipliğini belirtmezseniz, logrotate yeni oluşturduğu dosyayı root:root olarak bırakacaktır. Uygulama ise root olmayan bir kullanıcıyla çalıştığı için (örneğin www-data veya özel bir servis kullanıcısı) yeni log dosyasına yazamaz ve hata üretir.

3. Zamanlama Çakışmaları ve Cron

Logrotate günlük olarak çalışır, ancak sistem her zaman açık olmayabilir. anacron kullanmayan sunucularda, sunucu gece kapalıysa logrotate o günü atlayabilir. Bu gibi durumlarda log dosyaları beklenenden çok daha büyük boyutlara ulaşabilir. Boyut bazlı (size 100M) yapılandırmaları zaman bazlı yapılandırmalarla birlikte kullanarak bu riski minimize edebilirsiniz.


Adım Adım Özel Bir Uygulama İçin Logrotate Yapılandırması

Farz edelim ki /var/log/myapp/ dizini altında log üreten özel bir Python veya Node.js uygulamanız var. Bu uygulamanın logları app.log dosyasına yazılıyor ve uygulama appuser kullanıcısı tarafından çalıştırılıyor.

Adım 1: Konfigürasyon Dosyası Oluşturma

/etc/logrotate.d/myapp dosyasını metin düzenleyicinizle açın:

sudo nano /etc/logrotate.d/myapp

Adım 2: Kuralları Yazma

Dosyanın içine aşağıdaki yapılandırmayı ekleyin:

/var/log/myapp/*.log {
    size 50M
    rotate 7
    missingok
    compress
    delaycompress
    notifempty
    create 0640 appuser appuser
    copytruncate
}

Bu yapılandırma şunları yapar:

  • Log dosyası 50 Megabayt boyutuna ulaştığında günün hangi saati olduğuna bakılmaksızın döndürme tetiklenir (size 50M).
  • En fazla 7 adet eski log saklanır.
  • Sıkıştırma uygulanır ancak bir sonraki döngüye ertelenir (delaycompress).
  • Yeni dosya appuser kullanıcısı ve grubuyla 0640 yetkileriyle oluşturulur.
  • copytruncate kullanılarak uygulamanın kesintisiz çalışması sağlanır.

Adım 3: Test Etme ve Doğrulama

Logrotate yapılandırmanızı canlıya almadan önce mutlaka manuel olarak test etmelisiniz. -d (debug) parametresi ile hataları görebilir, -f (force) parametresi ile döngüyü zorlayabilirsiniz.

Dry-run (Simülasyon) testi için:

sudo logrotate -d /etc/logrotate.d/myapp

Bu komut dosyayı gerçekten döndürmez, ancak logrotate’in adımlarını ekrana yazdırır. Herhangi bir hata görmezseniz, zorunlu çalıştırma testi yapabilirsiniz:

sudo logrotate -f /etc/logrotate.d/myapp

İşlem sonrasında /var/log/myapp/ dizinini kontrol ederek app.log.1 veya app.log.1.gz dosyasının oluştuğunu doğrulayabilirsiniz.


Log Yönetiminde En İyi Uygulamalar (Best Practices)

  1. Boyut ve Zaman Kombinasyonu: Sadece zamana (daily) bağlı kalmayın. Beklenmeyen trafik patlamalarında disklerin dolmasını engellemek için size parametresini de senaryonuza dahil edin.
  2. İzleme ve Alarm Mekanizmaları: Logrotate disk yönetimini otomatikleştirir, ancak logların boyutu bazen sistemdeki anormal bir hatanın (infinite loop, sürekli hata basma durumu) habercisidir. Disk kullanım oranlarını (df -h) ve log dizinlerinin büyüme hızlarını izleme araçlarıyla takip edin.
  3. Saklama Süresi (Retention) Planlaması: Yasal zorunluluklar veya hata ayıklama gereksinimleri yoksa, logları aylarca saklamayın. Çoğu üretim ortamı için son 14 ila 30 günlük log geçmişi fazlasıyla yeterlidir.
  4. Logrotate Durum Dosyası: Logrotate, hangi dosyanın ne zaman döndürüldüğünü /var/lib/logrotate/status dosyasında saklar. Sorun giderme aşamasında bu dosyayı inceleyerek logrotate’in en son ne zaman çalıştığını kontrol edebilirsiniz.

Sonuç

Logrotate, Linux altyapılarının kararlılığı ve sürdürülebilirliği için vazgeçilmez bir araçtır. Doğru yapılandırılmamış log yönetimi, en güçlü sunucuları bile küçük bir disk doluluk hatası yüzünden erişilemez kılabilir. Uygulamalarınızın loglama alışkanlıklarını analiz ederek, yukarıda ele aldığımız parametreleri sisteminize uyarlamak, gece yarısı sürprizlerinin önüne geçecektir. Unutmayın; iyi bir sistem yöneticisi krizleri çözen değil, krizlerin oluşmasını engelleyendir.


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