Event policy'leri

Test → Olaylar → Event policy'leri, bir event açılınca ya da yeniden açılınca ne olacağını belirleyen sıralı kurallardır: gece warning'lerini susturmak, payment critical'larını Slack'e gönderip ack yoksa SMS'e yükseltmek, bakım penceresinde bildirimi kesmek, host'u yok sayarak tekilleştirmek, bir süre sonra kendiliğinden resolve etmek.

#Nasıl çalışır

1. Bir event açılır ya da yeniden açılır (sıradan bir tekrar policy'leri yeniden çalıştırmaz).
2. Açık policy'ler listedeki sırayla denenir. Koşulları tutan policy'nin aksiyonları uygulanır.
3. Burada dur açıksa (varsayılan) sonraki policy'lere bakılmaz; kapalıysa sıradaki eşleşen policy'ler de uygulanır.
4. Ne yapıldığı event sayfasındaki Policy izi'ne yazılır: policy'nin adı, sürümü, aksiyon ve ayrıntı.

Sırayı satırı sürükleyerek ya da ok düğmeleriyle değiştirin. Kapalı bir policy sırasını korur ama uygulanmaz. Çalışma alanının her üyesi policy ekleyip değiştirebilir; her değişiklik sürüm geçmişine ve audit log'a yazılır.

#Hazır politikalar ve sizin policy'leriniz

Hazır politikalar sekmesindeki kurallar (Kubernetes, Docker, Linux, Windows, ağ cihazları) kurulumla birlikte açıktır ve metriklerden spitfire.builtin kaynaklı event açar; eşiklerini ve kanallarını orada değiştirirsiniz. Sizin politikalarınız sekmesindeki policy'ler ise açılan her event'e (hazır kurallardan gelenler dahil) ne olacağını seçer. Sekmeler açık ve toplam sayıyı gösterir, ör. Hazır politikalar (32 açık / 32); sol menüdeki Event policy'leri yanındaki sayı ikisinin açık toplamıdır.

#Şablondan başla

1. Sizin politikalarınız sekmesinde Yeni policy'ye basın.
2. Şablondan başla kartlarından birini seçin (arama kutusu ve kategoriler, yanlarında şablon sayısı): Boş policy, Hazır kural olayları (bir alanın ya da tek kuralın event'leri, ör. builtin.k8s.*), Bildirim, Gürültü azaltma, Yaşam döngüsü.
3. Koşullar ve aksiyonlar doldurulur. Kanal isteyen aksiyonlarda (route, escalate, tracker) kanalı seçin.
4. Kaydet'e basın.

Kontrol: policy listede görünür, sekmedeki açık sayısı bir artar.

#Koşullar

Boş bırakılan alan "hepsi" demektir. Doldurulan alanların hepsi tutmalıdır; bir alanın değerlerinden biri yeter.

Her listede en çok 20 değer olur.

#Zaman penceresi

Hazır seçimler: Mesai içi (Pzt–Cum 09:00–18:00), Mesai dışı (aynı pencerenin dışı), Gece (her gün 22:00–07:00) ve Hafta sonu (Cmt–Paz). Başlangıç bitişten büyükse pencere gece yarısını geçer. Saat dilimi tarayıcınızınkiyle dolar (Europe/Istanbul gibi); değiştirebilirsiniz.

#Aksiyonlar

Bir policy'de 1–12 aksiyon olur, her türden en çok bir tane.

#Bildirim, escalation ve renotify

Route'un açtığı bildirim planı event sayfasında görünür: hangi policy, hangi kanallar, kaçıncı adımda olduğu ve sonraki işlem zamanı. Ack ya da resolve planı durdurur. Escalation adımları 1–1440 dakika arasıdır ve artmalıdır; renotify 5–1440 dakika, auto-resolve 5–10080 dakika (7 gün).

#İmzalı ack / resolve linkleri

Ayarlar → Genel → Genel adres doluysa, sorun bildirimlerinde (e-posta, Slack, Teams, SMS, JSON) Ack ve Resolve linkleri gelir. Link giriş gerektirmez, 7 gün geçerlidir ve bir kez kullanılır; timeline'da "link ile" diye görünür. JSON webhook'larında eventLinks (ackUrl, resolveUrl, eventUrl) alanındadır.

#Dene (dry run)

Düzenleyicideki Dene, kaydetmeden policy'yi son 7 günün event'lerinde çalıştırır: kaç event'e bakıldığı (en çok 5000), kaçının eşleştiği, her aksiyonun kaç event'i etkileyeceği ve 20'ye kadar örnek (severity değişimi ve iz ile). Hiçbir şey değişmez, bildirim gitmez.

#Sürüm geçmişi

Her kayıt, açma/kapama ve silme yeni bir sürüm yazar. Listede bir policy'nin Geçmiş düğmesi sürümleri, kimin ne zaman değiştirdiğiyle gösterir. İki kişi aynı policy'yi aynı anda düzenlerse ikinci kayıt reddedilir: sayfayı yenileyip yeniden kaydedin.

#Drop

Drop varsayılan olarak kapalıdır. Çalışma alanı admin'i sayfanın üstündeki Drop'a izin ver ile açabilir. Kapalıyken drop aksiyonlu bir policy event'i yine de kaydeder ve suppress eder (izde drop_off). Drop edilen event listede, sayaçlarda ve timeline'da görünmez; geri getirilemez. Mümkünse susturmayı kullanın.

#Korelasyon

Correlate aksiyonu, aynı kökten gelen event'leri tek grupta toplar; örneğin aynı host'tan birkaç dakika içinde gelen disk, CPU ve servis alarmları.

1. Şu alanların değeri aynıysa altında grubu belirleyen alanları işaretleyin: servis, host, ortam, resource, kaynak, tip; isterseniz tag key'leri de (virgülle). Varsayılan servis + ortam.
2. Pencere'yi dakika olarak girin (1–1440, varsayılan 10).
3. Aynı policy'ye bir Yönlendir aksiyonu ekleyin: grubun bildirimleri onunla gider.

Grubun ilk event'i parent olur ve her zamanki gibi bildirilir. Pencere içinde (parent'ın açılışından sayarak) gelen, key'i farklı ama seçilen alanları aynı event'ler onun child'ı olur: kaydedilir, listede Grupta rozetiyle ve parent'ın sayfasında İlgili event'ler altında görünür, ama kendi bildirimini, escalation'ını, renotify'ını ya da writeback'ini göndermez. Pencereden sonra gelen event yeni bir grup açar. Seçilen alanların hepsi boş olan event gruplanmaz (izde correlate_skipped).

Policy yazmadan, aynı host ya da servisin farklı kaynaklardan gelen event'lerini gruplayan kaynaklar arası korelasyon için Hazır politikalar, gruplar ve bildirim teslimi sayfasına bakın.

#Flap

Flap aksiyonu, kısa sürede tekrar tekrar açılıp kapanan (flapping) bir event'in her açılışta bildirim göndermesini önler.

1. Açılış sayısı'nı (2–50, varsayılan 4) ve pencere'yi dakika olarak (1–1440, varsayılan 30) girin.
2. Aynı policy'ye bir Yönlendir aksiyonu ekleyin: flap durunca gidecek tek bildirim route'un kanallarına gider.

Event pencere içinde bu kadar açılınca flapping işaretlenir: tek event kalır, flapping=true tag'ini alır, listede ve event sayfasında Flapping rozetiyle görünür. Flapping sürerken bildirim, escalation ve renotify gitmez; auto-resolve çalışmaya devam eder. Pencere boyunca açılış ya da kapanış olmazsa flap durur (timeline'da Flap durdu); event o an hâlâ açıksa kanallara tek bildirim gider. Flap aksiyonu yeniden açılma süresini de en az pencere kadar uzatır, böylece arada resolve olan event yeni satır açmaz.

Dene, son 7 günün event'lerinde kaç event'in gruba katılacağını ve kaçının flap edeceğini gösterir.

#Örnekler

Her örnek Yeni policy ile başlar; bitince Dene, sonra Kaydet. Denemek için bir test event'i gönderin (bir API token'ı ile, her klasörden çalışır):

curl -s -X POST -H "Authorization: Bearer $SPITFIRE_TOKEN" -H "Content-Type: application/json" \
  -d '{"source":"policy-test","type":"disk.full","severity":"warning","title":"disk 91%","service":"payment","host":"pay-1"}' \
  "https://spitfire.example.com/api/v1/events"

#Gece warning'lerini sustur

1. Ad: Gece warning sustur
2. Severity: Şunlardan biri → Warning, Info
3. Zaman: Gece
4. Aksiyon: Sustur (başlangıç ve bitiş boş)

Kontrol: gece gönderilen warning event'i listede Suppressed görünür, izde suppress yazar.

#Payment critical → Slack, 15 dakikada ack yoksa SMS

1. Ad: Payment critical
2. Servis: payment*
3. Severity: En az → Critical
4. Aksiyon: Yönlendir → Slack kanalınız, Yerine
5. Aksiyon: Escalation → 1 adım, 15 dakika, SMS kanalınız

Kontrol: event sayfasında plan Payment critical, sonraki işlem 15 dakika sonrası; ack'leyince plan durur.

#Bakım penceresi

1. Ad: Cumartesi bakım
2. Servis: api, ortam: prod
3. Aksiyon: Sustur → başlangıç 2026-11-14 02:00, bitiş 2026-11-14 04:00

Kontrol: pencere içinde gelen event Suppressed; pencere dışında izde suppress_inactive yazar ve event açık kalır.

#Host'u yok sayarak dedup

1. Ad: Disk dolu tek event
2. Tip: disk.*
3. Aksiyon: Dedup → Kaynak, Tip, Servis, Ortam (Host işaretsiz)
4. Burada dur kapalı (sonraki policy'ler de uygulansın)

Kontrol: pay-1 ve pay-2'den gelen aynı event listede tek satır, sayısı 2.

#Auto-resolve

1. Ad: Deploy event'leri kapanır
2. Tip: deploy.*
3. Aksiyon: Auto-resolve → 60 dakika

Kontrol: 60 dakika tekrar gelmeyen event Resolved, timeline'da "policy ile".

#Desktik ile olay yönetimi

Desktik yardım masasında her event için bir talep açılır. Ack, resolve, yeniden açılma ve severity değişikliği aynı talebe gider. Desktik'te ack'lenen ya da çözülen talep Spitfire'daki event'i de ack'ler ya da resolve eder. Desktik kanalı her sürümde ücretsizdir.

#Kurulum

1. Desktik'te Ayarlar → İzleme olayları'nı açın; talebin açılacağı ürünü, firmayı ve talep edeni orada seçin.
2. Desktik'te Ayarlar → API anahtarları'ndan dtk_ ile başlayan bir anahtar oluşturun. Yalnız olay yetkili (events) bir anahtar yeterlidir.
3. Spitfire'da Entegrasyonlar → Kanal ekle → Desktik'i seçin.
4. Desktik adresi'ni (https://desk.example.com) ve Desktik API anahtarı'nı girin.
5. Test'e basın, sonra kaydedin.
6. Event policy'leri'nde bir policy'ye Tracker aksiyonunu ekleyin ve bu Desktik kanalını seçin.

Kontrol: policy'ye uyan bir event açıldığında event sayfasında Desktik talebi #1234 linki görünür.

#Desktik bulutu

Adres desktik.com ya da onun bir alt alan adıysa event bilgileri kurumunuzun dışına çıkar. Bu yüzden gönderim varsayılan olarak kapalıdır.

• Olayları Desktik bulutuna gönder işaretlenmeden hiçbir şey gitmez. Kanalın teslimat geçmişinde nedeni yazar.
• Gönderim açıldığında yalnız işaretli alanlar gider. Varsayılan alanlar Başlık, Servis ve Önem'dir.
• Mesaj ve Host çoğu zaman iç adres ya da müşteri verisi içerir. Bunları gerekmedikçe işaretlemeyin.
• Başlık işaretli değilse talep "Spitfire olayı " adıyla açılır.

Kendi sunucunuzdaki bir Desktik event'in tüm alanlarını alır.

#Ne gider, ne gelir

Spitfire yalnız severity gönderir; önceliği ve yükseltmeyi Desktik belirler. Flap'te ya da susturulmuş bir event için yeni talep açılmaz, ama açık bir talep event'in her değişikliğini alır.

Desktik Spitfire'a bağlanmaz: Spitfire, Desktik'te ack'lenen ya da çözülen talepleri 30 saniyede bir okur. Desktik'e Spitfire token'ı vermeniz gerekmez. Bu durumda timeline'da "Desktik: <kişi>" görünür ve işlem audit log'a yazılır. Bu işlem Desktik'e geri gönderilmez, böylece döngü olmaz. Desktik'e ulaşılamazsa sonraki turda yeniden okunur; arada hiçbir şey kaybolmaz.

#Escalation ve renotify uyarısı

Desktik kendi yükseltmesini ve tekrar bildirimini yapar. Aynı policy'de Desktik'e giden bir Tracker ile birlikte Escalation ya da Renotify de varsa, policy düzenleyicisi uyarı gösterir; bu durumda kişilere iki kez ulaşılır. Birini kaldırın ya da bilerek ikisini birden tutun.

#Lisans limitleri

Limit dolunca yeni policy eklenemez; var olanları değiştirmek ve kapatmak sürer.