Linux Sunucularda Logrotate ile Log Dosyası Yönetimi

Son Güncelleme: Eylül 2026

Logrotate, Linux sunucularda büyüyen log dosyalarını otomatik olarak döndürmek, sıkıştırmak, silmek ve arşivlemek için kullanılan temel bir log yönetimi aracıdır. Özellikle hosting, VPS, VDS ve kiralık sunucu ortamlarında disk alanını korumak, servis sürekliliğini sağlamak ve güvenlik kayıtlarını düzenli tutmak için doğru yapılandırılması gerekir.

İçindekiler

• Logrotate Nedir?
• Log Dosyası Yönetimi Neden Önemlidir?
• Logrotate Nasıl Çalışır?
• Temel Yapılandırma Dosyaları
• Örnek Logrotate Kuralları
• Web Sunucularında Logrotate Kullanımı
• Güvenlik ve Dosya İzinleri
• Test ve Sorun Giderme
• En İyi Uygulamalar
• Sıkça Sorulan Sorular
• Sonuç

Logrotate Nedir?

Logrotate, Linux sistemlerde log dosyalarının belirli kurallara göre otomatik yönetilmesini sağlayan bir yardımcı programdır. Log dosyaları, işletim sistemi, web sunucusu, veritabanı, güvenlik servisi, kontrol paneli ve uygulamalar tarafından sürekli üretilen kayıt dosyalarıdır. Bu dosyalar sistemde neler olduğunu anlamak için çok değerlidir; ancak kontrol edilmezse kısa sürede disk alanını tüketebilir.

Logrotate, büyüyen bir log dosyasını yeniden adlandırır, yeni ve boş bir log dosyası oluşturur, eski logları sıkıştırır ve belirli sayıda eski kopyayı sakladıktan sonra otomatik olarak siler. Bu işleme log rotasyonu veya log döndürme denir. Örneğin /var/log/nginx/access.log dosyası günlük olarak access.log.1, sonra access.log.2.gz gibi arşivlenebilir.

Bu araç; paylaşımlı hosting altyapılarında, Sanal Sunucu ortamlarında, Kiralık Sunucu sistemlerinde ve yüksek trafikli web uygulamalarında kritik bir rol oynar. Çünkü log dosyaları sadece performans açısından değil, olay inceleme, saldırı tespiti ve hata ayıklama açısından da gereklidir.

Log Dosyası Yönetimi Neden Önemlidir?

Log dosyaları sunucunun hafızası gibidir. Bir ziyaretçi isteği, hatalı PHP betiği, başarısız SSH giriş denemesi, veritabanı bağlantı problemi veya web sunucusu hatası loglara yazılır. Fakat bu kayıtlar düzenlenmezse, faydalı bir kaynak olmaktan çıkarak disk doluluğu, performans düşüşü ve servis kesintisi gibi sorunlara neden olabilir.

• Disk alanı kontrolü: Büyük log dosyaları özellikle küçük diskli VPS planlarında sistemi kullanılamaz hale getirebilir.
• Performansın korunması: Çok büyük log dosyalarında okuma, arama ve analiz işlemleri yavaşlar.
• Güvenlik incelemesi: Düzenli arşivlenen loglar, brute force, zararlı trafik ve yetkisiz erişim denemelerinin geriye dönük analizini kolaylaştırır.
• Uyumluluk ihtiyacı: Bazı sektörlerde belirli kayıtların belirli süre saklanması gerekir. Logrotate bu saklama politikasını teknik olarak uygulamaya yardımcı olur.
• Servis sürekliliği: Disk tamamen dolduğunda MySQL, PostgreSQL, Nginx, Apache veya mail servisleri yazma işlemi yapamayabilir.

Örneğin yoğun trafik alan bir e-ticaret sitesinde web erişim logları günde birkaç gigabayta ulaşabilir. Eğer bu loglar sıkıştırılmaz ve belirli süre sonunda silinmezse, sunucu diskinde ani doluluk meydana gelir. Disk dolduğunda oturum dosyaları yazılamaz, veritabanı geçici dosyaları oluşturulamaz ve web sitesi 500 veya 503 hataları vermeye başlayabilir.

Logrotate Nasıl Çalışır?

Logrotate genellikle sistem zamanlayıcısı ile çalışır. Modern Linux dağıtımlarında bu işlem çoğunlukla systemd timer veya cron üzerinden tetiklenir. Logrotate çalıştığında ana yapılandırma dosyasını ve ek kural dosyalarını okur, ardından her log dosyası için belirlenmiş politikalara göre işlem yapar.

Temel çalışma adımları şu şekildedir:

1. Yapılandırmayı okur: /etc/logrotate.conf ve /etc/logrotate.d/ dizinindeki kuralları inceler.
2. Durum dosyasını kontrol eder: Son rotasyon zamanını takip etmek için genellikle /var/lib/logrotate/status dosyasını kullanır.
3. Koşulları değerlendirir: Dosya boyutu, tarih, eksik dosya, boş dosya ve saklama sayısı gibi kriterleri kontrol eder.
4. Rotasyon uygular: Eski log dosyasını yeniden adlandırır ve gerekiyorsa yeni log dosyası oluşturur.
5. Servise sinyal gönderir: Bazı servislerin yeni log dosyasına yazmaya başlaması için yeniden yüklenmesi gerekir.
6. Sıkıştırma ve silme yapar: Eski logları gzip gibi araçlarla sıkıştırır ve saklama limitini aşanları siler.

Logrotate, doğrudan servislerin içeriğini değiştirmez; sadece dosya yönetimi yapar. Bu nedenle bazı servislerde postrotate bloğu ile servis yeniden yükleme komutu eklemek gerekir. Aksi halde servis eski dosya tanıtıcısına yazmaya devam edebilir ve yeni oluşturulan log dosyası boş kalabilir.

Temel Yapılandırma Dosyaları

Logrotate yapılandırması iki ana yerde tutulur. Genel ayarlar /etc/logrotate.conf dosyasında, servis bazlı özel kurallar ise /etc/logrotate.d/ dizininde yer alır. Paket yöneticisi ile kurulan Nginx, Apache, MySQL, PHP-FPM veya sistem servisleri genellikle bu dizine kendi kural dosyalarını ekler.

Temel bir kural bloğu şu yapıdadır:

/var/log/ornek-uygulama/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
}

Bu örnekte /var/log/ornek-uygulama/ dizinindeki .log uzantılı dosyalar günlük olarak döndürülür, 14 kopya saklanır, eski dosyalar sıkıştırılır ve yeni dosya 0640 izinleriyle oluşturulur.

Örnek Logrotate Kuralları

Logrotate yapılandırmasında kullanılan direktifleri doğru anlamak, güvenli ve öngörülebilir bir log yönetimi için önemlidir. Aşağıdaki direktifler en sık kullanılan seçeneklerdir.

• daily, weekly, monthly: Rotasyonun günlük, haftalık veya aylık yapılacağını belirtir.
• rotate: Kaç eski log dosyasının saklanacağını belirler. Örneğin rotate 30 otuz arşiv kopyası tutar.
• size: Dosya belirli boyuta ulaşınca rotasyon yapılmasını sağlar. Örneğin size 100M.
• compress: Eski log dosyalarını sıkıştırır ve disk tasarrufu sağlar.
• delaycompress: En son döndürülen dosyanın bir sonraki çalıştırmaya kadar sıkıştırılmasını erteler.
• missingok: Log dosyası yoksa hata üretmeden devam edilmesini sağlar.
• notifempty: Boş log dosyalarının döndürülmesini engeller.
• create: Rotasyon sonrası yeni log dosyasının izin, kullanıcı ve grup bilgilerini tanımlar.
• copytruncate: Dosyayı kopyalayıp mevcut dosyayı sıfırlar. Servisi yeniden başlatmanın mümkün olmadığı durumlarda kullanılır.
• postrotate: Rotasyon sonrasında çalıştırılacak komutları belirtir.

Özel bir uygulama için boyuta dayalı rotasyon örneği:

/var/log/myapp/app.log {
    size 200M
    rotate 10
    compress
    missingok
    notifempty
    create 0640 myapp myapp
    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

Bu yapı, özellikle yoğun yazma yapan Node.js, Laravel, Python veya Go tabanlı uygulamalar için kullanışlıdır. Dosya 200 MB boyuta ulaştığında rotasyon tetiklenir. Rotasyon sonrası uygulama servisi yeniden yüklenir ve yeni log dosyasına yazmaya başlaması sağlanır.

Web Sunucularında Logrotate Kullanımı

Web sunucuları log üretimi açısından en yoğun servisler arasındadır. Nginx ve Apache, her HTTP isteği için erişim logu ve hatalar için hata logu oluşturabilir. Trafiği yüksek olan bir Linux Hosting altyapısında veya uygulama barındıran bir Türkiye VDS Sunucu üzerinde bu logların kontrolsüz büyümesi ciddi disk sorunlarına yol açabilir.

Nginx için örnek yapılandırma

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

Nginx için USR1 sinyali yaygın olarak kullanılır. Bu sinyal, Nginx ana sürecine log dosyalarını yeniden açmasını söyler. Böylece servis tamamen durdurulmadan yeni log dosyasına yazma işlemi devam eder.

Apache için örnek yapılandırma

/var/log/apache2/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        systemctl reload apache2 >/dev/null 2>&1 || true
    endscript
}

Apache tarafında çoğu senaryoda systemctl reload apache2 komutu yeterlidir. Bu komut aktif bağlantıları kesmeden yapılandırmayı yeniden yüklemeyi ve log dosyalarının yeniden açılmasını sağlar.

Web sunucularında erişim logları ile hata logları için farklı saklama politikaları belirlemek de mümkündür. Örneğin hata loglarını 30 gün, erişim loglarını 7 gün saklamak disk alanını daha verimli kullanmayı sağlar. Güvenlik ve trafik analizi yapılıyorsa erişim loglarının merkezi bir log sistemine aktarılması da düşünülebilir.

Güvenlik ve Dosya İzinleri

Log dosyaları çoğu zaman hassas bilgiler içerebilir. IP adresleri, kullanıcı ajanları, oturum hataları, dosya yolları, başarısız giriş denemeleri ve uygulama hata mesajları loglarda bulunabilir. Bu nedenle Logrotate sadece disk temizliği aracı olarak değil, aynı zamanda güvenli kayıt yönetimi mekanizması olarak değerlendirilmelidir.

• Doğru sahiplik: Log dosyaları ilgili servis kullanıcısı ve uygun grup tarafından erişilebilir olmalıdır.
• Sınırlı okuma izni: Her kullanıcının log okuyabilmesi bilgi sızıntısına neden olabilir. 0640 genellikle daha güvenli bir tercihtir.
• Yetkisiz yazma engeli: Log dizinlerine herkesin yazabilmesi log zehirleme ve disk doldurma riskini artırır.
• Sıkıştırılmış arşiv güvenliği: Eski logların izinleri de yeni dosyalar kadar önemlidir.
• Merkezi yedekleme: Kritik loglar yalnızca aynı diskte tutulmamalı, gerekiyorsa Yedekleme Hizmeti ile korunmalıdır.

create direktifi bu noktada kritik öneme sahiptir. Yanlış kullanıcı veya izin tanımı, servisin yeni log dosyasına yazamamasına neden olabilir. Örneğin Nginx loglarının www-data veya dağıtıma göre ilgili servis kullanıcısı tarafından erişilebilir olması gerekir. Ancak bu dosyaların tüm sistem kullanıcıları tarafından okunabilir olması güvenli değildir.

Ayrıca bazı uygulamalar log dosyalarını kendi içinde açıp uzun süre açık tutar. Bu durumda yalnızca dosyanın adını değiştirmek yeterli olmayabilir. Uygulamanın yeniden yüklenmesi, sinyal alması veya copytruncate kullanılması gerekebilir. Ancak copytruncate kısa bir zaman aralığında log kaybı riski taşıyabileceği için dikkatli kullanılmalıdır.

Test ve Sorun Giderme

Logrotate kurallarını canlı ortamda uygulamadan önce test etmek gerekir. Yanlış bir kural, beklenmedik log silinmesine, servislerin log yazamamasına veya disk doluluğunun devam etmesine neden olabilir. Bu nedenle önce hata ayıklama modunda çalıştırma yapılmalıdır.

Bir kural dosyasını test etmek için:

logrotate -d /etc/logrotate.d/myapp

-d parametresi hata ayıklama modudur; işlem gerçekten uygulanmaz, sadece ne yapılacağı gösterilir. Zorla rotasyon testi için:

logrotate -f /etc/logrotate.d/myapp

Genel yapılandırmayı test etmek için:

logrotate -d /etc/logrotate.conf

Logrotate çalışıyor mu kontrol etmek için sistem zamanlayıcısı incelenebilir:

systemctl status logrotate.timer

Yaygın sorunlar ve çözümleri şunlardır:

Test sırasında dikkat edilmesi gereken bir diğer nokta, aynı log dosyası için birden fazla kural tanımlamamaktır. Logrotate aynı dosyayı iki farklı kural içinde görürse hata verebilir veya beklenmeyen davranışlar oluşabilir.

En İyi Uygulamalar

Sağlıklı bir log yönetimi için tek bir standart her sunucuya uymaz. Web sitesi trafiği, uygulama mimarisi, disk kapasitesi, güvenlik gereksinimi ve analiz ihtiyaçları birlikte değerlendirilmelidir. Ancak birçok Linux sunucu için uygulanabilecek genel iyi uygulamalar vardır.

• Servis bazlı ayrı politika kullanın: Web erişim logu, hata logu, uygulama logu ve güvenlik logu aynı saklama süresine sahip olmak zorunda değildir.
• Sıkıştırmayı aktif edin: compress çoğu senaryoda ciddi disk tasarrufu sağlar.
• Boş dosyaları döndürmeyin: notifempty gereksiz arşiv oluşumunu engeller.
• Eksik dosyada hata üretmeyin: Dinamik oluşan uygulama logları için missingok kullanın.
• İzinleri açık bırakmayın: 0644 yerine mümkünse 0640 tercih edin.
• Disk kullanımını izleyin: Logrotate tek başına izleme aracı değildir; disk doluluğu ayrıca takip edilmelidir.
• Merkezi loglama düşünün: Kritik sistemlerde loglar ayrı bir sunucuya veya log yönetim platformuna gönderilmelidir.
• Yedekleme politikasını unutmayın: Güvenlik ve denetim açısından önemli logları yalnızca yerel diskte tutmak yeterli olmayabilir.

Küçük bir kurumsal web sitesi için günlük rotasyon ve 14 günlük saklama yeterli olabilir. Ancak ödeme altyapısı, kullanıcı hesabı veya kritik yönetim paneli barındıran sistemlerde hata ve erişim loglarının daha uzun süre saklanması gerekebilir. Bu noktada disk kapasitesi ve yedekleme stratejisi birlikte planlanmalıdır.

Sunucu kaynakları sınırlıysa Türkiye VPS Sunucu planlarında log saklama süresi daha dikkatli belirlenmelidir. Daha yüksek disk I/O, özel kaynak ve geniş depolama ihtiyacı olan projelerde ise Türkiye Kiralık Sunucu seçenekleri daha esnek bir altyapı sağlayabilir.

Sıkça Sorulan Sorular

Sonuç

Logrotate, Linux sunucularda düzenli, güvenli ve sürdürülebilir log yönetimi için vazgeçilmez bir araçtır. Doğru yapılandırıldığında disk alanını korur, servis kesintisi riskini azaltır, güvenlik incelemelerini kolaylaştırır ve uygulama loglarının daha yönetilebilir olmasını sağlar.

Başarılı bir Logrotate yapılandırması için servislerin log yazma davranışı, dosya izinleri, saklama süresi, sıkıştırma ihtiyacı ve yedekleme politikası birlikte değerlendirilmelidir. Web sunucuları, uygulama servisleri ve sistem logları için ayrı kurallar oluşturmak hem performans hem de güvenlik açısından daha doğru bir yaklaşımdır.

Corelux altyapısında projenizin ihtiyacına göre Hosting, Sanal Sunucu, Kiralık Sunucu ve Yedekleme Hizmeti seçeneklerini değerlendirebilirsiniz. Düzenli log yönetimi, doğru sunucu seçimi ve güvenli yedekleme stratejisi bir araya geldiğinde daha kararlı, izlenebilir ve güvenli bir web altyapısı elde edilir.