Sunucu Loglarından Anormallik Tespiti: Net İzleme Rehberi

Sunucu logları, performans düşüşü ve güvenlik olaylarını “önce sinyal, sonra hasar” şeklinde yakalamanın en pratik yoludur. Bu rehberde Nginx/Apache, uygulama, sistem ve güvenlik loglarından anormallik tespit etmeyi; hangi alanlara bakacağınızı, hangi eşiklerle hareket edeceğinizi ve nasıl aksiyon planı oluşturacağınızı öğreneceksiniz. Hedef, log okuyarak belirsiz durumlarda karar vermeyi kolaylaştırmak ve aynı hatayı yeniden üretmeden hızlı müdahale etmektir.

Ne zaman log izleme anormallik için “zorunlu” olur?

Aşağıdaki durumlarda yalnızca “web sitesi yavaş açılıyor” demek yerine loglardan nedenini netleştirmek gerekir:

Tekil kullanıcı etkisi yokken tüm isteklerde gecikme artışı görülüyorsa
CPU/RAM artışı ile aynı zaman aralığında hata oranı yükseliyorsa
HTTP 4xx/5xx oranı aniden sıçrıyorsa
Sunucuda yeniden başlatma (reboot) ya da servis restart kayıtları varsa
Güvenlik tarafında başarısız SSH denemeleri veya anormal istek paterni görüyorsanız

Log izleme, “olayı kronolojiye oturtma” işidir. Doğru zaman aralığı, doğru kaynak dosyası ve doğru filtre ile anormallik tespiti hızlanır.

Log kaynakları: Anormallik türüne göre nereye bakılır?

Anormallikleri tek bir logla yakalamak genellikle mümkün değildir. Türüne göre mantıklı sıralama şu şekildedir:

1) Web katmanı (Nginx/Apache)

Nginx access log: Status kodları, kaynak IP, path, istek hacmi
Nginx error log: Upstream hataları (502/504), zaman aşımı, TLS sorunları
Apache access/error: Benzer metrikler, farklı formatlar

Hızlı kontrol için hedefler: - 401/403 artışı (kimlik doğrulama / WAF / yetki) - 404 artışı (yanlış route taraması olabilir) - 429 artışı (rate limit) - 502/503/504 artışı (upstream servis sağlığı)

2) Uygulama katmanı (Node.js, PHP-FPM, Java vb.)

Uygulama logları: exception mesajları, stack trace, iş kuyruğu (queue) beklemeleri
PHP-FPM: “pool is exhausted” benzeri mesajlar
Node.js: event loop gecikmesi, timeout, out-of-memory sinyalleri

3) Sistem katmanı (kernel, journal)

dmesg / kernel: disk hataları, I/O gecikmesi, OOM (Out Of Memory)
system log / journalctl: servis restartları, cron aktiviteleri, fail2ban kararları

4) Güvenlik ve erişim (SSH, auth)

auth.log veya journald: başarılı/başarısız girişler
sudo kullanımı: yetki yükseltme davranışları
fail2ban (kullanıyorsanız): ban kararları ve tekrar eden IP paterni

Anormallik tespiti için net metrikler ve eşikler

“Bakılacak şeyler” net olmalı. Aşağıdaki metrikler, çoğu senaryoda anormalliğin erken göstergesidir.

Hız ve hata metrikleri

Ölçüm birimini seçin (dakika bazlı / 5 dakika bazlı) ve şu oranları takip edin:

5xx oranı = 5xx istek / toplam istek
4xx oranı = 4xx istek / toplam istek
Yüksek gecikme = p95 veya p99 (varsa)

Pratik eşik seti (başlangıç): - 5xx oranı normal seviyesine göre 3 kat artarsa - 5xx sayısı 5 dakika içinde beklenenin 2 katına çıkarsa - 401/403 artışı 10 dakikadan uzun sürerse

Kaynak ve hacim metrikleri

Ortalama istek sayısında ani artış (özellikle tek bir path’te)
Tek IP’nin istek payının hızla yükselmesi
Aynı yanıt kodunun tek path’te tekrar etmesi (ör. sürekli 404)

Sistem kaynak metrikleri

Log ile birlikte sistem metriklerini de zaman damgasıyla eşleştirin: - CPU steal time (cloud ortamında), yük ortalaması - RAM kullanımı + OOM sinyalleri - Disk I/O gecikmesi (I/O wait) - Network retransmit / bağlantı kopmaları

Logları filtreleyerek hızlı kök neden (root cause) bulma

Anormallik tespiti için en iyi yöntem “önce sinyali bul, sonra genişlet” yaklaşımıdır. Aşağıdaki adımlar bu sırayı verir.

1) Zaman penceresini sabitle (en kritik adım)

İlk iş, kullanıcı şikayetinin veya izleme uyarısının başladığı an ile bitiş anını belirleyin.

Örnek: “02:10 ile 02:25 arası yavaş açılıyordu.”
Loglarda aynı pencere içinde hata sayısını ve tekrar eden kalıpları karşılaştırın.

2) Status kodlarına göre ayırın

Web erişim loglarından status kodlarını ayırın. Amaç: “sorun hata kodu mu, yoksa sadece trafik mi?”

Örnek (Nginx access log)

grep yerine log yapınıza göre awk / sed veya gözlem aracını tercih edin. Yine de pratik bir başlangıç şu mantıktadır:

Önce 5xx için filtre
Sonra en çok isabet alan path’leri çıkar

Örnek komut mantığı: - status=5xx olan satırları yakala - bu satırlarda en sık görülen path değerini say

Not: Log formatınız farklıysa path alanının hangi sütunda olduğunu belirlemeniz gerekir.

3) Error log ile upstream zincirini doğrulayın

5xx var ise, access log tek başına yeterli değildir. Aynı zaman penceresinde error log’a gidin: - Upstream connect timeout / refused - upstream sent no response - resolver / DNS sorunları - TLS handshake hataları

Bu aşamada aradığınız şey şudur: 5xx’in kaynağı. - Nginx mi uygulama mı? - Uygulama mı veritabanı mı?

4) Uygulama loglarında “ilk exception”ı bulun

Anormallik genelde çok hata üretir. Yapmanız gereken, her satırı değil ilk tetikleyiciyi yakalamaktır. - Aynı istek için zincir halinde oluşan hatalarda ilk exception - Timeout başladıktan sonra mı yoksa önce mi patladı - OOM ya da disk doluluğu gibi sistem etkileri var mı

5) Sistem loglarını “seri olay” olarak okuyun

Kernel/journal tarafında şu anormallikler kritik: - OOM kill - disk error / I/O error - servislerin restart döngüsü - disk alanı doluluğu (ENOSPC)

Güvenlik kaynaklı anormallikleri logdan nasıl ayırt edersiniz?

Güvenlik olayları çoğu zaman hata kodlarına ve trafik kalıplarına yansır. Ama tek başına 403 artışı her zaman saldırı demek değildir; sebep kimlik doğrulama hatası, yanlış token, bot taraması gibi farklı olabilir.

SSH anormalliği (auth log)

Aşağıdaki kalıplar net sinyaldir: - Aynı IP’den çok sayıda başarısız deneme - Farklı kullanıcı adları denemeleri (enumeration paterni) - Deneme saatlerinin düzenli olması (robot davranışı)

Aksiyon mantığı: - fail2ban (kullanıyorsanız) ban kayıtlarını kontrol edin - SSH için key-only giriş politikasına geçişi tamamlayın - gereksiz kullanıcı/port maruziyetini azaltın

Web uygulaması anormalliği (WAF olmadan da görülebilir)

Aynı path’te sürekli 404/400
Çok uzun User-Agent veya şüpheli header dizilimleri
Beklenmeyen içerik türleri (ör. JSON yerine farklı payload)

Net yaklaşım: - WAF logu yoksa bile access+error log birleşimiyle saldırı kalıbını çıkarın - Aynı zaman penceresinde uygulama exception’larını eşleyin

Anormalliği izleme ve aksiyon planı: Tek sayfalık kontrol listesi

Aşağıdaki listeyi, her uyarıda aynı sırayla uyguladığınızda karar verme standardize olur.

Kontrol listesi (5 adım)

Zaman penceresi: Uyarı başladığı andan itibaren 10-20 dk genişlet
Access log: 4xx/5xx oranı ve en sık path
Error log: upstream / timeout / TLS / backend hatası türü
Uygulama log: İlk exception + ilgili request id (varsa)
Sistem log: OOM, disk dolu, I/O error, servis restart

Aksiyon planı (örnek)

Upstream timeout: uygulama seviyesinde yavaş sorgu, thread pool tıkanması veya veritabanı gecikmesi kontrol edilir
502: uygulama yanıt üretmiyor veya connection kapanıyor; upstream health ve process sayısı incelenir
OOM: uygulama memory leak veya yanlış cache; heap ayarı ve sınırlama yapılır
Disk dolu: log rotasyonu (logrotate) ve veri tutma politikası güncellenir

Pratik araçlar: Logları tek tek okumak yerine görünürlük kurun

Log dosyaları büyüdükçe manuel grep yaklaşımı yavaşlar. Bu noktada amaç, aynı metrikleri tekrar tekrar çıkarmayı otomatikleştirmektir.

“Minimum kurulum” yaklaşımı

Log rotasyonu aktif mi (büyüyen dosya kontrolü)
Zaman damgası senkronu var mı (NTP)
logların merkezi bir yere akışı (tek sunucuda kalmıyorsa)

Merkezi loglama (örnek mimari)

Uygulama ve web sunucusundan logları gönderin
Arama ve filtrelemeyi aynı arayüzde yapın
Dashboard’ta 5xx/4xx ve spesifik hata mesajlarını saat/dk bazında görün

Bu yaklaşımın getirisi şudur: anormallik çıktığında “hangi satırlar” değil, hangi desen olduğu hızlı görülür.

Sunucu konfigürasyonu: Logların anormalliği yakalayacak kadar “detaylı” olması

Anormalliği tespit etmenin şartı, logların doğru seviyede üretilmesidir.

Web sunucusu: error log seviyesi çok düşükse upstream hatası görünmez
Uygulama: exception bilgisi eksikse kök neden bulunamaz
Sistem: OOM ve disk hatası gibi olaylar için journal erişimi kısıtlıysa kritik sinyal kaçırılır

Net hedef

Problem başladığında ilk 5-10 dakikada hata türü belirlenebilmeli
En azından request path, status kodu ve zaman damgası korunmalı
Sistem tarafında kernel/journal olayları erişilebilir olmalı

Sonuç: Her uyarı için standart bir “log tabanlı” akış kurun

Sunucu loglarını anormallik tespitinde etkili kullanmak için tek ihtiyacınız “her şeyi okumak” değil, sabit bir zaman penceresiyle access+error+uygulama+sistem loglarını sırayla eşleştirmek. İlk 2-3 haftada, en sık yaşadığınız arıza türleri için (5xx artışı, timeout, OOM, disk doluluğu, SSH denemeleri) kontrol listeni somutlaştırın. Sonra izleme uyarıları geldiğinde aynı akışı takip edin: zaman penceresi → status kodları → error mesajları → ilk exception → sistem sinyali. Bu standardizasyon, kök nedeni hızlı bulmanızı ve aynı hatayı yeniden üretmeden çözmenizi sağlar.