Distributed Tracing Nedir? Mikroservislerde İstek Nasıl Takip Edilir?

Bir kullanıcı “Siparişi tamamla” düğmesine bastığında tek bir işlem, arka planda API gateway, kimlik doğrulama, stok, ödeme, kampanya, veritabanı ve mesaj kuyruğu gibi birçok bileşenden geçebilir. Toplam yanıt süresi yükseldiğinde yalnızca sunucu loglarına bakmak, gecikmenin hangi adımda oluştuğunu göstermeyebilir. Her servis kendi kaydını üretse bile bu kayıtların aynı kullanıcı isteğine ait olduğu anlaşılmıyorsa teşhis parçalı kalır.

Distributed tracing, tek bir isteğin dağıtık sistem boyunca izlediği yolu uçtan uca kaydeder. Her servis çağrısı veya önemli işlem bir span olarak temsil edilir; span'ler ortak bir trace kimliği altında birleştirilir. Böylece ekip, isteğin hangi servise ne zaman girdiğini, ne kadar sürdüğünü, nerede hata verdiğini ve hangi alt işlemin toplam gecikmeyi büyüttüğünü inceleyebilir.

Distributed tracing nedir?

Distributed tracing, bir kullanıcı veya uygulama isteğinin birden fazla servis, süreç ve ağ sınırı boyunca ilerleyişini kaydeden gözlemlenebilirlik yöntemidir. OpenTelemetry, distributed trace'i tek bir isteğin mikroservis veya serverless mimaride birden fazla hizmet üzerinden geçerken izlediği yolun kaydı olarak tanımlar OpenTelemetry Observability Primer. Bu kayıt, tek bir toplam süre yerine isteği oluşturan alt operasyonların ilişkisini gösterir.

Bir trace; frontend isteği, API çağrısı, veritabanı sorgusu, dış ödeme servisi, cache erişimi veya kuyruk mesajı gibi adımlardan oluşabilir. Her adımın başlangıç ve bitiş zamanı, servis adı, durum bilgisi ve uygun bağlamsal özellikleri kaydedilir. Bu yapı, “ödeme yavaş” gibi geniş bir belirtinin “kampanya servisi yanıtı 1,8 saniye geciktiriyor” gibi daha araştırılabilir bir bulguya dönüşmesini sağlar.

Trace, span ve parent-child ilişkisi nedir?

Distributed tracing'in temel veri modeli trace ve span kavramlarına dayanır. Trace, isteğin uçtan uca yolculuğudur. Span ise bu yolculuk içindeki tek bir işlemi veya zaman aralığını temsil eder. OpenTelemetry dokümantasyonuna göre span'ler context propagation sayesinde farklı yerlerde üretilseler bile birbiriyle ilişkilendirilerek trace hâline getirilebilir OpenTelemetry Traces.

• Trace ID: Uçtan uca isteğin bütün parçalarını aynı trace altında birleştiren kimliktir.
• Span ID: Trace içindeki tek bir operasyonu tanımlar.
• Parent Span ID: Bir span'in hangi üst operasyondan doğduğunu gösterir.
• Başlangıç ve süre: Operasyonun ne zaman başladığını ve ne kadar sürdüğünü belirtir.
• Attributes: Servis, endpoint, HTTP yöntemi, durum kodu ve sürüm gibi filtrelenebilir bağlamı taşır.
• Events: Span süresi içinde gerçekleşen istisna veya önemli olayları kaydeder.
• Status: Operasyonun hata durumuna ilişkin uygulama tarafından verilen işarettir.

Örneğin sipariş API'sine gelen kök istek root span olabilir. Bunun altında stok kontrolü, kupon doğrulama ve ödeme çağrıları child span olarak yer alır. Ödeme servisi kendi veritabanına sorgu gönderdiğinde bir alt span daha oluşur. Bu hiyerarşi, toplam gecikmenin hangi dalda biriktiğini görmeyi kolaylaştırır.

Context propagation neden distributed tracing'in temelidir?

Bir serviste oluşturulan trace kimliği sonraki servise aktarılmazsa her bileşen bağımsız bir trace başlatır ve uçtan uca yol kopar. Context propagation, trace ve parent span bilgisinin HTTP header, RPC metadata veya mesaj özellikleri gibi taşıyıcılarla servis sınırlarını aşmasını sağlar. Alıcı servis bu bilgiyi çıkarır, yeni span'i mevcut trace'in çocuğu olarak başlatır ve kendi dış çağrılarına yeniden aktarır.

W3C Trace Context standardı, dağıtık trace kimliğinin farklı tracing sistemleri ve sağlayıcılar arasında taşınabilmesi için traceparent ve isteğe bağlı tracestate header'larını tanımlar W3C Trace Context. OpenTelemetry de varsayılan ve birlikte çalışabilir propagation yaklaşımında W3C Trace Context'i kullanır.

Context propagation yalnız HTTP isteklerinde düşünülmemelidir. gRPC, mesaj kuyruğu, event stream ve arka plan job'larında da trace bilgisinin uygun metadata alanına eklenmesi gerekir. Aksi durumda senkron servis zinciri görünürken asenkron işlemler ayrı ve ilişkisiz kayıtlar olarak kalır.

Bir mikroservis isteği distributed tracing ile nasıl izlenir?

Bir istek sisteme girdiğinde tracing SDK veya otomatik instrumentation, giriş operasyonu için bir server span oluşturur. Servis başka bir API'ye çağrı yapmadan önce aktif context'i ilgili protokolün taşıyıcısına enjekte eder. Karşı servis context'i çıkarır, child span başlatır ve aynı işlem zincirini sürdürür.

1. Giriş span'i oluşturulur: API gateway veya ilk uygulama servisi trace ID ve root span üretir.
2. İstek bağlamı eklenir: Endpoint, yöntem, servis sürümü ve güvenli iş bağlamı span attribute olarak kaydedilir.
3. Context dış çağrıya aktarılır: traceparent bilgisi HTTP, gRPC veya mesaj metadata'sına eklenir.
4. Alt servis child span oluşturur: Yeni operasyon aynı trace içinde parent-child ilişkisiyle kaydedilir.
5. Veritabanı ve dış servis çağrıları izlenir: Her önemli bağımlılık kendi client span'iyle görünür olur.
6. Span'ler sonlandırılır ve export edilir: Telemetri collector veya tracing backend'ine gönderilir.
7. Backend trace'i birleştirir: Aynı trace ID'ye ait span'ler zaman çizelgesi ve servis grafiği hâlinde gösterilir.

Bu akışın doğru çalışması için bütün servislerin aynı vendor ürününü kullanması zorunlu değildir. Standart trace context'i korunuyor ve telemetri uyumlu biçimde export ediliyorsa farklı dil ve framework'lerdeki servisler aynı uçtan uca trace'in parçası olabilir. Bu özellik özellikle çok teknolojili yazılım geliştirme projelerinde önemlidir.

Distributed tracing hangi sorunları teşhis etmeye yardımcı olur?

Tracing'in en belirgin faydası, toplam gecikmeyi servis ve operasyon düzeyinde parçalayabilmesidir. Google Cloud Trace dokümantasyonu, distributed tracing'in bir isteğin işlenme süresini ve istek sırasında gerçekleştirilen RPC gibi operasyonların süresini anlamaya yardımcı olduğunu belirtir Google Cloud Trace Overview. Ancak kullanım alanı yalnız performans değildir.

• Hangi mikroservisin toplam yanıt süresini büyüttüğünü bulmak
• Bir retry zincirinin aynı dış servise kaç kez çağrı yaptığını görmek
• Belirli bir sürüm veya endpoint'te hata yoğunlaşmasını incelemek
• Cache miss sonrasında oluşan veritabanı yükünü takip etmek
• Kuyrukta bekleyen mesaj ile arka plan işinin ilişkisini kurmak
• Bir timeout'un kaynağının istemci, ağ veya sunucu tarafı olup olmadığını daraltmak
• Hatalı bir isteğe ait log kayıtlarına trace ID üzerinden ulaşmak
• Servis bağımlılıklarının gerçek çalışma zamanındaki ilişkisini çıkarmak

Trace tek başına her zaman kök nedeni ispatlamaz. Bir span'in uzun sürmesi, gecikmenin o servisin kendi kodundan, bağımlı veritabanından veya ağdan kaynaklandığını ayrıca araştırmayı gerektirebilir. Trace, problemin aranacağı alanı daraltır; log, metric ve profil verileriyle birlikte değerlendirilmesi daha güvenilir sonuç üretir.

Trace zaman çizelgesi nasıl okunur?

Tracing arayüzleri çoğunlukla span'leri yatay zaman çubuklarıyla gösterir. En üstte root span, altında child span'ler bulunur. Bir span'in uzunluğu kendi süresini, zaman çizelgesindeki konumu ise diğer operasyonlarla paralel mi yoksa ardışık mı çalıştığını gösterir.

Span süresi ile self time aynı değildir. Bir parent span uzun görünse de sürenin büyük bölümü child operasyonlarda geçmiş olabilir. Teşhis sırasında “en uzun span” yerine kritik yolu ve span'in kendi içinde harcadığı zamanı ayırmak gerekir.

Otomatik ve manuel instrumentation arasındaki fark nedir?

Otomatik instrumentation; yaygın HTTP framework'leri, veritabanı istemcileri, RPC kütüphaneleri ve mesajlaşma sistemleri için kodu tek tek değiştirmeden temel span'ler üretebilir. İlk görünürlük için hızlıdır ve servisler arasında standart isimlendirme sağlamaya yardımcı olur. Ancak uygulamanın iş anlamını her zaman bilemez.

Manuel instrumentation, “stok rezervasyonu”, “teklif hesaplama” veya “ödeme onayı” gibi iş açısından önemli operasyonlar için özel span ve event oluşturur. Her fonksiyon için span açmak doğru değildir; telemetri hacmi artar ve trace okunamaz hâle gelir. Manuel span, kritik iş sınırı, pahalı operasyon veya otomatik araçların göremediği anlamlı bekleme için kullanılmalıdır.

En dengeli yaklaşım, ağ ve framework katmanında otomatik instrumentation; kritik domain operasyonlarında sınırlı manuel instrumentation kullanmaktır. API'ler ve dış sistemler arasında context aktarımının kesilmemesi ise API entegrasyonu tasarımının zorunlu bir parçası olarak ele alınmalıdır.

Asenkron mesajlar ve kuyruklarda trace ilişkisi nasıl korunur?

HTTP çağrısında parent-child ilişkisi çoğunlukla açıktır; mesaj kuyruğunda ise producer ile consumer farklı zamanda ve farklı süreçte çalışabilir. Producer mesajı yayınlarken aktif trace context'ini mesaj metadata'sına eklemeli, consumer bu context'i çıkararak işleme span'ini ilişkilendirmelidir. Mesaj aracısı trace header'larını korumuyorsa bağlantı kopar.

Her asenkron ilişki doğrudan parent-child olmak zorunda değildir. Bir batch işlemi birden fazla mesajdan doğabilir veya tek mesaj birkaç bağımsız süreci tetikleyebilir. Bu durumlarda span links, nedensel ilişkiyi tek bir ebeveyn hiyerarşisine zorlamadan gösterebilir. Veri modeli, iş akışının gerçek yapısını yansıtmalıdır.

Retry ve dead-letter süreçleri de izlenmelidir. Aynı mesajın her denemesinde yeni bir operasyon span'i oluşturulabilir; ancak mesaj kimliği ve önceki denemeyle ilişki korunmalıdır. Aksi durumda başarısız entegrasyon yalnızca çok sayıda bağımsız hata gibi görünür ve gerçek tekrar zinciri anlaşılamaz.

Sampling nedir ve neden gereklidir?

Yoğun trafikli bir sistemde her isteğin bütün span'lerini saklamak yüksek ağ, depolama ve sorgu maliyeti oluşturabilir. Sampling, trace'lerin belirli bir bölümünü kaydetme veya export etme kararıdır. OpenTelemetry, yüksek hacimli sistemlerin önce head sampling ile belirli bir oranı seçebileceğini, daha sonra telemetry pipeline içinde tail sampling ile tamamlanmış trace'e bakarak daha gelişmiş karar verebileceğini açıklar OpenTelemetry Sampling.

• Head sampling: Karar trace başlarken verilir. Basit ve düşük maliyetlidir; fakat sonradan oluşacak hata veya yüksek gecikme henüz bilinmez.
• Tail sampling: Karar trace'in span'leri toplandıktan sonra verilir. Hatalı, yavaş veya belirli özelliğe sahip trace'leri koruyabilir; daha fazla buffer ve işlem kaynağı gerektirir.
• Parent-based sampling: Alt servislerin üst trace'in sampling kararını takip etmesine yardım eder ve parçalı trace riskini azaltır.

Sampling rastgele birkaç trace saklamakla sınırlı kalmamalıdır. Kritik ödeme, yönetici işlemi veya düşük hacimli ama yüksek değerli operasyonlar ayrı kurallarla korunabilir. Hata ve aşırı gecikme trace'lerinin kaybedilmemesi gerekir. Sampling oranı belirlenirken teşhis değeri, trafik hacmi, depolama maliyeti ve yasal saklama sınırları birlikte değerlendirilmelidir.

Distributed tracing veri güvenliği açısından nasıl yönetilmeli?

Span attribute ve baggage alanları kullanıcı veya işlem bağlamı taşıyabilir. Ancak parola, access token, kart verisi, kişisel mesaj, tam sorgu içeriği veya gereksiz kişisel veri trace'e yazılmamalıdır. OpenTelemetry, baggage bilgisinin HTTP header'ları üzerinden taşınabildiğini ve ağ trafiğini inceleyen kişiler tarafından görülebileceğini açıkça belirtir OpenTelemetry Baggage.

Trace ID bir kimlik doğrulama mekanizması değildir ve kullanıcı kimliği yerine kullanılmamalıdır. Dışarıdan gelen trace header'ları doğrulanmadan güvenilir iş bağlamı kabul edilmemeli; çok uzun veya kötü biçimlendirilmiş header'lara karşı sınırlar uygulanmalıdır. Telemetry backend erişimi rol bazlı sınırlandırılmalı ve saklama süresi iş ihtiyacından uzun tutulmamalıdır.

Distributed tracing kurulumunda sık yapılan hatalar

• Context propagation'ın bazı servislerde kopması: Trace'in ortasında yeni root span'ler oluşur ve uçtan uca yol parçalanır.
• Servis adlarının tutarsız olması: Aynı servis farklı ortamlarda veya sürümlerde ayrı sistemler gibi görünür.
• Her fonksiyona span eklemek: Telemetri maliyeti artar, trace okunamaz ve kritik operasyonlar kaybolur.
• Yalnız başarılı trace'leri örneklemek: Teşhis için en değerli hata ve yüksek gecikme kayıtları kaybedilir.
• Asenkron akışları izlememek: HTTP zinciri görünürken queue consumer ve arka plan işleri trace dışı kalır.
• Trace ile logları ilişkilendirmemek: Hatalı span bulunsa bile ayrıntılı olay kaydına geçiş manuel kalır.
• Deploy ve sürüm bilgisini eklememek: Sorunun hangi yazılım değişikliğinden sonra başladığı anlaşılamaz.
• Hassas veriyi attribute olarak eklemek: Gözlemlenebilirlik sistemi yeni bir veri sızıntısı yüzeyine dönüşür.

Tracing bir kez kurulup unutulan özellik değildir. Yeni servis, framework, kuyruk veya üçüncü taraf entegrasyon context zincirini bozabilir. Trace coverage ve örnek kritik akışlar düzenli olarak test edilmeli; bu kontrol canlı uygulamanın bakım ve sürüm sürecine eklenmelidir.

Distributed tracing ne zaman gereklidir, ne zaman fazla karmaşıktır?

Tek uygulama ve tek veritabanından oluşan küçük bir sistemde yapılandırılmış log, request ID ve temel performans metric'leri çoğu sorunu çözebilir. Bu mimaride tam tracing backend'i ve collector ağı kurmak sağlayacağı faydadan fazla operasyon yükü oluşturabilir. Yine de dış ödeme, e-posta veya kargo servisi gibi kritik bağımlılıklar varsa seçili operasyonlarda tracing yararlı olabilir.

Servis sayısı, asenkron işlem, üçüncü taraf API, tenant ve dağıtım sıklığı arttığında tek isteğin yolunu loglardan birleştirmek zorlaşır. Ekip hata araştırırken farklı log sistemlerinde zaman ve kullanıcı bilgisiyle manuel eşleştirme yapıyorsa distributed tracing ihtiyacı belirginleşmiştir. Özellikle yüksek değerli işlemlerin birçok bileşenden geçtiği özel yazılım projelerinde trace tasarımı mimari planın parçası olmalıdır.

Distributed tracing uygulama kontrol listesi

1. Kritik kullanıcı ve sistem akışlarını belirleyin; her endpoint'i aynı öncelikte ele almayın.
2. Servis adları, ortam, sürüm ve operasyon isimleri için ortak standardı tanımlayın.
3. HTTP, RPC, veritabanı ve mesajlaşma katmanlarında otomatik instrumentation kapsamını çıkarın.
4. traceparent bilgisinin bütün servis ve kuyruk sınırlarında aktarıldığını test edin.
5. İş açısından önemli operasyonlara sınırlı ve anlamlı manuel span ekleyin.
6. Hatalı ve yavaş trace'leri koruyan sampling politikası tasarlayın.
7. Trace ID'yi yapılandırılmış loglara ekleyerek log-trace korelasyonu sağlayın.
8. Attribute ve baggage alanları için hassas veri yasakları oluşturun.
9. Collector, exporter ve backend kesintilerinin uygulama trafiğini bozmamasını sağlayın.
10. Yeni sürümlerde trace coverage, maliyet ve veri kalitesini düzenli denetleyin.

Sonuç: Tek isteğin bütün yolunu ortak bağlamla görünür kılın

Distributed tracing, mikroservislerde bir isteği oluşturan servis çağrılarını, veritabanı işlemlerini ve asenkron adımları tek trace altında birleştirir. Trace ID uçtan uca ilişkiyi, span'ler operasyonları, parent-child yapısı ise nedensel sırayı gösterir. Context propagation koparsa bu bütünlük kaybolur; bu nedenle tracing'in asıl temeli grafik arayüzünden önce servisler arası bağlam aktarımıdır.

Sağlıklı bir kurulum otomatik instrumentation ile başlar, kritik iş operasyonlarında manuel span'lerle zenginleşir, sampling ile maliyeti kontrol eder ve loglarla korelasyon kurar. Amaç mümkün olan en fazla span'i üretmek değil; kullanıcı etkisi olan bir hatanın veya gecikmenin hangi servis zincirinde ve hangi koşulda oluştuğunu güvenilir biçimde açıklayabilmektir.