Bir kullanıcı destek ekibini arayıp "Az önce kasko sorgusu yaptım, bir şirketin sonucu gelmedi" dediğinde ne olur? Çoğu sistemde destek ekibi önce kullanıcının adını, ardından yaklaşık saati sorar, sonra farklı sunucuların loglarında o saat aralığındaki kayıtları tek tek tarar. İstek mobil uygulamadan API sunucusuna, oradan kuyruğa, kuyruktan bir işçiye ve işçiden sigorta şirketi servisine geçtiği için ilgili kayıtlar beş farklı yerde dağınık durur. Dağıtık izleme ve korelasyon kimliği, bu dağınıklığı tek bir iplikte birleştirir.
Korelasyon kimliği nedir?
Korelasyon kimliği, bir kullanıcı işleminin başlangıcında üretilen ve o işlemin dokunduğu her bileşene taşınan benzersiz bir değerdir. Mobil uygulama sorgu isteğini gönderirken bu kimliği bir başlıkta iletir. API sunucusu aynı kimliği kendi loglarına yazar ve kuyruğa bıraktığı mesaja ekler. İşçi mesajı alırken kimliği okur, kendi loglarına yazar ve sigorta şirketine yaptığı çağrının kaydına da ekler. Sonuçta bu kimlikle yapılan tek bir arama, işlemin bütün yolculuğunu ortaya çıkarır.
Kimliği kim üretmeli?
İdeal olarak işlemin ilk temas noktası, yani istemci veya sistemin dış kapısındaki ilk bileşen kimliği üretir. İstek bir kimlik olmadan gelirse ilk sunucu katmanı yeni bir kimlik oluşturur. Bir istemciden gelen kimliğe körü körüne güvenilmemeli, biçimi doğrulanmalı ve uzunluğu sınırlanmalıdır; aksi halde log sistemine istenmeyen içerik enjekte edilebilir.
Yapılandırılmış log: Aranabilir kayıtlar
Korelasyon kimliğinin işe yaraması için logların aranabilir olması gerekir. Serbest metin halindeki log satırları insan için okunabilir ama makine için zor işlenir. Yapılandırılmış logda her kayıt, alanları belli bir nesne olarak yazılır. Tipik alanlar şunlardır:
- Zaman damgası ve log seviyesi
- Korelasyon kimliği
- Bileşen adı ve sürümü
- Acente kimliği
- Branş ve hedef sigorta şirketi
- İşlem adı ve süresi
- Sonuç durumu ve varsa hata kategorisi
Bu yapı sayesinde "dün öğleden sonra belirli bir şirketin DASK sorgularında zaman aşımına düşen işlemler" gibi sorgular saniyeler içinde yanıtlanabilir.
Loglarda kişisel veri
Yapılandırılmış log yazarken en sık yapılan hata, istek ve yanıt gövdelerini olduğu gibi kaydetmektir. Bu gövdeler kimlik numarası, plaka, adres ve telefon gibi kişisel veriler içerir. Loglara yalnızca kayıt kimlikleri yazılmalı; hassas alanlar maskelenmeli veya hiç yazılmamalıdır. Log sistemine erişim de en az yetki ilkesiyle sınırlandırılmalıdır.
Korelasyondan dağıtık izlemeye
Korelasyon kimliği hangi kayıtların aynı işleme ait olduğunu gösterir. Dağıtık izleme ise bir adım öteye geçerek işlemin zaman içindeki yapısını ortaya koyar. Bir iz (trace), işlemin tamamını temsil eder. İz, aralık (span) adı verilen parçalardan oluşur. Her aralık bir bileşenin yaptığı bir işi, başlangıç ve bitiş zamanlarıyla birlikte kaydeder. Aralıklar arasındaki ebeveyn-çocuk ilişkisi, hangi işin hangi iş tarafından tetiklendiğini gösterir.
Bir kasko sorgusunun izi, örneğin şöyle bir yapıya sahip olabilir: API isteğini karşılayan ana aralık, içinde araç bilgisi doğrulama aralığı, kuyruğa yazma aralığı ve ardından her şirket için ayrı birer işçi aralığı. İşçi aralıklarının her birinde de şirket servisine yapılan dış çağrının süresi ayrı bir aralık olarak görünür.
Zaman çizelgesi görünümü ne kazandırır?
İzler genellikle yatay çubuklardan oluşan bir zaman çizelgesi olarak görselleştirilir. Bu görünüm, sorunun nerede olduğunu çoğu zaman tek bakışta gösterir:
- Uzun bir dış çağrı çubuğu: Gecikme sigorta şirketi tarafındadır.
- Kuyrukta uzun bekleme: Mesaj işçiye geç ulaşmıştır; kapasite yetersizdir.
- Art arda sıralanmış çağrılar: Paralel yapılabilecek işler sırayla yapılıyordur.
- Tekrarlanan aynı aralık: Yeniden deneme mekanizması devrededir.
Asenkron sınırları geçmek
Dağıtık izlemenin en zorlu kısmı, kuyruk gibi asenkron sınırlardır. HTTP çağrılarında iz bağlamı başlıklarla kolayca taşınır. Kuyruk mesajlarında ise bağlamın mesaj meta verisine açıkça eklenmesi ve işçi tarafında okunarak yeni aralığın doğru ebeveyne bağlanması gerekir. Bu adım atlanırsa iz kuyruğun iki tarafında kopar ve tek bir işlem iki ayrı iz gibi görünür. Yaygın açık standartlar, bağlamın hangi alanlarda taşınacağını tanımlar ve farklı dillerde yazılmış bileşenlerin uyumlu çalışmasını sağlar.
Örnekleme: Her şeyi kaydetmek gerekmez
Yoğun bir sistemde her işlemin ayrıntılı izini saklamak ciddi bir depolama maliyeti doğurur. Bunun yerine örnekleme uygulanır. Başarılı ve hızlı işlemlerin yalnızca bir kısmı saklanırken hatalı veya yavaş işlemlerin tamamı saklanabilir. Bu yaklaşım, sorun incelemesi için gereken veriyi korurken maliyeti makul seviyede tutar.
Destek sürecine etkisi
Korelasyon kimliğinin kullanıcı arayüzünde de erişilebilir olması önemli bir kolaylıktır. Hata mesajlarının yanında kısa bir işlem referansı göstermek, kullanıcının bu referansı destek ekibine iletmesini sağlar. Destek ekibi de saat ve isim sormadan doğrudan ilgili izi açabilir.
İz verisini performans iyileştirmede kullanmak
Dağıtık izleme yalnızca hata anında başvurulan bir araç değildir. Toplanan izler belirli aralıklarla toplu olarak incelendiğinde sistemin genel davranışı hakkında değerli bulgular sunar. Örneğin kasko sorgularında araç bilgisi doğrulama adımının toplam sürenin önemli bir kısmını oluşturduğu görülebilir; bu durumda doğrulama sonucunu kısa süreliğine önbelleğe almak anlamlı bir iyileştirme olabilir. Benzer şekilde bazı şirket çağrılarının sırayla yapıldığı fark edilirse paralel hale getirilerek ilk sonuca kadar geçen süre kısaltılabilir. Bu tür kararlar, tahmine değil ölçülmüş veriye dayandığında yanlış yere emek harcama riski azalır.
InsureHub destek ekibinde izlenebilirlik
InsureHub, sigorta acentelerine yazılım sağlayan bir platform olarak mobil sigorta uygulaması, web paneli ve teklif motoru arasında geçen işlemlerin izlenebilir olmasını destek kalitesinin temel koşulu olarak görür. Bir sigorta teklif programı sorgusunun hangi adımda ne kadar sürdüğünü bilmek, hem sorunları hızla çözmeyi hem de sistemi doğru yerden iyileştirmeyi mümkün kılar.