Küçük ligler — amatör e-spor ligleri, yerel oyun sunucuları veya bölgesel turnuva altyapıları — genellikle büyük işletmelerin sahip olduğu geniş izleme kaynaklarına sahip değildir. Ancak doğru metriklerle, sınırlı bütçeyle bile çöküşleri ve performans düşüşlerini önceden fark edebilirsiniz.
Giriş: Neden basit ve etkili metrikler yeterli?
Her gün binlerce bağlantı yönetmeyen küçük lig altyapıları için amaç, karmaşık gösterge setleri değil; erken uyarı veren, eyleme dönüştürülebilir göstergeler kurmaktır. Aşağıda, hemen kurabileceğiniz 10 metrik ve her biri için ölçüm, tipik eşikler, Prometheus/Grafana örnekleri ve müdahale adımları bulacaksınız.
Listicle: 10 Kritik Metriğe Genel Bakış
- Sunucu CPU Kullanımı (ortalama ve spike)
- Sunucu Bellek Kullanımı ve Swap Aktivasyonu
- Disk I/O ve Disk Doluluk Oranı
- Network Latency (RTT) — Hem iç ağ hem kullanıcı yönlü
- Packet Loss & Jitter (oyun/voIP için kritik)
- TCP/UDP Connection Count ve Listen Queue
- Uygulama Hata Oranı (5xx, işlem başarısızlıkları)
- Database Query Latency ve Slow Queries
- Synthetic Health Checks / Uptime ve RTT testleri
- Process Restarts ve Garbage Collection (JVM/Node vb.)
1. Sunucu CPU Kullanımı
Neden önemli: CPU tıkanmaları oyun döngülerini, eşleştirme servislerini ve web arayüzlerini yavaşlatır. Spike'ler kısa süreli kesintilere ve artan latency'ye yol açar.
Nasıl ölçülür: node_exporter veya benzeri ile node_cpu_seconds_total kullanın; ortalama % ve 1/5/15 dakikalık trendleri izleyin.
Örnek eşik: 5 dakikalık ortalama % CPU > 80% veya tekil coreda %95 spike — uyarı ver.
PromQL örneği (ortalama 5m): 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
Müdahale: CPU-bound süreçleri profilize edin, oyun loop optimizasyonu, instance ölçeklendirme veya cron işlerini yeniden zamanlayın.
2. Bellek Kullanımı ve Swap Aktivasyonu
Neden önemli: Bellek baskısı swap kullanımına yol açarsa performans dramatik şekilde düşer. Oyun sunucularında bellek tahsisi kritik.
Nasıl ölçülür: node_memory_MemAvailable_bytes ve node_memory_SwapUsed_bytes. Swap artışı bir alarm sebebidir.
Örnek eşik: Kullanılabilir bellek < %15 veya swap > 0 aktifse uyarı oluşturun.
Remedy: Bellek sızıntılarını bulma, JVM heap/GC ayarları, instance yükseltme veya daha iyi bellek yönetimi.
3. Disk I/O ve Disk Doluluk
Neden önemli: Log yazma gecikmeleri, veritabanı yavaşlıkları veya oyun save'lerinde gecikme oluşur.
Nasıl ölçülür: node_disk_io_time_seconds_total, node_disk_read_bytes_total, node_filesystem_avail_bytes.
Örnek eşik: Disk kullanım > %85 veya I/O wait süresi artışı (iowait CPU > %10) — uyarı verin.
Müdahale: Disk temizliği, log rotasyonu, SSD yükseltme veya IOPS artırımı.
4. Network Latency (RTT)
Neden önemli: Oyuncu deneyimi doğrudan latency ile bağlantılıdır. İç ağda artan RTT sunucu arası synchronizasyonda sorun yaratabilir.
Nasıl ölçülür: ICMP/ICMP-v6 veya uygulama seviyesinde ping (synthetic checks). Prometheus blackbox_exporter veya ping exporter kullanın.
Örnek eşik: Ortalama RTT kullanıcı yönünde > 100 ms veya iç ağda > 20 ms — uyarı oluşturun.
Grafana paneli: Time series + heatmap; kullanıcı konumuna göre breakdown.
5. Packet Loss & Jitter
Neden önemli: Özellikle gerçek zamanlı oyun ve ses için packet loss ve jitter kabul edilemezdir.
Nasıl ölçülür: ping testlerinin packet loss yüzdesi, RTP stream izleme veya ağ cihazı SNMP istatistikleri.
Örnek eşik: Paket kaybı > %1 (ses için), jitter > 30 ms — acil uyarı.
Müdahale: QoS ayarları, trafik şekillendirme, ISP ile görüşme veya yol seçimi değiştirme.
6. TCP/UDP Connection Count ve Listen Queue
Neden önemli: Çok sayıda yarım açık bağlantı veya dolu listen queue yeni oyuncuların bağlanmasını engeller.
Nasıl ölçülür: netstat/snmp veya exporter'lar; tcp_connections{state="established"} gibi metrikler.
Örnek eşik: SYN backlog doluysa veya connection count beklenenin 3x'ine çıkarsa uyarı.
Müdahale: Keepalive, connection timeout ayarları, load balancing veya ek oyun server örneği ekleme.
7. Uygulama Hata Oranı (5xx ve işlem hataları)
Neden önemli: 5xx hataları sunucu tarafı problemlerin açık göstergesidir. Kullanıcı memnuniyeti hızlı düşer.
Nasıl ölçülür: Uygulama metrikleri (Prometheus client) veya APM logları; 5xx yüzdesi / istek sayısı.
Örnek eşik: 5xx oranı > %1 sürekli 5dk ise alarm.
Müdahale: Log analizi, stack trace inceleme, rollback veya servis yeniden başlatma.
8. Database Query Latency
Neden önemli: Veritabanı oyun lobby, kullanıcı profili ve eşleştirme için merkezi olabilir. Sorgu gecikmeleri zincirleme sorunlara neden olur.
Nasıl ölçülür: Slow query logları, histogramlar (Prometheus Histogram veya Summary), p99/p95 latencies.
Örnek eşik: p95 > 300ms veya ani p99 yükselişi — uyarı verin.
Müdahale: Index optimizasyonu, query rewrite, cache kullanımı veya DB ölçeklendirme.
9. Synthetic Health Checks / Uptime
Neden önemli: Gerçek kullanıcı gözünden basit availability testleri (login, matchmake) sorunları doğrudan gösterir.
Nasıl ölçülür: Blackbox tests, uptime robot benzeri synthetic testler, her 30s veya 1m aralıklarla.
Örnek eşik: 2 ardışık check failure veya RTT artışı > %50.
Müdahale: Otomatik failover, trafik yönlendirme veya manuel müdahale akışı tetikleme.
10. Process Restarts ve Garbage Collection
Neden önemli: Sık process restart'ları veya uzun GC duraklamaları hizmet kesintisine sebep olur.
Nasıl ölçülür: Process exporterlardan restart count, JVM GC pause times, Node.js event loop latency.
Örnek eşik: 1 saat içinde 3'ten fazla restart veya GC pause > 200ms p99 — uyarı ver.
Müdahale: Memory tuning, daha uygun GC parametreleri, process supervisor (systemd) ile restart limitleri, rolling redeploy.
Panoyu Hemen Kurmak: Örnek Dashboard Yerleşimi
- Üst satır: Global health (synthetic checks, uptime, total active players)
- İkinci satır: Alt yapı (CPU, Memory, Disk, IOWait)
- Üçüncü satır: Ağ (RTT, packet loss, jitter, connection count)
- Dördüncü satır: Uygulama (5xx, DB latency, process restarts)
- Sağ panel: Olay geçmişi ve son 24 saat kritik uyarılar
Grafana'da her panel için threshold'ları renk kodlayın (yeşil/sarı/kırmızı) ve açıklayıcı tooltip ekleyin.
Uyarı Stratejisi: Gürültü Azaltma ve Eyleme Dönüştürülebilir Uyarılar
Her uyarının anlamlı olması için:
- Çok kısa spike'lar için 2-5 dakikalık sustain kontrollleri kullanın.
- Aynı anda ilgili metriklerde multi-condition uyarılar (ör. CPU yüksek + 5xx artışı) oluşturun.
- Alert deduplication, silence ve eskalasyon politikası kurun.
- İlk uyarı kanalı olarak Slack/Discord, kritik için SMS/phone ekleyin.
İzleme Araçları ve Hafif Entegrasyon Önerileri
Hızlı kurulum için düşük maliyetli araç kombinasyonları:
- Prometheus + node_exporter + blackbox_exporter (metrik + synthetic)
- Grafana (dashboard), Alertmanager (uyarı yönetimi)
- Netdata veya Telegraf + InfluxDB (daha hafif alternatifler)
- SNMP veya sFlow ile ağ cihazları izlenebilir.
Küçük ligler için öneri: Önce 3–4 temel metrik (CPU, Memory, RTT, 5xx) ile başlayın; seviyeyi kademeli genişletin.
Pratik Örnek: Prometheus AlertRule (Basit)
CPU yüksekliği için örnek kural:
alert: HighCpuUsage expr: (100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80 for: 5m labels: severity: warning annotations: summary: "{{ $labels.instance }} CPU kullanımı yüksek"
Sonuç: Önlem, Müdahale, Öğrenme Döngüsü
Küçük lig altyapılarında izleme; alarm yağmuru değil, hızlı, uygulanabilir içgörüler üretmeli. Yukarıdaki 10 metriği önceliklendirin, basit bir dashboard ile başlayın ve her uyarı sonrası post-mortem yaparak eşiklerinizi ve runbook'ları geliştirin.
Unutmayın: İyi bir gösterge panosu çöküşleri %100 engellemez ama müdahale süresini kısaltır, kullanıcı deneyimini korur ve operasyonel maliyeti düşürür.
Hemen uygulamak için öneri: Prometheus + Grafana ile ilk haftada CPU, Memory, RTT ve synthetic checks panosunu kurun. İkinci hafta disk ve DB metriklerini ekleyin; üçüncü hafta alert oynatma ve runbook'ları test edin.