Sunucu Logları İncelemesi: 7 Pratik İpucu

Sunucu Logları Nasıl İncelenir? Hakkında Bilmeniz Gerekenler

Sunucu logları neden bu kadar önemli? Çünkü gerçek zamanlı sorun yaşarken, monitoring araçları genelde sonucu gösterir; loglar ise sebebi. Şöyle düşünün: Grafikte CPU %100 görüyorsun. Güzel, peki ne yüzünden? İşte onu access ve error logları, sistem logları, servis logları anlatıyor.

Aslında durum tam olarak şöyle: Her bileşenin kendi günlüğü var. Web sunucusu (Apache/nginx/LiteSpeed) için access ve error logları, sistem için /var/log/messages veya journalctl, veritabanı için MySQL/PostgreSQL logları… Mantık hep aynı: Zaman damgası, isteği yapan istemci, yapılan işlem ve sonuç (başarılı mı, hata mı, ne hata?).

En çok duyduğumuz efsanelerden biri şu: “Loglara bakmaya gerek yok, zaten sorun sunucudan.” Hayır, çoğu zaman sorun kodda, bazen veritabanında, bazen de kullanıcı davranışında. Özellikle “Sunucu çok yavaşladı” şikayetlerinin ciddi bir kısmı aslında tek bir eklentinin, tek bir sorgunun veya bot trafiğinin loglarda bıraktığı izlerden çıkıyor. Bir başka yanlış inanış da şu: “Ne kadar çok çekirdek, o kadar hızlı site.” Dürüst olmak gerekirse, siteceğin tek bir PHP-FPM child üzerinde takıldıysa, 32 çekirdeğin pek bir anlamı olmuyor; asıl ipuçlarını error_log ve veritabanı loglarında buluyorsun.

Bu arada, performansınızı artırmak için Sunucu sayfamızdaki diğer çözümlere de bakabilirsiniz.

Yapılandırma ve Yönetim: Adım Adım

Kaynak Yönetimi – Limitleri Zorlamayin

Sunucu logları nasıl incelenir diye sorduğumuzda, ilk odaklanılması gereken yer genelde kaynaklar: CPU, RAM, disk I/O. Çünkü loglar bize yalnızca “ne hata oldu”yu değil, “ne zaman yük arttı”yı da gösteriyor. Özellikle web erişim loglarında (örneğin Apache için access_log) ani trafik artışlarını, belirli bir IP’nin saldırı mı yoksa normal kullanıcı mı olduğunu, hangi sayfaların en çok yük bindirdiğini net görüyorsun.

Aşırı kaynak kullanımı uyarısı geldiğinde panik yapmadan önce bakılacak ilk dosya genelde şunlardan biri: web sunucusu error_log ve access_log. Örnek: /var/log/apache2/error.log veya /usr/local/apache/logs/error_log. Burada sık gördüğümüz şeyler: PHP Fatal error, MySQL server has gone away, Allowed memory size exhausted gibi PHP hataları. İşin püf noktası şurada: Bu hatalar çoğu zaman “sunucu bozuk” demek değil, yazılım veya yapılandırma tarafında bir sınırın aşıldığını gösteriyor.

Pratik bir yaklaşım: Kısa bir zaman penceresine odaklan. Mesela sorun 10:15’te başladıysa, önce logu o aralıkta filtrele. Terminalde tail veya grep kullandığını düşün; cPanel veya Plesk panelindeysen de “Raw Access” veya “Errors” alanlarını incele. Terminal komutu vermeyeyim ama mantık şu: O zaman dilimindeki IP’leri, istek URL’lerini ve hata kodlarını (500, 502, 503, 504 gibi) çıkar ve “Bu yükü ne tetikliyor?” sorusuna cevap ara.

Guvenlik Duvari ve Port Ayarlari

Log incelemek sadece performans için değil, güvenlik için de kritik. Dış dünyaya açık her port, açık bir penceredir. Ve güvenlik duvarının (CSF, firewalld, ufw, vs.) logları sana kimlerin o pencereden içeri bakmaya çalıştığını gösterir. Özellikle auth.log veya secure loglarında, SSH brute-force denemelerini, başarısız girişleri ve yasaklanan IP’leri görebilirsin.

Şöyle düşünün: SSH’ı 22. porttan çalıştırıp loglara bakmazsan, dakikalar içinde yüzlerce deneme görmen gayet normal. Log incelerken burada dikkat etmen gerekenler:

• Aynı IP’den ardışık çok sayıda başarısız giriş (SSH, FTP, e-posta).
• Firewall loglarında DROP veya REJECT olarak geçen sıra dışı port denemeleri.
• cPanel, Plesk veya web uygulaması yönetim panellerine yönelik başarısız girişler.

Basit ama etkili adımlar: SSH portunu değiştir, root ile doğrudan girişe izin verme, kullanılmayan servisleri (özellikle eski FTP sunucuları, gereksiz açık panel portları) kapat. Burada logları rehber gibi kullan: “Ben hangi servisi gerçekten kullanıyorum, hangi servise sürekli başarısız erişim denemesi var?” sorusunun cevabını loglardan çıkar.

Eğer cloud veya VDS üzerinde kendi güvenlik duvarını yönetiyorsan, loglarla birlikte port listesini düzenli kontrol et. VDS sunucu veya cloud sunucu kullanıyorsan, yönetim panelindeki firewall ayarlarını loglardaki trafiğe göre şekillendirmek ciddi fark yaratır.

Yazilim Uyumlulugu ve PHP/Veritabani Secimi

Logların en çok işe yaradığı alanlardan biri de uyumsuzluk sorunları. En güncel sürüm her zaman en iyisi mi? Kağıt üzerinde evet gibi durur ama pratikte her zaman değil. Özellikle PHP ve veritabanı sürümlerinde: Uygulaman WordPress, Laravel veya özel yazılım olabilir; eklentilerin ve kütüphanelerin desteklediği sürümlerle sunucu tarafı aynı hizada değilse, loglar uyarıyı hemen verir.

PHP error loglarında sık görülen uyarılar: Deprecated, Warning, Notice mesajları. Bunlar siteyi anında düşürmeyebilir ama gelecekte patlayacak sorunların habercisidir. Sunucu logları nasıl incelenir diye sorarken, sadece “fatal error” ararsan bu sinyalleri kaçırırsın. Aslında işin doğrusu, hata seviyesine göre filtrelemek ve en azından ciddi Warning’leri ciddiye almak.

Veritabanı tarafında altın kural şu: “Yavaş sorgu, yoğun kaynak tüketir; yoğun kaynak, tüm sunucuyu yavaşlatır.” MySQL’in slow query log’u bu yüzden var. Logda belirli sorguların sürekli 2–3 saniyenin üzerinde sürdüğünü görüyorsan, RAM eklemekten önce o sorguları optimize etmek çok daha etkili olur. Yani önce indeks, sonra donanım. Dürüst olmak gerekirse, RAM yükseltip geçmek kısa vadede rahatlatır ama loglarda aynı sorgular tekrar tekrar karşına çıkıyorsa, bu sadece daha pahalı bir şekilde aynı hatayı yaşamaktır.

WordPress gibi yaygın sistemler için özel optimize edilmiş hosting çözümlerinde, çoğu uyumluluk ayarı ve log yapılandırması zaten senin yerine düşünülmüş olur; ama yine de logları okumayı bilmek, özellikle plugin veya tema kaynaklı sorunlarda hayat kurtarır.

Uygulama: Kurulum ve Yayına Alma

Teoriyi bir kenara bırakalım, pratiğe bakalım. Terminali açın, şu komutu girin demiyorum ama mantık şu: Önce sistemde hangi logların aktif olduğunu ve nereye yazıldığını bilmen gerekiyor. Apache mi kullanıyorsun, nginx mi, LiteSpeed mi? Her birinin varsayılan log dizinleri farklı. İlk adım: Konfigürasyon dosyasına bak ve access_log, error_log yollarını not et.

İkinci adım: Log rotasyonunu ve boyutunu kontrol et. Çok büyük dosyalar hem okunması zor hem de disk I/O’yu yorabiliyor. Logrotate veya benzeri araçlarla günlük/haftalık döndürme, sıkıştırma ayarlarını gözden geçir. Özellikle yüksek trafikli sitelerde bu kritik.

Üçüncü adım: Filtreleme ve arama alışkanlığı kazan. “Sunucu logları nasıl incelenir?” sorusunun gizli cevabı aslında şu: Hepsini bir anda okumaya çalışma. Tarih, IP, hata kodu, URL veya hata mesajına göre filtrele. Örneğin sadece 500 hatalarını, sadece belirli bir domainin loglarını veya sadece belirli bir zaman aralığını izle. Panel kullanıyorsan bile, çoğu kontrol paneli bu filtreleri arayüzde sunuyor.

Genelde yeni bir siteyi yayına alırken yapmayı sevdiğim şey şu: İlk birkaç gün logları daha sık kontrol etmek. Özellikle:

• 404 hataları (yanlış URL’ler, eksik dosyalar).
• PHP uyarıları (uyumsuz eklentiler, eski fonksiyonlar).
• Bot trafiği (agresif tarayıcılar, saldırı denemeleri).

Bu kısa gözlem süresi, ileride başını ağrıtacak problemleri erken yakalamanı sağlıyor. Genelde 5–10 dakikalık bir log taraması bile fazlasıyla yeterli oluyor.

Sık Karşılaşılan Sorunlar ve Pratik Çözümler

Loglarla bu tabloda gördüğün sorunları nasıl eşleştirirsin? Örneğin “Site yavaş” dendiğinde, access logda belirli URL’lerin yanıt sürelerini ve istek sayısını inceleyebilirsin. Aynı URL için yüzlerce istek ve her birinde yüksek yanıt süresi görürsen, o sayfanın sorguları veya cache yapılandırması zayıf demektir. “Bağlantı zaman aşımı” durumunda ise, web sunucusu loglarına ek olarak firewall ve sistem loglarına da bakmak gerekir; isteğin sunucuya hiç ulaşıp ulaşmadığı logtan anlaşılır.

Paylaşımlı ortamda çalışıyorsan, cPanel hata logları ve raw access logları en yakın arkadaşın. Kendi sunucunu yönetiyorsan, web hosting yerine VDS veya cloud sunucuda daha ayrıntılı log seviyeleri tanımlayıp analizi derinleştirebilirsin.

Sıkça Sorulan Sorular

Sunucu logları incelemek güvenli mi?

Tek başına logları okumak gayet güvenli. Risk, logları herkesin erişebileceği yere kopyalamak, e-posta ile oraya buraya göndermek veya yanlış izinlerle bırakmakta. Çünkü logların içinde IP adresleri, bazen header bilgileri, bazen hata mesajları üzerinden sistemin iç yapısına dair ipuçları olur. Yani loglar hassas veri sayılır. Erişimi sadece yetkili hesaplarla sınırlandır, mümkünse SSH veya güvenli panel üzerinden görüntüle.

Fiyat/performans dengesini nasıl kurarım?

İşin püf noktası şu: Önce loglarla gerçekten neye ihtiyacın olduğunu anla, sonra paketi büyüt. Kuru kuru “site yavaş” hissi yerine, “veritabanı sorguları 3 saniye sürüyor” veya “aynı anda 200 eşzamanlı istek geliyor” gibi net çıktılar elde edersen, buna göre CPU, RAM veya disk I/O odaklı bir plan seçebilirsin. Kaynağı körlemesine yükseltmek yerine, log destekli karar ver. İhtiyacına göre cloud sunucu ile esnek ölçeklendirme veya web hosting ile daha ekonomik bir başlangıç yapabilirsin.

Taşıma (Migration) işlemi zor mu?

Zor olan kısmı genelde dosyaları taşımak değil, yeni ortamda log yapılandırmalarının ve PHP/veritabanı sürümlerinin uyumlu olduğundan emin olmak. Sunucu logları nasıl incelenir sorusuna az çok hakimsen, taşıma sonrası ilk günlerde logları izleyerek gizli hataları hızlıca yakalarsın. Bilhost tarafında, taşıma sürecini mümkün olduğunca zahmetsiz hale getirmeye çalışıyoruz; log yönetimi ve uyumluluk konularında teknik ekibimiz el veriyor, böylece sen uygulamana odaklanıyorsun. Domain, SSL ve e-posta tarafında da domain sorgulama, SSL sertifikası ve kurumsal e-posta hizmetleriyle taşımayı tek pakette toplamak işleri epey kolaylaştırıyor.

Sonuç

İşin özü şu: Sunucu logları nasıl incelenir sorusuna vereceğin cevap, aslında sunucuyu ne kadar “karşılıklı konuşabilir” gördüğünle ilgili. Loglar, sana her hatanın, her yavaşlamanın, her beklenmedik davranışın hikayesini anlatıyor. Okumayı öğrendiğinde, sorun çıktığında tahmin yürütmek yerine somut veriye bakıyorsun. Bu da hem zaman kazandırıyor hem de boş yere kaynak yükseltip masraf etmeni engelliyor.

Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma ve düzenli log takibi hayat kurtarır. Eğer bir yerde takılırsan biz buradayız, yorumlarda sorularını bekliyorum.