Bulut altyapısı için izleme ve uyarı

Bulut izleme neden basit bir panelden daha fazlasıdır?

Altyapınızı bir bulut platformuna taşıdığınızda, sunucu odasındaki ağ kabloları ve fiziksel sunucular artık yok; ancak karmaşıklık azalmadığı gibi sanallaştırma katmanları, yazılım tanımlı ağ ve yönetilen hizmetler ile daha da genişledi. Böyle bir ortamda, bulut izleme uygulamanızın gerçekten sağlıklı olduğundan emin olmanın tek yoludur; sadece sunucunun yanıt verdiğini görmek yeterli değildir.

Birçok teknik ekip, açık kaynaklı bir araç kurup birkaç grafiğe bakmanın izleme yapmak anlamına geldiğini düşünür. Ancak gerçek izleme, tam bir döngüdür: veri toplama, temel metrikleri tanımlama, akıllı eşik değerleri ayarlama ve son olarak doğru zamanda doğru kanala uyarı gönderme. Bu makalede, dört adımı da pratik örnekler ve gerçek kodlarla inceleyeceğiz.

Temel metrikler: Neyi izlemelisiniz?

İlk yaygın hata, her şeyi izlemektir. Her metrik için bir uyarı tanımlarsanız, ekibiniz hızla "uyarı yorgunluğu" yaşar ve gerçek uyarıları göz ardı eder. Doğrudan kullanıcı deneyimini ve hizmet sağlığını etkileyen metrikler üzerine odaklanmalısınız.

Altyapı seviyesi metrikleri (Infrastructure Metrics)

Bu kategori, genellikle Prometheus, Grafana veya her bulut sağlayıcısının yerel hizmetleri gibi araçlarla toplanabilen temel kaynakları içerir:

• CPU Kullanımı: 5 ve 15 dakikalık aralıklarda ortalama işlemci kullanımı. 10 dakika boyunca %80 oranı genellikle alarm zilidir.
• Bellek Kullanımı: Tüketilen bellek yüzdesi ve takas (swap) miktarı. Linux'ta free -h komutunu cron betikleriyle birleştirin.
• Disk I/O ve Disk Alanı: Boş disk alanı ve saniyedeki okuma/yazma işlemi sayısı (IOPS). Diskin dolması, veritabanı arızalarının başlıca nedenlerinden biridir.
• Ağ Veri Hızı (Network Throughput): Gelen ve giden bant genişliği. Bu metrik, DDoS saldırılarında veya anormal trafikte ilk işarettir.

Uygulama seviyesi metrikleri (Application Metrics)

Altyapı izleme size makinenin hayatta olduğunu söyler; ancak uygulamanızın doğru çalışıp çalışmadığını söylemez. Bunun için uygulama seviyesi metrikleri de toplamanız gerekir:

• Gecikme (Latency): İsteklere yanıt süresi. Ortalamayı değil, 95. yüzdelik dilimi (p95) izleyin; ortalama anormallikleri gizleyebilir.
• Hata Oranı (Error Rate): 5xx hata koduyla yanıtlanan isteklerin yüzdesi. Önerilen eşik: 5 dakikalık aralıkta %1'den fazla.
• Veri Hızı (Throughput): Saniyedeki başarılı istek sayısı (RPS). RPS'deki ani düşüş, hizmet kesintisi veya mesaj kuyruğunda sorun olduğunun işareti olabilir.
• Kuyruk Derinliği (Queue Depth): Mesaj kuyruklarının derinliği (RabbitMQ veya Kafka gibi). Kuyruk sürekli doluyorsa, tüketici üreticiden daha yavaştır.

İş metrikleri (Business Metrics)

Profesyonel bulut izlemede sadece teknik metrikler incelenmez. Dönüşüm oranı, başarılı işlem sayısı veya çevrimiçi kullanıcı sayısı gibi metrikler de panele eklenebilir. Bu, teknik bir değişikliğin iş üzerindeki etkisini ölçmenize yardımcı olur.

Eşik değerleri ayarlama: Gereksiz uyarılardan geç uyarılara

Eşik değeri (Threshold), uyarı sisteminin kalbidir. Eşiği çok düşük ayarlarsanız, ekibiniz bildirimlere boğulur. Çok yüksek ayarlarsanız, sorunu kullanıcılar şikayet ettiğinde fark edersiniz. Çözüm, dinamik ve çok seviyeli eşik değerleri kullanmaktır.

Sabit eşik değeri ve dinamik eşik değeri

"CPU %80'i aşarsa uyar" gibi sabit bir eşik, küçük ortamlar için yeterlidir. Ancak büyük ortamlarda trafik desenleri farklıdır. Örneğin, bir haber sitesi sabah saatlerinde yüksek CPU kullanabilir ve gece neredeyse boşta olabilir. Bu durumda, 7 günlük hareketli ortalamaya dayalı dinamik eşik daha doğru çalışır.

Prometheus'ta record kurallarını kullanarak dinamik eşik tanımlayabilirsiniz. Aşağıdaki örnek, ortalamadan sapmaya dayalı bir uyarı kuralıdır:

groups:
  - name: dynamic-thresholds
    rules:
      - record: job:cpu_usage:avg_7d
        expr: avg_over_time(instance:cpu_usage:rate5m[7d])
      - alert: HighCpuDynamic
        expr: |
          instance:cpu_usage:rate5m > job:cpu_usage:avg_7d * 1.5
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "CPU usage is 50% above 7-day average"

Çok seviyeli eşik değerleri (Multi-Level Thresholds)

Tek bir uyarı durumu yerine üç seviye tanımlayın:

1. Bilgi (Info): Örneğin, disk kullanımı %70'e ulaştı. Bu uyarı ekibin genel kanalına gider ve acil müdahale gerektirmez.
2. Uyarı (Warning): Disk kullanımı %85'e ulaştı. Bu uyarı, sorumlu kişiye SMS veya bildirim olarak gönderilir.
3. Kritik (Critical): Disk kullanımı %95'e ulaştı. Bu uyarı, telefon araması veya acil durum kanalına gönderim yoluyla iletilir.

Bu yaklaşım, ekibinizin önceliklendirme yapmasını ve yalnızca kritik durumlarda uyanmasını sağlar.

Yaygın hata: "Süreyi" (For Duration) göz ardı etmek

Bulut izlemede en yaygın hatalardan biri, tek bir örneğe (sample) dayalı uyarı vermektir. CPU 30 saniye boyunca %90'a ulaşırsa, bu kendiliğinden çözülen kısa bir ani yükseliş (spike) olabilir. Sorun belirli bir süre devam etmedikçe uyarının etkinleşmemesi için her zaman for parametresini kullanın. Yukarıdaki örnekte, for: 15m sorunun uyarı verilmesi için 15 dakika sürmesi gerektiği anlamına gelir.

Bildirim kanalları: Doğru mesaj, doğru kanalda

İyi bir uyarı, görülen uyarıdır. Uyarı kimsenin görmediği bir kanala gönderilirse, pratikte işe yaramaz. Bildirim kanalı seçimi, uyarının şiddetine ve gereken tepki süresine göre yapılmalıdır.

Kanal ve uyarı seviyesi matrisi

• E-posta: Bilgi seviyesi uyarılar ve periyodik raporlar için uygundur. Kritik durumlar için e-posta kullanmayın; saatlerce görülmeyebilir.
• SMS: Uyarı seviyesi için uygundur. Ekibiniz vardiyalı çalışıyorsa, SMS'i vardiya sorumlusuna gönderin.
• Ekip mesajlaşma uygulamaları (Slack, Telegram, Rocket.Chat): Uyarı ve Kritik seviyeleri için en iyi seçenektir. Webhook kullanarak uyarıları belirli kanallara gönderebilirsiniz.
• Telefon araması (Phone Call): Yalnızca Kritik seviye için. PagerDuty veya Opsgenie gibi hizmetler bu imkanı sağlar.

Pratik örnek: Webhook ile Telegram'a uyarı gönderme

Alertmanager kullandığınızı ve Kritik uyarıları bir Telegram botuna göndermek istediğinizi varsayalım. Önce bir bot oluşturun ve token'ını alın. Ardından Alertmanager yapılandırma dosyasında bir alıcı (receiver) tanımlayın:

receivers:
  - name: 'telegram-critical'
    webhook_configs:
      - url: 'https://api.telegram.org/bot<YOUR_BOT_TOKEN>/sendMessage'
        send_resolved: true
        http_config:
          headers:
            Content-Type: application/json
        body: |
          {
            "chat_id": "<YOUR_CHAT_ID>",
            "text": "{{ range .Alerts }}{{ .Annotations.summary }}\n{{ .Annotations.description }}{{ end }}",
            "parse_mode": "HTML"
          }

Önemli not: Telegram Webhook'unda sendMessage metodunu doğrudan URL'ye koymalı ve istek gövdesini JSON olarak göndermelisiniz. Ayrıca chat_id değerini Telegram'daki @userinfobot botu aracılığıyla alabilirsiniz.

Yaygın hata: Tüm uyarıları tek bir kanala göndermek

Bilgi seviyesinden Kritik seviyeye kadar tüm uyarılar tek bir Telegram kanalına gönderilirse, ekip üyeleri bildirimleri hızla sessize alır (Mute). Kanalları mutlaka ayırın: Bilgi ve Uyarı seviyeleri için genel bir kanal ve yalnızca sorumlu kişilerin üye olduğu Kritik seviyeler için sınırlı bir kanal (veya ayrı bir grup) oluşturun.

Sonuç: Bulut izleme bir süreçtir, bir araç değil

Etkili bulut izleme; doğru metrikleri seçme, akıllı eşik değerleri ayarlama ve uyarıları uygun kanallara göndermenin bir birleşimidir. Bu makalede açıklanan döngüyü uygulayarak, reaktif durumdan çıkabilir ve sorunları kullanıcıları etkilemeden önce proaktif olarak tespit edebilirsiniz.

Ekibiniz bulut altyapısıyla yeni çalışmaya başladıysa, önce Prometheus ve Grafana gibi basit bir araçla başlamanızı ve karmaşıklığı kademeli olarak eklemenizi öneririm. Unutmayın ki nihai hedef güzel bir panele sahip olmak değil; tespit ve kurtarma süresini (MTTD ve MTTR) azaltmaktır. ServerNet'in sunduğu bulut barındırma hizmetleri genellikle temel izleme araçlarını sağlar; ancak uyarıların ve metriklerin ince ayarı her zaman sizin teknik ekibinizin sorumluluğundadır.

Son olarak pratik bir öneri: Her ay bir "uyarı gözden geçirmesi" yapın. Son bir ayda hiçbir pratik eyleme yol açmayan uyarıları kaldırın veya düzeltin. Bu, uyarı sisteminizin her zaman düzenli, verimli ve güvenilir kalmasını sağlar.