Olaylar

Test → Olaylar, Spitfire'ın ürettiği ve kendi araçlarınızın gönderdiği her event'i tek yerde listeler:

• sentetik monitörlerin düşmesi ve düzelmesi;
• APM alarmları, SLO burn alarmları, yeni ve yeniden açılan hata grupları ve gerilemeler;
• karşılaştırma gerilemeleri, başarısız ya da kaçırılan zamanlanmış koşular;
• bağlantı sağlığı (yanıt vermeyen bir veri kaynağı ya da issue tracker) ve başarısız Sweeper koşuları;
• izleme araçlarınızın bir webhook girişine gönderdiği alarmlar;
• Events API'ye gönderilen event'ler.

Kime bildirim gittiği değişmez: kanallar ve issue tracker'lar abone oldukları bildirimleri aynen almaya devam eder. Liste, her şeyi bir arada görmek ve ekibin kimin neyle ilgilendiğini söylemesi içindir. Zil (bildirimler) ayrıdır.

Event'leri kuralla susturmak, yönlendirmek, escalation yapmak, tekilleştirmek ya da resolve etmek için Event policy'leri sayfasını kullanın (Test → Olaylar → Event policy'leri).

#Bir sorun, bir event

Her event'in kaynağından, tipinden, servisinden, ortamından, host'undan ve resource'undan oluşan bir key'i (dedup key) vardır; ya da gönderdiğiniz dedupKey kullanılır.

• Bu key ile bir event open ya da acknowledged iken tekrar gelen yeni satır açmaz: sayıyı ve son görülme zamanını, değiştiyse severity'yi günceller.
• Düzelme (monitör yeniden ayakta, alarm resolved) event'i resolved yapar.
• Resolve'dan sonraki 10 dakika içinde gelen sorun aynı event'i yeniden açar; daha sonra gelen yeni event açar.
• Bilgi event'leri (bir deploy, geçen bir karşılaştırma) her biri ayrı kaydedilir.

Severity, yüksekten düşüğe: critical, major, minor, warning, info, ok.

#Filtreler

1. Durum: listenin üstündeki çubukta Canlı (open + acknowledged, varsayılan), Open, Acknowledged, Suppressed, 24 saatte resolved ya da Tümü. Yanındaki sayı o durumdaki event sayısıdır.
2. Ara: başlıktan ya da mesajdan kelimeler veya key'in bir parçası.
3. Filtreler sütunu (solda):
   • Severity: bir değere tıklayın, o değer ve üstü listelenir; Major Major ve Critical'ı gösterir. Tekrar tıklamak kaldırır.
   • Son görülme: 1 saat, 6 saat, 24 saat, 7 gün, 30 gün ya da Her zaman.
   • Tag: team=pay ya da yalnız region yazıp Ekle. Her tag eşleşmeli.
   • Kaynak, tip, servis, host, ortam: değer işaretleyin. Sayılar diğer filtrelere göre değişir.
4. Seçilen filtreler listenin üstünde etiket olarak durur: × ile tek tek ya da Tümünü temizle ile kaldırın.
5. Sütunu gizlemek için başlığındaki « düğmesi, geri açmak için Filtreler. Telefonda Filtreler sütunu yandan açar.

Filtreler adres çubuğunda durur: aynı görünümü paylaşmak için adresi kopyalayın.

#Ack ve resolve

• Ack (acknowledge): ekibe birinin ilgilendiğini söyler. Event canlı kalır; tekrarlar sayılmaya devam eder.
• Resolve: elle kapatır. Aynı key ile 10 dakika içinde gelen yeni sorun yeniden açar.
• Yeniden aç: resolved bir event'te, key'inin başka canlı event'i yoksa.
• Not: bulduğunuz her şey; timeline'a yazılır. Ack ve Resolve de notu alır.

Listede satırları işaretleyin (başlıktaki kutu bütün sayfayı işaretler), sonra Ack ya da Resolve. Çalışma alanının her üyesi bunu yapabilir; her işlem audit log'a yazılır.

Event sayfası alanlarını, tag'lerini (birine tıklayınca ona göre filtreler), geldiği yere linkleri (monitör, alarm, koşu…) ve timeline'ı gösterir: açılış, severity değişiklikleri, ack, notlar, resolve ve yeniden açılış, kimin yaptığıyla.

#İzleme bağlantılarından event'ler

Altyapı → Gözlemlenebilirlik'teki Zabbix, Datadog, New Relic, Dynatrace ve Instana bağlantıları (izleme olayları modülü) dakikada bir okunur ve açık problemleri buraya gelir:

• Kaynak connector:<tür> olur (connector:zabbix gibi); listede bağlantı türünün adıyla görünür. Resource bağlantının adıdır; connection, connector, problemId ve varsa priority tag'leri eklenir.
• İzleme sisteminde açık olan problem açık event'tir; orada kapanan ya da artık okunmayan problem event'i resolved yapar. Aynı kalan problem 15 dakikada bir yeniden sayılır.
• Okuma yalnız okumadır, koşu korelasyonunun yaptığı çağrıların aynısıdır; izleme sisteminizde hiçbir şey değişmez.
• Hata veren bir bağlantı 1, 2, 4 … en çok 30 dakika bekleyip yeniden denenir; diğerlerini etkilemez.
• Bu event'ler kendiliğinden bildirim göndermez: bildirim için connector:* kaynağına bir event policy'si ile route ekleyin.

#Gruplar ve flapping

• Bir correlate policy'sinin grubuna katılan event listede Grupta, grubun ilk event'i Grup: N event daha rozetini taşır. Parent'ın sayfası gruptaki event'leri listeler; child'ın sayfası parent'a link verir.
• Çok sık açılıp kapanan ve bir flap policy'sine takılan event Flapping rozetini ve flapping=true tag'ini taşır. Event sayfası kaç açılış görüldüğünü ve ne zaman stabil sayılacağını gösterir.

#Events API

Kendi event'lerinizi bir API token'ı (ya da oturum) ile gönderin. Her klasörden çalışır:

curl -s -X POST -H "Authorization: Bearer $SPITFIRE_TOKEN" -H "Content-Type: application/json" \
  -d '{"source":"deploy-bot","type":"deploy.failed","severity":"critical","title":"deploy api failed","service":"api","env":"prod","tags":{"team":"pay"}}' \
  "https://spitfire.example.com/api/v1/events"

Yanıt 202'dir; her event'in id'si ve sonucu (opened, repeated, reopened, resolved, recorded) döner. Kapatmak için aynı event'i "status":"resolved" (ya da "severity":"ok") ile gönderin.

Bir istek tek event, bir liste ya da {"events": [...]} taşır: en çok 100 event ve 1 MB. Alan hatası 400 ile alanı ve event'in sırasını döner. Her çalışma alanı saniyede 10 event (120'lik ani yük) gönderebilir; fazlası 429 ve Retry-After ile yanıtlanır.

#Saklama süresi

Event'in son görülme zamanından sayılır, günde bir kez silinir: