Tempo 2.6 Mimarisi ve Production Topolojisi

Grafana Tempo 2.6, 2026 yılında distributed tracing alanında en hızlı büyüyen open-source projeye dönüştü. CNCF 2025 raporuna göre Kubernetes üzerindeki kurumların %38’i Tempo’yu production’da kullanıyor; bu rakam 2023’teki %14 seviyesinden %171 büyüme demek. Bu yükselişin tek bir nedeni var: Tempo’nun object storage’a doğrudan trace yazan tasarımı, Jaeger’in Elasticsearch backend’ine göre depolama maliyetlerini %91 oranında düşürüyor. Datadog APM’in yıllık 2.4 milyon dolarlık faturasını 140 bin dolara indiren saha vakaları artık istisna değil, kural.

Bu yazıda Tempo 2.6’nın production implementation pattern’lerini, TraceQL sorgu dili optimizasyonlarını, metrics-generator özelliğini ve OpenTelemetry entegrasyonunu ele alacağız. Hedef, günde 10 milyon ile 5 milyar span üreten platformların SRE ekipleri. Türkiye’deki finans ve e-ticaret sektöründen 7 vaka analizini de paylaşacağız.

Tempo 2.6 Mimarisi ve Production Topolojisi

Tempo 2.6, microservices deployment’ta 6 bileşenden oluşur: Distributor, Ingester, Querier, Query Frontend, Compactor ve Metrics Generator. Loki’nin tersine, Tempo’nun “block-based” yapısı her 5 dakikada bir trace bloklarını object storage’a flush eder. Bu sayede ingester memory footprint’i sabit kalır; 6 vCPU + 24 GB RAM yapılandırması günde 8 milyar span’a kadar yetiyor.

2026 production topolojisi şu şekilde olgunlaştı: 3 Distributor pod (4 vCPU, 8 GB RAM), 6 Ingester pod (6 vCPU, 24 GB RAM, persistent volume 100 GB), 4 Querier pod (8 vCPU, 16 GB RAM), 2 Query Frontend pod (4 vCPU, 8 GB RAM), 1 Compactor pod (8 vCPU, 16 GB RAM) ve 2 Metrics Generator pod (4 vCPU, 12 GB RAM). Object storage olarak S3 %67, GCS %19, Azure Blob %9, MinIO %5 oranında tercih ediliyor.

Parquet Block Format ve vParquet4

Tempo 2.0’dan itibaren trace blokları Apache Parquet formatında saklanıyor. 2.6 sürümüyle gelen vParquet4 versiyonu, attribute’ların column-store olarak organize edilmesini sağlıyor ve TraceQL sorgu performansını 3.4 kat artırıyor. Eski v2 format ile karşılaştırıldığında aynı 100 milyar span üzerinde 2 saatlik sorgu, vParquet4 ile 18 dakikaya düşüyor.

storage:
  trace:
    backend: s3
    s3:
      bucket: tempo-traces-prod
      endpoint: s3.eu-west-1.amazonaws.com
      region: eu-west-1
    block:
      version: vParquet4
      row_group_size_bytes: 100_000_000
      bloom_filter_false_positive: 0.05
    pool:
      max_workers: 400
      queue_depth: 20000

Bu konfigürasyon, ortalama 3 KB span boyutu için optimal Parquet kompresyonu sağlıyor; ZSTD level 5 ile %78 boyut tasarrufu görüyor.

TraceQL ve Sorgu Dili Pattern’leri

TraceQL, Tempo’nun PromQL/LogQL ailesine kattığı tracing-native sorgu dili. 2026’da TraceQL’in production’da en sık kullanılan 5 pattern’i:

TraceQL’in en güçlü yanı, span-to-span ilişki kurabilen >> (descendant) ve << (ancestor) operatörleri. Bu sayede “Service A’dan başlayıp Service D’de 500ms üzeri süren tüm trace’ler” gibi sorgular tek satırda yazılır.

Metrics Generator ve RED Otomasyonu

Tempo 2.6’nın Metrics Generator bileşeni, gelen span’lardan otomatik Prometheus metriği üretir. span_metrics ve service_graphs olmak üzere iki ana metric set sağlar. Span metrics, her servisin RED (Rate, Errors, Duration) üçlüsünü ekstra instrumentation gerektirmeden çıkarır. Service graphs ise servisler arası bağımlılığı otomatik haritalandırır.

Production’da metrics-generator’a aktarılan span oranı %100 değil, %15 ile %25 arasında tutulur. Tüm span’ları işlemek metrics-generator’ın CPU kullanımını 12 katına çıkarır; sample tabanlı yaklaşım istatistiksel olarak yeterli doğruluk sağlar. 2025’te Trendyol’un yayınladığı engineering blog, %20 sampling ile RED metriklerinin %98.3 doğrulukla üretildiğini gösterdi.

OpenTelemetry Collector Entegrasyonu

Tempo 2.6’nın OTLP receiver’ı, OpenTelemetry Collector ile mükemmel uyum içinde çalışır. 2026 standart topolojide her Kubernetes node’unda bir OTel Collector DaemonSet’i çalışır, oradan da centralized Gateway Collector’a forward edilir, en sonda Tempo Distributor’a yazılır. Bu 3 katmanlı yapı, network failure senaryolarında trace kaybını %0.07’nin altında tutar. Konuyla ilişkili olarak OTel Collector Pipeline: Receiver, Processor, Exporter 2026 rehberimiz detaylı incelemeyi içerir.

exporters:
  otlp/tempo:
    endpoint: tempo-distributor.observability.svc:4317
    tls:
      insecure: false
      ca_file: /etc/ssl/certs/ca.crt
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 5000
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s

Bu konfigürasyon, Gateway Collector pod restart’larında dahi 30 saniyelik retry penceresi sayesinde span kaybını sıfıra yakın tutar.

Tail Sampling ve Maliyet Kontrolü

Production’da en kritik kararlardan biri sampling stratejisidir. Head sampling (Tempo Distributor seviyesinde) basittir ama bilgilendirici trace’leri kaybedebilir. Tail sampling (OTel Collector tail_sampling processor’ında) tüm trace’i analiz edip akıllı karar verir; hatalı veya yavaş trace’lerin %100’ünü, başarılı trace’lerin %3’ünü saklar.

2026’da en yaygın tail sampling policy seti şudur: errors (status=error → %100), latency (duration > 1s → %100), probabilistic (geri kalan → %3), rate_limiting (toplam > 5000/s → drop). Bu strateji ile günde 80 milyar span üreten bir platform, sadece 2.8 milyar span’ı saklar; storage maliyeti %96 düşer ama observability değeri %92 korunur.

Exemplars ve Metrics-Tracing Linki

Prometheus 2.43’ten itibaren stabil olan exemplar özelliği, Tempo ile birleştiğinde metric grafiğinden trace’e tek tıkla geçişi mümkün kılıyor. Grafana’da p99 latency grafiğindeki spike’ın hangi trace’lerden kaynaklandığı 2 saniyede görülüyor. 2026’da bu özellik artık SRE workflow’unun olmazsa olmazı; Grafana 11.5 sürümünde exemplar overlay’i varsayılan açık geliyor.

Exemplar üretimi için OTel Collector’da spanmetrics connector’ı kullanılır. Her histogram bucket’ına, o bucket’a düşen örnek trace ID’si iliştirilir. Üretim ortamında exemplar count limit 100/dakika tutulur; aksi takdirde Prometheus’un remote_write kuyruğu şişer.

Multi-Tenant ve Erişim Kontrolü

Tempo, Loki ile aynı X-Scope-OrgID mekanizmasını kullanır. 2026’da Türkiye’deki büyük platformlar ortalama 23 tenant barındırıyor. Tenant başına max_traces_per_user, max_bytes_per_trace ve max_search_duration limit’leri ayrı ayrı belirlenir.

• max_traces_per_user: Ingester memory’sinde tutulan aktif trace sayısı. Tipik 100.000.
• max_bytes_per_trace: Tek trace boyut limiti. Production’da 50 MB (5000 span ortalaması).
• max_search_duration: TraceQL sorgu zaman aralığı limiti. Tipik 24 saat.
• ingestion_rate_limit_bytes: Tenant başına saniyede byte cinsinden ingestion. Tipik 50 MB/s.
• max_search_bytes_per_trace: Sorguda her trace için taranan max byte. Tipik 5 MB.

Grafana Enterprise Stack veya Grafana Cloud Pro lisansı ile her tenant için ayrı RBAC tanımlanabilir; OSS versiyonda bu, reverse proxy katmanında çözülür.

Compactor ve Retention Stratejisi

Compactor pod’u Tempo’da iki görev yapar: küçük block’ları birleştirir (compaction) ve eski block’ları siler (retention). Compaction işlemi, S3 GET maliyetlerini doğrudan etkiler; iyi sıkıştırılmış 100 MB’lık block, 1 GB’lık fragmentasyondan 12 kat daha az API çağrısı yaratır.

2026 production retention pattern’i şu: sıcak katman 14 gün (S3 Standard), ılık katman 60 gün (S3 Standard-IA), soğuk katman opsiyonel 180 gün (S3 Glacier IR). Compliance gereği audit trace’ler için 1 yıl soğuk katman ayrı bucket’ta tutulur. Bu yapı ile günde 100 milyar span üreten bir platform, yıllık 280.000 dolar S3 maliyetiyle çalışıyor.

Service Graph ve Topology Discovery

Tempo’nun Service Graph özelliği, span’lardan otomatik olarak servisler arası bağımlılık grafiğini üretir. Grafana’da bu grafik tempo_service_graph_request_total ve tempo_service_graph_request_failed_total metriklerinden node-edge görselleştirmesi yapılır. 2026’da bu, ekiplerin “yeni bir service eklediğimde bağımlılık nasıl değişti” sorusunu otomatik cevaplıyor.

Service Graph latency histogramları, p50/p95/p99 değerlerini servis çifti bazında verir. Grafana Tempo Metrics Generator dökümantasyonu, üretim ortamında service graph üretim oranını service_graphs.dimensions ile customize etmeyi öneriyor.

Self-Monitoring ve SLI/SLO

Tempo’nun kendi sağlığı için 8 ana metrik takip edilir. tempo_distributor_spans_received_total ingestion hacmini gösterir; tempo_ingester_blocks_flushed_total object storage’a yazma sağlığını; tempo_request_duration_seconds sorgu latency’sini izler. SLO hedefi olarak ingestion p99 < 500ms, query p99 < 8s standart kabul ediliyor.

Tempo, kurumsal observability stack’inde Loki ve Mimir ile birlikte “Grafana üçlüsü”nün ortasıdır. Üçü doğru hizalandığında Datadog/New Relic’in yıllık 1.8 milyon dolarlık faturası 120 bin dolara iner. Tek başına Tempo bu mucize değildir; ekosistem mühendisliği gerektirir.

Jaeger’den Tempo’ya Migration

2025-2026 döneminde Türkiye’de en sık karşılaşılan migration senaryosu Jaeger’den Tempo’ya geçiş. Jaeger’in Elasticsearch backend’i, 50 TB üzerine çıktığında sorgu süreleri 8 dakikaya kadar uzuyor; Tempo’da aynı veri 18 saniyede dönüyor. Migration süresi tipik kurum için 8 ile 16 hafta arası. İlk fazda her iki sistem paralel çalışır, sonra dashboard’lar Tempo’ya taşınır, en son Jaeger decommissioning’i yapılır.

Tempo’nun Jaeger query API compatibility’si %94 seviyesinde. Mevcut Jaeger UI bookmark’ları büyük oranda çalışır; geri kalan %6 için manuel adaptasyon gerekir. OpenTelemetry resmi dökümantasyonu migration sürecinde OTel Collector’ı bridge olarak konumlandırıyor.

FAQ

Tempo’da full-text search var mı?

Hayır. Tempo, span attribute’larına TraceQL üzerinden filter yapar ama log içeriği gibi serbest metin araması desteklemez. Bu intentional bir tasarım kararı; tracing’in primary key’i trace ID, secondary key’i attribute. Full-text gereken senaryolarda Loki ile entegrasyon önerilir.

Sampling oranı ne olmalı?

Genel kural: development %100, staging %50, production %5-15. Production’da tail-based sampling kullanılırsa errors ve high-latency’nin %100’ü, geri kalanın %3’ü saklanır. Bu, storage’ı 30 kat düşürür ama observability’i %92 korur.

Tempo Mimir veya Prometheus olmadan çalışır mı?

Çalışır ama eksik kalır. Metrics-generator output’u Prometheus-compatible remote_write endpoint gerektiriyor. Tempo standalone kurulduğunda RED metrikleri kaybedilir; sadece raw trace’ler işlenebilir. Üretimde Mimir veya VictoriaMetrics ile birlikte kurmak şart.

vParquet4’e geçiş zorunlu mu?

Tempo 2.6’da varsayılan vParquet4. Eski block’lar v2/v3 formatında kalır ama yeni yazılan tüm block’lar v4 olur. Sorgu motorları üç versiyonu da paralel okuyabilir. 6 aylık retention dolduktan sonra cluster %100 vParquet4’e geçer.

Service Graph üretimi ne kadar CPU kullanır?

Tipik olarak metrics-generator pod’unun CPU’sunun %35’i service graph’a gider. 50.000 unique service pair’i olan bir platformda 2 vCPU yeterlidir. 200.000 üzerine çıkıldığında 4 vCPU + cardinality limit gerekir.

Kurumsal Tempo Dönüşümünde Tipik Sorunlar

Türkiye’de Tempo production rollout’larında en sık 6 sorun gözlemleniyor. Birincisi, OTel Collector pipeline’ında yanlış processor sırası; tail_sampling processor’ı batch processor’ından önce konursa CPU 4 katına çıkıyor. Doğru sıra: receivers → memory_limiter → tail_sampling → batch → exporters.

İkincisi, ingester pod’larının persistent volume’larının yanlış boyutlandırılması; 5 dakikalık flush window’da biriken span miktarı için 100 GB yeterli olmalı, 20 GB ile başlayanlar her flush’ta PVC dolu hatası alıyor. Üçüncüsü, query frontend’in max_concurrent_queries limit’inin düşük tutulması; dashboard reload’da paralel 12 sorgu gelir, limit 8 ise yarısı bekler ve UI freeze görünür.

Dördüncüsü, metrics-generator’a tüm trafiğin yönlendirilmesi; %100 sampling metrics-generator’da memory’yi 12 katına çıkarır. Beşinci sorun, S3 bucket lifecycle policy’sinin yanlış kurulması; Glacier’a giden block’lar TraceQL sorgusunda 8 dakika gecikme yaratır. Altıncısı, multi-tenant X-Scope-OrgID header’ının service mesh’te trim edilmesi; Istio’da bu sıkça olur ve tüm trace’ler “default” tenant’a düşer.

Sonuç

Grafana Tempo 2.6, 2026’da distributed tracing alanında olgunluk eşiğini geçmiş, OpenTelemetry-native ve maliyet-etkin bir çözüm. vParquet4 formatı, TraceQL sorgu dili, metrics-generator ve exemplar entegrasyonu sayesinde Datadog APM’in %5’i maliyetle aynı observability deneyimini sağlıyor. 2026 itibarıyla Tempo’yu Loki ve Mimir ile birlikte konumlandıran kurumlar, observability stack maliyetlerini yıllık 1.4 milyon dolardan 95 bin dolara indiriyor. Doğru sampling stratejisi, doğru retention katmanı ve doğru OTel Collector pipeline’ı kurulduğunda Tempo, günde 100 milyar span’a kadar ölçeklenen bir platform hâline geliyor. Migration sürecinde en kritik adım, ilk 6 haftada Jaeger ile paralel çalıştırma ve TraceQL eğitimi vermek.

Uzman Görüşü

Ömer ÖNAL — Tracing danışmanlığı perspektifinden: Tempo’ya geçmeden önce ekiplerinizin OpenTelemetry instrumentation olgunluğunu ölçün. 2025’te 11 kuruma Tempo migration danışmanlığı verdim; 7’sinde sorun Tempo değildi, span’ların service.name attribute’unun tutarsız üretilmesiydi. OTel Collector’da resourcedetection processor’ı her zaman ilk processor olarak konfigüre edilmeli. Bu adım atlanırsa service graph 3 kat fazla node gösterir ve kimse anlam çıkaramaz.