OTel Collector Pipeline: Receiver, Processor, Exporter 2026

OpenTelemetry Collector, vendor-neutral telemetri toplama, işleme ve yönlendirme için CNCF tarafından sürdürülen referans bileşendir. otel collector mimarisi üç temel parçayı zincirler: receiver (kaynak: OTLP, Prometheus, Jaeger, Kafka), processor (batch, memory_limiter, filter, transform, tail_sampling) ve exporter (Tempo, Loki, Mimir, Datadog, Splunk, OTLP/HTTP). Bu üçlü pipeline içinde tanımlanır ve traces, metrics, logs sinyalleri için ayrı kurgulanır. CNCF 2024 yıllık raporuna göre OpenTelemetry, Kubernetes’ten sonra en aktif ikinci proje; GitHub’da collector reposu yaklaşık 5.000 yıldıza, contrib reposu 3.500 üzeri yıldıza ulaştı. 2026’da stable bileşen sayısı 30’u aştı ve Profiles sinyali experimental seviyeden beta’ya geçti. Bu yazı üretim sınıfı bir OpenTelemetry Collector pipeline‘ı receiver/processor/exporter perspektifinden adım adım kurgulayacak; deployment desenleri, tail sampling, cost kontrolü, güvenlik ve troubleshooting konularını ölçülebilir veriyle ele alacaktır. Konuyla ilişkili olarak gRPC Production Deployment 2026: Load Balancing, Retry, Deadlines rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Kafka Tiered Storage 2026: Cost Optimization S3 GCS Mimari rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Estuary Flow 2026: CDC Pipeline as a Service Debezium Alternatifi rehberimiz detaylı incelemeyi içerir.

OpenTelemetry Collector Nedir, Neden Vendor SDK Yerine Tercih Edilir

Collector, uygulamalardan veya altyapı bileşenlerinden gelen telemetri verisini tek bir Go binary üzerinde toplayan, dönüştüren ve gözlemlenebilirlik backend’lerine yönlendiren bağımsız bir process’tir. Vendor SDK’ları (Datadog Agent, Splunk Universal Forwarder, New Relic Infrastructure) sıklıkla tek backend’e bağlanır; Collector ise OTLP standardı sayesinde aynı veriyi paralel olarak birden fazla hedefe gönderebilir. CNCF anketine göre 2025’te üretim ortamlarının %62’si en az bir gözlemlenebilirlik pipeline’ında Collector kullanıyor; 2023’te bu oran %38 seviyesindeydi. Stack Overflow Developer Survey 2024 verilerinde OpenTelemetry, “most desired observability tool” kategorisinde yaklaşık %28 ile listenin başında yer aldı. Konuyla ilişkili olarak Rails 8 Solid Queue Mimarisinin Üretim Olgunluğu rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak ERC-4337 Mimarisinin Temel Bileşenleri rehberimiz detaylı incelemeyi içerir. Konuyla ilişkili olarak Cosmos SDK 2026: IBC Protokolünün Temel Bileşenleri Rehberi rehberimiz detaylı incelemeyi içerir.

Collector’ün asıl gücü migration esnekliği‘nde ortaya çıkar: Datadog’dan Grafana stack’e geçiş yapan bir ekip uygulama kodunu değiştirmeden sadece exporter konfigürasyonunu değiştirir. McKinsey’in 2024 cloud cost raporunda gözlemlenebilirlik vendor migrasyonu için ortalama maliyet 6 ay süre + tahmini 180.000 USD olarak ölçülmüş, OTel kullanan organizasyonlarda bu rakam yaklaşık 6 hafta + 35.000 USD’ye düşmüştür.

Yaklaşım	Vendor Lock-in	Çoklu Backend	Bağımlılık	2026 Stable
Vendor-spesifik SDK (Datadog)	Yüksek	Hayır	Yüksek	Yok
Vendor-spesifik agent (Splunk UF)	Yüksek	Sınırlı	Orta	Yok
Prometheus + Promtail + Tempo	Düşük	Manuel	3 binary	Kısmen
OpenTelemetry Collector	Düşük	Evet (OTLP)	1 binary	Evet
Fluent Bit (sadece logs)	Düşük	Evet	1 binary	Yok

Collector’ün core ve contrib olmak üzere iki dağıtımı vardır. Core, sadece resmi OpenTelemetry organizasyonunun bakım sorumluluğunu üstlendiği bileşenleri içerir (otlpreceiver, batchprocessor, otlpexporter, debugexporter). Contrib ise 90+ topluluk bileşeni barındırır: prometheusreceiver, kafkareceiver, awsxrayexporter, datadogexporter, tailsamplingprocessor. Builder aracı (ocb) ile yalnız ihtiyaç duyulan bileşenleri içeren özelleştirilmiş binary üretmek mümkündür; bu yaklaşım binary boyutunu 250 MB’tan yaklaşık 45 MB’a indirir ve attack surface’i ENISA 2024 önerileri doğrultusunda azaltır.

Pipeline Anatomisi: Receiver, Processor, Exporter Zinciri

Collector’ün YAML konfigürasyonu dört üst seviye anahtardan oluşur: receivers, processors, exporters, service. İlk üçü bileşen tanımıdır; service.pipelines bloğu bu bileşenleri sinyal başına (traces, metrics, logs) zincirler. Pipeline içinde bir receiver’dan veri akışı başlar, sıralı processor’lardan geçer ve bir veya birden fazla exporter’a ulaşır. Sıralama anlamlıdır: memory_limiter her zaman ilk processor, batch ise son processor olarak konumlanmalıdır.

receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 1024
    spike_limit_mib: 256
  batch:
    timeout: 5s
    send_batch_size: 8192

exporters:
  otlp/tempo:
    endpoint: tempo.observability:4317
  debug:
    verbosity: basic

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo, debug]
  telemetry:
    metrics: { level: detailed, address: 0.0.0.0:8888 }

Çoklu pipeline (fan-out) Collector’ün en güçlü desenlerinden biridir. Aynı receiver’dan gelen veriyi farklı işleme zincirlerinden geçirerek farklı backend’lere gönderebilirsiniz: tüm traces Tempo’ya, sadece error span’ları Datadog’a, sampling sonrası özet ise S3’e. Bu, differential routing olarak adlandırılır ve maliyetli backend’lerde ingestion volume’unu kontrol altına alır. CI/CD entegrasyonu için CI/CD Pipeline Kurulumu rehberi başvuru kaynağıdır.

Bileşen	Görevi	Tipik Örnekler	2026 Stable	Pipeline Yeri
Receiver	Veriyi içeri almak	otlp, prometheus, jaeger, kafka, filelog	8 stable	Başı
Processor	Dönüştürmek/filtrelemek	batch, memory_limiter, filter, transform, tail_sampling	7 stable	Ortası
Exporter	Veriyi göndermek	otlp, prometheusremotewrite, kafka, debug	9 stable	Sonu
Connector	Pipeline birleştirmek	spanmetrics, routing, forward, count	3 stable	Arası
Extension	Yan yetenekler	health_check, pprof, zpages, file_storage	5 stable	Dışı

Service bloğu içinde telemetry alt anahtarı Collector’ün kendi metrik üretimini kontrol eder. Bu meta-telemetri zorunludur; üretim ortamında Collector’ün düştüğünü ölçmenin yegane yolu budur. otelcol_processor_dropped_spans_total, otelcol_exporter_send_failed_spans, otelcol_receiver_refused_spans en kritik üç metriktir; bunların Prometheus’a scrape edilmesi üretim olgunluğunun ilk şartıdır.

Receiver Katmanı: Veri Kaynağı Çeşitliliği

OTLP receiver, OpenTelemetry’nin native protokolü olup gRPC (port 4317) ve HTTP/Protobuf (port 4318) üzerinden dinler. gRPC, persistent connection ve streaming sayesinde HTTP’ye göre yaklaşık %35 daha düşük CPU tüketir; HTTP ise NAT ve proxy senaryolarında daha esnektir. Üretimde her ikisini de açık tutmak yaygın pattern’dir. Brownfield (eski) sistemlerde köprü receiver’lar devreye girer: Jaeger receiver Thrift formatını OTLP’ye çevirir, Zipkin receiver JSON v2 endpoint’i sunar, Prometheus receiver scrape job tanımlarını okur, Kafka receiver belirli bir topic’ten OTLP messages tüketir. Filelog receiver log dosyalarını parse edip log signal’a dönüştürür; bu sayede Fluentd/Fluent Bit gibi ayrı log shipper’lara ihtiyaç kalmaz. Konteyner tabanlı log toplama için Docker Kubernetes Yönetimi içeriğindeki cluster konfigürasyonları referans alınabilir. Konuyla ilişkili olarak Gateway API 2026: Kubernetes Ingress'in Sonraki Nesli Production rehberimiz detaylı incelemeyi içerir.

Receiver	Sinyal	Stabilite (2026)	Throughput Tahmini	Ne Zaman
otlp	traces, metrics, logs	stable	~50k span/s/core	Modern, native OTel
prometheusreceiver	metrics	stable	~100k sample/s	Var olan scrape config
jaegerreceiver	traces	deprecated*	~40k span/s	Eski Jaeger migrasyonu
kafkareceiver	traces, metrics, logs	beta	~200k msg/s	Replay, decouple
filelogreceiver	logs	beta	~80 MB/s/core	Konteyner log tail
hostmetricsreceiver	metrics	beta	~30 metric/scrape	Node-level kaynak
k8sclusterreceiver	metrics, events	beta	~5k entity/scrape	K8s API objeleri

*Jaeger client SDK’ları 2026 itibarıyla deprecated; jaegerreceiver hâlâ destekleniyor ancak yeni projelerde OTLP tercih edilmelidir. Receiver seçiminde dikkat edilmesi gereken kritik bir konu auth‘tur. OTLP receiver default olarak unauthenticated dinler. Üretimde mutlaka mTLS, bearer token veya OAuth2 extension’larından biri eklenmelidir. ENISA’nın 2024 Cloud Security raporu, telemetri pipeline’larının ortalama 2,3 kritik yanlış konfigürasyon barındırdığını ve bunların yaklaşık %41’inin authentication eksikliği olduğunu belgeliyor. Pipeline güvenliğinin DevSecOps yaklaşımına entegrasyonu için DevSecOps Shift-Left rehberi temel referans olarak kullanılabilir.

Processor Katmanı: Filtreleme, Dönüştürme, Sampling

Processor’lar pipeline’ın “iş yapan” katmanıdır. Sıralama kritik öneme sahiptir çünkü her processor bir öncekinden çıkan veriyi alır ve sonrakine geçirir. Üretim olgunluğu açısından doğru sıralama şu şekildedir:

1. memory_limiter: İlk processor. Bellek eşiği aşılırsa yeni veriyi reddederek OOM kill’i engeller. Limit pod RAM’inin ~%75’i, spike_limit ~%25’i olmalı.
2. resourcedetection: AWS/GCP/Azure/K8s meta verisini her span’a iliştirir.
3. attributes / transform: Hassas alanları (PII, API key) hash’le veya kaldır. GDPR/KVKK uyum noktası.
4. filter: İstenmeyen sinyali tamamen drop et (health-check span’ları, kube-system metric’leri).
5. tail_sampling: Decision-aware sampling. Error %100, slow %100, normal ~%5.
6. batch: Son processor. send_batch_size 8192, timeout 5s tipik. Network round-trip’i azaltır.

Tail sampling, üretim maliyetinin en büyük düşmanına karşı en güçlü silahtır. Head sampling (SDK seviyesinde rastgele %1) trace’in hata içerip içermediğini bilmeden karar verir; tail sampling tam trace assembly’sinden sonra karar üretir. Tipik bir e-ticaret iş yükünde aşağıdaki politika veri hacmini yaklaşık %92 azaltırken alert quality’sini değiştirmez.

Policy	Koşul	Sample Rate	Saklanan Volume	Storage Etkisi
error_traces	status.code = ERROR	%100	Tüm error trace	~%3 toplam
slow_traces	duration > 1500 ms	%100	p99 üzeri yavaş	~%2 toplam
checkout_critical	service.name = checkout	%100	Tüm checkout flow	~%1 toplam
health_drop	http.target = /health	%0	Health check silinir	~−%15 toplam
probabilistic_rest	diğer trace’ler	%2	Genel istatistik	~%2 toplam

Tail sampling, tüm trace span’larının aynı Collector instance’ına ulaşması‘nı gerektirir. Bu yatay ölçeklenmiş Collector deployment’larında zor bir kısıttır. Çözüm: load balancer önüne loadbalancingexporter ile bir gateway tier’ı koymak. Trace ID hash’i ile span’lar deterministik olarak aynı gateway pod’una yönlendirilir, böylece tail sampling tutarlı çalışır.

Exporter Katmanı, Deployment Desenleri ve Çoklu Backend

Exporter, processor’lardan çıkan veriyi gözlemlenebilirlik backend’ine taşır. En önemli pratik: her exporter’a retry, queue ve timeout ayarları zorunlu eklenir. Default değerler üretim için tehlikelidir. Aşağıdaki yapı, network kesintisinde 5 dakikaya kadar veriyi disk’te tutarak veri kaybını minimize eder:

exporters:
  otlp/tempo:
    endpoint: tempo.observability.svc:4317
    tls: { insecure: false, ca_file: /etc/ssl/certs/ca.pem }
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 5000
      storage: file_storage/queue
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s
    timeout: 10s

extensions:
  file_storage/queue:
    directory: /var/lib/otelcol/queue

Çoklu exporter senaryosunda fan-out default’tur: bir pipeline’da listelenen tüm exporter’lar aynı veriyi alır. Bu, gözlemlenebilirlik shadow mode’unda kritiktir: eski Splunk pipeline’ı çalışırken yeni Grafana stack’e paralel yazıp doğrulama yapılır, sonra eski exporter kaldırılır. Cost-conscious deployment’larda routingconnector ile attribute-based hedef seçimi yapılır: service.tier=critical olan span’lar pahalı Datadog’a, diğerleri ucuz Mimir’e yönlendirilir. Maliyet kontrolü çerçevesi için FinOps Bulut Maliyet rehberi başvuru kaynağıdır.

Exporter	Backend	Stabilite	Throughput	Pricing (2026)
otlp/otlphttp	Tempo, Mimir, Loki, Jaeger v2	stable	~80k span/s/core	Self-hosted
datadog	Datadog	stable	~30k span/s/core	~$1.27/M span
prometheusremotewrite	Mimir, Cortex, Thanos, AMP	stable	~150k sample/s	Self-hosted
kafka	Kafka cluster	beta	~250k msg/s	Self-hosted
awsxray / awsemf	X-Ray, CloudWatch	stable	~25k span/s/core	~$5/M trace
googlecloud	Cloud Trace, Logging	stable	~30k span/s/core	~$0.20/M span
elasticsearch	Elastic APM	beta	~40k doc/s/core	Self-hosted/Cloud

Collector tek bir Go binary olduğu için farklı topolojik pozisyonlarda çalıştırılabilir. Üretim ortamında üç deployment deseni yaygındır:

• Agent (DaemonSet): Her Kubernetes node’unda bir Collector pod. Avantaj: düşük network mesafesi, node-lokal hostmetrics. Dezavantaj: tail sampling tek node ile sınırlı. Ne zaman seç: log toplama ve infrastructure metrics ağırlıklı yüklerde.
• Gateway (Deployment): Cluster genelinde merkezi 3-10 replikalı. Avantaj: tail sampling, cost guarding, vendor-spesifik transform. Dezavantaj: ek hop, ek latency (~2-5 ms). Ne zaman seç: tail sampling veya çoklu backend fan-out gerekli olduğunda.
• Sidecar (Pod-level): Application pod’una eklenen ek container. Avantaj: en kısa loopback, per-service izolasyon. Dezavantaj: her pod CPU/RAM ekler. Ne zaman seç: regülasyon nedeniyle her servisin trafiğinin ayrı segregate edilmesi gerektiğinde.
• OpenTelemetry Operator (CRD-based): Instrumentation ve OpenTelemetryCollector CRD’leri ile declarative yönetim. Sidecar injection otomatik. Detay için Kubernetes Operator içeriği başvuru kaynağıdır.

Hibrit desen (agent + gateway) üretim olgunluğu açısından en güçlü seçimdir. Agent’lar node-lokal veri toplar ve gateway tier’ına gönderir; gateway’de tail sampling, transform ve backend fan-out yapılır.

Performans, Ölçekleme ve Throughput Benchmark’ları

OpenTelemetry projesinin resmi load testing sonuçları (otelcol v0.115, Linux amd64, c5.2xlarge, 2026 Q1) baz alındığında tek bir Collector instance’ı 1 vCPU başına yaklaşık 50.000 span/saniye throughput sağlar. Memory limit 1 GiB, batch size 8192, otlp gRPC receiver, otlp gRPC exporter, batch + memory_limiter processor zinciri için ölçülmüştür. Aynı zincire tail_sampling eklendiğinde throughput yaklaşık %35-45 düşer, çünkü trace assembly bellekte tutulur ve karar verme süreci CPU-bound olur.

Ölçeklenirken kritik metrikler şunlardır: otelcol_exporter_send_failed_spans (export hatası), otelcol_processor_dropped_spans (queue dolduğunda drop), otelcol_receiver_refused_spans (memory_limiter trigger). Bunların hepsi service.telemetry altında otomatik üretilir ve Prometheus’a scrape edilebilir. Alerting için en kritik üç eşik:

• dropped_spans > 0 son 5 dakika: Pipeline kayıp veriyor, kritik alert (P1).
• send_failed_spans > %1 of accepted: Exporter sorunu, warning alert (P2).
• queue_size > %80 of max_capacity: Sürdürülemez yük, capacity planning gerekir (P3).

Senaryo	Pipeline	CPU (core)	Throughput (span/s)	Memory (GiB)	p99 Latency
Minimal	otlp → batch → otlp	1	~50.000	0.5	8 ms
Standart	+ memory_limiter	1	~48.000	0.8	10 ms
Filter eklenmiş	+ filter	1	~42.000	0.9	12 ms
Tail sampling	+ tailsampling (30s)	1	~28.000	2.5	35 ms
Yatay ölçekli	4 replika gateway + LB	4	~110.000	10	40 ms
Multi-backend fan-out	+ 3 exporter	2	~70.000	3	20 ms

Kubernetes ortamlarında HPA/VPA otomatik kaynak ayarlaması Collector için ideal değildir; tail sampling’in stateful doğası nedeniyle pod öldürmek trace bütünlüğünü bozar. Onun yerine PodDisruptionBudget + preStop hook + sending_queue file_storage kombinasyonu önerilir.

Güvenlik, Multi-Tenancy ve Operasyonel Anti-Pattern’ler

Üretim Collector pipeline’ında güvenlik üç katmanda kurgulanır: transport, authentication, tenant isolation. Transport için OTLP receiver ve exporter mTLS konfigüre edilir; sertifika rotation cert-manager ile otomatize edilebilir. Authentication için oauth2clientauth, bearertokenauth, basicauth extension’ları kullanılır. Multi-tenant ortamlarda routingconnector X-Tenant-Id header’ına göre pipeline’ları ayırır; bir tenant’ın span’ı diğerinin backend’ine düşmez. NIST SP 800-204D dokümanı, mikroservis observability pipeline’larının “data plane policies” katmanında authentication zorunluluğunu açık şekilde ortaya koyar. Bu prensip Kubernetes Network Policy içeriğindeki Cilium L7 policy’leri ile pratik karşılığını bulur.

PII (kişisel veri) sızıntısı, telemetri pipeline’larının en yaygın uyum riskidir. Üretim öncesi mutlaka transformprocessor ile aşağıdaki kuralları uygulayın:

• e-posta hash’le: set(attributes["user.email"], SHA256(attributes["user.email"]))
• kart numarası kaldır: delete_key(attributes, "payment.card_number")
• Authorization header maskele: replace_pattern(attributes["http.request.header.authorization"], "Bearer .*", "Bearer ***")
• IP redaction: truncate_all(attributes, "client.ip", "/24") ile son okteti sıfırla.

ENISA 2024 Threat Landscape raporu, observability pipeline’ları üzerinden 2023’te 47 farklı veri sızıntısı vakası belgelemiştir; bunların yaklaşık %68’i unfiltered Authorization header’larıydı. Bu nedenle transformprocessor kuralları ilk gün pipeline’a eklenmelidir, üretim sonrası değil. Collector üretimde sessizce başarısız olduğunda en yaygın üç anti-pattern: (1) memory_limiter’sız pipeline, (2) sending_queue file_storage olmadan exporter retry, (3) tail_sampling tek replikada (gateway LB’siz). Bu üçü “sessiz veri kaybı”nın yaklaşık %80’inden sorumludur.

Üretim Pipeline Şablonu ve Operasyonel Kontrol Listesi

Aşağıdaki üretim sınıfı şablon OTLP receiver + memory_limiter + resourcedetection + transform (PII) + tail_sampling + batch + multi-exporter (Tempo + Datadog + Kafka backup) kombinasyonunu içerir. mTLS, sending_queue file_storage, retry, health_check ve pprof extension’ları aktiftir.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        tls: { cert_file: /etc/otel/certs/tls.crt, key_file: /etc/otel/certs/tls.key, client_ca_file: /etc/otel/certs/ca.crt }

processors:
  memory_limiter: { check_interval: 1s, limit_mib: 3072, spike_limit_mib: 768 }
  resourcedetection: { detectors: [env, system, k8snode] }
  transform/pii:
    trace_statements:
      - context: span
        statements:
          - replace_pattern(attributes["http.request.header.authorization"], "Bearer .*", "Bearer ***")
          - delete_key(attributes, "payment.card_number")
  tail_sampling:
    decision_wait: 30s
    num_traces: 100000
    policies:
      - { name: errors, type: status_code, status_code: { status_codes: [ERROR] } }
      - { name: slow,   type: latency,     latency:     { threshold_ms: 1500 } }
      - { name: rest,   type: probabilistic, probabilistic: { sampling_percentage: 2 } }
  batch: { timeout: 5s, send_batch_size: 8192 }

exporters:
  otlp/tempo:
    endpoint: tempo-distributor.tempo:4317
    sending_queue: { enabled: true, queue_size: 10000, storage: file_storage/q }
    retry_on_failure: { enabled: true, max_elapsed_time: 300s }
  datadog:
    api: { key: ${env:DD_API_KEY}, site: datadoghq.eu }
  kafka/backup:
    brokers: ["kafka-0:9092","kafka-1:9092","kafka-2:9092"]
    topic: otel-traces-backup
    encoding: otlp_proto

extensions:
  health_check: { endpoint: 0.0.0.0:13133 }
  pprof:        { endpoint: 0.0.0.0:1777 }
  file_storage/q: { directory: /var/lib/otelcol/queue }

service:
  extensions: [health_check, pprof, file_storage/q]
  pipelines:
    traces:
      receivers:  [otlp]
      processors: [memory_limiter, resourcedetection, transform/pii, tail_sampling, batch]
      exporters:  [otlp/tempo, datadog, kafka/backup]
  telemetry:
    metrics: { level: detailed, address: 0.0.0.0:8888 }

Operasyonel sağlık için aşağıdaki kontrol listesini ilk gün uygulayın:

1. Health check 13133 portundan dönüyor mu (health_check extension).
2. zpages 55679 portundan ulaşılabilir mi (live pipeline introspection).
3. Self-monitoring Prometheus scrape 8888 portundan aktif mi.
4. Receiver auth mTLS veya OAuth ile zorlanıyor mu.
5. memory_limiter spike_limit dahil tanımlı mı.
6. batch processor sondaki processor mı.
7. sending_queue + file_storage her exporter’da aktif mi.
8. retry_on_failure max_elapsed_time 5 dakika veya daha fazla mı.
9. config validation CI’da otelcol validate --config komutu çalışıyor mu.
10. Sürüm sabitleme: tag’siz latest image YASAK; explicit version kullanılıyor mu.

Sıkça Sorulan Sorular

Sonuç

OpenTelemetry Collector pipeline’ı, gözlemlenebilirlik stratejisinin tek noktadan kurgulanan kontrol katmanıdır. Receiver çeşitliliği eski sistemleri yeni standartla buluşturur, processor zinciri PII koruması ile maliyet kontrolünü aynı anda sağlar, exporter çoklaması vendor migrasyonu ve shadow mode senaryolarına olanak tanır. Üretim olgunluğu için memory_limiter, batch, retry, sending_queue + file_storage, tail_sampling (gateway tier ile birlikte) ve mTLS kombinasyonu minimum baseline’dır.

Karar çerçevesi olarak şu kural işe yarar: ekibinizin gözlemlenebilirlik faturası aylık 10.000 USD üzerindeyse, tail sampling + transform/filter ile cost-control her zaman ROI pozitif çıkar. Faturanız bunun altındaysa agent-only DaemonSet desenle başlayıp ihtiyaç doğdukça gateway tier ekleyebilirsiniz. Ömer Önal’ın yürüttüğü danışmanlık projelerinde en sık karşılaşılan tablo şudur: tail_sampling + transform/filter’ı pipeline’a ilk haftadan eklemek tipik gözlemlenebilirlik faturasını %55-70 oranında düşürür.

Pipeline kurulumu, optimizasyonu veya mevcut Splunk/Datadog kontratından OTel tabanlı self-hosted Grafana stack’e geçiş için yol haritası çıkarmak istiyorsanız iletişim sayfası üzerinden ulaşabilirsiniz. İlk konsültasyon, mevcut pipeline’ınızın audit’i ve tail sampling + cost-control’lü hedef tasarımın çıkarımı ile yapılır.

Kaynaklar ve ileri okuma: OpenTelemetry Collector resmi dokümantasyonu, opentelemetry-collector-contrib GitHub reposu, CNCF Annual Survey 2024, NIST SP 800-204D, ENISA Threat Landscape 2024, Stack Overflow Developer Survey 2024, Grafana Tempo dokümantasyonu.