Servis Haritası
Monitörleriniz arasındaki canlı bağımlılık grafiği, kök neden izleme, etki alanı görselleştirme ve aşağı yönlü alarmları bastırma.
Servis Haritası, monitörlerinizi düz bir liste yerine bir bağımlılık grafiği olarak gösterir. Servisler arasındaki bağımlılıkları (veritabanı → API → frontend → CDN) tanımlarsınız; bir düğüm düştüğünde graf, ondan etkilenen tüm alt servisleri vurgular.
Ne işe yarar?
- Kök neden analizi: Frontend down olduğunda gerçek sorun frontend'in kendisi mi, bağlı olduğu API mi, yoksa API'nin altındaki veritabanı mı?
- Etki alanı: "Postgres düştü" gerçek sorunsa hangi 12 servis bozulur? Bunu hangi müşteriler hisseder?
- Aşağı yönlü alarm bastırma: Bir veritabanı düştüğünde alta doğru yayılan 12 fazlalık alarm yerine tek bir kök alarm gönderilir.
- Onboarding: Yeni mühendise sistemin haritasını 5 dakikada anlatırsınız.
Plan kapsamı
Servis Haritası Starter ve üzeri planlarda yer alır (Starter, Professional, Enterprise). Free ve Hobby hesapları harita yerine yükseltme davetiyle karşılaşır.
Servisler neye göre bağlanır?
Haritadaki her bağ bir kanıta dayanır ve hangi kanıta dayandığını söyler. Nedenlerini görmek için bağa tıklayın:
| Neden | Anlamı |
|---|---|
| Birlikte düştü (Went down together) | İki monitörün kesintileri son 30 günde en az 3 kez birbirine bir kontrol aralığı kadar yakın başladı ve bu, tesadüfün vereceğinin en az 10 katı. Bağ sayıları gösterir ("Went down together 12 times in 30 days"). |
| Aynı IP (Same IP) | İki monitör de aynı sunucu adresine ulaştı. Aynı CDN adresinin arkasındaki iki site bu yüzden bağlanmaz: bir CDN adresini birbiriyle ilgisiz birçok site paylaşır. |
| Aynı kayıtlı alan adı (Same registered domain) | İkisi de aynı kayıtlı alan adının altında; Public Suffix List ile okunur. api.ornek.com.tr ile www.ornek.com.tr ilişkilidir, .com.tr altındaki iki ayrı şirket değildir. |
| Aynı CDN (Same CDN) | İkisi de aynı CDN üzerinden sunuluyor. Yalnızca başka bir kanıtın yanında gösterilir, tek başına bağ kurmaz. |
| Sizin bağınız / bağımlılığınız | Sizin çizdiğiniz bir bağ ya da tanımladığınız bir bağımlılık. |
Ortak sunucu ya da alan adı, en fazla 10 monitörlük gruplarda bağ kurar. Monitörlerinizden 30'u aynı alan adını paylaşıyorsa bu bilgi her çift için doğrudur ve hiçbiri hakkında bir şey söylemez; o yüzden yalnızca başka bir kanıtın kurduğu bağın yanında gösterilir. Monitör adları bağ kurmak için kullanılmaz ve hiçbir bağa yapay zeka modeli karar vermez.
Bağlar her gece aranır; istediğiniz an Discover dependencies ile de başlatabilirsiniz. Tur bitene kadar (yaklaşık 45 saniyeye kadar) buton dönen bir göstergeyle bekler.
Bağları onaylamak, reddetmek, eklemek
Bulunan bir bağ, siz bakana kadar önerilen (kesik çizgili) durumdadır. Bağa tıklayın:
- Confirm link bağı tutar; kanıtı zamanla silinse bile kalır.
- Not related bağı kaldırır ve bir daha önerilmez.
- Mark as a dependency hangisinin diğerine bağımlı olduğunu kaydeder.
Keşfin kaçırdığı bir bağı kendiniz ekleyin: Add manual link'e tıklayın, kanvas üzerinde iki servis seçip onaylayın. İsteğe bağlı bir not ekleyebilirsiniz. Sildiğiniz bağlar silinmiş kalır, sonraki keşif turlarında yeniden oluşturulmaz.
Her monitörün sayfası da aynı nedenlerle Related monitors listesini gösterir; bu liste tüm planlarda vardır. İki monitör sık sık birlikte düşüyorsa ve aralarında kayıtlı bir bağımlılık yoksa, liste birinin diğerine bağımlı olup olmadığını sorar.
Görselleştirme
Servis Haritası sayfası, monitörleri etkileşimli bir graf olarak çizer:
Her düğüm, sağlık eğilimine göre renklendirilir (düğüm kenarlığı, eşleşen eğilim ikonuyla birlikte):
- Kırmızı kenarlık: kritik
- Turuncu kenarlık: kötüleşiyor
- Mavi kenarlık: stabil
- Yeşil kenarlık: iyileşiyor
- Gri kenarlık: bilinmiyor / henüz eğilim yok
- Altın kenarlık ve "Upstream": başka servisler ona bağımlı olarak kayıtlı
- Kesik çizgili kenar: henüz onaylamadığınız önerilen bir bağ
- Ok: bir bağımlılık; bağımlı servisten bağlı olduğu servise doğru
- Kenar etiketi: en güçlü neden (Down together ×12, Same IP, Same domain, Your link, Dependency)
Her düğüm kartı, ilgili monitörün uptime %'sini ve ortalama yanıt süresini doğrudan kart üzerinde gösterir. Kanvası bir servis kümesine daraltmak için Environment ve Service Type filtrelerini kullanın.
Etki alanı
Bir servis arızalanıp alt bağımlılıklarını da yanında götürdüğünde, Servis Haritası bir kaskad arıza (cascade failure) uyarısı çıkarır; bu uyarı birincil servisi ve etkilediği servisleri listeler. Kavramsal olarak bir Postgres arızası şöyle yayılır:
Postgres (DOWN) ─────┬─> Auth API ─────> Frontend ──> CDN
├─> Reports API ──> Dashboard
├─> Webhooks Worker
└─> Search Service
Bu, "kim etkileniyor?" sorusuna bir bakışta cevap verir; müşteri iletişim ekibi durum sayfasında doğru servisleri kırmızıya boyayabilir.
Aşağı yönlü alarm bastırma
Servis haritası kurulduğunda incident akışı aşağı doğru yayılan gürültüyü bastırabilir:
- Postgres down → kök incident normal yönlendirmeyle açılır
- Auth API down (Postgres'e bağımlı) → kök incident'e bağlı şekilde bastırılmış olarak kaydedilir, bildirim gönderilmez
- Frontend down (Auth'a bağımlı) → aynı kök altında bastırılır
Yalnızca kök incident insanları rahatsız eder. Postgres iyileştiğinde alt incident'lar otomatik kapanır.
Önemli, iki anahtar birden açık olmalıdır. Aşağı yönlü alarm bastırma için yöneticinizin açtığı genel bir anahtar ve plan bazında bir tercih anahtarı vardır. İkisi de varsayılan kapalıdır. Önce genel anahtarı açın, sonra istediğiniz planlarda etkinleştirin.
Keşif detayları
Keşif, zaten topladığımız üç bilgiyi okur: her monitörün kesintilerinin ne zaman başladığı, her HTTP kontrolünün hangi adrese, CDN'e ve sertifikaya ulaştığı ve her monitörün URL'i. Kodunuzdan dağıtık iz (trace) almaz ve kendi başına hiçbir bağımlılık eklemez: bir bağımlılık, dolayısıyla aşağı yönlü alarm bastırma da, yalnızca sizin seçiminizle oluşur.
Sık sorulan sorular
S: 200 monitörüm var; servis haritasını elle çizmek imkansız. C: Önce kritik 20-30 monitörle başlayın (veritabanları, gateway'ler, ana API'ler). %80 değer, %20 efor. Geri kalanı zaman içinde ekleyin.
S: Bir bağımlılığı yanlış tanımlarsam ne olur? C: Aşağı yönlü alarm bastırma açıksa alt servis alarmı sessizce gizlenir. İlk birkaç hafta bastırmayı kapalı tutun ve haritayı yalnızca görselleştirme için kullanın.
S: Servis Haritası ile Incident Analitik arasındaki fark nedir? C: Servis Haritası gerçek zamanlı topolojidir, "şu an ne durumda?" Incident Analitik ise zaman serisi raporudur. MTTR, sıklık. İki farklı soru, iki farklı araç.