Sunucu Loglarından Anormallik Tespiti: Net İzleme Rehberi

Sunucu loglarını izlemek, arıza bildirimini beklemek yerine problemi olmadan önce yakalamanın en net yoludur. Doğru log kaynağını seçmek, anomaliyi “gürültü”den ayırmak ve düzenli bir aksiyon akışı kurmak gerekir. Bu rehberde, Linux ve yaygın hosting senaryolarında loglardan anormallik tespiti için uygulanabilir bir kontrol listesi ve örnek metrikler göreceksin.

1) Anormallik tespiti için doğru log türlerini seç

Anormallik tespiti, tek bir dosyaya bakmakla olmaz. Önce sistemin hangi katmanında risk aradığını tanımlarsın: ağ, sistem, güvenlik, uygulama ve servis. Aşağıdaki tablo pratik bir başlangıç haritasıdır.

Katman	Log kaynakları (örnek)	Tipik anormallik sinyali
Sistem/Kernel	`journalctl`, `/var/log/syslog`, `dmesg`	OOM (out of memory), kernel panic, disk I/O hataları
Kimlik doğrulama	`/var/log/auth.log`, `journalctl -u ssh`	Çoklu başarısız SSH denemesi, şifre deneme artışı
Web erişimi	`nginx/access.log`, `apache/access.log`	404 dalgası, alışılmadık user-agent, artan 5xx
Web hata	`nginx/error.log`, `apache/error.log`	“Upstream timed out”, PHP-FPM 502/504
Uygulama	`php-fpm`, `queue`, uygulama logları	Retry döngüleri, pattern’li exception
Veritabanı	`mysql/error.log`, `postgresql/*`	lock contention, yavaş sorgu artışı
Zamanlayıcı	cron logları	Cronjob çalışmıyor, tekrar eden hata
Sistem süreçleri	`systemd` unit logları	servis yeniden başlatma (restart loop)

Hedefi netleştir: “Ne bozulunca ne fark edilir?”

Anomaliyi tanımlamadan eşik koyamazsın. Örneğin hedefin: - Erişim artışı değil, “bot gibi davranan trafik” ise web access log + user-agent + HTTP status dağılımı izlenir. - “Uygulama çöktü” değil, “yavaşlamaya geçiş başladı” ise CPU yükü değil; response süresi dağılımı ve 4xx/5xx oranındaki trend izlenir.

2) Log toplama ve standardizasyon: tek yerde görünürlük kur

Sunucu loglarını anormallik için kullanmak istiyorsan, farklı dosyaları elle açıp karşılaştırmak yerine bir toplama standardı gerekir. En azından şu iki noktayı kur:

Log formatını tutarlı yap: Nginx/Apache’de mümkünse yapılandırılmış (ör. access log common/default değil, derlenen alanları içeren) format.
Zaman damgası senkronu: Sunucu saati hatalıysa anomali analizi kırılır. NTP/chrony ile saat doğruluğunu kontrol et.

En pratik yöntem: journal + servis loglarını birlikte ele al

Birçok VDS/VPS kurulumunda her şey sistemd ile akar. Şu yaklaşımı benimsersen analizin hızlanır: - Önce servis birimlerinin loglarını (örn. nginx, php-fpm, mysql) ayrı takip et. - Sonra güvenlik ve sistem loglarını aynı zaman çizelgesinde incele.

Örnek komut yaklaşımı: - journalctl -u nginx --since "30 days ago" - journalctl -u ssh --since "7 days ago" - journalctl _SYSTEMD_UNIT=php-fpm* --since "7 days ago"

Not: Bu komutları çalışma saatlerine ve log boyutlarına göre kısıtlamak gerekir. Aksi halde taramalar uzar.

3) Anomali eşikleri: “tek seferlik hata” ile “trend bozulması”nı ayır

Anormallik tespiti için en kritik parça eşik mantığıdır. Tek bir 500 hatası genellikle servis sağlayıcı değil uygulama hatası olabilir; trend ise risk sinyalidir.

Aşağıdaki metrikler hosting için en uygulanabilir örneklerdir:

Web erişimi (Nginx/Apache)

5xx oranı (dakikalık): Ortalama değerini al, belirgin artışı alarm yap.
404/403 artışı (günlük): Ani yükseliş tarama/bot veya yanlış yönlendirme belirtisi olabilir.
Upstream timeout (örn. upstream timed out): Uygulama veya arka plan servis tıkanıklığına işaret eder.

SSH ve kimlik doğrulama

başarısız login denemesi sayısı (15 dk/1 saat)
Aynı IP’den yoğun deneme sayısı
Başarılı girişlerin alışılmadık saat/dosya modeli

Sistem kaynakları

OOM (out of memory) olayları
Disk I/O hataları (örn. “blk_update_request” benzeri kernel mesajları)
CPU steal / iowait trend artışı (özellikle sanallaştırılmış ortamda)

Veritabanı

Lock bekleme süreleri (lock wait)
Yavaş sorgu sayısı (dakikalık)
Bağlantı sayısında ani artış (pool davranışı)

Basit eşik kuralı (başlangıç için)

Eşikleri sıfırdan üretmek yerine önce “normal”i görmek gerekir. 7 gün veri topla ve şu kuralı uygula: - “Normal bant”: son 7 günün medyanı ve %75-%95 aralığı - Alarm: medyanın X katı veya %Y üzeri artış + minimum deneme hacmi

Örnek mantık (net başlangıç): - 5xx oranı > %1 ve aynı 15 dk’da toplam istek > 500 ise alarm - SSH başarısız denemesi > 30/15 dk ise alarm - OOM olayı 24 saatte > 0 ise kritik alarm

4) Filtreleme ve arama: yüzlerce satırdan “sebebe” in

Loglar büyüdükçe “gözle okuma” imkânsızlaşır. Anomaliyi yakaladıktan sonra hızlı kök neden bulma için filtreleme şart.

Önce zaman penceresi, sonra anahtar kelime

İlk adım: 1. Alarmın geldiği saat aralığını daralt. 2. O saat aralığında en çok tekrar eden hataları çıkar.

Pratik olarak şu desenler çok iş yapar: - Web: " 502 ", " 503 ", " upstream timed out", " client intended to send too large" - Uygulama: Exception, Traceback, Fatal, OutOfMemory - DB: lock wait timeout, deadlock, too many connections - Sistem: Out of memory, disk I/O error, reset, segfault

En sık tekrar edenleri listele

Bir anormallik tespit ettiğinde hedef “en sık hata türü”dür. Bu sayede yanlış alarm (tekil hata) ile gerçek problem (çoklu tekrar) ayrılır.

Örnek: Nginx access log’ta 5xx oranı arama mantığı

Elinde doğrudan metrik aracı yoksa bile şu yaklaşım çalışır: - Alarm saatinde 5xx status barındıran satırları say. - Aynı saat aralığında toplam istek sayısına böl. - Bir önceki güne aynı saat aralığıyla karşılaştır.

Bu karşılaştırma, “trafik arttı diye 5xx de arttı” durumunu ayıklar.

5) Alarm kurma: log tabanlı tespiti aksiyona dönüştür

Log izleme ancak aksiyonla değer üretir. Net bir alarm tasarımı, gereksiz bildirimleri azaltır ve ekibin doğru zamanda doğru hamleyi yapmasını sağlar.

Alarm hiyerarşisi

Bilgi (warning): trend sinyali (ör. 5xx artıyor ama servis tamamen düşmedi)
Kritik (critical): servis etkileniyor (örn. uptime düşüyor, OOM yaşanıyor)
Güvenlik: şüpheli deneme artışı, anormal ülke/IP dağılımı

Bildirim kanalı ve içeriği standartlaştır

Her alarm mesajında şu bilgiler olmalı: - Zaman (timezone dahil) - Etkilenen servis (nginx, php-fpm, mysql) - Ölçülen metrik + değer - En sık 3 hata örneği (logdan kısa snippet) - İlgili sunucu IP/hostname

Bu formatı standart yaparsan aynı alarmı tekrar tekrar yorumlamazsın.

6) Aksiyon planı: Alarm sonrası sıralı kontrol listesi

Anormallik yakaladığında “rastgele denemek” yerine adım adım ilerlemek gerekir. Aşağıdaki akış, en sık hosting problemlerinde hızlı kök neden buldurur.

6A) Web 5xx artışı alarmı

nginx error log: upstream timeout / connect error var mı?
php-fpm log: child process sayısı tükeniyor mu?
Disk ve CPU: iowait artışı var mı? CPU throttling var mı?
Veritabanı: bağlantı sayısı veya lock problemi artmış mı?
Cache kullanımı varsa: cache hit oranı düşüyor mu?

6B) SSH başarısız denemesi alarmı

Aynı IP blokajı var mı? (fail sayısına göre)
Şifre denemesi mi, anahtar (key) denemesi mi?
Kullanıcı listesi değişti mi?
Rate-limit / fail2ban benzeri koruma devrede mi?

SSH güvenliği için şifre tabanlı giriş kapatma ve key ile erişim kullanımı gibi önlemler, bu alarm türünün tekrarını azaltır.

6C) Sistem OOM veya servis restart loop alarmı

OOM olayının hangi servisle ilişkili olduğu loglarda net mi?
Bellek limitleri (container/cgroup veya systemd limitleri) doluyor mu?
Swap kullanımına rağmen RAM tükeniyor mu?
Uygulama heap/cache büyüyor mu? (ör. memory leak)

Bu noktada “loglardan anormalliği görmek” ile “bellek ayarı/servis limitleri” aynı sürecin parçasıdır.

7) Log tabanlı anormallik tespitinde sık yapılan 6 hata

Bu bölüm, iyi kurulum ile işe yaramayan kurulum arasındaki farkı verir.

Sadece tek log dosyasına bakmak: Örn. sadece access log izlemek, DB kaynaklı yavaşlıkta yetersiz kalır.
Eşikleri güncellememek: Trafik mevsimseldir; sabit eşik false alarm üretir.
Saat senkronu yokluğu: Yanlış saat dilimi, “neden ne zaman oldu” analizini bozar.
Log saklama süresinin kısa olması: Kök neden için geri tarih gerekir.
Alarm mesajını standartlaştırmamak: Her alarm farklı formatta gelirse ekip zaman kaybeder.
Aksiyon akışının yazılı olmaması: Alarm var ama “şu sırayla kontrol et” yoksa müdahale gecikir.

Sonuç: 7 günlük veriyle başlayıp aksiyonlu alarm kur

Sunucu loglarından anormallik tespiti, doğru log seçimi + ölçülebilir eşikler + alarmı aksiyona dönüştürme kombinasyonudur. Uygulama önerim net: Önce 7 gün boyunca web/SSH/sistem/DB loglarındaki temel metrikleri topla, sonra 3 senaryoyu (web 5xx artışı, SSH deneme artışı, OOM/restart loop) kapsayan alarm hiyerarşisini kur. Alarm mesajını standartlaştır ve her alarm için kontrol sırasını yazılı hale getir; böylece her yeni olayda karar verme süresi kısalır.

İstersen mevcut altyapına göre (Nginx mi Apache mi, MySQL mi PostgreSQL mi, panel kullanıyor musun) hangi logların hangi formatla izleneceğini ve başlangıç eşiklerini birlikte netleştirecek bir kontrol listesi tasarlayabilirim.