Bir sunucuda log dosyaları ilk bakışta yalnızca kayıt tutma amacıyla var gibi görünür. Oysa erişim kayıtları, hata günlükleri, veritabanı logları, güvenlik olayları ve uygulama çıktıları zamanla büyüdüğünde doğrudan disk kullanımını, I/O performansını ve servis kararlılığını etkiler. Log rotasyonu yapılmadığında sorun genellikle bir anda değil, kademeli olarak ortaya çıkar; sayfa açılışları yavaşlar, panel işlemleri gecikir, yedekleme süreleri uzar ve bazı servisler beklenmedik şekilde durabilir.
Log rotasyonu nedir ve neden gereklidir?
Log rotasyonu, büyüyen günlük dosyalarının belirli aralıklarla arşivlenmesi, sıkıştırılması, belirli bir süre saklanması ve eski kayıtların silinmesi işlemidir. Bu işlem sayesinde sunucu hem ihtiyaç duyulan geçmiş kayıtlara erişebilir hem de sınırsız büyüyen dosyaların sistemi tüketmesi engellenir.
Kurumsal bir hosting altyapısında log yönetimi yalnızca düzen konusu değildir; performans, güvenlik ve sürdürülebilir operasyon açısından temel bir bakım adımıdır. Özellikle yoğun trafik alan web sitelerinde access log dosyaları kısa sürede gigabaytlarca boyuta ulaşabilir.
Performans düşüşünün temel nedenleri
Disk alanının kontrolsüz dolması
Log rotasyonu yapılmayan sunucularda en sık görülen sorun disk alanının dolmasıdır. Disk kullanım oranı kritik seviyeye geldiğinde veritabanı geçici dosya oluşturamayabilir, oturum verileri yazılamayabilir veya e-posta kuyruğu sağlıklı çalışmayabilir.
Diskin tamamen dolması beklenmeden önlem almak gerekir. Çünkü birçok servis, disk yüzde 90 seviyesine ulaştığında bile yavaşlamaya başlayabilir. Bu noktada yalnızca büyük dosyayı silmek de her zaman yeterli değildir; açık dosya tanıtıcıları nedeniyle servis yeniden başlatılmadan alan boşalmamış görünebilir.
Disk I/O yükünün artması
Büyük log dosyalarına sürekli veri yazılması disk I/O yükünü artırır. Aynı disk üzerinde web dosyaları, veritabanı ve loglar birlikte çalışıyorsa bu yük kullanıcı deneyimine doğrudan yansır. Özellikle mekanik disk kullanılan eski sistemlerde etki daha belirgindir; SSD kullanılan yapılarda ise sorun daha geç fark edilse de tamamen ortadan kalkmaz.
Log dosyaları büyüdükçe analiz, arama ve hata ayıklama işlemleri de yavaşlar. Basit bir hata satırını bulmak için büyük dosyaların taranması CPU ve bellek tüketimini artırabilir.
Servislerin log yazamaması
Bazı uygulamalar log yazamadığında çalışmaya devam eder, bazıları ise hata üretir veya tamamen durabilir. Web sunucusu, güvenlik duvarı, veritabanı ya da uygulama servisleri için log yazma yetkisi ve kullanılabilir alan kritik önemdedir.
Bu nedenle “loglar sadece takip içindir” düşüncesi eksiktir. Log altyapısı bozulduğunda olay takibi zorlaşır, güvenlik ihlallerinin izleri kaybolur ve teknik ekip sorunun kaynağını belirlemekte daha fazla zaman harcar.
Yanlış müdahaleler performans sorununu büyütebilir
Performans düştüğünde yapılan en yaygın hatalardan biri büyük log dosyasını doğrudan silmektir. Eğer ilgili servis dosyayı hâlâ açık tutuyorsa, dosya dizinden kaybolsa bile disk alanı hemen geri gelmeyebilir. Daha güvenli yaklaşım, log dosyasını uygun şekilde truncate etmek veya servisi kontrollü yeniden başlatmaktır.
Bir diğer hata, tüm log seviyelerini sürekli “debug” modunda bırakmaktır. Debug logları geliştirme ve sorun analizi için değerlidir; ancak üretim ortamında uzun süre açık kalırsa gereksiz veri üretir ve performans maliyeti oluşturur.
Sağlıklı log rotasyonu nasıl planlanır?
İyi bir planlama için önce hangi servislerin ne kadar log ürettiği ölçülmelidir. Web sunucusu, PHP, veritabanı, sistem logları, güvenlik araçları ve uygulama logları ayrı ayrı değerlendirilmelidir. Her log türü aynı süreyle saklanmak zorunda değildir.
- Yoğun erişim logları günlük döndürülebilir ve sıkıştırılabilir.
- Hata logları daha uzun süre saklanabilir; ancak boyut sınırı konulmalıdır.
- Güvenlik logları uyumluluk gereksinimlerine göre korunmalı ve mümkünse merkezi bir sisteme aktarılmalıdır.
- Debug kayıtları yalnızca ihtiyaç olduğunda etkinleştirilmelidir.
Linux tabanlı sistemlerde logrotate yaygın olarak kullanılır. Burada kritik nokta yalnızca rotasyon periyodu değil; sıkıştırma, saklama adedi, dosya izinleri ve servis yeniden yükleme adımlarının doğru tanımlanmasıdır. Hatalı izin verilirse servis yeni log dosyasına yazamayabilir.
Performans sorununu anlamak için kontrol edilecek göstergeler
Bir sunucuda yavaşlama başladıysa yalnızca CPU kullanımına bakmak yanıltıcı olabilir. Disk doluluk oranı, inode kullanımı, I/O bekleme süresi, büyük log dosyaları ve servis hata kayıtları birlikte incelenmelidir. Özellikle inode doluluğu gözden kaçabilir; disk alanı boş görünse bile çok sayıda küçük dosya nedeniyle sistem yeni dosya oluşturamayabilir.
Pratik bir kontrol yaklaşımı olarak önce en büyük dizinler belirlenmeli, ardından log dizinleri ayrıntılı incelenmelidir. Apache, Nginx, PHP-FPM, MySQL/MariaDB ve sistem günlükleri farklı konumlarda bulunabilir. Yönetilen hosting hizmetlerinde bu kontrollerin sağlayıcı paneli, izleme sistemi veya destek ekibi üzerinden düzenli yapılması beklenir.
Operasyonel açıdan doğru yaklaşım
Log rotasyonu tek seferlik temizlik işlemi olarak görülmemelidir. Trafik artışı, yeni eklentiler, güvenlik araçları, API entegrasyonları ve hata veren uygulama kodları log hacmini hızla değiştirebilir. Bu nedenle eşik değerler, uyarılar ve saklama politikaları düzenli gözden geçirilmelidir.
En sağlıklı yapı; kritik logların kaybolmadığı, gereksiz kayıtların sistemi tüketmediği ve teknik ekibin olaylara hızlı müdahale edebildiği dengeli bir modeldir. Böyle bir modelde sunucu kaynakları daha öngörülebilir kullanılır, arıza anında teşhis süresi kısalır ve kullanıcı tarafındaki yavaşlama riski belirgin biçimde azalır.