Mikroservis Labirentinde Kaybolmamak: OpenTelemetry ve Jaeger ile Dağıtık İzleme
Modern bir devops ekibinin kabusu, gecenin üçünde gelen bir PagerDuty alarmıyla başlar. Sisteminizdeki 10’larca mikroservis birbirine zincirlenmişken, ödeme adımındaki bir gecikmenin ya da hatanın kaynağını bulmak samanlıkta iğne aramaya benzer. Geleneksel log analiz araçları (ELK, Loki) bu kaotik ortamda yetersiz kalır; çünkü size korelasyonu değil, sadece bağımsız olayları sunarlar. Tam da bu yüzden, modern sistem mimarilerinde uçtan uca observability sağlamak ve hata tespitini dakikalara indirmek için opentelemetry ve jaeger ikilisi fiili endüstri standardı haline geldi. Bu rehberde, lafı hiç uzatmadan, production ortamında çalışan servisleriniz için dağıtık izleme (distributed tracing) altyapısını nasıl kuracağımızı ve karmaşık darboğazları nasıl analiz edeceğimizi göreceğiz.
Neden APM Ajanları Değil de OpenTelemetry?
Geçmişte New Relic, Datadog veya Dynatrace gibi kapalı kaynak APM (Application Performance Monitoring) ajanlarını uygulamaya gömmek kolay bir kaçış yoluydu. Ancak bu yaklaşım beraberinde ciddi bir “vendor lock-in” (tedarikçiye bağımlılık) ve kontrol edilemez maliyet artışları getiriyor. OpenTelemetry (OTel), CNCF çatısı altında geliştirilen satıcıdan bağımsız (vendor-agnostic) açık bir standarttır. Yarın öbür gün Jaeger yerine başka bir backend’e (örneğin Grafana Tempo) geçmek isterseniz, uygulama kodunuzda tek bir satır bile değiştirmeden sadece konfigürasyon seviyesinde bu değişikliği yapabilirsiniz.
Peki, arka planda bu iş nasıl dönüyor? İşin sırrı W3C Trace Context standardında saklıdır. Servisler arası HTTP veya gRPC çağrıları yapılırken, istek başlıklarına (headers) benzersiz bir traceparent eklenir:
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
# Format: sürüm-traceId-spanId-traceFlagsBu başlık sayesinde, istek hangi servise giderse gitsin, o servisin ürettiği loglar ve span’ler aynı üst kimlik (Trace ID) altında birleşir.
Mimariyi Doğru Tasarlamak: Collector Neden Şart?
Uygulamalarınızdan trace verilerini doğrudan Jaeger’a göndermek ilk bakışta cazip görünebilir. Ancak bu yaklaşım production ortamında intihardır. Jaeger geçici olarak ulaşılamaz olduğunda uygulamanızın bellek (heap) tüketimi tavan yapabilir veya ağ trafiğiniz optimize edilmemiş paketlerle dolabilir.
Doğru yaklaşım, her Kubernetes node’unda bir DaemonSet olarak veya merkezi bir Gateway olarak OpenTelemetry Collector konumlandırmaktır. Uygulamalar trace verilerini localhost üzerindeki Collector’a gönderir (çok düşük gecikme ile), Collector ise veriyi tamponlar (buffer), sıkıştırır (batch) ve asenkron olarak Jaeger’a iletir.
Adım Adım Kurulum: Production-Ready OTel Collector Konfigürasyonu
Aşağıda, yük altında ezilmeyecek, memory limiter ve batching mekanizmaları aktif edilmiş örnek bir otel-collector-config.yaml dosyası yer alıyor. Bu konfigürasyonu Kubernetes ortamında ConfigMap olarak tanımlayabilirsiniz:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
memory_limiter:
check_interval: 1s
limit_percentage: 75
spike_limit_percentage: 15
batch:
send_batch_size: 8192
timeout: 5s
send_batch_max_size: 10240
exporters:
otlp/jaeger:
endpoint: "jaeger-collector.observability.svc.cluster.local:4317"
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlp/jaeger]Neden bu işlemcileri (processors) kullandık?
- memory_limiter: Collector’ın bellek tüketimi belirlenen limitin (%75) üzerine çıktığında, çökmeyi (OOMKilled) önlemek için yeni gelen verileri dropping moduna alır. Güvenli limanda kalmanızı sağlar.
- batch: Her trace span’ini tek tek ağ üzerinden göndermek yerine, bunları gruplayarak gönderir. CPU ve network overhead’ini dramatik ölçüde düşürür.
Uygulama Seviyesinde Context Propagation (Go Örneği)
OTel SDK’sını uygulamanıza entegre ederken en kritik nokta, bağlamın (context) kaybolmamasını sağlamaktır. Eğer bir HTTP çağrısı yapıyorsanız, HTTP istemcinizi OTel transport katmanı ile sarmalamanız gerekir. Aşağıdaki Go kod bloğu, gelen isteğin trace bağlamını alıp bir sonraki servise nasıl güvenli bir şekilde aktaracağınızı gösterir:
package main
import (
"context"
"net/http"
"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/trace"
)
func handleCheckout(w http.ResponseWriter, req *http.Request) {
// Gelen istekten trace context'i çıkar ve yeni bir span başlat
ctx := req.Context()
tracer := otel.Tracer("checkout-service")
ctx, span := tracer.Start(ctx, "ProcessPayment", trace.WithSpanKind(trace.SpanKindServer))
defer span.End()
// Ödeme servisine yapılacak HTTP çağrısını sarmala
client := http.Client{Transport: otelhttp.NewTransport(http.DefaultTransport)}
nextReq, _ := http.NewRequestWithContext(ctx, "POST", "http://payment-service/charge", nil)
resp, err := client.Do(nextReq)
if err != nil {
span.RecordError(err)
span.SetStatus(500, "Payment initiation failed")
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
defer resp.Body.Close()
w.Write([]byte("Checkout successful"))
}Bu kodda otelhttp.NewTransport, arka planda W3C standartlarına uygun traceparent header’ını giden HTTP isteğine otomatik olarak enjekte eder. Manuel müdahaleye gerek kalmaz.
Production SRE Pratikleri: Sampling Rate (Örnekleme) Ayarı
Saniyede 10.000 istek alan bir sistemde her bir isteğin trace verisini saklamak hem Jaeger depolama alanınızı (Elasticsearch/Cassandra) saniyeler içinde doldurur hem de ciddi bir maliyet kalemi oluşturur. Çözüm: Head-based veya Tail-based sampling uygulamaktır.
Uygulama seviyesinde (Head-based) sadece başarılı olan isteklerin %1’ini, hatalı (error status) olanların ise %100’ünü saklamak mantıklıdır. Ancak uygulamanın bir isteğin hata vereceğini en baştan bilmesi imkansızdır. Bu yüzden Collector seviyesinde Tail-based sampling yapılandırmak en profesyonel çözümdür. Collector, trace tamamlanana kadar veriyi belleğinde tutar; eğer trace içinde bir hata kodu veya yüksek gecikme saptanırsa trace’in tamamını saklar, aksi takdirde belirlediğiniz oranda eler.
Bunun için Collector konfigürasyonunuza şu işlemciyi ekleyebilirsiniz:
processors:
tail_sampling:
decision_wait: 10s
num_traces: 10000
expected_new_traces_per_sec: 2000
policies:
- name: filter_errors
type: status_code
status_code: { status_codes: [ ERROR ] }
- name: filter_latency
type: latency
latency: { threshold_ms: 500 } # 500ms üzerindeki tüm trace'leri sakla
- name: probabilistic_sample
type: probabilistic
probabilistic: { sampling_percentage: 5.0 } # Normal trafikten %5 örnek alJaeger Arayüzünde Darboğaz Analizi: Nereden Başlamalı?
Her şey kuruldu ve Jaeger UI’a girdiniz. Önünüzde yüzlerce span içeren karmaşık bir trace ağacı duruyor. SRE bakış açısıyla analiz yaparken şu üç altın kuralı unutmayın:
- Gap Analizi (Boşluklar): İki ardışık span arasında büyük bir zaman boşluğu varsa, bu durum ağ gecikmesine, kuyrukta bekleyen (message queue) mesajlara veya uygulama içindeki CPU-bound kilitlemelere (mutex contention) işaret eder.
- Database Span’leri (N+1 Sorgu Problemi): Eğer tek bir HTTP isteğinin altında yüzlerce ardışık SQL sorgu span’i görüyorsanız, yazılımcılarınız ORM kütüphanesini yanlış kullanmış ve N+1 query tuzağına düşmüş demektir.
- Baggage vs Span Attributes Ayrımı: Trace akışı boyunca tüm downstream servislere taşınmasını istediğiniz kritik meta verileri (örneğin
tenant_idveyauser_tier) “Baggage” olarak ekleyin. Sadece o servise ait verileri (örneğin SQL query string) ise “Span Attribute” olarak tutun.
Sonuç: Kör Noktaları Yok Edin
OpenTelemetry ve Jaeger yatırımı, ilk kurulumda kod değişikliği ve konfigürasyon yükü getirse de, production’da yaşanacak ilk büyük krizde kendini amorti eder. Servislerinizin birbiriyle nasıl konuştuğunu tahmin etmek yerine, onları canlı olarak izleyin. Unutmayın; ölçemediğiniz sistemi yönetemezsiniz.