Analitik betikleri size ziyaretçilerin ne yaptığını anlatır — ama yalnızca betiği çalıştıran ziyaretçileri sayar. Reklam engelleyiciler, betik çalıştırmayan istemciler ve botlar bu ölçümün dışında kalır.
Sunucu erişim logları ise gelen her isteği kaydeder. Bu, farklı ve tamamlayıcı bir gerçeklik sunar: sunucunuza gerçekte kimin ne kadar yük bindirdiğini yalnızca burada görebilirsiniz.
Bu rehber, kendi sanal sunucunuzda log analizini ve pratik kullanımlarını anlatıyor.
Analitik Betiği ve Log Farkı
| Analitik betiği | Sunucu logu | |
|---|---|---|
| Kapsam | Betiği çalıştıran ziyaretçiler | Her istek |
| Botlar | Genellikle görünmez | Tamamı görünür |
| Kaynak tüketimi | Ölçmez | Doğrudan gösterir |
| Hatalar | Kısmen | Durum koduyla tamamı |
| Kullanıcı davranışı | Ayrıntılı | Sınırlı |
| Veri sahipliği | Üçüncü tarafta | Sizde |
İkisi rakip değildir. Analitik betiği kullanıcı davranışını, sunucu logu sistem gerçekliğini anlatır. Kaynak tüketimi sorunlarını yalnızca loglarda çözebilirsiniz.
Kullanım 1: Gerçek Yükün Kaynağını Bulmak
Sunucunuz yoğun ama analitik panelinizde ziyaretçi sayısı normal görünüyorsa, aradaki farkı loglar açıklar.
Erişim logunu istek kaynağına göre gruplayıp sıralayın. Tipik bulgular:
- Arama motoru botları. Değerlidirler ama tarama hızları bazen agresif olur. Site haritanız düzgünse ve gereksiz sayfalar taramadan çıkarılmışsa yük belirgin biçimde azalır.
- İçerik kazıyıcılar. İçeriğinizi kopyalamak için tüm siteyi tarayan istemciler. Hiçbir değer üretmez, sadece kaynak tüketirler.
- Güvenlik açığı tarayıcıları. Var olmayan yönetim panellerini ve bilinen açık yollarını deneyen otomatik istekler. Log'da 404 yığını olarak görünürler.
- Hatalı entegrasyonlar. Sonsuz döngüye girmiş bir istemci, saniyede yüzlerce istek üretebilir.
Bazı sitelerde toplam isteklerin önemli bir bölümünün hiçbir ticari değer üretmediği bu analizde ortaya çıkar.
Kullanım 2: Kırık Bağlantı ve Hata Tespiti
Durum kodlarına göre gruplama, sitenizin sağlığını hızla gösterir:
- 404 hataları. Hangi adresler bulunamıyor ve oraya nereden geliniyor? Yönlendirme kaydı olan bir kaynak varsa, kalıcı yönlendirme tanımlayın.
- 500 hataları. Sunucu tarafı hataları. Hangi sayfada, hangi saatte? Bu bilgi, uygulama loglarında arama yapmayı hedefli hâle getirir.
- 403 hataları. Erişim reddi. Yanlış izinler veya fazla sıkı bir güvenlik kuralı olabilir.
- Yavaş yanıtlar. Log biçiminize yanıt süresini eklerseniz, hangi sayfaların yavaş olduğunu doğrudan görürsünüz.
Dördüncü madde için log biçimini değiştirmeniz gerekir ve bu, yapılabilecek en yüksek getirili tek değişikliktir: yanıt süresi loglanmıyorsa performans sorunlarını loglardan teşhis edemezsiniz.
Kullanım 3: Güvenlik İncelemesi
Bir güvenlik olayı yaşandığında elinizdeki tek kanıt loglardır. İncelenmesi gerekenler:
- Yönetim paneline yapılan istekler ve başarısız giriş denemeleri
- Olağandışı yollara yapılan istekler (dizin geçişi, yapılandırma dosyası denemeleri)
- Tek bir kaynaktan gelen yoğun ve hızlı istekler
- Beklenmedik saatlerde gelen başarılı istekler
- Yükleme dizinlerine yapılan yazma istekleri
Bu inceleme ancak loglar duruyorsa mümkündür. Bu yüzden erişim loglarının saklama süresi, güvenlik açısından anlamlı bir uzunlukta olmalıdır — güvenlik olayları genellikle geç fark edilir.
Pratik Analiz Yöntemi
Karmaşık bir araç kurmadan, komut satırı araçlarıyla çok şey öğrenebilirsiniz. Temel yaklaşım her zaman aynıdır: ilgili alanı çıkar, grupla, say, sırala.
Bu kalıpla cevaplanabilecek sorular:
- En çok istek yapan kaynaklar hangileri?
- En çok istenen sayfalar hangileri?
- En çok 404 veren adresler hangileri?
- Trafik saatlere göre nasıl dağılıyor?
- Hangi istemci türleri geliyor?
Düzenli raporlama isterseniz bu analizi bir log analiz aracına devredebilirsiniz — sunucunuzda çalışan, verinizi dışarı çıkarmayan seçenekler mevcuttur.
Bulgudan Aksiyona
Analiz, ancak müdahaleye dönüşürse değer üretir:
| Bulgu | Aksiyon |
|---|---|
| Agresif kazıyıcı | Hız sınırla veya engelle |
| Çok sayıda 404 | Kalıcı yönlendirme tanımla |
| Açık tarayıcıları | Otomatik engelleme kur |
| Yavaş sayfalar | O sayfaları önbelleğe al veya optimize et |
| Bot trafiği yoğunluğu | Tarama kurallarını gözden geçir |
Gizlilik Notu
Erişim logları IP adresi içerir ve bu kişisel veri sayılabilir. İki önlem alın: saklama süresini yazılı olarak belirleyin ve döndürme kuralıyla otomatik uygulayın; uzun süreli istatistik tutacaksanız IP adreslerini anonimleştirmeyi değerlendirin.
Sonuç
Sunucu logları, analitik panelinizin göremediği gerçekliği gösterir: sunucunuza gerçekte kim yük bindiriyor, hangi sayfalar hata veriyor, hangi istekler hiçbir değer üretmiyor. Kaynak sorunu yaşadığınızda bakılacak ilk yer burasıdır. En yüksek getirili tek değişiklik, log biçimine yanıt süresini eklemektir — bu olmadan performans teşhisi loglardan yapılamaz. Kaynakların size ayrıldığı bir VDS ortamında bu logların tamamı sizindir ve dışarı çıkmaz.
Sıkça Sorulan Sorular (SSS)
Analitik panelim ile log sayıları neden farklı?
Farklı şeyleri sayıyorlar. Analitik betiği yalnızca betiği çalıştıran ziyaretçileri sayar; loglar her isteği kaydeder — botlar, betik engelleyen tarayıcılar ve statik dosya istekleri dahil. Log sayılarının daha yüksek olması normaldir.
Botları engellemeli miyim?
Arama motoru botlarını engellemeyin — onlar değerlidir. İçerik kazıyıcıları ve açık tarayıcılarını ise sınırlamak hem kaynak kazandırır hem logları okunabilir tutar. Engellemeden önce hangi botun ne kadar yük ürettiğini ölçün.
Logları ne kadar saklamalıyım?
Performans analizi için günler, güvenlik incelemesi için aylar gerekebilir. Güvenlik olayları genellikle geç fark edildiği için erişim loglarını anlamlı bir süre saklamak değerlidir. Ancak kişisel veri içerdiklerini unutmayın — saklama süresini yazılı belirleyin.
Log analizi için araç kurmalı mıyım?
Ara sıra bakacaksanız komut satırı araçları yeterlidir ve hiçbir kurulum gerektirmez. Düzenli rapor ve grafik isterseniz sunucunuzda çalışan bir analiz aracı kurabilirsiniz — verinizin dışarı çıkmaması avantajını da korursunuz.
