Loglar iki uçtan da sorun çıkarır. Yetersiz log tutan bir sunucuda bir olay yaşandığında elinizde hiçbir kanıt olmaz. Aşırı log tutan bir sunucuda ise disk dolar, I/O baskısı artar ve ihtiyaç duyduğunuz satırı milyonlarca satır arasında bulamazsınız.
Bu rehber, kendi sanal sunucunuz üzerinde bu dengeyi kurmayı — hangi logların tutulacağını, nasıl döndürüleceğini ve nasıl aranacağını — anlatıyor.
Hangi Loglar Önemli?
| Log | Ne için gerekli | Saklama |
|---|---|---|
| Web erişim logu | Trafik analizi, bot tespiti, saldırı incelemesi | Orta-uzun |
| Web hata logu | Kırık sayfalar, yapılandırma sorunları | Orta |
| Uygulama logu | İş mantığı hataları, istisna izleri | Orta |
| Kimlik doğrulama logu | Giriş denemeleri, yetki yükseltmeleri | Uzun |
| Veritabanı yavaş sorgu logu | Performans teşhisi | Kısa (teşhis sırasında) |
| Sistem logu | Servis çökmeleri, donanım uyarıları | Orta |
Kimlik doğrulama logu en uzun saklanması gereken kayıttır: bir güvenlik olayı genellikle yaşandıktan haftalar sonra fark edilir ve o noktada geriye dönük bakabilmeniz gerekir.
Log Seviyesi: Üretimde Ne Kadar Ayrıntı?
Geliştirme ortamından üretime taşınırken en sık atlanan ayar budur. Hata ayıklama seviyesinde açık bırakılmış bir uygulama logu, her istekte onlarca satır yazar. Bu üç sorun üretir: disk hızla dolar, sürekli disk yazımı I/O baskısı yaratır ve gerçek hatalar gürültü içinde kaybolur.
Üretimde uygun seviye genellikle "uyarı ve üzeri"dir. Hata ayıklama seviyesini yalnızca aktif bir sorun araştırırken, geçici olarak açın ve kapatmayı unutmayın — açık unutulmuş bir hata ayıklama logu, disk dolma vakalarının en yaygın nedenidir.
Log Döndürme (Rotation)
Döndürme, log dosyalarını belirli bir boyuta veya süreye ulaştığında arşivleyip yenisini başlatan mekanizmadır. Kurulmadığında tek bir dosya sınırsız büyür ve sonunda diski doldurur.
Çoğu sistem, kendi servisleri için döndürmeyi hazır kurulu getirir. Atlanan yer, uygulamanızın kendi log dosyalarıdır — bunlar için kuralı elle tanımlamanız gerekir. Disk dolma vakalarının büyük bölümünde suçlu, döndürme kuralı yazılmamış tek bir uygulama log dosyasıdır.
Döndürme yapılandırmasında dört karar verirsiniz: hangi sıklıkta döndürüleceği, kaç arşiv tutulacağı, arşivlerin sıkıştırılıp sıkıştırılmayacağı (sıkıştırın — metin logları çok iyi sıkışır) ve döndürme sonrası servise yeniden yükleme sinyali gönderilip gönderilmeyeceği.
Son madde önemlidir: sinyal gönderilmezse servis eski dosyaya yazmaya devam eder ve döndürme işe yaramaz. Bu, sessizce başarısız olan bir yapılandırmadır.
Log İçinde Arama
Milyonlarca satır arasında aradığınızı bulmanın pratik yöntemleri:
- Zaman aralığıyla daraltın. Olayın yaklaşık saatini biliyorsanız önce o aralığı kesin. Tüm dosyada arama yapmak hem yavaştır hem gereksiz sonuç üretir.
- Sıklık sayımı yapın. Hangi IP kaç istek atmış, hangi hata kaç kez tekrarlanmış? Ham satırları okumak yerine gruplayıp saymak, kalıbı çok daha hızlı gösterir.
- Durum kodlarına göre filtreleyin. Sunucu hatalarını ayrı, yetkisiz erişim denemelerini ayrı inceleyin.
- İstek kimliği kullanın. Uygulamanız her isteğe benzersiz bir kimlik atıyorsa, tek bir isteğin tüm izini katmanlar arasında takip edebilirsiniz. Bu, dağıtık sorunları çözmenin en etkili yoludur.
Merkezi Loglama Ne Zaman Gerekir?
Tek sunuculu bir kurulumda loglar sunucuda durabilir. Şu üç durumda merkezi toplama anlamlı hale gelir:
- Birden fazla sunucunuz var. Bir isteğin izini birkaç makine arasında takip etmek, loglar dağınıkken pratikte imkânsızdır.
- Sunucu çökebilir. Sunucu erişilemez hâle geldiğinde, çökme nedenini gösteren loglar da erişilemez olur. Dışarı aktarılmış loglar bu durumda elinizde kalır.
- Log bütünlüğü önemli. Sunucuyu ele geçiren bir saldırganın ilk yapacağı işlerden biri izlerini silmektir. Anlık olarak dışarı aktarılan loglar silinemez.
Üçüncü madde, güvenlik açısından merkezi loglamanın asıl gerekçesidir ve tek sunuculu kurulumlarda bile geçerlidir.
Loglarda Kişisel Veri
Loglar kişisel veri içerebilir: IP adresleri, kullanıcı adları, bazen URL parametrelerine sızmış e-posta adresleri. İki kural:
- Hassas veriyi hiç loglamayın. Parola, kart bilgisi ve oturum anahtarı log dosyasına yazılmamalıdır. Hata izlerinde bu verilerin maskelendiğinden emin olun.
- Saklama süresi tanımlayın. Sınırsız saklama hem gereksiz maliyet hem gereksiz sorumluluktur. Ne kadar süre saklayacağınızı yazılı olarak belirleyin ve döndürme kuralını buna göre kurun.
Sonuç
Log yönetimi, ihtiyaç duyulana kadar görünmez olan bir altyapıdır — ve ihtiyaç duyulduğunda ya elinizde ya değildir. Üretimde uygun log seviyesi, tüm uygulama logları için döndürme kuralı ve kimlik doğrulama loglarının uzun saklanması: bu üçü bir VDS sunucu için sağlam bir taban oluşturur. Disk dolma vakalarının çoğu, üzerine döndürme kuralı yazılmamış tek bir dosyadan kaynaklanır; o kuralı yazmak beş dakika sürer.
Sıkça Sorulan Sorular (SSS)
Logları ne kadar süre saklamalıyım?
Kullanım amacına göre değişir: performans teşhisi için günler, güvenlik incelemesi için aylar gerekebilir. Kimlik doğrulama loglarını en uzun saklayın — güvenlik olayları genellikle geç fark edilir ve o noktada geriye bakabilmeniz gerekir.
Disk doldu, logları silebilir miyim?
Dosyayı doğrudan silmek yerine içeriğini boşaltın: servis o dosyayı açık tutuyorsa, silinen dosyanın alanı servis yeniden başlatılana kadar geri gelmez. Acil müdahaleden sonra asıl işi yapın — o dosya için döndürme kuralı tanımlayın, yoksa aynı durum tekrarlanır.
Erişim logunu kapatabilir miyim?
Teknik olarak evet ama önerilmez. Erişim logu, saldırı incelemesinde ve bot trafiği tespitinde en değerli kaynaktır. Disk baskısı sorunsa çözüm logu kapatmak değil, döndürme ve sıkıştırmayı doğru yapılandırmaktır.
Tek sunucum var, merkezi loglama gereksiz mi?
Performans teşhisi için gereksiz sayılabilir, ancak güvenlik açısından değerlidir: sunucu ele geçirilirse yerel loglar değiştirilebilir. Anlık olarak dışarı aktarılan loglar, olay incelemesinde güvenilir tek kaynak olur.
