DevOps ve Yazılım Kalitesi

Dağıtık İzleme ile Yavaş Bir Teklif Sorgusunun Kaynağını Bulmak

InsureHub Ekibi
18 Ağustos 2026

Diyelim ki bir acente kullanıcısı, kasko teklif sonuçlarının bazı günler hızlı, bazı günler belirgin biçimde geç geldiğini bildirdi. Ortalama yanıt süresi grafiğinde belirgin bir sorun görünmüyor; çünkü yavaş istekler, hızlı olanların arasında kayboluyor. Böyle bir durumda sorunun kaynağını bulmak için tek tek isteklerin içine bakmak gerekir. Dağıtık izleme tam olarak bunu sağlar.

Bu yazı, kavramları bir inceleme hikâyesi üzerinden anlatıyor: Yavaş bir teklif sorgusunun izini sürerken hangi sorular sorulur ve hangi sonuçlara ulaşılır?

Önce kavramlar: iz ve span

Bir iz, tek bir kullanıcı isteğinin baştan sona yolculuğudur. Bu yolculuk, span adı verilen parçalardan oluşur. Her span bir işi temsil eder: veritabanından müşteri bilgisini okumak, teklif motorunu çağırmak, bir sigorta şirketi servisine istek göndermek gibi. Span'ler iç içe geçebilir; teklif motoru span'i, altında her şirket için ayrı span'ler barındırabilir. Görselleştirildiğinde bu yapı, soldan sağa uzanan ve aşağı doğru basamaklanan çubuklardan oluşan bir şelale grafiğine benzer.

İnceleme: adım adım

Adım 1: Yavaş istekleri ayırmak

İlk iş, ortalamaya değil dağılıma bakmaktır. Yanıt sürelerinin yüzdelik dilimleri incelendiğinde, isteklerin büyük çoğunluğunun makul sürede tamamlandığı ama en yavaş dilimin belirgin şekilde uzun sürdüğü görülür. İz aracında yalnızca bu dilimdeki kasko istekleri filtrelenir.

Adım 2: Ortak noktayı aramak

Yavaş izler yan yana konduğunda bir örüntü aranır. Hepsi aynı saat aralığında mı? Aynı şubeden mi? Aynı araç türü için mi? Bu örnekte ortak nokta zaman değil, bir alandır: Yavaş isteklerin tamamında araç değeri bilgisi kullanıcı tarafından elle girilmemiş ve sistemin bu bilgiyi ayrı bir kaynaktan tamamlaması gerekmiştir.

Adım 3: Şelalede uzun çubuğu bulmak

Bir iz açıldığında, şirket servislerine yapılan çağrıların paralel ilerlediği, ancak bunlardan önce gelen bir span'in diğerlerinden çok daha uzun sürdüğü görülür. Bu span, araç değeri tamamlama adımıdır. Daha da önemlisi, bu adım tamamlanmadan hiçbir şirket çağrısı başlamamaktadır. Yani gecikme, şirket servislerinden değil, onlardan önce gelen bir hazırlık adımından kaynaklanmaktadır.

Adım 4: Span özniteliklerini okumak

Span'lere eklenen öznitelikler, yani küçük açıklayıcı bilgiler, nedeni netleştirir. Uzun süren span'in özniteliklerinde, tamamlama servisine yapılan çağrının ilk denemede zaman aşımına uğradığı ve ikinci denemede başarılı olduğu görülür. Yeniden deneme bekleme süresi, gecikmenin büyük kısmını oluşturmaktadır.

Bulgudan çözüme

İnceleme, tek bir değişiklik yerine birkaç iyileştirme fırsatı ortaya çıkarır:

  • Zaman aşımı ayarı: Tamamlama servisi için tanımlı zaman aşımı, servisin olağan yanıt süresine göre yeniden belirlenir.
  • Paralelleştirme: Araç değerine ihtiyaç duymayan şirket çağrıları, tamamlama adımını beklemeden başlatılabilir.
  • Önbellek: Aynı araç bilgisi kısa süre içinde tekrar sorgulandığında sonuç yeniden kullanılabilir.
  • Kullanıcı bilgilendirmesi: Ek bilgi tamamlanırken ekranda hangi adımın sürdüğü gösterilebilir.

Her değişiklikten sonra aynı izler yeniden incelenir ve şelale grafiğinde uzun çubuğun kısalıp kısalmadığı kontrol edilir. Kanıta dayalı iyileştirme, tahmine dayalı optimizasyondan çok daha az yan etki üretir.

Bu incelemeden çıkan dersler

  1. Ortalama yanıltır: Sorunlar çoğu zaman dağılımın kuyruğunda saklanır.
  2. Sıralı bağımlılıklar pahalıdır: Birbirini bekleyen adımlar, her birinin gecikmesini toplar.
  3. Öznitelikler iz kadar önemlidir: Branş, şirket, yeniden deneme sayısı gibi bilgiler olmadan iz yalnızca bir zaman çizelgesidir.
  4. Branşlar ayrı değerlendirilmeli: Bu örnekte sorun kaskoya özgüydü; trafik ve DASK akışları farklı adımlar içerdiği için etkilenmemişti. Tüm teklifleri tek grafikte izlemek bu farkı gizlerdi.

İzleme altyapısında dikkat edilecekler

Her isteği izlemek yüksek trafikli sistemlerde maliyetli olabilir. Bu yüzden örnekleme kullanılır: İsteklerin bir kısmı izlenir, ancak hata alan ya da yavaş kalan isteklerin izlenme önceliği artırılır. Ayrıca span özniteliklerine kişisel veri yazılmamalıdır. Plaka ya da kimlik numarası yerine iç kayıt tanımlayıcısı kullanmak, incelemeyi zorlaştırmadan veriyi korur.

Acente açısından

Dağıtık izleme, teklif programının hızına dair şikâyetlerin somut bir nedene bağlanmasını sağlar. Bu sayede iyileştirmeler tüm sisteme rastgele yayılmak yerine gerçekten darboğaz olan noktaya odaklanır. Acente ekibi için sonuç, özellikle yoğun saatlerde daha öngörülebilir bir teklif deneyimidir. Kendi senaryolarınızda bu deneyimi görmek isterseniz demo talebi oluşturabilirsiniz.

İz bağlamının kaybolmaması

Dağıtık izlemenin çalışabilmesi için, isteğin geçtiği her serviste aynı iz kimliğinin taşınması gerekir. Buna bağlam aktarımı denir. Senkron çağrılarda bu genellikle istek başlıklarıyla otomatik yapılır. Ancak bazı noktalarda bağlam kolayca kaybolur:

  • Kuyruklar ve arka plan işleri: Teklif sonuçlarının bir kuyruğa yazılıp ayrı bir işçi tarafından işlenmesi gibi durumlarda, iz kimliğinin mesajla birlikte taşınması gerekir.
  • Mobil istemciler: İz, kullanıcının dokunduğu andan başlatılırsa ağ gecikmesi ve cihaz tarafındaki bekleme de görünür hâle gelir.
  • Dış servis çağrıları: Sigorta şirketi servisi izi devam ettirmese bile, çağrının kendisi bir span olarak kaydedilmelidir.

Bağlamın koptuğu yerde iz ikiye bölünür ve inceleme sırasında hikâyenin yarısı eksik kalır. Bu nedenle yeni bir servis ya da kuyruk eklendiğinde bağlam aktarımının test edilmesi, izleme altyapısının bakımının bir parçası olmalıdır.

Bağlam aktarımının doğru çalıştığını düzenli olarak kontrol etmenin pratik bir yolu, bilinen bir test isteğini sistemin uçtan uca içinden geçirip ortaya çıkan izin tek parça olup olmadığına bakmaktır. Bu kontrolün yayın hattına eklenmesi, yeni bir değişikliğin izleri sessizce bölmesini erken fark ettirir ve inceleme sırasında eksik hikâyeyle uğraşma ihtimalini azaltır.

Özet

Dağıtık izleme, birçok servise yayılan bir isteğin içini görünür kılar. Yavaş istekleri ayırmak, ortak noktalarını bulmak, şelale grafiğinde uzun span'i tespit etmek ve özniteliklerle nedeni doğrulamak; performans sorunlarını tahmin yerine kanıtla çözmenin güvenilir bir yoludur.