Olaylar

UptimeWarden'da olay yaşam döngüsü, zincir bastırma, postmortem akışı ve nöbet yönetiminin temelleri.

Monitörlerinizden biri başarısız olduğu anda UptimeWarden bir olay kaydı açar. Olay; alarm tetiklemenin, nöbet rotasyonunun, durum sayfası güncellemesinin ve sonradan yazılan postmortem'in tek merkezi kaydıdır. Bu bölümün tamamı, ilk hata sinyalinden defterin kapatıldığı ana kadar bu kaydın nasıl davrandığını anlatır.

Bu bölümde neler var

• Olay yaşam döngüsü: bir olayın geçtiği tüm durumlar ve her geçişi neyin tetiklediği
• Zincir Bastırma (Cascade Suppression): tek bir üst kaynak arızasının 50 alarma dönüşmesini engelleme
• Bakım Pencereleri: planlı kesintileri sessize alıp gerçek alarmların ciddiye alınmasını sağlama
• Postmortem İş Akışı: çözülmüş bir olayı, ekibin öğrenebileceği yazılı bir kayda dönüştürme

Hangi monitörler olay açar?

Tüm monitör tipleri olay üretebilir. Pratikte en sık karşılaşılan beş tanesi:

• HTTP / HTTPS: uç nokta erişilemez, 5xx, zaman aşımı, yavaş yanıt
• SSL: sertifika süresi bitmek üzere (veya geri toparlama)
• TCP: port erişilemez
• Heartbeat: beklenen ping geç kaldı veya hiç gelmedi
• Ping (ICMP): sunucu yanıt vermiyor

Yaşam döngüsü tek satırda

open → acknowledged → investigating → monitoring → resolved

Çok bölgeli doğrulama için iki ek durum vardır:

• pending_verification, bir bölge arıza bildirdi, diğerleri hâlâ kontrol ediyor (bildirim bekler)
• rejected, doğrulama eşiği karşılanmadı, yanlış alarm reddedildi

Zincir Bastırma açıkken altıncı bir durum daha görünür:

• suppressed_cascade, üst kaynak bağımlılık zaten arızalı. Olay bildirim göndermez ve durum sayfasına çıkmaz (detay aşağıda).

Tüm durum makinesi için: Olay Yaşam Döngüsü.

Olayı kim açar?

Olaylar, bir monitör arıza bildirdiği anda otomatik açılır. Sistem önce birkaç güvenlik kontrolü yapar: monitör bir bakım penceresinde mi, üst bir olay tarafından bastırılıyor mu ve (uygun ise) çok bölgeli doğrulama tamamlanmış mı? Tüm bunlar geçtikten sonra olay open durumuna geçer ve bildirimler gönderilir.

Olayı manuel olarak da açabilirsiniz. Olaylar → Yeni Olay yolu, planlı bir bakımı geçmişe dönük kayda almak veya UptimeWarden'dan önce fark ettiğiniz bir kesintiyi belgelemek için kullanışlıdır.

Önem ve öncelik

Her olay birbirinden bağımsız iki sınıflandırma taşır.

Önem (severity), etkinin büyüklüğü:

• minor, bazı kullanıcılar etkilendi
• major, kullanıcıların önemli bölümü etkilendi
• critical, tüm sistem kapalı

Öncelik (priority), yanıtın aciliyeti:

• low, medium, high, critical

Önem, alarm tipine göre otomatik atanır: erişilemezlik (down) kritik, yavaş yanıt uyarı seviyesindedir; SSL ve alan adı olaylarında ise sona kalan gün sayısına göre belirlenir. Önceliği siz belirlersiniz veya eskalasyon politikanız belirler.

Bir olayı üstlenme

Her bildirim bir Acknowledge linki içerir. Tek tıkla:

• Giriş yapmanıza gerek kalmaz; link imzalı ve zaman sınırlıdır
• Olay acknowledged durumuna geçer
• Eskalasyon anında durur
• Denetim kaydı, olayı kimin üstlendiğini tutar

Detaylar: Olay Yaşam Döngüsü.

Zincir Bastırma

Bir veritabanı çöktüğünde, ona bağlı 50 monitör de çöker. Bunların hepsi için ayrı olay açıp 50 SMS göndermek hem gürültülü hem yanıltıcıdır. Zincir Bastırma bu durumu sessizce yönetir:

• UptimeWarden monitörlerinizin bağımlılık haritasını tutar
• Veritabanı olayı açıkken (varsayılan 60 saniyelik pencere içinde) bağımlı monitörlerin yeni hataları suppressed_cascade durumuna düşer
• Bastırılan olaylar bildirim göndermez, durum sayfasında görünmez ve eskalasyon tetiklemez
• Üst olay çözüldüğünde hâlâ arızalı olan monitörler otomatik olarak open durumuna yükseltilir

Sonuç: 1 olay ön planda, 49 olay sessizce arka planda izlenir. Olay listesindeki "Bastırılanları dahil et" anahtarıyla bunları denetleyebilirsiniz.

Postmortem akışı

Bir olay çözüldüğünde UptimeWarden sizin için postmortem taslağı oluşturur:

1. Sistem zaman çizelgesini, etkilenen monitörleri ve çözüm süresini (MTTR, ortalama onarım süresi) toplar.
2. Bir yapay zekâ modeli ilk taslağı yazar: ne oldu, neyi etkiledi ve önerilen aksiyon maddeleri.
3. Editör ve yönetici kullanıcılar olay sayfasındaki Postmortem sekmesini açar, taslağı düzenler (Markdown desteklidir) ve Yayınla'ya basar.
4. Yayınlanan postmortem, ekibinizin olaya dair kanonik kaydı haline gelir.

Zincir Bastırma ile bastırılmış olaylar postmortem üretmez. Postmortem taslakları aylık bir hakla her plana dahildir: Free ve Hobby'de 1, Starter'da 3; Professional ve Enterprise'da aylık sayı yoktur.

Detaylar: Postmortem İş Akışı.

Bakım pencereleri

Planlı bakım sırasında alarm yağmurunu önlemek için bakım penceresi tanımlayın:

• Belirli monitörler için, haftalık tekrarlı veya tek seferlik
• Pencere açıkken hatalar olay açmaz; kontroller kayıt altına alınmaya devam ettiği için grafikleriniz doğru kalır
• Geri toparlama sinyalleri pencere içinde bile her zaman geçer

Detaylar: Bakım Pencereleri.

API erişimi

# Aktif olayları listele (status: active | resolved | all)
curl -H "Authorization: Bearer $UPTIMEWARDEN_TOKEN" \
  "https://app.uptimewarden.online/api/v1/incidents?status=active"

# Bir olayı çözüldü olarak işaretle
curl -X PATCH \
  -H "Authorization: Bearer $UPTIMEWARDEN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status":"resolved","resolutionMessage":"Servis toparlandı"}' \
  "https://app.uptimewarden.online/api/v1/incidents/{publicId}"

# Bir olaya yorum ekle
curl -X POST \
  -H "Authorization: Bearer $UPTIMEWARDEN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"message":"Kök neden tespit edildi"}' \
  "https://app.uptimewarden.online/api/v1/incidents/{publicId}/comments"

incidents:read (30 günlük pencere) ve incidents:update izinleri gerekir. Detaylar: API Token'lar.

Sonraki adımlar

• Olay Yaşam Döngüsü
• Postmortem İş Akışı
• Bakım Pencereleri
• Eskalasyon Politikaları