Alarm Kurarken "Bir Şey Bozuldu" Değil "Kullanıcı Etkileniyor" Kuralı

Bir sistemde iki tür alarm kurabilirsiniz. Birincisi "şu bileşen anormal davranıyor" der: CPU yüzde doksanı geçti, disk doldu, kuyrukta bekleyen iş sayısı yükseldi, bir cron başarısız bitti. İkincisi "şu kullanıcı grubu şu anda sorun yaşıyor" der: istek başarısızlık oranı belirlenen eşiği aştı, gecikme dağılımı kabul edilebilir sınırın dışına çıktı. Ekiplerin büyük çoğunluğu birinci gruba yığılır çünkü kurulumu kolaydır ve metrikler zaten oradadır. Sonuç genelde aynı hikâyedir: nöbetçinin telefonu gece üçte disk alarmıyla çalar, yarım saat harcanır, meğer disk doluluğu yüzde seksen beşe çıkmış ama hiçbir kullanıcı isteği başarısız olmamış. Sabah da kimse "dün gece bir şey oldu mu" sorusuna net cevap veremez.

Bu iki yaklaşım birbirinin yerine geçmez, ama karıştırılınca ikisi de işe yaramaz hale gelir. Sebep bazlı alarm doğru kullanıldığında erken uyarı sağlar: disk dolmadan önce büyümeyi görürsünüz, bellek sızıntısını üretime yansımadan yakalarsınız. Yanlış kullanıldığında ise alarm yorgunluğu üretir. Bir ekip günde elli bildirim alıyorsa kırk dokuzuncusunda artık okumaz, hangisinin gerçek olduğunu ayıramaz hale gelir. Yakın zamanda yayınlanan büyük ölçekli nöbet raporlarının ortak bulgusu budur: bildirim sayısı arttıkça ortalama tepki süresi kısalmaz, uzar.

Kullanıcı etkisini ölçülebilir hale getirmek

Sonuç bazlı alarm kurmanın önkoşulu, "kullanıcı etkilendi" cümlesini sayıya dökmektir. Google'ın site güvenilirliği mühendisliği pratiğinden gelen üç terim burada işe yarar: Hizmet Seviyesi Göstergesi (SLI), bunun hedef değeri (SLO) ve hedefin izin verdiği başarısızlık payı (hata bütçesi). Bir web servisi için tipik SLI'lar şunlardır: başarılı isteklerin oranı, isteklerin belirli bir gecikme eşiğinin altında tamamlanma yüzdesi, kuyruğa giren bir işin belirli bir süre içinde işlenme oranı. SLO ise bu göstergenin otuz günlük pencerede tutması gereken hedeftir, örneğin yüzde 99,9 başarı oranı. Geri kalan yüzde 0,1, ekibin bilinçli olarak kabul ettiği hata bütçesidir; bu bütçe deploy riski almak, bakım penceresi açmak gibi kararlarda kullanılır.

Buradaki kritik fark şudur: CPU yüzde doksan bir SLI değildir çünkü kullanıcının deneyimiyle doğrudan ilişkisi kanıtlanmamıştır. Sistem CPU'su yüzde doksanken de tüm istekler zamanında ve hatasız dönüyor olabilir. SLI, kullanıcının doğrudan hissettiği şeydir: istek başarılı mı oldu, ne kadar sürdü, veri doğru mu geldi.

Yanma hızı alarmı: ne zaman, ne kadar ciddi

SLO'yu tek eşikli bir alarma çevirmek ("aylık hata oranı yüzde 0,1'i geçerse uyar") pratikte işe yaramaz, çünkü ay sonuna kadar beklemek gerekir ve hızlı bir bozulmayı erken yakalayamazsınız. Bunun yerine kullanılan yöntem çoklu pencere, çoklu yanma hızı alarmıdır. Fikir basit: hata bütçenizin ne hızla tükendiğini ölçersiniz. Bütçenin tamamını normalde otuz günde bir kez harcayacak şekilde tasarlarsınız; eğer mevcut hata oranıyla giderseniz bütçe bir saatte tükenecekse bu, normalin kırk dört kat üzerinde bir yanma hızı demektir ve derhal müdahale gerektirir. Aynı hesabı altı saatlik ve bir günlük pencerelerde de yaparsınız; daha yavaş ama sürekli bir bozulma da yakalanmış olur.

Prometheus ile örnek bir kural şöyle görünür:

groups:
  - name: slo-burn-rate
    rules:
      - alert: ErrorBudgetBurnFast
        expr: |
          (
            sum(rate(http_requests_total{code=~"5.."}[1h]))
            /
            sum(rate(http_requests_total[1h]))
          ) > (14.4 * 0.001)
          and
          (
            sum(rate(http_requests_total{code=~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))
          ) > (14.4 * 0.001)
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "Hata bütçesi hızlı tükeniyor, 1 saatlik pencerede bütçenin %2'si harcanıyor"

Burada 0.001 aylık hedef hata oranını (yüzde 99,9 SLO), 14.4 çarpanı ise bu hızda giderse bütçenin tamamının yaklaşık iki günde tükeneceğini gösteren yanma katsayısını temsil eder. Kısa pencere (5 dakika) ile uzun pencere (1 saat) birlikte kontrol edilir ki tek bir kısa süreli sıçrama yanlış alarm üretmesin, ama gerçek bir bozulma da bir saat boyunca fark edilmeden geçmesin. Daha yavaş yanma hızları (6 kat, 3 kat, 1 kat) için daha uzun pencerelerle aynı desen kurulur ve bunlar genelde sayfalama yerine bilet açma seviyesinde tutulur.

Sebep bazlı alarmı tamamen atmayın

Burada yapılan yaygın hata, sonuç bazlı alarma geçince sebep bazlı izlemeyi tamamen kaldırmaktır. İkisi farklı işler görür. Sonuç bazlı alarm size "şu an müdahale et" der ve nöbetçiyi uyandırma yetkisine sahiptir. Sebep bazlı metrikler ise, alarm çaldıktan sonra kök nedeni bulmak için kullanılır: disk doluluğu, kuyruk derinliği, bağlantı havuzu doygunluğu, yeniden deneme sayısı. Doğru mimari, sebep bazlı sinyalleri panolara ve düşük öncelikli bildirimlere yönlendirmek, yalnızca kullanıcı etkisini kanıtlayan sinyalleri sayfalamaya bağlamaktır. Alertmanager'da bu ayrım severity etiketiyle yapılır: severity=page olan kurallar doğrudan nöbetçiye giden bir alıcıya, severity=ticket olanlar ise iş takip sistemine yönlendirilir.

Tuzaklar

Birinci tuzak, hatayı yutup akışa devam eden "uyar ve devam et" kalıplarıdır. Bir adım başarısız olduğunda sistemin geri kalanı çalışmaya devam ediyorsa ve tek belirti bir log satırıysa, o log satırı kimse tarafından okunmaz ve gösterge yeşil kalır. Böyle bir noktada iki soru sorulmalı: bu adım başarısızken devam etmek hiç çalışmamaktan gerçekten daha mı iyi, ve devam ediliyorsa sonraki adımın hangi veriyle çalıştığı ölçülebiliyor mu? İkisinin de cevabı hayırsa akış durdurulmalı ve gürültü çıkarılmalı.

İkinci tuzak, alarmın gerçekten çalıştığını hiç doğrulamamaktır. Bir SLI'ı yanlış metrik kaynağından hesaplamak, yanlış etiket kümesiyle sorgulamak ya da farklı bir ad alanına yazılan veriyi okumaya çalışmak, alarmı sessizce hiçbir zaman tetiklenmeyecek hale getirir. Bunun tek güvenilir testi, gerçek bir bozulmayı kasıtlı olarak üretmektir: test trafiğine hata enjekte edin, alarmın gerçekten çaldığını, doğru kanala gittiğini ve doğru eşikte tetiklendiğini gözlemleyin. Bu, hataları izole bir ortamda tetikleyip izleme zincirinin uçtan uca çalıştığını kanıtlamaktır; kurulumdan sonra bir kere yapılıp unutulacak bir iş değil, alarm mantığı her değiştiğinde tekrarlanması gereken bir alışkanlıktır.

Üçüncü tuzak, pencereleri çok dar veya eşikleri çok gevşek seçmektir. Çok dar pencere kısa trafik sıçramalarında bile alarm üretir ve nöbetçi bunu görmezden gelmeyi öğrenir; çok gevşek eşik gerçek bir kesintiyi saatlerce fark ettirmez. Pencere ve çarpan seçimi, geçmiş trafik verisiyle geriye dönük test edilmeli: gerçekte yaşanmış kesinti olaylarınızda yeni kuralın ne zaman tetiklendiğine bakın, hem çok geç hem çok erken tetiklenen kuralları elenir.

Ne zaman bu yaklaşıma geçmemeli

Bu yatırım her sistem için gerekli değildir. Trafiği düşük, kullanıcı sayısı az olan erken aşama bir üründe anlamlı bir SLI hesaplamak için yeterli örneklem yoktur; yüzde 99,9 hedefi, günde birkaç yüz istek alan bir serviste istatistiksel olarak gürültüden ayrılamaz. Böyle durumlarda basit eşik alarmları (hizmet ayakta mı, temel uç noktalar cevap veriyor mu) yeterlidir ve SLO altyapısı kurmanın getirisi, harcanan mühendislik zamanını karşılamaz. Trafik ve kullanıcı sayısı büyüdükçe, özellikle birden fazla ekip aynı sistemin farklı parçalarından sorumlu olmaya başladığında, kullanıcı etkisine dayalı alarm önceliklendirmesi asıl değerini gösterir.