1. GİRİŞ

Dağıtık sistemler ve mikroservis mimarileri, modern uygulamaların esnek ve ölçeklenebilir olmasını sağlar ancak aynı zamanda gözlemlenebilirliği (observability) zorlaştırır. Bir kullanıcının tek bir istek yoluyla birçok hizmeti tetiklemesi; latency, hatalar ve kaynak darboğazlarının kökenini bulmayı karmaşık hale getirir. İşte burada distributed tracing (dağıtık izleme) devreye girer: bir isteğin tüm yolunu, her hizmetteki işlem sürelerini, hataları ve bağımlılık ilişkilerini uçtan uca görünür kılar.

Neden bugün konuşuluyor?

• Mikroservis, serverless ve event‑driven mimarilerin yaygınlaşmasıyla servisler arası korelasyon zorunlu hale geldi.
• Performans optimizasyonu, SLO izleme ve hızlı RCA (root cause analysis) için traces kritik veri sağlar.
• OpenTelemetry gibi standartların olgunlaşması vendor‑agnostic tracing uygulamalarını mümkün kıldı.

Kimler için önemli?

• SRE ve platform ekipleri — MTTR azaltma ve servis sağlığını izleme için.
• Backend geliştiriciler — uygulama davranışını anlamak ve optimizasyon yapmak için.
• CTO ve teknoloji yöneticileri — operasyonel performans ve yatırım kararlarını veriyle desteklemek için.

Hangi problemleri çözüyor?

• Dağıtık çağrı zincirlerinde hangi adımın geciktiğini veya hataya neden olduğunu gösterir.
• High‑cardinality hatalar, transient network sorunları ve cascading failures gibi karmaşık olayların teşhisini hızlandırır.
• SLO/SLI korelasyonunda, kullanıcı deneyimini en çok etkileyen parçaların tespitini sağlar.

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

• Trace: Bir isteğin sistem boyunca izlenen uçtan uca kaydı; genelde bir veya daha fazla span içerir.
• Span: Trace içindeki tek bir işlem birimi; başlangıç ve bitiş zaman damgası, meta veriler (attributes), olaylar (events) ve ilişkiler (parent/child) içerir.
• Context propagation: Trace context bilgisinin servisler arası taşınması; trace id ve span id'nin HTTP header veya message metadata olarak iletilmesi.
• Sampling: Yüksek trafikli sistemlerde tüm trace'leri saklamak pratik olmadığında hangi trace'lerin alınacağını belirleyen strateji.

2.2 Tracing ekosistemi ve terminoloji

• Instrumentation: Uygulamada manuel veya otomatik olarak span/trace oluşturma süreçleri.
• Trace backend: Traces'in saklandığı ve sorgulandığı sistem (Jaeger, Tempo, Zipkin, Datadog APM vb.).
• OpenTelemetry (OTel): Traces, metrics ve logs için vendor‑agnostic bir standard ve SDK/collector ekosistemi.

2.3 Neden traces, yalnızca metrics/logs'tan farklı?

Metrics genel sistem sağlığını gösterir (numeric aggregates), logs olayların detaylı kayıtlarını tutar, traces ise istek yolunu ve zamanlamasını kullanıcı odaklı olarak gösterir. Bir hatanın "nerede" ve "neden" olduğunu bulmak için traces gerekli bağlamı sağlar; tek başına metrics ve logs bunu eksik bırakabilir.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ, BİLEŞENLER VE VERİ AKIŞI

3.1 Yüksek seviyeli mimari

Dağıtık tracing mimarisi genelde şu bileşenleri içerir: instrumentation (SDK), collectors/agents (OTel Collector), ingestion/transport (OTLP/HTTP/gRPC), trace backend (Jaeger/Tempo/Zipkin/Commercial APM) ve sorgu/visualization aracı (Grafana, vendor UI). Context propagation HTTP header (W3C Trace Context), messaging metadata veya custom header'lar aracılığıyla gerçekleştirilir.

3.2 Context propagation — W3C Trace Context

W3C Trace Context standardı, trace id, parent id ve trace flags gibi bilgileri taşıyan tek ve yaygın kabul görmüş bir formattır. Örnek header: "traceparent: 00‑4bf92f3577b34da6a3ce929d0e0e4736‑00f067aa0ba902b7‑01". Doğru propagation, tüm servislerin aynı trace altında ilişkilendirilmesini sağlar.

3.3 Instrumentation stratejileri

• Automatic instrumentation: Framework ve library seviyesinde (HTTP client/server, DB driver, message broker) otomatik span oluşturma. Hızlı kurulum ve geniş coverage sağlar fakat bağlam ayrıntıları sınırlı olabilir.
• Manual instrumentation: Kritik path'lerde developer tarafından anlamlı spans, attributes ve events eklenmesi. En doğru bağlamı sağlar ancak emek gerektirir.
• Semantic conventions: OpenTelemetry'nin önerdiği attribute isimlendirme standartlarına uymak (http.method, db.system vb.) korrelasyonu kolaylaştırır.

3.4 Sampling stratejileri

Tüm trace'leri yakalamak maliyetli olabilir. Yaygın sampling stratejileri:

• Head‑based sampling: Trace başında karar verilir; ör. 1% random sampling. Basit ama hatalı veya yavaş trace'leri kaçırabilir.
• Tail‑based sampling: Trace tamamlandıktan sonra içeriğe göre karar verilir (hata içerenler, yüksek latency olanlar tutulur). Daha doğru ancak ileriye dönük işleme ve daha yüksek gecikme gerektirir.
• Adaptive sampling: Sistem yüküne göre dinamik sampling oranı ayarlama.

3.5 Trace enrichment ve correlation

Collector aşamasında trace'lere deploy metadata (commit id, release tag), service owner, SLO tag'leri gibi ek bilgiler bağlanır. Ayrıca logs ile korelasyon için trace id'lerin log'lara eklenmesi (log injection) önemlidir. Bu sayede bir trace tetiklendiğinde ilgili logları otomatik bulmak mümkün olur.

3.6 Storage ve sorgu maliyetleri

Trace verisi yüksek hacimli olabilir; storage seçimi retention, sorgu hızı ve maliyete göre yapılmalıdır. Jaeger/Tempo modeli object storage (S3) + indexer ile düşük maliyetli uzun dönem saklama sağlar; commercial APM'ler sorgu optimizasyonu sunar ancak maliyet yüksek olabilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix ve hayati tracing teknikleri

Netflix, yüksek hacimli dağıtık sistemlerde tracing ile hot‑path analizi, latency attribution ve chaos engineering çıktılarının etkisini ölçmek için tracing'i yoğun şekilde kullanır. Canary deploy'larında trace korelasyonu ile regresyonlar hızlı tespit edilir.

4.2 Uber ve yüksek cardinality yönetimi

Uber gibi firmalar, trace içindeki etiketlerin (tags) yüksek cardinality olmasını yönetmek için özel ingestion ve index stratejileri geliştirmiştir. Örneğin bazı attribute'ların yalnızca sampling sonrası saklanması tercih edilir.

4.3 E‑ticaret ve iş mutabakatı

Ödeme işlemleri gibi kritik kullanıcı yolculuklarında trace'ler, hangi servisin geciktiğini, hangi dış API'nın başarısız olduğunu ve müşteri etkileşimini nasıl etkilediğini gösterir. Bu bilgilerle prioritization ve incident response hızlanır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Uçtan uca görünürlük: İsteklerin hangi adımda geciktiğini veya hangi bağımlılığın hataya sebep olduğunu gösterir.
• Hızlı RCA: Traces ile root cause analysis süresi önemli ölçüde azalır.
• SLO korelasyonu: Kullanıcıyı etkileyen problemleri doğrudan belirleyip önceliklendirme sağlar.

Sınırlamalar

• Maliyet: Yüksek traffic ortamlarında trace saklama ve sorgu maliyetleri hızla artabilir.
• Karmaşıklık: Doğru instrumentation, sampling ve storage stratejileri tasarlamak uzmanlık gerektirir.
• Veri gizliliği: Trace meta verilerinde PII veya hassas bilgi varsa uygun redaction uygulanmalı.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• OpenTelemetry standardını kullanarak vendor‑agnostic instrumentasyon sağlayın.
• Semantic conventions'a uyun; ortak attribute isimleri ile ekipler arası korelasyon kolaylaşır.
• Trace id'leri loglara inject edin; log‑trace korelasyonu otomatik olmalı.

Performans ve maliyet optimizasyonu

• Tail‑based sampling kritik trace'leri yakalamak için güçlü bir yaklaşımdır; maliyet/fayda analizi yapın.
• Hot/cold storage stratejisi uygulayın: recent traces hızlı sorgulanabilir bir backend'de, eski veriler object storage'da tutulur.
• Attribute cardinality kontrolü uygulayın; dinamik veya user‑level taging'i sınırlayın.

Güvenlik

• Trace metadata'sında PII veya secret bilgileri barındırmayın; collector seviyesinde redaction uygulayın.
• Trace veritabanlarına erişimi RBAC ile sınırlandırın ve audit logları tutun.

Ölçeklenebilirlik

• Collector ve indexer'ları autoscaling ile çalıştırın; ingestion throttling mekanizmalarını uygulayın.
• Distributed tracing backends için HA ve replication stratejileri planlayın.

8. SIK YAPILAN HATALAR

• Trace id'leri loglara eklememek — korelasyonu zorlaştırır.
• Yalnızca automatic instrumentation'a bel bağlamak — iş mantığı bağlamı kaçabilir.
• High cardinality attribute'ları kontrolsüz bırakmak — storage maliyeti ve sorgu performansını bozar.
• Tüm trace'leri kaydetmeye çalışmak — maliyetleri patlatır; akıllı sampling şarttır.

9. GELECEK TRENDLER

1. AI‑assisted tracing: Anomali tespiti ve RCA önerileri için ML modelleri traces içinde otomatik korelasyon yapacak.
2. Edge tracing: IoT ve edge senaryolarında merkezileştirilmiş tracing yerine hibrit, kısmi offline korelasyon çözümleri gerekecek.
3. Integrated observability: Metrics, logs ve traces tek bir veri modelinde birleşip semantik sorgu dilleriyle erişilebilir olacak.
4. Privacy‑aware tracing: PII'yi koruyan ve GDPR uyumlu tracing pratikleri standartlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Distributed tracing'e nereden başlamalıyım?

   OpenTelemetry SDK ile uygulamanızı instrument ederek başlayın; basit HTTP ve DB spans'larını yakalayın, collector'ı kurun ve küçük bir backend (Jaeger) ile uçtan uca akışı test edin.

2. 2. Head‑based mi yoksa tail‑based sampling mi tercih etmeliyim?

   Başlangıç için head‑based sampling basit ve düşük gecikmelidir; ancak hata/latency odaklı doğru veri istiyorsanız tail‑based sampling daha uygun olacaktır.

3. 3. Trace verilerinde hangi metadata'ları tutmalıyım?

   Semantic conventions'a uyun: http.method, http.status_code, db.system, rpc.method gibi temel alanların yanı sıra deploy metadata ve service owner bilgisi faydalıdır. Ancak user‑level PII'yi trace'e koymaktan kaçının.

4. 4. OpenTelemetry Collector gerekli mi?

   Collector, vendor‑agnostic pipeline kurmak, enrichment ve sampling merkezi yapmak ve exporter'ları soyutlamak için çok yararlıdır. Küçük ölçeklerde direkt SDK → backend mümkün olsa da collector ölçeklendikçe avantaj sağlar.

5. 5. Traces ile logs nasıl korele edilir?

   Trace id ve span id'leri log mesajlarına eklenmelidir. Bunun için uygulama log framework'ünüzde trace context injection sağlayan entegrasyonları kullanın.

6. 6. Trace storage maliyetlerini nasıl düşürebilirim?

   Sampling, attribute pruning, hot/cold tiering ve retention policy'leri ile maliyetleri optimize edin. Ayrıca only error/high‑latency traces için full‑fidelity saklama stratejileri uygulayın.

7. 7. Tracing APM'leri ile open source karşılaştırması?

   Managed APM'ler hızlı özellik, analytics ve destek sunar ancak maliyetlidir. Open source kombinasyonları (OTel + Jaeger/Tempo) daha uygun maliyetli ve esnektir ama operasyonel yük getirir.

8. 8. Tracing'i GDPR/PII ile nasıl uyumlu hale getiririm?

   Trace attribute'larında PII saklamayın; collector seviyesinde redaction, hashing veya tokenization uygulayın. Ayrıca retention ve access control politikalarını sıkı tutun.

Anahtar Kavramlar

Trace

Bir isteğin sistem boyunca takip edilen uçtan uca kaydı.

Span

Trace içindeki tek bir işlem birimi; başlangıç/bitış zamanları ve metadata içerir.

Context propagation

Trace id ve parent span id gibi bilgilerin servisler arasında taşınması.

Sampling

Hangi trace'lerin capture edilip saklanacağını belirleyen strateji.

OpenTelemetry

Traces, metrics ve logs için vendor‑agnostic standard ve SDK/collector ekosistemi.

Öğrenme Yol Haritası

1. 0–1 ay: Tracing temel kavramlarını, span/trace ilişkisini ve W3C Trace Context standardını öğrenin; küçük bir uygulamada OpenTelemetry ile basit spans oluşturun.
2. 1–3 ay: Collector kurulumu, Jaeger veya Tempo entegrasyonu, trace injection in logs ve semantic conventions pratiği yapın.
3. 3–6 ay: Sampling stratejileri (tail‑based), trace enrichment, SLO korelasyonu ve hot/cold storage stratejileri üzerinde çalışın.
4. 6–12 ay: Large scale tracing (high cardinality), adaptive sampling, AI‑assisted RCA ve security/privacy‑aware tracing projelerinde deneyim kazanın.