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

Linux sunucularla çalışan herkesin hayatının bir döneminde karşılaştığı klasik bir kriz vardır: No space left on device hatası. Servisler durur, veritabanları yazamaz hale gelir ve sistem yöneticisi olarak ilk refleksimiz df -h komutunu çalıştırmak olur. Çoğu zaman suçlu bellidir: /var/log dizini altındaki devasa log dosyaları. Uygulamalarımız çalıştıkça hata, erişim ve işlem logları üretir. Bu loglar zamanla gigabaytlarca hatta terabaytlarca boyuta ulaşabilir. Peki, bu verileri tamamen silmeden veya sistem performansını düşürmeden nasıl yönetebiliriz?

İşte bu noktada Linux ekosisteminin en sadık ama en az değer gören araçlarından biri devreye girer: Logrotate. Bu yazıda, logrotate aracının nasıl çalıştığını, konfigürasyon dosyalarının mantığını, günlük operasyonlarda sıkça kullanılan direktifleri ve sahada karşılaşılan pratik senaryoları ele alacağız.

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

Logrotate, Linux sistemlerde log dosyalarının rotasyonunu (döndürülmesini), sıkıştırılmasını, silinmesini ve e-posta ile gönderilmesini otomatikleştiren bir sistem aracıdır. Temel amacı, log dosyalarının kontrolsüz bir şekilde büyüyerek disk alanını tüketmesini engellemek ve eski logların arşivlenmesini sağlamaktır.

Logrotate genellikle doğrudan bir daemon (arka plan servisi) olarak çalışmaz. Bunun yerine, sistemdeki cron mekanizması (genellikle /etc/cron.daily/logrotate altında bulunur) vasıtasıyla günde bir kez tetiklenir. Çalıştığı anda /etc/logrotate.conf ana yapılandırma dosyasını ve /etc/logrotate.d/ dizini altındaki uygulama özelindeki konfigürasyon dosyalarını okur. Hangi log dosyasının ne zaman döneceğine bu dosyalardaki kurallara göre karar verir.

Log Rotasyonu Ne Anlama Gelir?

“Log rotasyonu” terimi, aktif olarak yazılan log dosyasının yeniden adlandırılması, yeni ve boş bir log dosyasının oluşturulması ve eski logların belirli bir politikaya göre arşivlenmesi sürecini ifade eder. Örneğin, app.log dosyası rotasyona girdiğinde şu adımlar izlenir:

Mevcut app.log dosyası app.log.1 olarak yeniden adlandırılır.
Uygulama hâlâ eski dosya tanımlayıcısına (file descriptor) yazmaya devam ediyor olabilir, bu nedenle logrotate servise sinyal göndererek yeni log dosyasına yazmasını söyler.
Eski app.log.1 dosyası gzip gibi araçlarla sıkıştırılarak app.log.1.gz haline getirilebilir.
Belirlenen saklama süresi (retention) dolan eski loglar sistemden kalıcı olarak silinir.

Logrotate Konfigürasyon Dosyalarının Yapısı

Logrotate yapılandırması oldukça sezgiseldir ancak yanlış yapılan bir ayar, logların kaybolmasına veya uygulamaların log yazamamasına neden olabilir. Ana konfigürasyon dosyası /etc/logrotate.conf’tur. Ancak en iyi pratik, sistem genelindeki ayarları bu dosyada tutmak, özel uygulamaların log kurallarını ise /etc/logrotate.d/ dizini altına ayrı dosyalar olarak yazmaktı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 direktifin ne anlama geldiğini detaylıca inceleyelim:

Temel Direktifler ve Anlamları

daily, weekly, monthly, yearly: Logların hangi sıklıkla döndürüleceğini belirler. Günlük, haftalık, aylık veya yıllık seçenekleri mevcuttur.
rotate <sayı>: Saklanacak maksimum eski log dosyası sayısını belirler. Örneğin rotate 14 ayarı, sistemde en fazla 14 adet eski log dosyası tutulacağını, 15. dosya oluşturulduğunda en eskisinin silineceğini ifade eder.
compress: Eski log dosyalarının sıkıştırılmasını (varsayılan olarak gzip ile) sağlar. Disk tasarrufu açısından kritik öneme sahiptir.
delaycompress: Sıkıştırma işlemini bir sonraki rotasyon döngüsüne erteler. Genellikle compress ile birlikte kullanılır. Amacı, logrotate çalıştıktan hemen sonra log dosyasına yazmaya devam eden aktif süreçlerin sıkıştırılmamış dosyaya yazmasını engellemek ve olası kilitlenmelerin önüne geçmektir.
missingok: Rotasyonu yapılacak log dosyası bulunamazsa (örneğin dosya silinmişse veya hiç oluşturulmamışsa) hata vermez ve sessizce sonraki dosyaya geçer.
notifempty: Log dosyası boşsa (boyutu 0 bayt ise) rotasyon yapılmaz.
create <mod> <kullanıcı> <grup>: Rotasyon sonrasında hemen yeni ve boş bir log dosyasının hangi izinler ve sahiplik bilgileriyle oluşturulacağını belirler. (Örn: create 0640 nginx adm). Bu ayar, uygulamanın yeni log dosyasına yazmaya devam edebilmesi için yetki sorunları yaşamaması adına hayati önem taşır.
sharedscripts: Birden fazla log dosyası tek bir blokta tanımlandıysa (/var/log/nginx/*.log gibi), postrotate betiğinin her bir dosya için ayrı ayrı değil, tüm dosyalar işlendikten sonra bir kez çalıştırılmasını sağlar.

Log Rotasyonu Sırasında Uygulama Süreçleri: `postrotate` ve `copytruncate`

Log yönetimi yaparken karşılaşılan en büyük teknik zorluklardan biri, çalışan bir uygulamanın açık olan dosya işaretçisini (file descriptor) koparmaktır. Siz log dosyasını yeniden adlandırdığınızda, uygulama hâlâ eski dosya yoluna (artık adı değişmiş olan dosyaya) yazmaya devam edebilir. Bu sorunu çözmek için iki temel yaklaşım vardır.

1. Sinyal Gönderme (`postrotate`) En İyi Yöntem

Yukarıdaki Nginx örneğinde gördüğümüz yöntem budur. Log dosyası taşındıktan sonra uygulamaya bir sinyal (SIGUSR1 gibi) gönderilerek log dosyasını kapatıp yeniden açması söylenir.

postrotate
    [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript

Bu yöntem en güvenlisidir çünkü log kaybı yaşanmaz. Ancak uygulamanın bu sinyali destekliyor olması gerekir (Nginx, Apache, Rsyslog gibi birçok kurumsal yazılım bunu destekler).

2. `copytruncate` Yöntemi

Bazı uygulamalar sinyal alarak log dosyalarını yeniden açma yeteneğine sahip değildir veya bu özelliği yapılandırmak zordur. Bu gibi durumlarda copytruncate direktifi kullanılır.

/var/log/custom-app/app.log {
    daily
    rotate 7
    copytruncate
    compress
}

copytruncate mantığı şu şekilde çalışır:

Logrotate önce mevcut log dosyasının içeriğini olduğu gibi kopyalar.
Ardından orijinal log dosyasının içini boşaltır (truncate eder, boyutu 0 yapar).

Avantajı: Uygulamayı yeniden başlatmaya veya sinyal göndermeye gerek kalmaz. Dezavantajı: Kopyalama işlemi ile sıfırlama işlemi arasında geçen çok kısa bir süre zarfında uygulamadan gelen loglar kaybolabilir. Ayrıca çok büyük log dosyalarında kopyalama işlemi Disk I/O yükünü artırabilir.

Özel Bir Senaryo: Kendi Uygulamanız İçin Logrotate Yapılandırması

Diyelim ki sunucunuzda /opt/my-app/logs/app.log yoluna log yazan özel bir Python veya Node.js servisiniz var. Bu servis standart logrotate paketleri tarafından otomatik olarak yönetilmez. Bu durumda kendi konfigürasyon dosyamızı oluşturmalıyız.

/etc/logrotate.d/my-app adında bir dosya oluşturun:

/opt/my-app/logs/*.log {
    weekly
    rotate 8
    size 100M
    compress
    delaycompress
    missingok
    notifempty
    create 0660 appuser appgroup
    copytruncate
}

Bu konfigürasyondaki yeni parametreye dikkat edin: size 100M. Bu ayar, zaman bağımsız olarak log dosyası 100 Megabayt boyutuna ulaştığı an rotasyon yapılmasını tetikler. Haftalık kural ile birleştirildiğinde, log dosyası 100 MB’ı geçerse hemen, geçmezse haftada bir kez dönecektir.

Logrotate Test Etme ve Sorun Giderme

Yeni bir logrotate kuralı yazdığınızda bunun doğru çalışıp çalışmadığını sistemin cron tetiklemesini bekleyerek test etmek verimsizdir. Logrotate aracı, konfigürasyon hatalarını kontrol etmek ve simülasyon yapmak için harika parametreler sunar.

Kuru Sıkı Test (`--debug` veya `-d`)

Konfigürasyonunuzu test etmek için -d parametresini kullanabilirsiniz:

sudo logrotate -d /etc/logrotate.d/my-app

Bu komut dosyayı gerçekten döndürmez, ancak logrotate’in adımlarını simüle ederek ekrana detaylı bir çıktı verir. Yazım hatalarını, dosya yolu problemlerini bu çıktı üzerinden rahatlıkla görebilirsiniz.

Zorla Çalıştırma (`--force` veya `-f`)

Eğer logrotate kurallarınız doğru görünmesine rağmen dosyalar dönmüyorsa (çünkü henüz zamanı gelmemiş olabilir), zorlama parametresini kullanabilirsiniz:

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

-f parametresi, koşullara bakılmaksızın logrotate işlemini hemen zorla gerçekleştirir. Yapılandırma sonrası test etmek için en pratik yoldur.

Durum Dosyası (State File)

Logrotate, hangi log dosyasının en son ne zaman döndürüldüğünü hafızasında tutmak için /var/lib/logrotate/status dosyasını kullanır. Eğer logrotate mantıksız bir şekilde “bu dosyayı daha dün döndürdüm, şimdi dokunmayacağım” diyorsa, bu durum dosyasını inceleyebilir veya test amaçlı geçici olarak silebilirsiniz (dikkatli kullanılmalıdır).

Sık Yapılan Hatalar ve En İyi Pratikler

Yanlış Dosya İzinleri (create direktifi): Logrotate log dosyasını sıfırdan oluştururken yanlış kullanıcı yetkileri verirse, uygulamanız log yazamaz hale gelir ve hata fırlatır. Her zaman uygulamanın çalıştığı kullanıcı ve grup bilgilerini create direktifine doğru tanımlayın.
Aşırı Agresif rotate Değerleri: Sınırsız log saklamak disk kapasitesini tüketir. İş gereksinimlerinize uygun (örneğin 30 gün veya 12 hafta) bir saklama politikası belirleyin.
Logrotate Servis Çakışmaları: Aynı log dosyası için birden fazla konfigürasyon dosyası yazmaktan kaçının. Bu durum logların iki kez döndürülmeye çalışılmasına ve dosya kilitlenme hatalarına yol açar.
Log İzleme Araçları ile Uyum: Eğer sisteminizde Fluentd, Filebeat, Promtail gibi log toplama ajanları çalışıyorsa, log rotasyonu sırasında dosya yollarının ani değişimi bu ajanların log kaçırmasına neden olabilir. Bu gibi durumlarda copytruncate veya doğru sinyal yönetimleri hayati önem taşır.

Sonuç

Logrotate, Linux sistem yönetiminin en temel ama en kritik yapı taşlarından biridir. Doğru yapılandırılmamış bir log yönetimi, en güçlü sunucuları bile birkaç hafta içinde disk doluluğu nedeniyle erişilemez duruma getirebilir. postrotate sinyalleri, copytruncate stratejileri ve doğru saklama politikaları ile sisteminizin sağlığını güvence altına alabilir, olası disk krizlerinin önüne geçebilirsiniz.

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