Sunucu izleme ve etkili uyarı sistemi

Sunucu İzleme Neden Sadece Araç Değil, Bir Strateji Gerektirir

Çoğu teknik ekip sunucu izlemeyi ilk kurduğunda her şeyi izler: CPU, RAM, disk, ağ, servisler. Sonuç mu? İlk gün 40 uyarı alırlar, üçüncü gün 20 ve haftanın sonunda kimse uyarılara bakmaz. Bu "Uyarı Yorgunluğu" (Alert Fatigue) olarak bilinir ve gerçek bir kesintinin saatlerce sessiz kalmasına neden olan şey tam olarak budur.

Etkili sunucu izleme, neyi izleyeceğinizi, hangi eşiğin mantıklı olduğunu ve ne zaman gerçekten birini aramanız gerektiğini bilmek demektir. Bu makale pratik bir yol haritasıdır: temel metrikleri seçmekten yanıtlanmaya değer uyarılar ayarlamaya kadar.

Neyi İzlemeli? Gerçekten Önemli Olan Kritik Metrikler

Tüm metrikler aynı değere sahip değildir. 200 metriği izlemek sadece gürültü yaratır. Doğrudan kullanıcı deneyimi ve servis sağlığıyla ilişkili 5-7 temel metriğe odaklanmak çok daha iyi sonuç verir.

Temel Altyapı Metrikleri

• CPU: Ortalama yükü (Load Average) çekirdek sayısına göre ölçün. 4 çekirdekli bir sunucuda yük ortalaması 4'e ulaşırsa, CPU tamamen doymuş demektir. Ancak yüksek CPU her zaman kötü değildir; servisiniz video işleme veya ağır hesaplama yapıyorsa, %80 kullanım normaldir.
• RAM: Kullanım yüzdesi önemlidir, ancak daha da önemlisi swap kullanımıdır. Sistem takas yapmaya başlarsa, RAM gerçekten yetersiz demektir ve performans ciddi şekilde düşer. Takas için uyarı eşiğini %50 değil, %10 olarak ayarlayın.
• Disk: Diskin dolması, servis kesintilerinin en yaygın nedenlerinden biridir. Ancak %80'de uyarı vermek yerine büyüme hızını düşünün. Disk %70 doluysa ve günlük %2 büyüyorsa, 15 gün sonra sorun yaşarsınız. Uyarı, anlık duruma değil, tahmine dayanmalıdır.
• Ağ: Kullanılan bant genişliğini ve ağ arayüzü hatalarını (RX/TX errors) izleyin. Ağ hataları genellikle donanım veya kablo arızasının işaretidir ve tam kesintiden önce ortaya çıkar.

Servis Odaklı Metrikler

Altyapı sadece bir araçtır. Asıl önemli olan servisinizin sağlığıdır. Bu metrikleri mutlaka ekleyin:

• Çalışma Süresi (Uptime): Başka bir konumdan sitenize veya API'nize her 60 saniyede bir istek gönderen harici bir kontrol (External Check). Servisin kullanıcı açısından gerçekten ayakta olup olmadığını anlamanın tek yolu budur.
• Yanıt Süresi (Latency): Son 5 dakikadaki ortalama yanıt süresi. 500 milisaniyeden 2 saniyeye çıkarsa, CPU ve RAM sağlıklı olsa bile bir şeyler bozulmuş demektir.
• Uygulama Hataları: Web sunucusundaki 5xx hata sayısı veya uygulama hata günlükleri. Bu metrik genellikle bir hatanın veya bellek sızıntısının ilk işaretidir.
• Mesaj Kuyrukları (Message Queues): Redis veya RabbitMQ kullanıyorsanız, kuyruk uzunluğunu izleyin. Kuyruğun sürekli büyümesi, tüketicinin (Consumer) çalışmadığı anlamına gelir.

Eşikleri Ayarlama: Doğru Sayıyı Nasıl Bulursunuz

Eşikleri tahminlere göre ayarlamayın. Doğru yöntem üç adımdan oluşur:

1. Temel Dönem (Baseline) Toplayın: Hiçbir uyarı olmadan en az 2 hafta veri toplayın. Normal koşullarda her metriğin ne kadar dalgalandığını görün.
2. Eşiği standart sapmanın 2-3 katına ayarlayın: CPU normalde %20 ile %40 arasında dalgalanıyorsa, uyarı eşiğini %50 değil, %70-80 olarak ayarlayın. Erken uyarılar sadece gürültü yaratır.
3. Eşiği zamanla ayarlayın: Her gerçek olaydan sonra, eşiğin erken mi yoksa geç mi uyarı verdiğini kontrol edin. Eşikler canlı olmalıdır, bir kez ayarlanıp unutulmamalıdır.

Pratik Örnek: Disk İçin Uyarı Ayarlama

500 GB diske sahip bir veritabanı sunucunuz olduğunu varsayalım. Önerilen yöntem:

# Aşamalı Uyarılar (Staged Alerts)
Warning:  disk kullanımı > %75  (Telegram'da bildirim, sayfa yok)
Critical: disk kullanımı > %85  (SMS + yöneticiye e-posta)
Emergency: disk kullanımı > %92 (Otomatik telefon araması, yalnızca nöbetçi ekip için)

# Büyüme hızına dayalı uyarı (tahmin için)
Günlük büyüme oranı > %1,5 ve kalan alan < 20GB ise → acil uyarı

Önemli not: Aşamalı uyarılar (Staged), ekibin her uyarının ne kadar acil olduğunu bilmesini sağlar. Tüm uyarılar aynıysa, ekip hızla duyarsızlaşır.

Akıllı Uyarı Sistemi: Daha Az, Ama Daha Etkili

Uyarı sisteminin amacı her küçük sorunu raporlamak değildir. Amaç, insan müdahalesi gerektiren sorunları raporlamaktır. Bunun için birkaç temel teknik vardır:

1. Uyarıları Birleştirme ve Sıkıştırma

Bir sunucudaki 5 servis çökerse, 5 ayrı uyarı göndermemelisiniz. "X sunucusu erişilemez durumda ve 5 servis etkilendi" diyen tek bir uyarı gönderin. Prometheus'taki Alertmanager gibi araçlar bunu otomatik olarak yapar.

2. Olaya Değil, Duruma Dayalı Uyarı

Durum tabanlı uyarı (State-based), yalnızca durum değiştiğinde uyarı vermek demektir, her kontrol yapıldığında değil. Örnek:

# Kötü: Sorun çözülene kadar her 5 dakikada bir uyarı
if cpu > %90 then alert

# İyi: Yalnızca durum OK'den CRITICAL'e değiştiğinde uyarı ver
state = OK
if cpu > %90 for 10 minutes then
    if state != CRITICAL then
        alert("CPU kritik seviyeye ulaştı")
        state = CRITICAL
    end
end

Bu tek başına uyarı sayısını %90 azaltır.

3. Süreklilik Süresini (Duration) Dikkate Alın

5 saniyelik bir CPU pikleri genellikle zararsızdır. 15 dakikalık bir pik gerçek bir sorundur. Her uyarı için bir süreklilik süresi belirleyin:

• CPU > %90: en az 10 dakika süreklilik
• Disk > %85: en az 30 dakika süreklilik (çünkü disk büyümesi kademelidir)
• Servis Down: hemen (0 dakika süreklilik)

4. Bildirim Kanallarını Katmanlandırın

Tüm uyarılar tüm kanallara gitmemelidir. Önerilen bir yapı:

1. Bilgilendirme Uyarıları (Info): Yalnızca ekibin Telegram veya Slack kanalına. Acil müdahale gerekmez.
2. Uyarılar (Warning): E-posta + nöbetçi yöneticiye mesaj. 1 saat içinde incelenmelidir.
3. Kritik Uyarılar (Critical): SMS + otomatik telefon araması. 15 dakika içinde müdahale edilmelidir.

Önerilen Araçlar ve Pratik Bir Yapılandırma Örneği

Sunucu izleme için birçok açık kaynaklı araç vardır. Prometheus + Alertmanager + Grafana kombinasyonu endüstri standardıdır ve küçük ve büyük ekipler için çalışır. Daha basit bir altyapınız varsa, Netdata veya Zabbix daha hafif seçeneklerdir.

Yukarıdaki kavramları uygulayan Prometheus'ta örnek bir uyarı kuralı:

groups:
  - name: server-alerts
    rules:
      - alert: HighCPULoad
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} üzerinde CPU %90'ın üzerinde"

      - alert: DiskWillFillIn24h
        expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 24*3600) < 0
        for: 30m
        labels:
          severity: critical
        annotations:
          summary: "Kök disk 24 saat içinde dolacak"

İkinci kuralın, büyüme hızını tahmin eden predict_linear fonksiyonunu kullandığına dikkat edin — bu, eşikler bölümünde bahsettiğimiz "tahmine dayalı uyarı"dır.

Uyarı Yorgunluğunu Nasıl Ortadan Kaldırırsınız

Ekibiniz uyarıları görmezden geliyorsa, sorun ekipte değil, uyarı sistemindedir. Üç altın kural:

• Her uyarının belirli bir eylemi olmalıdır: "CPU yüksek" uyarısı gönderiyorsanız, kimin, neyi, ne zaman yapacağı tam olarak belirtilmelidir. Belirli bir eylem yoksa, o uyarıyı kaldırın.
• Her uyarı test edilebilir olmalıdır: Ayda en az bir kez gerçek bir hata senaryosu simüle edin (örneğin bir servisi durdurmak) ve uyarının doğru gelip gelmediğini ve doğru kişiye ulaşıp ulaşmadığını görün.
• Periyodik uyarı incelemesi: Her ay 30 dakikalık bir toplantı yapın ve geçen ayın tüm uyarılarını gözden geçirin. Bir eyleme yol açmayan her uyarıyı kaldırın veya düzeltin.

Özet: Sunucu İzleme Kaygı Değil, Huzur Demektir

İyi bir sunucu izleme sistemi, her şey normal olduğunda sessiz kalan ve gerçek bir sorun olduğunda doğru kişiye, doğru zamanda, yeterli bilgiyle haber veren sistemdir. Doğru metrikleri izleyerek, veriye dayalı eşikler ayarlayarak ve aşamalı uyarılar tasarlayarak maliyetli kesintileri önleyebilir ve ekibinizi uyarı yorgunluğundan kurtarabilirsiniz.

Bu araçları kolayca çalıştırabileceğiniz bir altyapı arıyorsanız, ServerNet sunucu izlemeyi kurmak için uygun bir bulut platformu sağlar. Ancak her araçtan daha önemlisi, bu makalede açıkladığımız süreçtir — uygulayın ve sonucu görün.