Pulse

• Müşteriye ürün çıkaran küçük ekipler ve tek başına geliştirenler; düz bir uptime pinger’ın vermediği iki şeye ihtiyaçları var: bölgesel bir ağ kesintisi için gece 3’te alarm yok, göstermelik bir uptime yüzdesi yerine dürüst bir hata bütçesi.
• Onların müşterileri: gerçekten ölçülenle örtüşen herkese açık bir durum sayfası okuyorlar — Türkçe ve İngilizce, saatler Europe/Istanbul.
• Önce ben: Pulse melihkizmaz.dev, naylalabs.com, meetmentorz.com ve diğer ürünlerimin API’lerini izliyor.

• Cloudflare’ın ücretsiz planında tek bir Worker olarak tek başıma kurdum: statik dosya olarak React uygulaması, Hono API, alarm’ı her 30 saniyede bir çalan bir Coordinator Durable Object, locationHint ile Frankfurt, İstanbul ve Amsterdam’a yerleştirilen üç Probe Durable Object (her biri gerçek colo’sunu kaydediyor), D1 ve KV.
• Saf ve test edilmiş bir çekirdek — çoğunluk kararı, histerezisli ve dalgalanma bastırmalı monitör durum makinesi, burn-rate hesabı, birleştirilebilir gecikme histogramları ve özetler — Durable Object da kanıt düzeneği de birebir aynı kodu kullanıyor.
• Ürün: 30 sn, 1 dk ya da 5 dk aralıklı HTTP(S) ve heartbeat monitörleri, hata bütçeli SLO’lar ve burn-rate uyarıları, kendiliğinden açılıp kapanan (elle güncellenebilen) olaylar, JSON API, SVG rozet ve gömülebilir bileşenle herkese açık durum sayfaları; Slack, Telegram, imzalı webhook ya da e-postaya uyarılar.
• Herkese açık, salt okunur bir demo — 90 günlük geçmişi ve aynı hattan geçen canlı sentetik probları olan kurgusal bir lojistik firması, Kervan Kargo — ayrıca idempotent monitör API’li API anahtarları, hata oranı ayarlanabilen bir kaos hedefi ve her iddianın arkasındaki simülasyon ile yerel uçtan uca koşular.

1. 1Monitör ekle

   Panelden ya da koddan bir API anahtarıyla — kendi referansına göre idempotent. Yöntem, beklenen durum kodu, anahtar kelime ve gecikme eşiğiyle HTTP(S) ya da cron işleri için bir heartbeat URL’si; bir aralık ve bir SLO hedefi.

2. 2Üç bölgeden yokla

   Coordinator her 30 saniyede sırası gelen kontrolleri Frankfurt, İstanbul ve Amsterdam’daki problara dağıtıyor.

3. 3Çoğunlukla karar ver

   Bir tur ancak en az 3 bölgeden 2’si başarısızsa DOWN. Monitör üst üste 2 DOWN turdan sonra DOWN oluyor, 2 iyi turdan sonra düzeliyor; dalgalanma tespit edilip susturuluyor.

4. 4Özetle ve bütçele

   Turlar dakika, saat ve gün özetlerine bölge başına p50/p95/p99 ile toplanıyor. Hata bütçesi azalıyor; 1 saat ve 5 dakika pencereleri birlikte ≥ 14,4× yakınca sayfa, 6 saat ve 30 dakika birlikte ≥ 6× yakınca bilet açılıyor.

5. 5Haber ver

   Olay kendiliğinden açılıp kapanıyor (Araştırılıyor → Tespit edildi → İzleniyor → Çözüldü), durum sayfası, JSON API ve rozet güncelleniyor, uyarı Slack’e, Telegram’a, imzalı bir webhook’a ya da e-postaya gidiyor.

1. 01

   Tek bir pinger değil, çoğunluk ve histerezis

   Yerine: Tek bir konum üst üste iki kez başarısız olunca alarm vermek.

   Neden: Tek bir bölgedeki anlık sorun kesinti değildir. Bir tur ancak en az 3 bölgeden 2’si başarısızsa DOWN sayılıyor ve monitör için üst üste 2 böyle tur gerekiyor. %20 tek bölge hatalı 30 simüle günde bu 0 yanlış olay verdi; aynı gürültü tek bir konumdan bakınca 2.786 yanlış alarm üretti.

2. 02

   Ham kontroller asla D1’e yazılmıyor

   Yerine: Her kontrol için bir veritabanı satırı.

   Neden: Kontrol başına bir satır, üç monitörle ücretsiz planın günlük 100.000 yazma hakkını bitirirdi. Turlar Coordinator’ın SQLite deposunda duruyor; D1’e monitör başına dakikada bir özet satırı ve bölge başına log-kovalı bir histogram gidiyor; böylece saat ve gün özetleri birebir birleşiyor, yüzdelikler her seviyede yaklaşık %10 içinde kalıyor. Bedeli: kontrol bazlı kayıt yalnızca son 40 turu tutuyor.

3. 03

   Üretim ve kanıtlar için tek bir saf çekirdek

   Yerine: Zamanlayıcıyı kendisinin bir modeline karşı test etmek.

   Neden: Çoğunluk kararı, durum makinesi, burn-rate hesabı ve özetler saf fonksiyonlar; Durable Object da simülasyon düzeneği de bunları birebir kullanıyor — yani kanıtlar bir kopyayı değil, üretim kodunu sınıyor. Burn-rate uyarıları 6 senaryonun 6’sında SRE çalışma kitabının söylediği dakikada tetiklendi.

4. 04

   Tek Worker, 30 saniyelik kontroller için Durable Object alarm’ları

   Yerine: Uygulama için Cloudflare Pages, cron için ayrı bir Worker.

   Neden: Cron en az bir dakikada bir çalışıyor; Durable Object alarm’ı 30 saniye veriyor. Pages yine de cron ve Durable Object sınıfları için ayrı bir Worker isterdi — iki deploy ve scriptler arası bağlantılar. Kota analizi: varsayılan 14 monitör, ücretsiz planın hiçbir günlük kotasının %45’inden fazlasını kullanmıyor; plan yaklaşık 35 monitör taşıyor.

Tek bir Worker deploy’u uygulamayı, API’yi, zamanlayıcıyı ve probları birlikte çıkarıyor; ham kontroller Coordinator’da kalıyor, D1 yalnızca dakika özetlerini görüyor. Buradaki her şey benim.

kesintiden olay ve uyarıya, yerel ortamda (60 sn aralık)

60,4 sn

%20 tek bölge hatalı 30 simüle günde yanlış DOWN olayı — çoğunluk olmadan 2.786

0

SRE çalışma kitabının söylediği dakikada tetiklenen burn-rate senaryosu

6 / 6

aylık maliyet — Cloudflare’ın ücretsiz planı

0 €