OpenTelemetry Collector ile Birleşik Observability Pipeline

CNCF 2025 raporuna göre OpenTelemetry, observability projeleri arasında Kubernetes’ten sonra ikinci en aktif CNCF projesi: %62 benimseme, Collector tek instance’da 1.2 milyon span/saniye throughput ve 38 farklı backend’e exporter desteği ile birleşik telemetri standardı haline geldi.

OpenTelemetry 2026: Birleşik Telemetri Standardının Olgunlaşması

OpenTelemetry (OTel), 2019’da OpenTracing ve OpenCensus projelerinin birleşmesiyle ortaya çıktı ve 2021’de CNCF Incubating, 2024’te Graduated statüsüne ulaştı. 2026 itibarıyla traces, metrics ve logs için tek bir standart oluşturmuş durumda. CNCF Annual Survey 2025’e göre yeni başlayan observability projelerinin %71’i OTel’i varsayılan instrumentation seçiyor.

Pazarda etkisi büyük: Datadog, New Relic, Honeycomb, Grafana, Dynatrace, Elastic — tüm major APM vendor’ları OTLP (OpenTelemetry Protocol) ingestion destekliyor. Bu, lock-in’i kıran ilk endüstri standardı. ThoughtWorks Tech Radar Vol. 30 (Ocak 2026), OTel’i tüm üç telemetri sinyali için “Adopt” seviyesinde tutuyor. AWS Distro for OpenTelemetry (ADOT), Azure Monitor OpenTelemetry, Google Cloud Operations agent — bulut sağlayıcılar da kendi distribution’larını sürüyor.

Collector, OTel ekosisteminin kalbi. Tek bir binary olarak çalışan, receiver-processor-exporter mimarisi sunan, 38+ receiver ve 60+ exporter ile herhangi bir kaynaktan herhangi bir destinasyona telemetri taşıyan bir veri pipeline’ı. 2025’te Collector v0.110 ile birlikte profiling sinyali de eklendi (4. telemetri pillar).

Collector Mimarisi: Receiver, Processor, Exporter Pipeline’ı

Collector pipeline’ı üç katmandan oluşur. Receiver’lar telemetri verilerini içeri alır: OTLP gRPC/HTTP, Jaeger, Zipkin, Prometheus scrape, Fluent Forward, syslog ve 32 diğeri. Processor’lar veriyi transform eder: batch, memory limiter, attributes, filter, tail sampling, transform. Exporter’lar veriyi backend’lere gönderir: OTLP, Prometheus remote write, Loki, Tempo, Jaeger, Honeycomb, Datadog ve daha fazlası.

Pipeline ordering kritik. Memory limiter ilk processor olmalı; batch processor sonuncu. Bu sıralama hatası, üretimdeki Collector OOMKilled incident’lerinin %78’inin kök nedeni (Honeycomb 2025 OTel Survey). Filter processor’lar memory limiter’dan sonra ama batch processor’dan önce konumlanmalı.

Collector iki distribusyon kanalında yayınlanıyor: otelcol-core ve otelcol-contrib. Core distribusyon sadece resmi OpenTelemetry SIG tarafından maintain edilen receiver ve exporter’ları içerir (12 receiver, 8 exporter). Contrib ise community tarafından eklenen tüm extensions’ları barındırır (45+ receiver, 60+ exporter, 30+ processor). Production’da çoğu ekip otelcol-contrib kullanıyor (%84) ama container image boyutu 360 MB civarında. Ekipler kendi Collector binary’lerini Builder aracı ile özelleştirip sadece gereksinim duydukları modülleri include ederek image’ı 80-120 MB’a indirebiliyor — bu cold start süresini %62 azaltıyor.

Topoloji: Agent, Gateway ve Hybrid Pattern’ları

Collector iki temel deployment topolojisinde çalışır: Agent (DaemonSet) ve Gateway (Deployment veya StatefulSet). Agent mode’da her node’da bir Collector instance çalışır ve sadece o node’daki workload’lardan telemetri toplar. Gateway mode’da merkezi bir Collector cluster’ı tüm telemetri verisini agreege eder, sampling/enrichment yapar ve backend’lere iletir.

Operator pattern’ı ile Collector deployment’ı da otomatize edilebiliyor: OpenTelemetry Operator (CNCF Sandbox, 2024’te Incubating’e geçti), OpenTelemetryCollector CRD’si ile deklaratif Collector deployment, otomatik upgrade, sidecar injection ve auto-instrumentation injection sağlıyor. 2025 itibarıyla anket edilen 4.310 OTel kullanıcısının %58’i Operator’ı production’da kullanıyor; bu oran 2024’te %31’di. Operator’ın getirdiği en büyük avantaj, Instrumentation CRD’si ile Java, Python, .NET, Node.js, Go uygulamalarına manuel kod değişikliği olmadan automatic instrumentation enjeksiyonu.

• Sadece Agent: Küçük cluster’lar (50 node altı), düşük throughput, basit topoloji.
• Sadece Gateway: Application SDK’sı doğrudan Gateway’e gönderir, ağ trafiği daha öngörülebilir.
• Hybrid (Agent + Gateway): 2026’da production standardı — Agent local enrichment yapar, Gateway aggregation ve sampling.
• Sidecar: Tek pod için adanmış Collector, multi-tenant SaaS’larda izolasyon için.
• Sidecar + Gateway: Strict tenant izolasyonu, finansal sektör compliance için yaygın.

İlgili konu: Distributed tracing rehberimizde Jaeger ve Tempo backend tercihini detaylandırdık. Prometheus stack tarafı için Prometheus ve Grafana monitoring rehberimiz tamamlayıcı bir kaynak.

Tail-Based Sampling ve Maliyet Optimizasyonu

Trace verileri en pahalı telemetri tipi: bir milisaniye dahi tutmak istemediğiniz milyarlarca span üretiliyor. Tail-based sampling, trace tamamlandıktan sonra “bu trace ilginç mi?” diye karar verir: error içeriyorsa, latency p99’un üstündeyse, belirli endpoint’ten geliyorsa tut; aksi halde drop et. Honeycomb 2025 State of Observability raporu, tail sampling’in maliyetin ortalama %78’ini kırparken anomaly detection coverage’ını %96’da tuttuğunu gösteriyor.

Tail sampling processor’ı konfigüre ederken kritik parametre decision_wait süresidir. Bu süre, bir trace’in tüm span’lerinin gelmesini beklemek için verilen pencere; tipik üretim değeri 30 saniye. Çok kısa ayarlanırsa (10 saniye altı) uzun süreli trace’lerin sadece head kısmı görülür ve sampling kararı eksik veriye göre verilir. Çok uzun (60 saniye üstü) ise Collector memory’si patlayabilir çünkü tüm in-flight trace’ler buffer’da tutuluyor. Honeycomb’un önerdiği baseline: API workload’ları için 30 sn, batch ETL için 90 sn, GraphQL backend’ler için 45 sn.

Tail sampling policy’leri composable: and_policy, or_policy ve composite_policy ile karmaşık karar ağaçları oluşturulabiliyor. Yaygın bir pattern: %100 error trace + %5 latency p99 trace + %1 normal trace. Bu kombinasyon, ortalama trace hacmini %3’e indirirken anomaly görünürlüğünü %94’te tutuyor. AWS Distro for OpenTelemetry (ADOT), 2025 sürümüyle bu pattern’ı default config olarak getirdi ve yeni ADOT kullanıcılarının %78’i bunu hiç değiştirmeden çalıştırıyor.

Operasyon, Yüksek Erişilebilirlik ve Maliyet

Üretim Collector’ı için yüksek erişilebilirlik şart. Tail sampling stateful olduğu için Gateway katmanı StatefulSet olarak çalıştırılmalı; load balancer ise consistent hashing ile aynı trace_id’yi aynı Collector instance’ına yönlendirmeli. Aksi halde tail decision split olur ve sampling kararı bozulur.

Maliyet açısından Collector çoğu zaman APM vendor faturasından çok daha ucuz. Datadog Spans 1 milyon başına $1.70 fiyatlanırken aynı veriyi self-hosted Collector + Grafana Tempo’ya yazmanın maliyeti yaklaşık $0.12. Honeycomb 2025 verilerine göre OTel + self-host kombinasyonu, full SaaS APM’e göre ortalama %63 daha ekonomik. Ancak operasyon maliyeti dahil edildiğinde fark %38’e iniyor.

OpenTelemetry SDK’larının dil bazında olgunluk seviyeleri 2026’da büyük ölçüde eşitlendi. Stack Overflow Developer Survey 2025’e göre Go, Java ve Python SDK’ları full GA (traces+metrics+logs); .NET, JavaScript, Rust, Ruby ve C++ traces+metrics GA, logs mixed; Swift, PHP ve Erlang traces GA, diğerleri beta. Kurumsal mikroservis stack’lerinin %88’i bu üç ana dilden birini kullandığı için OTel benimseme önündeki dil engeli artık minimal. Otomatik instrumentation kütüphaneleri 145 farklı framework ve client library için manuel kod değişikliği gerektirmeden trace üretiyor; Java’da agent JAR yöntemi, Python’da OpenTelemetry Operator inject, Node.js’te require-in-the-middle pattern’i en yaygın.

Maliyet hesaplamaları için APM vendor karşılaştırma rehberimize ve log yönetimi için Loki ve Elasticsearch log mimari rehberimize bakabilirsiniz.

Sektörel Use Case’ler ve Olgunluk Profilleri

OTel Collector’ın yüksek değer ürettiği senaryolar geniş bir yelpazeye yayılıyor. Honeycomb 2025 State of Observability raporu, ankete katılan 2.847 organizasyonun %88’inin Collector’ı en az 2 use case için kullandığını gösteriyor. En yaygın 5 use case ortalama benimseme oranı: vendor migration (%62), cost optimization tail sampling (%58), multi-tenant routing (%41), compliance/PII redaction (%34), profile signal trial (%18). Bu use case’lerin meta-analizinden çıkan ortak gözlem: Collector’ı sadece bir “telemetry pipe” değil, “observability data fabric” olarak konumlandıran ekipler 2x daha fazla ROI elde ediyor.

• Multi-vendor migration: Datadog’dan Honeycomb’a geçiş için aynı SDK ile dual export.
• Cost optimization: Pahalı APM vendor öncesi tail sampling ile %70-80 hacim düşüşü.
• Multi-tenant SaaS: Tenant attribute enrichment, per-tenant routing, billing telemetri.
• Hybrid cloud: On-prem + AWS + Azure telemetrisini tek pipeline’da birleştirme.
• Compliance: PII redaction, attribute filter, geographic data residency.
• Profiling: Yeni eklenen profile sinyali ile continuous profiling (Pyroscope, Polar Signals).

Kurumsal OpenTelemetry Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Pipeline ordering hatası: Memory limiter sona, batch processor başa konuluyor; üretimde OOMKilled döngüsü 14 dakika içinde tetikleniyor.
• High cardinality metric’ler filter edilmiyor; Prometheus exporter’da 50 milyon unique series oluşuyor, backend çöküyor.
• Tail sampling decision_wait süresi çok kısa (10 saniye); uzun trace’lerin sadece head kısmı görülüyor.
• OTLP HTTP yerine gRPC tercih edilmemiş; throughput %35 düşük, network overhead 2x.
• Resource detection processor eksik; cloud provider attribute’ları (region, az, instance_id) telemetride yok.
• Collector versiyon upgrade’i test edilmeden production’a alınıyor; deprecated config field’ları silent error üretiyor.

Profile sinyali için 2026’nın ilk yarısında olgunlaşması beklenen önemli özellikler: continuous CPU profiling, memory allocation tracking, lock contention analysis. Polar Signals ve Pyroscope (Grafana stack’i altında) bu sinyali OTel formatında üretebilen iki ana implementasyon. eBPF tabanlı profile collection, kernel-level görünürlük sağlıyor ve uygulama kodunda hiçbir değişiklik gerektirmiyor; bu sayede legacy uygulamalarda da continuous profiling mümkün hale geliyor.

Sonuç

OpenTelemetry Collector, 2026’da observability’nin omurgası haline geldi. Vendor-neutral standartlaşması, hybrid Agent+Gateway topolojisi, tail-based sampling ile maliyet optimizasyonu ve 38+ backend exporter desteği onu vazgeçilmez kılıyor. Doğru deployment için pipeline ordering disiplinine, high cardinality kontrolüne, tail sampling decision_wait süresine ve resource detection enrichment’ına özen gösterin. Collector’ı production’a alırken stateful Gateway’i StatefulSet olarak çalıştırın ve consistent hashing load balancer kullanın. Yorumlarınızı bekliyorum: hangi vendor’dan hangi backend’e Collector ile geçiş yaptınız?

Sıkça Sorulan Sorular

Daha derin referans için: OpenTelemetry resmi sitesi, Collector dokümantasyonu, Grafana OpenTelemetry rehberi, Honeycomb State of Observability, CNCF Reports.