Alarmlar

Orbtrace'te alarmlar on bir alt sayfaya bölünmüştür. Çok görünüyor — değil. Bu sayfadaki sırayla okuyun; her biri öncekinin üstüne kurulur.

Büyük resim

Bir alarm kuralı şunu söyler: "X metriği Y eşiğini Z dakikadır geçerse alarm yansın". Alarm yandığında, yönlendirmeden geçer ve hangi kanala (Slack, PagerDuty, e-posta, webhook…) gideceğine karar verir. Eskalasyon politikasının ilk adımında kimse onaylamazsa sonraki adıma geçer. Takvim alarmın anında kimin nöbette olduğunu söyler. Susturma alarmı sabit pencere için bastırır. Bakım penceresi planlı bir kesinti boyunca her alarmı bastırır.

Hepsi bu. Geri kalan tesisat.

Alt sayfa 1 — Kurallar

Sistemdeki her kuralın listesi. Sütunlar: ad, önem, durum (yanıyor / iyi / susturulmuş / sessiz), metrik sorgusu, süre, son yanma, "düzenle" / "çoğalt" / "sil".

Kuralın anatomisi

Çok pencereli, çok yanma oranlı alarmlar

SLO tabanlı alarmlar için kural editörü, dört pencereli Google-SRE-handbook tarzı alarmı tek tıkla bağlayan "SLO yanma oranı" modu sunar: hızlı yanma (1 saatte 14×), kısa yanma (6 saatte 6×), yavaş yanma (24 saatte 3×), düşük yanma (3 günde 1×). Her SLO için bunu kullanın.

Alt sayfa 2 — Kanallar

Kanal bir hedeftir — Slack workspace, PagerDuty service, e-posta dağıtım listesi, jenerik webhook.

Her kanal için: ad, tür, türe özgü config (bot token, service key, URL), "Test mesajı gönder" butonu. Kanallar ne; yönlendirme hangisidir.

Alt sayfa 3 — Yönlendirme

(önem, etiketler) → kanal(lar) haritalayan bir ağaç. Yukarıdan aşağı okunur; ilk eşleşme kazanır.

Örnek ağaç:

- match: severity=P0
  channels: [pagerduty-primary, slack-incidents]
- match: severity=P1 AND team=payments
  channels: [pagerduty-payments]
- match: severity=P1
  channels: [slack-incidents]
- match: severity=P2
  channels: [slack-warnings]
- default:
  channels: [email-sre]

Sayfa ağacı gösterir, satırları sürükleyerek yeniden sıralamaya izin verir ve üstünde "şu etiketlerle alarm hangi kanallara gider?" test alanı var — etiketleri yapıştırın, kararı görün.

Alt sayfa 4 — Eskalasyon

Her önem (ya da belirli bir yönlendirme dalı) için N adımlı eskalasyon politikası: "kanal A'ya bildir; 10 dakikada onaylanmazsa B'ye bildir; 20 dakikada onaylanmazsa C'ye bildir".

Her adım bir kanala ve bekleme süresine referans verir. Adımlar sırayla çalışır; biri onayladığı an zincir durur. P0 genelde üç adım; yalnız-info alarmların eskalasyonu yoktur.

Alt sayfa 5 — Takvimler

Nöbet rotasyonları tanımlayın: takım, kişi listesi ve rotasyonun nasıl döndüğü (haftalık, günlük, özel). Eskalasyonları besler: adım, "X takviminden nöbetçi" diyebilir.

Sayfa rotasyonu takvim olarak çizer — her kişinin vardiyası renkli. Üzerinde geçersiz kılma yapabilirsiniz (vardiya değişimi, tatil).

Alt sayfa 6 — Susturmalar

Susturma, bir veya daha fazla alarmı sabit pencere boyunca bastırır:

• Eşleştirici (etiketler). Örn. service=checkout-api AND severity=P2.
• Pencere — başlangıç ve bitiş.
• Sebep — serbest metin. Zorunlu.
• Yazar.

"Biliyorum, düzeltene kadar çağırma" için var. Otomatik süresi dolar — kalıcı susturma yapamazsınız.

Alt sayfa 7 — Bakım pencereleri

Susturmaya benzer ama servis/pano düzeyinde ve takvim şeklinde. Planlı kesintiler (db upgrade, ağ bakımı) için. Pencere boyunca etkilenen servislerden her alarm bastırılır ve gelen olaylar maintenance etiketli olur.

Çoklu aylık takvim üzerinde çakışmaları görürsünüz.

Alt sayfa 8 — Denetim

Alarm nesnelerini değiştiren her aksiyon — kural oluştur, kanal düzenle, susturma uygula, alarmı onayla, olayı çöz — bir denetim satırı üretir. Sütunlar: zaman damgası, aktör, aksiyon, hedef, önce/sonra diff.

Aktöre, aksiyon türüne, hedefe göre süzün. "Checkout alarmını kim susturdu?" tipi post-mortem'ler için.

Alt sayfa 9 — Analitik

Alarm sağlığınızla ilgili özet istatistikler:

• Kanal başına hacim (zaman içinde).
• En gürültülü kurallar (hafta başına yanma).
• Takım başına medyan MTTA (onaylama süresi).
• Alarm yorgunluğu ısı haritası — kural × hafta renk ızgarası; her hafta yanıp çözülmeyen kural, yorgunluk demektir.

Bir kural üç hafta üst üste "en gürültülü 5" arasındaysa neredeyse her zaman kötü ayarlıdır. Eşiği düzeltin ya da kuralı öldürün.

Alt sayfa 10 — GitOps

Alarm kurallarınızı bir Git reposunda sürümlemeye izin verir.

• SSH anahtarı veya GitHub App ile repo bağlayın.
• Orbtrace değişimde her kuralın YAML temsilini repoya yazar.
• Repo'da yapılan düzenlemeler Orbtrace'e geri uzlaştırılır.

Takımınız PR onaylı alarm değişiklikleri tercih ediyorsa açın; yoksa kapalı bırakın.

Alt sayfa 11 — Yeni

Yeni kural editörü. İki yol:

• Sıfırdan — boş sorgu, siz doldurun. Metrik kâşifi ile aynı şekil.
• Metrik sorgusundan — herhangi bir metrik grafiğinde "Alarm oluştur"a tıklayınca sorgu önceden doluyken buraya düşersiniz.

Editörün sağı canlı önizleme: anlık değer, eşik çizgisi ve son 24 saatte yanmış olacağı bölgelerin gül gölgesinde küçük grafik. Önizleme, çok hassas eşiği kaydetmeden önce yakalamanın en ucuz yoludur.

Önerilen kurulum sırası

Yeni kurulumda alt sayfaları şu sırayla geçin:

1. 1

   Önce kanallar

   Slack kanal(lar)ınızı ve PagerDuty service'inizi ayarlayın. Kanal olmadan yönlendiremezsiniz.

2. 2

   Takvimler

   Nöbet rotasyonlarınızı kurun.

3. 3

   Eskalasyon

   Önemleri → eskalasyon adımlarına → takvimlere bağlayın.

4. 4

   Yönlendirme

   Etiketleri kanallara ve eskalasyonlara haritalayın.

5. 5

   Kurallar

   Şimdi kural ekleyin. Erişilebilirlik (servis yanıt veriyor mu) ve gecikme (p99 SLO içinde mi) ile başlayın. İlkleri bir hafta izledikten sonra fazlasını ekleyin.

6. 6

   Bakım + Susturmalar

   Bunları reaktif kullanın, proaktif değil. "Belki gerekir" diye önceden susturma açmayın.

7. 7

   Analitik gözden geçirme

   İki hafta sonra analitik sayfasına bakın. En gürültüleri ayarlayın.

Sırada: Olaylar.