Gece 3’te CPU %100 Olduğunda Öğrendiğim Şey: Monitoring Olmadan Sistem Yönetilmiyor

Sistem yöneticiliğinde birçok şeyi dokümantasyonlardan öğrenebilirsiniz ama bazı problemler vardır ki ancak canlı sistemde yaşayınca gerçekten oturuyor. Benim için bunlardan biri monitoring konusu oldu.

Özellikle ilk yıllarımda “sunucu çalışıyorsa sorun yoktur” mantığıyla ilerliyordum. CPU normal görünüyorsa, servisler açıksa ve kullanıcıdan şikayet gelmiyorsa sistemi sağlıklı kabul ediyordum. Gerçekte ise production ortamı böyle işlemiyor.

Bir gece gelen yüksek load alarmıyla başlayan olay, monitoring tarafına bakış açımı tamamen değiştirdi.

---

Problem Aslında CPU Değildi

Gece yaklaşık 03:00 civarında bir sunucuda load average aniden yükseldi.

İlk bakışta klasik bir CPU problemi gibi görünüyordu:

top

çıktısında birkaç PHP process’i sistemi tüketiyordu.

İlk refleks olarak process kill etmek kolaydı ama bu yaklaşım genelde problemi çözmüyor, sadece semptomu geçici olarak gizliyor.

Biraz log inceleyince olayın CPU değil, anormal trafik olduğunu fark ettim.

Nginx access log içinde aynı endpoint’e saniyede yüzlerce request geliyordu:

tail -f /var/log/nginx/access.log

İstekler gerçek kullanıcı gibi davranıyordu:

• Random user-agent
• Farklı IP blokları
• Geçerli cookie kullanımı
• Normal browser header’ları

İlk başta basit bot saldırısı gibi görünmedi.

---

O Gün Şunu Fark Ettim

Birçok kişi monitoring’i “grafik görmek” sanıyor.

Gerçekte monitoring’in amacı:

Sistemin normal davranışını öğrenmek.

Çünkü sistemi tanımıyorsanız anomalileri de fark edemiyorsunuz.

O geceden sonra sadece CPU ve RAM takip etmeyi bıraktım.

Şunları toplamaya başladım:

• Request distribution
• Upstream response süreleri
• 4xx / 5xx oranları
• ASN dağılımları
• Rate limit yoğunluğu
• Connection spike’ları
• PHP-FPM queue yoğunluğu
• Disk IO davranışı

Aslında sorunların çoğu kaynak tüketimi başlamadan önce sinyal veriyor.

---

En Büyük Hata: Ortalama Değerlere Bakmak

Özellikle yeni başlayanlarda çok görüyorum:

CPU %20 görünüyor, sistem rahat.

Ama ortalama değerler bazen hiçbir şey anlatmaz.

Örneğin:

• CPU kısa süreli spike yaşıyor olabilir
• IO wait yükseliyor olabilir
• Worker process’ler kilitleniyor olabilir
• Queue büyüyor olabilir

Bunlar birkaç dakikalık pencerelerde kaybolabiliyor.

Production ortamında önemli olan ortalama değil davranış değişimi.

---

False Positive Meselesi

Monitoring tarafında en zor konulardan biri de doğru alarm üretmek.

İlk kurduğum sistemlerde sürekli alarm alıyordum.

CPU %70 → alarm RAM arttı → alarm Network spike → alarm

Bir süre sonra alarmlar tamamen “arka plan gürültüsü” olmaya başladı.

Gerçek problemi kaçırmaya başladım.

Sonra şunu fark ettim:

İyi monitoring sistemi çok alarm veren değil, anlamlı alarm veren sistemdir.

Özellikle production ortamında:

• Backup saatleri
• Cron yoğunlukları
• Cache rebuild süreçleri
• Search indexing

gibi normal davranışları tanımak gerekiyor.

---

Sadece Sunucuyu Değil Trafiği de İzlemek Gerekiyor

Bir noktadan sonra sistem problemlerinin çoğunun aslında uygulama veya trafik davranışından kaynaklandığını fark ettim.

Örneğin bir dönem CPU problemi yaşadığımızı düşünüyorduk ama asıl problem şuydu:

Belirli ASN’lerden gelen botlar sürekli search endpoint’lerini tarıyordu.

Sunucu crash olmuyordu ama:

• Cache verimsizleşiyordu
• PHP worker’lar doluyordu
• MySQL query süreleri uzuyordu

Bu tarz durumlarda yalnızca resource monitoring yeterli olmuyor.

Traffic behavior monitoring gerekiyor.

---

Log Korelasyonu Her Şeyi Değiştiriyor

Gerçek problemleri çoğu zaman tek log dosyasıyla anlayamıyorsunuz.

Örneğin:

• Nginx access log
• PHP-FPM slow log
• MySQL slow query log
• System load
• Network connection count

birlikte incelenince olay netleşiyor.

Bir süre sonra şunu fark ettim:

Production’da problem çözmenin büyük kısmı aslında korelasyon kurmak.

Çünkü çoğu arıza tek noktada oluşmuyor.

---

Küçük Sorunlar Büyümeden Görülmeli

Monitoring’in en büyük avantajı sistem çökünce haber vermesi değil, çökmeden önce davranış değişimini göstermesi.

Örneğin:

• Disk IO normalden %15 farklı çalışıyorsa
• Cache hit ratio düşüyorsa
• Response süreleri yavaş yavaş artıyorsa

bunlar genelde yaklaşan problemin habercisi oluyor.

En kritik sorunlar çoğu zaman aniden oluşmuyor, yavaş yavaş büyüyor.

---

Sonuç

Zamanla şunu öğrendim:

Sistem yönetimi sadece servis çalıştırmak değil, sistemi tanımak.

Monitoring tarafında ne kadar görünürlük varsa problemi çözmek de o kadar kolaylaşıyor.

Bugün bir sunucu kurduğumda ilk düşündüğüm şey artık şu oluyor:

Bu sistemde problem çıktığında bunu nasıl anlayacağım?

Çünkü production ortamında en değerli şey bazen performans değil, görünürlük oluyor.