📌 Hızlı Özet & Temel Çıkarım:
Dağıtık İzleme (Distributed Tracing), yüzlerce mikroservisin birbirini çağırdığı karmaşık bulut yapılarında bir kullanıcının başlattığı tek bir HTTP veya gRPC isteğinin tüm alt servislerdeki yolculuğunu mikro-saniye hassasiyetinde görselleştiren gözlemlenebilirlik (observability) standardıdır. OpenTelemetry (OTel) projesi sayesinde, kodunuzu tek bir satıcıya (vendor lock-in) bağlamadan W3C TraceContext başlıkları ile küme genelinde P99 gecikme darboğazları tek bakışta tespit edilir.

1. Monolitik Loglamadan Dağıtık Gözlemlenebilirliğe Geçiş

Monolitik bir uygulamada hata çıktığında tek bir log dosyasına (app.log) bakıp hatanın hangi fonksiyonda gerçekleştiğini anlamak kolaydır. Ancak mikroservis mimarisinde tek bir sayfa yüklemesi arka planda 15 farklı servise yapılan 40 ayrı ağ isteğini tetikleyebilir.

Geleneksel loglamanın yetersiz kaldığı durumlar:

  • İstek Servis A’da 200 dönmüş ama Servis D’de 4 saniye takılmıştır; hangi servisin yavaşlattığını bulmak samanlıkta iğne aramaya benzer.
  • Ağ istekleri asenkron kuyruklar (Kafka vb.) üzerinden geçtiğinde bağlantı tamamen kopar.

Dağıtık izleme, her isteğe ilk giriş noktasında (API Gateway) benzersiz bir Trace ID ve her alt operasyona bir Span ID atayarak bu kaosu çözer.

2. W3C TraceContext ve Span Hiyerarşisi

W3C standardına göre HTTP istek başlıklarında şu format taşınır:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

  1. 00: Sürüm numarası.
  2. 4bf9...: 16 baytlık benzersiz Trace ID (tüm sistemde aynı kalır).
  3. 00f0...: 8 baytlık Span ID (o anki servisin alt adımı).
  4. 01: Örnekleme bayrağı (trace kaydedilsin mi?).

Aşağıdaki Python FastAPI kodu, OpenTelemetry SDK ile otomatik enstrümantasyon ve manuel özel span oluşturma pratiğini gösterir:

from fastapi import FastAPI, Request
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# OpenTelemetry Tracer Yapilandirmasi
provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True))
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("payment-service")

app = FastAPI()
FastAPIInstrumentor.instrument_app(app)

@app.post("/checkout")
async def checkout(request: Request):
    # Ana istek span'i otomatik olusturulur
    with tracer.start_as_current_span("fraud_check_database_query") as span:
        span.set_attribute("user.id", "usr_9981")
        span.set_attribute("payment.amount", 250.0)
        
        # Veritabani veya hesaplama simulasyonu
        is_safe = run_fraud_algorithm()
        span.set_attribute("fraud.result", "clean" if is_safe else "suspicious")
        
    return {"status": "approved"}

3. P99 Gecikme Analizi ve Darboğaz Tespiti

Ortalama yanıt süresi (Average Latency) yanıltıcıdır. Bir servisin ortalama yanıt süresi 50 ms iken, müşterilerin en şanssız %1’lik dilimi (P99) 5 saniye bekliyor olabilir.

OpenTelemetry verilerini Jaeger veya Grafana Tempo arayüzünde incelediğinizde:

  • Hangi veritabanı sorgusunun indeks kullanmadığı,
  • Hangi harici üçüncü parti API’nin timeout’a düştüğü,
  • Hangi kütüphanenin thread havuzunu bloke ettiği kırmızı span çubuklarıyla anında görünür hale gelir.

4. İlgili Konular ve İç Bağlantılar

5. Sıkça Sorulan Sorular

Her isteği trace etmek (100% Sampling) sunucuyu yorar mı?

Yüksek trafikli (saniyede on binlerce istek alan) sistemlerde %100 izleme ciddi ağ ve disk maliyeti üretir. Bu nedenle Head-based sampling (örneğin isteklerin rastgele %5’ini almak) veya Tail-based sampling (yalnızca hata alan veya 500 ms’den uzun süren istekleri saklamak) teknikleri kullanılır.

OpenTelemetry ile Prometheus arasındaki fark nedir?

Prometheus sayısal zaman serisi metriklerini (CPU kullanımı, saniyedeki istek adedi vb.) toplar. OpenTelemetry ise hem metrikleri hem logları hem de isteklerin tekil yolculuğunu gösteren izleri (traces) tek bir çatı altında toplayan evrensel standarttır.

6. OpenTelemetry Collector Mimarisi ve eBPF Tabanlı Sıfır Kod Enstrümantasyonu

Uygulama kodunun içine manuel olarak span yerleştirmek bazen eski (legacy) projelerde zor olabilir. Bu durumlarda Linux çekirdeğinin sunduğu eBPF (Extended Berkeley Packet Filter) teknolojisi devreye girer.

eBPF tabanlı OpenTelemetry ajanları (örneğin Grafana Beyla), çekirdek seviyesinde soket çağrılarını dinleyerek:

  • Uygulama kodunda tek bir satır dahi değiştirmeden,
  • HTTP/HTTPS istek sürelerini,
  • Veritabanı gidiş-dönüş gecikmelerini ve hata kodlarını otomatik olarak span nesnelerine dönüştürür.

Bu veriler yerel bir OTel Collector container’ına iletilir. Collector, gelen verileri filtreler, PII (Kişisel Veri) maskelemesi uygular ve toplu halde (batch) Jaeger veya Tempo arka yüzüne göndererek ağ üzerindeki ek yükü minimize eder.

7. Dağıtık İzleme Sistemlerinde Saklama Alanı ve Maliyet Optimizasyonu

Büyük ölçekli cloud-native mimarilerde her saniye on binlerce span üretilir. Eğer tüm bu veriler Jaeger veya Tempo üzerinde diskte saklanmaya çalışılırsa aylık terabaytlarca depolama maliyeti ortaya çıkar.

Maliyeti düşürürken gözlemlenebilirlikten ödün vermeyen iki strateji uygulanır:

  1. Kovaryans Tabanlı Örnekleme (Adaptive Sampling): Trafiğin sakin olduğu zamanlarda örnekleme oranı %100’e yakın tutulurken, trafik zirve yaptığında sistem otomatik olarak oranı %2’ye çeker ve istatistiksel dağılımı korur.
  2. Hata Odaklı Saklama (Error-Only Retention): HTTP 200 dönen ve 100 ms altında tamamlanan sağlıklı span’ler 24 saat sonra silinirken; HTTP 5xx hatası alan veya P99 eşiğini aşan sorunlu trace kayıtları kök neden analizi için 30 gün boyunca sıcak depolamada (hot storage) muhafaza edilir.

8. OpenTelemetry Span İsimlendirme Standartları ve Hata Nitelikleri (Semantics)

Dağıtık sistemlerde geliştiricilerin span’lere rastgele isim vermesi (“func1”, “db_call”) analiz aşamasında sorgulamayı imkansız kılar. OpenTelemetry Semantik Sözleşmeleri (Semantic Conventions) şu disiplini emreder:

  • HTTP İstekleri: {http.method} {http.route} (Örn: GET /v1/orders/{order_id}) formatında olmalıdır; asla dinamik ID doğrudan span adına yazılmamalıdır.
  • Veritabanı Çağrıları: db.system (postgresql/redis), db.name, db.statement öznitelikleriyle açıkça işaretlenmelidir.
  • Hata Durumları: Bir istisna oluştuğunda span durumu StatusCode.ERROR yapılmalı ve span.record_exception(e) çağrısıyla hata yığını (stack trace) span içine eklenmelidir. Bu standart sayesinde yüzlerce mikroservis arasında arama yaparken “Hangi PostgreSQL sorguları 500 ms üzerinde sürüyor?” sorusuna tek filtreyle saniyesinde ulaşılır.