Bir sunucuda “site açılmıyor”, “giriş reddedildi” veya “e-posta ulaşmadı” gibi belirtiler görüldüğünde ekrandaki hata çoğu zaman yalnız son sonucu gösterir. Asıl olay; web sunucusu, işletim sistemi, uygulama ya da posta servisi tarafından loglara kaydedilmiş olabilir. Doğru kayıt bulunduğunda sorunun ne zaman başladığı, hangi bileşeni etkilediği ve hangi isteğin hataya yol açtığı daha somut biçimde anlaşılır.
Log inceleme, binlerce satır arasında rastgele hata aramak değildir. Önce olayın zaman aralığı ve etkilenen servis belirlenir; ardından ilgili kayıtlar ortak bir zaman çizelgesinde birleştirilir. Bu rehber, sunucu log türlerini tanımanıza, satırları anlamlandırmanıza ve güvenli bir izleme düzeni kurmanıza yardımcı olur.
Sunucu Logları Nedir?
Sunucu logları; işletim sistemi, servisler ve uygulamalar tarafından üretilen zaman damgalı olay kayıtlarıdır. Bir HTTP isteği, başarısız giriş, servis başlangıcı, veritabanı bağlantı hatası veya e-posta teslimat denemesi ayrı loglarda yer alabilir. Her kayıt mutlaka sorun anlamına gelmez; bilgi, uyarı ve hata seviyeleri sistemin normal çalışmasını da görünür kılar.
Log dosyası tek bir standart biçime sahip değildir. Düz metin, JSON, ikili günlük veya merkezi kayıt sistemindeki bir olay olarak tutulabilir. İçerik ve konum kullanılan işletim sistemine, web sunucusuna, kontrol paneline ve uygulama ayarlarına göre değişir. Bu nedenle internette bulunan bir dosya yolunu doğrudan doğru kabul etmek yerine mevcut yapılandırmada doğrulamak gerekir.
Hangi Sunucu Logları İzlenmelidir?
Web erişim ve hata logları
Access log, web sunucusuna gelen istekleri; kaynak IP, istek zamanı, yöntem, URL, durum kodu ve aktarılan veri gibi alanlarla kaydeder. Error log ise yapılandırma, dosya izni, upstream bağlantısı ve uygulama çalıştırma gibi sorunları gösterir. Trafik analizi için erişim, neden analizi için hata kaydı çoğu zaman birlikte okunur.
Sistem ve servis logları
İşletim sistemi günlükleri yeniden başlatma, disk, bellek, ağ ve servis olaylarını içerir. Nginx, Apache, PHP-FPM, MySQL, SSH ve güvenlik duvarı gibi her servis kendi kayıt kaynağına sahip olabilir. Uygulama logları ise kodun ürettiği istisnaları, iş kurallarını ve dış API yanıtlarını gösterir.
Kimlik doğrulama ve mail logları
Authentication kayıtları başarılı ve başarısız oturum açma denemelerini, kullanıcıyı ve kaynak adresi incelemeye yardım eder. Mail logları mesajın kabul, kuyruk, yönlendirme, teslim veya ret aşamasını gösterir. “Login failed” benzeri bir sonuç, parola kadar bağlantı türü, hesap durumu veya servis ayarıyla da ilgili olabilir.
Sunucu Logları Nerede Tutulur?
Bir Linux VDS üzerinde kayıtlar çoğunlukla /var/log dizininde veya systemd journal içinde bulunur. Debian tabanlı sistemlerde Apache kayıtları genellikle /var/log/apache2 altında, RHEL tabanlı yapılarda /var/log/httpd altında tutulabilir. Nginx için /var/log/nginx, kimlik doğrulama için dağıtıma göre /var/log/auth.log ya da /var/log/secure yaygın örneklerdir.
Bu yollar kesin kural değildir. Sanal host yapılandırması her siteyi ayrı dosyaya yazabilir; konteyner ortamı kayıtları standart çıktıya gönderebilir. journalctl ile systemd servis günlükleri, ilgili servis yapılandırmasıyla da etkin log hedefi kontrol edilebilir. Windows Server tarafında Event Viewer; Application, System ve Security günlüklerini merkezi bir arayüzde sunar.
cPanel veya Plesk gibi paneller bazı kayıtları arayüzde gösterebilir, fakat tüm ayrıntılar panele taşınmayabilir. Panelde görünen özet ile servis dosyasının aynı zaman aralığı karşılaştırılmalıdır. Yönetim erişiminiz yoksa sağlayıcıya saat dilimi, tam zaman, etkilenen alan adı ve örnek istek bilgisi vererek ilgili kesiti istemek incelemeyi hızlandırır.
Sunucu Logları Nasıl Okunur?
Önce sunucunun ve kullanıcının saat dilimini doğrulayın. Tarayıcıda 14.05’te görülen olay, sunucu UTC kullanıyorsa farklı saatte kaydedilebilir. Ardından tek bir örnek istek seçin: URL, kullanıcı, kaynak IP, istek kimliği ve birkaç dakikalık zaman aralığı aramayı daraltır. Büyük dosyanın tamamını okumak yerine olay çevresindeki satırları incelemek daha verimlidir.
Bir web log satırının temel alanları
- Zaman damgası: Olayın gerçekleştiği an ve mümkünse saat dilimi.
- Kaynak IP: İsteğin görünen ağ adresi; proxy varsa gerçek istemci farklı olabilir.
- Yöntem ve yol: GET, POST gibi yöntem ile istenen kaynak.
- Durum kodu: Sunucunun HTTP sonucunu özetleyen 2xx, 3xx, 4xx veya 5xx değeri.
- Yanıt süresi: Yapılandırılmışsa isteğin işlenme süresi.
- İstek veya işlem kimliği: Aynı olayı farklı servisler arasında eşleştirmeye yarar.
Hata metninin hemen yanındaki dosya yolu, süreç kimliği ve upstream adresi önemli ipuçlarıdır. Aynı mesajın tekrar sıklığına da bakın: tek seferlik bir uyarı ile her saniye oluşan hata aynı öncelikte değildir. tail -f canlı akışı, grep belirli desenleri ve journalctl -u servis servis kayıtlarını filtreleyebilir. Döndürülmüş sıkıştırılmış dosyalar için uygun okuma aracını kullanmak gerekir.
Web Erişim ve Hata Logları
HTTP 4xx kodları genellikle isteğin veya yetkilendirmenin sonucunu, 5xx kodları ise sunucu tarafındaki başarısızlığı gösterir; fakat kesin neden için error log gerekir. Örneğin erişim kaydında 502 görülürken hata kaydında PHP-FPM soketine bağlanılamadığı yazabilir. Aynı saniyedeki iki satırı eşleştirmek, yalnız durum koduna bakmaktan daha açıklayıcıdır.
İstek hacmindeki ani artış, belirli bir URL’ye yoğun tarama veya tekrarlanan 404 kayıtları performans ve güvenlik incelemesini başlatabilir. Yine de her bot trafiği saldırı değildir. IP engellemeden önce proxy/CDN yapısı, kullanıcı aracısı, istek hızı ve etkilenen kaynaklar birlikte değerlendirilmelidir. Aksi halde paylaşılan bir ağdaki meşru kullanıcılar da engellenebilir.
Yavaşlık araştırmasında erişim loguna yanıt süresi alanı eklemek değerlidir. Uzun süren isteklerin ortak URL, yöntem veya upstream servisi var mı kontrol edilir. Uygulama logundaki sorgu süresi ve veritabanı kaydıyla aynı istek kimliği üzerinden ilişki kurulabiliyorsa darboğaz daha kesin belirlenir.
Kimlik Doğrulama ve Mail Logları
“530 login authentication failed” veya “login incorrect” kayıtları kullanıcı adı ya da parola hatasını gösterebilir; ancak hesap kilidi, yanlış port, devre dışı bırakılmış protokol ve hatalı şifreleme seçimi de benzer belirti üretir. Önce hesabın varlığı ve aktifliği doğrulanmalı, ardından istemcinin bağlandığı servis, port ve TLS yöntemi kontrol edilmelidir. Parolanın kendisi loga yazılmamalıdır.
Başarısız girişlerin kaynak IP, kullanıcı ve zaman dağılımı incelenir. Çok sayıda hesaba hızlı deneme otomatik saldırıya işaret edebilir; tek kullanıcının aralıklı hataları yanlış yapılandırılmış cihazdan kaynaklanabilir. Başarılı girişten hemen önceki başarısız denemeler de olay bütünlüğü içinde değerlendirilmelidir.
Mail loglarında kuyruk kimliği, gönderen, alıcı, uzak sunucu cevabı ve teslim durumu takip edilir. Mesajın uygulamadan çıkması, alıcı sunucu tarafından kabul edildiği anlamına gelmez. “Deferred”, “bounced” veya kimlik doğrulama hatalarının her biri farklı aşamayı gösterir. Aynı kuyruk kimliğini izlemek, mesajın hangi noktada beklediğini ortaya çıkarır.
Log İzleme ve Alarm Kurulumu
Manuel inceleme tek bir olay için yeterli olabilir; sürekli işletimde logların merkezi bir platforma aktarılması arama ve korelasyonu kolaylaştırır. Sunucular aynı saat kaynağını kullanmalı, alanlar mümkünse yapılandırılmış formatta tutulmalı ve kayıt iletimindeki kesinti ayrıca izlenmelidir. Merkezi sistem erişimi rol bazlı olmalı; her kullanıcı tüm güvenlik kayıtlarını görememelidir.
Alarm, her “error” sözcüğünde bildirim göndermemelidir. Normal taban çizgisi çıkarıldıktan sonra hata oranı, belirli zaman penceresindeki artış, bir servisin durması veya disk doluluğu gibi eyleme dönük koşullar seçilir. Örneğin 503 Service Unavailable hatası sayısındaki ani artış; PHP worker kuyruğu, bakım modu veya upstream servis sağlığıyla birlikte uyarı üretebilir.
Alarm mesajında ortam, servis, başlangıç zamanı, örnek kayıt ve inceleme bağlantısı bulunmalıdır. Uyarının kime, hangi saatte ve hangi öncelikle gideceği önceden belirlenir. Yanlış pozitifler düzenli gözden geçirilmezse ekip bildirimleri görmezden gelmeye başlayabilir. Hedef daha fazla alarm değil, doğru kişiyi zamanında harekete geçiren sinyaldir.
Log Saklama, Silme ve Güvenlik
Loglar IP adresi, kullanıcı adı, URL parametresi ve bazen kişisel veri içerebilir. Gereksiz veri kaydedilmemeli; parola, oturum belirteci, ödeme bilgisi ve gizli anahtarlar maskelenmelidir. Erişim yetkisi görevle sınırlandırılmalı, kayıt aktarımı şifrelenmeli ve logların izinsiz değiştirilmesini zorlaştıran kontroller uygulanmalıdır.
Saklama süresi “mümkün olduğu kadar uzun” şeklinde belirlenmemelidir. Yasal yükümlülük, güvenlik araştırması ihtiyacı, depolama maliyeti ve veri minimizasyonu birlikte değerlendirilir. Aktif dosyaları elle silmek servisin yazma davranışını bozabilir ve soruşturma kanıtını yok edebilir. Boyut ve süre yönetimi için logrotate benzeri döndürme politikaları kullanılmalı; silme işlemi onaylı saklama planına bağlanmalıdır.
Log bütünlüğü de önemlidir. Sunucuyu ele geçiren bir saldırgan yerel kayıtları değiştirebilir. Kritik güvenlik günlüklerini gecikmeden ayrı, erişimi sınırlı bir sisteme aktarmak riski azaltır. Yedek ile log arşivi aynı amaçta değildir; arama, bütünlük ve saklama politikaları ayrı tasarlanmalıdır.
Adım Adım Log İnceleme Akışı
- Belirtiyi, etkilenen kullanıcıyı, URL’yi ve kesin zaman aralığını kaydedin.
- Sunucu saat dilimi ile olayın bildirildiği saat dilimini eşleştirin.
- İlgili web, uygulama, sistem, kimlik veya mail kaynağını seçin.
- Örnek isteği IP, kullanıcı, kuyruk kimliği ya da request ID ile filtreleyin.
- Olaydan önceki değişiklikleri, servis yeniden başlatmalarını ve kaynak kullanımını kontrol edin.
- Hata mesajını aynı saniyedeki diğer servis kayıtlarıyla ilişkilendirin.
- Bir hipotez kurun, geri alınabilir tek değişiklik yapın ve aynı senaryoyu yeniden test edin.
- Nedeni, çözümü ve izleme kuralını olay kaydına ekleyin.
Sunucu yeniden başladıysa önce yeniden başlatmanın planlı olup olmadığı, açılış zamanı, başarısız servisler, disk dosya sistemi ve bellek olayları incelenmelidir. Ardından uygulama bağımlılıklarının doğru sırada ayağa kalktığı doğrulanır. Otomatik kullanıcı girişi gibi bir belirti varsa kimlik doğrulama ve zamanlanmış görev kayıtları ayrıca kontrol edilmelidir.
Sık Sorulan Sorular
Sunucunun IP logları nerede tutulur?
Kaynak IP bilgisi genellikle web access log, güvenlik duvarı, proxy/CDN ve kimlik doğrulama kayıtlarında bulunur. Kesin konum kullanılan servis ve yapılandırmaya bağlıdır. Proxy arkasında gerçek istemci IP’sinin güvenilir başlıktan doğru biçimde alınması gerekir.
Log dosyaları güvenle silinebilir mi?
Aktif dosyaları doğrudan silmek önerilmez. Önce saklama yükümlülüğü, olay incelemesi ve servis davranışı kontrol edilmeli; ardından döndürme ve arşiv politikası kullanılmalıdır. Disk acil biçimde doluyorsa nedeni belirleyip kontrollü müdahale yapılmalıdır.
Loglarda kritik hata nasıl anlaşılır?
Seviye etiketi ipucu verir, fakat gerçek önem etkiye bağlıdır. Tekrarlanan servis çökmesi, veri kaybı riski veya çok sayıda kullanıcıyı etkileyen 5xx artışı yüksek önceliklidir. Tek bir “critical” sözcüğünü bağlamdan koparmadan zaman çizelgesiyle değerlendirin.
Logları düzenli biçimde toplamak, bir sorun çıktığında ilk kez dosya yolu aramaktan daha etkilidir. Küçük bir başlangıç için kritik servisleri, ortak saat ayarını, saklama süresini ve birkaç eyleme dönük alarmı belgeleyin. Ardından gerçek olaylardan öğrendikçe filtreleri ve kontrol listesini geliştirin; böylece kayıtlar yalnız geçmişi anlatan dosyalar değil, operasyon kararlarını destekleyen bir araç hâline gelir.
