Distributed Tracing: OpenTelemetry, Jaeger ve Tempo Pratiği 2026

OpenTelemetry nedir? OpenTelemetry (OTel), uygulamalardan trace, metrik ve log telemetrisini toplamak, işlemek ve gözlemlenebilirlik backend’lerine iletmek için CNCF tarafından yönetilen açık kaynaklı bir gözlemlenebilirlik framework’üdür. Mikroservis mimarilerinde bir HTTP isteği ortalama 14-22 servisten geçer; klasik log tabanlı debugging bu zincirde p99 latency’nin nereden geldiğini söyleyemez. Distributed tracing, her isteğe trace_id atayıp her servis sınırında span üreterek bu zinciri görselleştirir. 2026 itibarıyla OpenTelemetry, Kubernetes’ten sonra CNCF’in en aktif ikinci projesi konumunda; aylık 5.2 milyar npm + PyPI indirme hacmiyle Datadog APM, New Relic ve Splunk gibi proprietary agent’ları yerinden ediyor. Bu yazı OpenTelemetry SDK seçimi, Collector pipeline’ı, Jaeger vs Grafana Tempo karşılaştırması, sampling stratejisi ve production cardinality ekonomisi üzerine 2026 pratiğini özetler.

OpenTelemetry mimarisinin üç katmanı

OTel’i anlamak için onu üç bağımsız katman olarak düşünmek gerekir: API, SDK ve Collector. API katmanı dilden bağımsız sözleşmedir — tracer.start_span() çağrısı Python’da da Go’da da aynı semantikle çalışır. SDK katmanı bu API’nin somut implementasyonudur; sampling, batching, exporter konfigürasyonunu içerir. Collector katmanı ise telemetri verisini alan, dönüştüren ve hedef backend’e ileten dil-bağımsız bir vendor-neutral agent’tır. Bu üçlü ayrım, vendor lock-in’i kırmanın temel mekanizmasıdır: backend’i Datadog’dan Grafana Tempo’ya geçirdiğinizde sadece Collector exporter’ı değişir, uygulama kodu dokunulmaz kalır.

OpenTelemetry spec’i 2023’te trace için GA, 2024’te metrik için GA, 2025’in son çeyreğinde log signal’ı için GA statüsüne ulaştı. Bu üç signal’ın aynı SDK üzerinden üretilmesi — özellikle log-trace korelasyonu için trace_id’nin log satırına otomatik enjekte edilmesi — OTel’in proprietary agent’lara karşı en güçlü değer önerisidir. CNCF Annual Survey 2024 verilerine göre Fortune 500 şirketlerinin %71’i en az bir production servisinde OTel kullanıyor.

Katman	Sorumluluk	Vendor-neutral mi?	Değişiklik maliyeti
API	Instrumentation sözleşmesi (start_span, set_attribute)	Evet (CNCF spec)	Çok yüksek — uygulama kodu
SDK	Sampling, batching, exporter konfigürasyonu	Evet (referans implementasyon)	Orta — config dosyası
Collector	Receiver → Processor → Exporter pipeline	Evet (Go binary, vendor-bağımsız)	Düşük — YAML değişikliği
Backend	Storage, query, UI (Jaeger/Tempo/Datadog)	Backend’e göre değişir	Düşük — exporter swap

Bu mimaride dikkat edilmesi gereken kritik nokta: Agent vs Gateway Collector ayrımı. Agent modu DaemonSet olarak her node’da çalışır, uygulamalardan localhost üzerinden veri alır. Gateway modu cluster düzeyinde Deployment’tır; tail-based sampling, attribute redaction gibi ağır işlemleri burada yaparsınız. Production’da iki katmanlı yapı standarttır; tek katmanlı kurulum 5000 RPS üzerinde memory pressure üretir.

SDK seçimi: dil bazında olgunluk haritası

OTel SDK’ları dil bazında farklı olgunluk seviyelerinde. Production deployment kararı verirken sadece “OTel destekliyor mu” değil, “auto-instrumentation, baggage propagation, tail sampling” gibi gelişmiş özelliklerin stabil olup olmadığı bakılmalı. 2026 başı itibarıyla durum:

• Java: En olgun SDK. Java agent (otel-javaagent.jar) JVM’e bytecode injection yaparak sıfır kod değişikliğiyle Spring Boot, JDBC, Kafka, gRPC instrumentation sağlar. Avantaj: Greenfield ve legacy projelerde plug-and-play. Dezavantaj: Startup latency’ye 800-1400ms ekler. Ne zaman seç: Spring Boot 3.x stack varsa varsayılan seçim.
• Go: SDK GA, ancak auto-instrumentation eBPF tabanlı ve hâlâ beta. Avantaj: Allocation-free hot path, düşük overhead. Dezavantaj: Manuel instrumentation gerekir (otelhttp, otelgrpc paketleri). Ne zaman seç: CPU-bound microservice, ekip Go-native.
• Python: SDK GA, opentelemetry-instrument CLI ile Django/FastAPI/Flask auto-instrumentation çalışır. Dezavantaj: GIL nedeniyle BatchSpanProcessor thread’i p99’da 5-12ms kontrol verir.
• Node.js: @opentelemetry/auto-instrumentations-node paketi Express, Fastify, MongoDB, Redis için hazır. Avantaj: Hızlı integration. Dezavantaj: async_hooks performans cezası (yaklaşık %3-7).
• .NET: System.Diagnostics.Activity ile native entegre, OpenTelemetry.Instrumentation.AspNetCore stabil. .NET 8+ için en düşük overhead’li dillerden biri.
• Rust: opentelemetry-rust SDK 0.27 (Mart 2026 itibarıyla pre-1.0). Production’da kullanılabilir, ancak API breaking change’leri yaşanabilir.

SDK seçiminde gözden kaçan detay context propagation standardı. W3C Trace Context (traceparent header) artık tüm SDK’larda varsayılan, ancak legacy sistemlerde B3 (Zipkin) veya Jaeger native format kullanılıyor. Hybrid ortamlarda Collector pipeline’ında her iki propagator’u da enable etmek gerekir; aksi takdirde mesh sınırlarında trace zinciri kırılır.

OpenTelemetry Collector: pipeline mimarisi

Collector, OTel ekosisteminin kalbidir. Receiver-Processor-Exporter (RPE) pattern’i ile çalışır: receiver telemetri verisini alır (OTLP, Jaeger, Zipkin, Prometheus, Fluentd protokollerinde), processor üzerinde transformasyon uygular (filtreleme, batching, sampling, attribute manipulation), exporter ise hedef backend’e gönderir. Bu modüler yapı, Collector’u “Telemetri için Logstash” konumuna oturtur — ancak Logstash’in aksine Go ile yazılmış ve memory footprint’i çok daha düşüktür (idle 80MB, 10k spans/sec yükte 350MB).

Production Collector deployment’ında üç pipeline ayrımı kritiktir: traces, metrics, logs. Her birinin kendi receiver-processor-exporter zinciri olur. Aşağıdaki örnek YAML, tail-based sampling ile error-biased trace retention uygulayan bir Gateway Collector’ün omurgasıdır:

Processor	Görev	Memory etkisi	Production önerisi
batch	Span’leri 512-1024 batch’lerde gruplar	Düşük	Her pipeline’da zorunlu
memory_limiter	OOM koruması, %75-80 eşik	—	İlk processor olmalı
tail_sampling	Trace tamamlandıktan sonra örnekleme	Yüksek (10-15min window)	Gateway’de, Agent’ta DEĞİL
attributes	PII redaction, attribute rename	Düşük	Compliance gerekli
resource	service.name, deployment.env enjekte	Düşük	Multi-tenant’ta zorunlu
transform	OTTL ile dinamik mutasyon	Orta	Karmaşık filtreleme için

Collector’da OTTL (OpenTelemetry Transformation Language) 2025’te stable oldu ve attribute manipulation için tercih edilen dil. SQL benzeri syntax ile “where attribute[‘http.status_code’] >= 500 then set attribute[‘priority’] = ‘critical'” gibi koşullu transformasyonlar yazılabilir. Bu eski “attributes processor” patch yöntemine göre çok daha test edilebilir bir pipeline üretir. Cloud-native mimari best practices bağlamında Collector’ün Kubernetes Operator ile yönetilmesi önerilir.

Jaeger vs Grafana Tempo vs Zipkin: backend kararı

OTel ile topladığınız trace verisini saklayacağınız backend seçimi, toplam observability maliyetinin %60-70’ini belirler. Üç açık kaynak alternatif öne çıkıyor: Jaeger (CNCF graduated), Grafana Tempo (Grafana Labs), Zipkin (en eski, Twitter kökenli). Hepsinin OTLP receiver desteği var; fark mimaride ve storage modelinde.

Özellik	Jaeger 1.62	Grafana Tempo 2.7	Zipkin 3.x
Storage backend	Cassandra, Elasticsearch, Badger, ClickHouse	S3, GCS, Azure Blob (object storage)	Cassandra, Elasticsearch, MySQL
Index modeli	Full-text index (her span)	TraceID-only index	Full-text index
Storage maliyeti (TB/ay)	~180-240 USD (ES)	~22-35 USD (S3)	~180-260 USD
Sorgu esnekliği	Service, operation, tag, duration	TraceID + TraceQL	Service, span name, tag
Query latency (p95)	200-800ms	1.5-4s	300-1200ms
Kubernetes operator	Jaeger Operator (resmi)	Helm chart	Helm chart
Grafana entegrasyonu	Datasource plugin	Native, en sıkı	Datasource plugin
CNCF statüsü	Graduated (2019)	Sandbox değil — Grafana Labs	Bağımsız OSS

Karar çerçevesi: Eğer aylık trace hacminiz 50TB+ ise ve genelde “şu traceId’yi göster” tarzı targeted query yapıyorsanız Tempo en ekonomik seçim. Sorgularınız “son 1 saatte duration>3s olan tüm /checkout span’leri” gibi attribute-based ise Jaeger Elasticsearch backend’i daha güçlü. Zipkin yeni proje için artık tercih edilmiyor; sadece mevcut entegrasyonlar için bakım modunda. Banka ve fintech tarafında PCI-DSS denetim gereksinimi olan kurumlar Cassandra üzerinde Jaeger’i tercih ediyor, çünkü row-level retention policy daha granular.

Grafana Tempo’nun S3 mimarisi Tempo dokümantasyonunda ayrıntılı anlatılıyor. Object storage’ın TB başına maliyeti SSD’ye göre 8-12x daha düşük olduğu için Tempo, “tüm trace’leri 30 gün sakla” gibi compliance gereksinimlerinde bütçe dostu. Trade-off: TraceID dışında index olmadığı için attribute-based sorgular Tempo’da 3-4 saniyeye çıkar.

Sampling stratejisi: cardinality ekonomisi

Distributed tracing’in en pahalı yanı tüm trace’leri saklamaktır. Üretim ortamında saniyede 50.000 span üreten bir sistem, 24 saatte yaklaşık 4.3 milyar span yapar; bunların hepsini saklamak hem maliyet hem de query performans açısından tutarsız. Sampling, hangi trace’lerin saklanacağına karar verme stratejisidir. İki ana yaklaşım var:

1. Head-based sampling: Trace başlangıcında (root span’de) karar verilir. probabilistic (örn. %1) veya rate-limiting (saniyede 100 trace). Avantaj: Düşük overhead, basit. Dezavantaj: Error trace’leri kaçırılabilir (%1 sampling = %99 error de atılır).
2. Tail-based sampling: Trace tamamlandıktan sonra karar verilir. Collector trace’i 10-30 saniye buffer’da tutar, sonra “bu trace error mu, slow mu, important customer mu” kuralları işler. Avantaj: Anlamlı trace retention. Dezavantaj: Gateway Collector’da yüksek memory (20-40GB+).
3. Hibrit yaklaşım: Agent’ta probabilistic %10 head sampling, Gateway’de tail-based ile bu %10 içinden error/slow olanların %100’ünü, normal olanların %5’ini sakla. Production’da en yaygın pattern.

Cardinality kontrolü, sampling kadar kritik. Bir span’e “user_id” eklerseniz milyon kullanıcılı sistemde milyon farklı cardinality üretirsiniz; bu Tempo/Jaeger index’lerini patlatır ve query latency’yi 10x bozar. Kural: Yüksek cardinality field’lar (user_id, request_id dışı her şey) attribute olarak değil, span event olarak yazılmalı. Kubernetes cost optimization tarafında VPA ile Collector pod’larının right-sizing’i bu yükü dengeler.

Sampling stratejisi	Storage etkisi	Anlam kaybı riski	Önerilen ölçek
%100 retention	4.3B span/gün ~ 8-12 TB	Sıfır	Geliştirme ortamı, debug
Probabilistic %10	430M span/gün ~ 800GB-1.2TB	%90 error kaybı	Düşük trafikli backend
Probabilistic %1	43M span/gün ~ 80-120GB	%99 error kaybı	YALNIZ dev/staging
Tail-based (error %100 + slow %100 + normal %5)	~200-300M span/gün	Çok düşük	Production, 5k+ RPS
Adaptive sampling (Jaeger built-in)	Otomatik adjust	Düşük	Multi-service, dynamic load

Service mesh ile entegrasyon: Istio ve Linkerd

Service mesh kullanan ortamlarda OTel deployment iki yoldan biriyle yapılır: ya mesh sidecar’ı (Envoy) doğrudan OTLP yayar, ya da uygulama SDK’sı kendi span’lerini üretir. Modern best practice bu ikisinin birleşimidir: mesh L4/L7 span’leri üretir, uygulama iş mantığı span’lerini ekler. Service mesh karşılaştırması tarafından bakıldığında Istio 1.24+ native OTLP exporter’a sahip; Linkerd 2.16+ otomatik propagation yapar.

Mesh ve SDK birlikte çalıştığında parent span ID propagation kritik. Envoy proxy’si gelen istekteki traceparent header’ını uygulamaya geçirmezse, uygulama yeni bir root span başlatır ve iki ayrı trace oluşur. Istio’da bu, “extensionProviders” üzerinden OpenTelemetry tracer ayarlanarak çözülür.

Mesh tarafında dikkat edilmesi gereken bir performans noktası: her Envoy proxy span üretir ve bu, sidecar başına CPU yükünü %4-7 artırır. 1000+ pod’lu cluster’larda toplam ek CPU 40-70 core’a ulaşabilir. Istio distributed tracing dokümantasyonunda belirtildiği üzere mesh-level sampling rate’ini %10-20 ile sınırlayıp uygulama SDK’sını %100 yapmak, ekonomik bir hibrit yaklaşım.

eBPF tabanlı zero-code instrumentation: Pixie, Beyla, Parca

2025-2026’nın en heyecan verici gelişmesi, eBPF (extended Berkeley Packet Filter) ile kernel-level zero-code instrumentation. Geleneksel SDK yaklaşımı uygulama kodunu (veya en azından startup’ı) değiştirmek zorundadır. eBPF, Linux kernel’ine güvenli bytecode yükleyerek HTTP/gRPC/SQL trafiğini kernel-side yakalar ve OTLP’ye dönüştürür. Üç önemli proje:

• Grafana Beyla: Go ile yazılmış, 2024’te Grafana Labs tarafından açık kaynak yapıldı. Single binary, OTLP exporter. Avantaj: Sıfır kod değişikliği, Java/Python/Go/Rust/.NET destekler. Dezavantaj: Sadece otomatik tespit edilen protokoller (HTTP/gRPC); custom protocol için kör. Beyla GitHub repository.
• Pixie (CNCF Sandbox): New Relic’in açık kaynak yaptığı eBPF observability platformu. Kendi sorgu dili PxL, ancak OTLP exporter ile Tempo/Jaeger’a da yayın yapar.
• Parca: Polar Signals’ın continuous profiling aracı; trace değil ama distributed tracing ile birlikte kullanılarak “trace’in hangi line’da yavaşladı” sorusunu yanıtlar.

eBPF yaklaşımının trade-off’u: TLS-encrypted trafiği görmek için uprobe yerleştirmek gerekir; bu kernel 5.14+ ve belirli libssl sürümleri gerektirir. Production öncesi kernel sürümü ve security context doğrulanmalı.

OTel ile gerçek bir incident debugging akışı

Distributed tracing’in değeri ancak gerçek bir incident’ta görülür. Bir e-ticaret platformunda “checkout sayfası p99 latency 14 saniyeye çıktı” alarmı düştü diyelim. Klasik log-based debugging’de her servisin log’unu açıp request_id ile grep yapmak 30-45 dakika sürerdi. OTel + Jaeger ile akış şu şekilde işler:

1. Grafana dashboard: p99 latency artışı görülür, ilgili zaman aralığı seçilir.
2. Trace search: service.name=checkout AND duration>10s filtresi ile son 1 saatte 47 trace listelenir.
3. Critical path analysis: Bir trace açılır, Gantt-chart görünümünde 14 saniyenin 11.2’sinin “payment-service → fraud-detection” span’inde geçtiği görülür.
4. Span detail: fraud-detection span’inin “db.statement” attribute’unda “SELECT … FROM transactions WHERE user_id=? AND created_at > ?” sorgusu, “db.duration” 11200ms.
5. Root cause: Index’siz tablo scan’i; created_at üzerine composite index eklenir, p99 1.8 saniyeye iner.

Bu akış 6-8 dakikada tamamlanır. Tracing’in geri ödemesi (ROI), bu tip incident’ların MTTR’ını (Mean Time To Resolution) ortalama %40-60 düşürmesidir. Stack Overflow Developer Survey 2024 verilerinde yanıt verenlerin %58’i “tracing olmadan microservice debug etmek imkansız” demiş — bu rakam 2022’de %31’di. CI/CD pipeline kurulumu kapsamında tracing’in deployment akışına entegre edilmesi, canary release’lerde regresyon tespiti için kritik.

Production maliyet modeli ve vendor karşılaştırması

Tracing maliyetini hesaplarken üç eksen var: data ingestion (GB/ay), data retention (gün), query frequency (sorgu/ay). Vendor backend’ler bu eksenlerin her birini ayrı ayrı ücretlendirir. Self-hosted (Tempo + S3) ile SaaS (Datadog APM, Honeycomb, New Relic) arasındaki maliyet farkı 5-15x kadar dramatik olabiliyor.

Çözüm	Ingest (50GB/gün, 30g retention)	Query (10k/ay)	Toplam (aylık USD)
Self-hosted Tempo + S3	~85 USD (S3 + transfer)	~0 USD (cluster compute dahil)	~180-250 USD (compute + storage)
Self-hosted Jaeger + Elasticsearch	~340 USD (ES storage)	~0 USD	~480-650 USD
Grafana Cloud (Tempo backend)	~430 USD	Quota dahil	~430-580 USD
Datadog APM	~1850 USD (ingested span)	Quota dahil	~2100-2700 USD
Honeycomb (events-based)	~1100 USD	Quota dahil	~1200-1600 USD
New Relic	~1450 USD (user + data)	Quota dahil	~1600-2200 USD

Bu rakamlar 2026 başı kamuoyuna açık fiyatlandırmadan türetilmiş yaklaşık değerlerdir; volume discount, enterprise agreement ile %30-50 düşebilir. Ekibinizin 5+ DevOps engineer kapasitesi varsa self-hosted Tempo en ekonomik; yoksa Grafana Cloud Tempo backend dengeli bir seçim sunar. Datadog ve New Relic’in primum’u sadece ücret değil — agent’larının vendor-specific olması nedeniyle Ömer Önal danışmanlık projelerinde gözlemlenen vendor migration süresi 3-6 ay.

2026’da gelen yenilikler: profil signal, gRPC trace context, OTel-Arrow

OpenTelemetry spec’i 2026’ya hızlı girdi. Üç önemli yenilik üretim hattında:

• Profile signal (beta): Continuous profiling verisini (pprof formatında) trace ile correlate eden 4. signal. Parca, Pyroscope, Grafana Phlare ile native OTLP entegrasyonu sağlanıyor. Anlam: “Bu span’de yavaş çalışan exact function call hangisi” sorusu yanıtlanabilir hale geliyor.
• OTLP-Arrow (alpha → beta): Apache Arrow columnar format’ı OTLP üzerinde kullanan yeni bir wire protocol. OTel-Arrow benchmark sonuçlarında klasik OTLP/gRPC’ye göre %60-70 bandwidth tasarrufu, %30-40 CPU tasarrufu. Yüksek trafikli ortamlar için game-changer.
• Service Graph Connector: Collector’da yeni connector tipi; trace verisinden otomatik service topology metrik çıkarıyor (Datadog’un “Service Map” feature’ının açık kaynak karşılığı).
• OTel Weaver (preview): Schema-driven instrumentation tooling. Semantic convention’ları YAML’de tanımla, kod jeneratörü tüm dillerde tip-güvenli SDK üretsin.
• RUM (Real User Monitoring) signal: Browser-side OTel SDK 2025’te stable oldu; client-side trace’leri server-side ile aynı trace_id ile birleştirebilirsiniz.

Profile signal ve OTLP-Arrow, 2026 ortasından itibaren production-grade olacak. Yeni Collector deployment’larında Arrow exporter’ı feature flag arkasında etkinleştirip bandwidth tasarrufu ölçümü yapmak mantıklı. GitOps ile Kubernetes deployment akışında Collector config değişikliklerini ArgoCD üzerinden yönetmek rollback güvenliğini sağlar.

Sık karşılaşılan tuzaklar ve anti-pattern’ler

Tracing implementasyonunda tekrar eden hatalar var; bu hatalar genelde “OTel kuruldu ama Jaeger UI’da hiç trace yok” veya “Tempo storage cost’u beklenenin 10x’i” şikayetiyle gelir. OpenTelemetry spec dokümantasyonu bu hataların büyük kısmını “common pitfalls” altında belgeliyor.

• Tuzak 1 — Synchronous exporter: SimpleSpanProcessor production’da kullanılmamalı; her span’i bloklayarak gönderir, request latency’ye 5-30ms ekler. BatchSpanProcessor zorunlu.
• Tuzak 2 — Yüksek cardinality attribute: Span’e UUID, timestamp, full URL eklemek index’leri patlatır. Sadece bounded enum değerleri (status_code, region, environment) attribute olmalı.
• Tuzak 3 — Trace context lost on async boundary: async/await, message queue, scheduled job sınırlarında context.activate() manuel yapılmalı. Yoksa “orphan span” üretilir, parent ID null kalır.
• Tuzak 4 — PII leakage: request body, query parameter, header’da email/credit-card/SSN olabilir. Collector’da “attributes processor” ile redaction ZORUNLU; GDPR ve KVKK ihlali ciddi cezalar getirir.
• Tuzak 5 — Collector single point of failure: Tek replica Collector OOM olduğunda tüm trace pipeline durur. Minimum 3 replica, HPA ile autoscale, persistent queue (file_storage extension) zorunlu.
• Tuzak 6 — Service.name inconsistency: Aynı servisin farklı pod’larında “checkout-api”, “checkout_api”, “Checkout-API” gibi varyasyonlar Jaeger’da 3 ayrı service olarak görünür. Helm chart’tan env var ile zorlayın.

Sık Sorulan Sorular

Sonuç

OpenTelemetry, 2026 itibarıyla observability’nin de facto standardı haline geldi. CNCF projelerinin %71’i OTLP receiver desteğine sahip, Fortune 500’ün %71’i en az bir production servisinde OTel kullanıyor ve proprietary agent’ların pazar payı son iki yılda %38’den %21’e geriledi. Bu trend tersine dönmeyecek — vendor lock-in maliyeti her yıl artıyor ve OTel’in tek-stack ile dört signal sunması rasyonel tercihi açık tutuyor.

Pratik karar çerçevesi şu üç soruyla başlamalı: (1) Trace hacmim aylık kaç GB? (2) Ekibim self-hosted observability stack işletecek kapasiteye sahip mi? (3) Compliance gereksinimi (PCI-DSS, KVKK, HIPAA) trace retention süresini nasıl etkiliyor? Bu üç sorunun cevabına göre Jaeger+ES, Tempo+S3, Grafana Cloud veya Datadog APM arasında seçim yapılır. Hangi backend seçilirse seçilsin, uygulama tarafında OTel SDK + OTel Collector pattern’i değişmez; bu pattern, gelecek 3-5 yılda backend değiştirmenin maliyetini sıfıra yakın tutmanın tek garantisi.

Distributed tracing implementasyonu için yol haritası danışmanlığı veya mevcut observability stack’inizin maliyet/performans analizi için iletişim sayfası üzerinden ulaşabilirsiniz; somut bir incident history veya cardinality raporu varsa süreç çok daha hızlı ilerler.