- Konu sahibi
- #1
Loglar neden düzenli rotasyona ihtiyaç duyar?
Web sitesi ve sunucu yönetiminde en sık ihmal edilen konulardan biri log yönetimidir. Trafik arttıkça access ve error log dosyaları hızla büyür; bu da hem disk alanını gereksiz tüketir hem de sorun ararken dosyaları okumayı zorlaştırır. Apache dokümantasyonu, yoğun olmayan sistemlerde bile logların hızlı büyüyebileceğini ve otomatik rotasyonun en baştan kurulması gerektiğini vurgular. Dış bir araçla rotasyon yapılıyorsa, sunucunun eski dosya tanıtıcısına yazmaya devam etmemesi için logları yeniden açacak bir reload ya da graceful restart gerekir.Sağlıklı bir log rotasyonu nasıl kurulur?
Log rotasyonunun amacı yalnızca dosyayı bölmek değildir; saklama süresi, sıkıştırma, izinler ve yeniden açma adımı birlikte düşünülmelidir. Pratikte üç temel karar verilir: log ne zaman dönecek, kaç kopya tutulacak ve dönen dosya nasıl arşivlenecek. Zaman tabanlı rotasyon günlük inceleme için uygundur; boyut tabanlı rotasyon ise ani trafik artışlarında disk taşmasını önlemeye yardım eder. Bazı platformlarda yerleşik araçlar, bazı sistemlerde ise logrotate gibi harici çözümler kullanılır. Harici çözüm seçildiğinde, postrotate aşamasında servise logları yeniden açtırmak kritik bir adımdır.En sık yapılan hata nedir?
En yaygın hata, rotasyonu kurup işi bitti sanmaktır. Rotasyon doğru çalışsa bile eski dosyalar uygulama tarafından hâlâ tutuluyorsa, beklenen disk kazancı oluşmayabilir. İkinci yaygın hata ise gereğinden fazla log tutmak ya da hiç tutmamaktır; biri disk ve yönetim yükünü artırır, diğeri ise olay incelemesini zorlaştırır. Bir diğer sorun da farklı sanal sitelerin aynı log adı altında toplanmasıdır. Bu durumda bir hata hangi siteye ait, ayırmak zorlaşır. NIST’in web sunucusu güvenliği rehberi, farklı sanal siteler için ayrı log adları kullanmanın faydalı olduğunu belirtir.Yedek denetiminde sadece dosya var mı diye bakmak neden yetmez?
Yedeğin var olması, geri dönülebileceği anlamına gelmez. Doğru yaklaşım, yedeği izole bir test ortamına alıp çalıştığını doğrulamaktır. AWS Well-Architected kılavuzu, periyodik recovery testleri ile yedeklerin gerçekten geri yüklenebildiğini, verinin bozuk olmadığını ve RTO/RPO hedeflerinin karşılandığını kontrol etmeyi önerir. Bu yüzden kontrol listesinin içinde sadece dosya bütünlüğü değil, uygulamanın açılması, veritabanının bağlanması ve kritik işlevlerin çalışması da olmalıdır.Bakım planı yaparken neyi ayırmak gerekir?
Bakım penceresi, günlük operasyonu bozmadan yapılacak işleri toplamak için kullanılır; ancak her iş aynı pencereye konulmamalıdır. Log rotasyonu gibi düşük riskli işler ile restore testi gibi daha yüksek riskli işler aynı gün yapılacaksa, birbirini etkileme ihtimali düşünülmelidir. Depolama, log temizliği, servis yeniden yükleme ve geri yükleme kontrolü arasındaki bağı önceden yazmak, bakım sırasında sürprizleri azaltır. Özellikle logların büyümesiyle disk kullanımının artması, yedekleme ve geri yükleme süreçlerini de dolaylı olarak etkileyebilir; bu yüzden bakım sadece "yenileme" değil, sistemin sağlık kontrolü olarak görülmelidir.Kısa uygulama listesi
- Log rotasyonunun zaman mı boyut mu bazlı olacağına karar verin.
- Harici rotasyon kullanıyorsanız, postrotate veya reload adımını test edin.
- Eski logların gerçekten kapandığını ve yeni dosyaya yazıldığını doğrulayın.
- Yedeği canlı sistemde değil, izole test ortamında geri yükleyin.
- Restore sonrası uygulama, veritabanı ve kritik sayfaları birlikte kontrol edin.
- Bakım notlarında hangi adımın neyi etkilediğini kısa ve net yazın.
Bu yaklaşım, tek başına disk dolmasını önlemekten daha fazlasını sağlar: loglar okunabilir kalır, bakım sırasında servis davranışı anlaşılır olur ve yedeklerin gerçekten işe yaradığı doğrulanır. Böylece sistem yönetimi rastgele müdahalelerden çıkıp izlenebilir bir rutine dönüşür.
