1. GİRİŞ

OpenTelemetry (kısaca OTel), uygulama ve altyapı telemetrisini (metrics, traces, logs) toplamak, iletmek ve işlemek için tanımlanmış bir açık kaynak standardı ve yazılım koleksiyonudur. CNCF (Cloud Native Computing Foundation) çatısı altında hızla olgunlaşan OpenTelemetry, vendor‑agnostic bir yaklaşım sunarak farklı gözlem araçlarına veri göndermeyi mümkün kılar. Modern dağıtık mimarilerde, microservice, serverless ve event‑driven uygulamalarda gözlemlenebilirlik ihtiyacı arttıkça, OpenTelemetry neden kritik bir çözüm haline geldiği daha iyi anlaşılıyor.

Neden bugün önemli?

• Dağıtık uygulamalarda izleme ihtiyacı arttı; tek bir standarda sahip olmak entegrasyonu ve taşınabilirliği kolaylaştırır.
• Vendor‑agnostic telemetri, lock‑in riskini azaltır ve veri taşınabilirliği sağlar.
• OpenTelemetry; tracing, metrics ve logs'i tek çatıda toplayarak korelasyon ve daha derin analiz imkânı verir.

Kimler için önemli?

• SRE ve platform ekipleri — unified telemetri ile MTTR azaltmak isteyenler.
• Geliştiriciler — uygulama davranışını anlamak ve performans problemlerini hızlıca bulmak isteyenler.
• Observability platform mühendisleri — vendor geçişleri ve pipeline yönetimini sadeleştirmek isteyenler.

Hangi problemleri çözüyor?

• Farklı SDK ve backend'ler arasında veri uyumsuzluğunu ortadan kaldırır.
• Context propagation ve semantic conventions sayesinde sistemler arası korelasyonu kolaylaştırır.
• Collector mimarisiyle veriyi merkezi olarak filtreleme, enrich etme ve yeniden yönlendirme imkânı sağlar.

2. KAVRAMSAL TEMELLER

2.1 OpenTelemetry nedir?

OpenTelemetry; SDK'lar, API'ler, protokoller (OTLP), semantic conventions ve Collector bileşenlerinden oluşan bir ekosistemdir. Amaç; telemetri üretimini standartlaştırmak, veri taşınabilirliği sağlamak ve observability pipeline'larını vendor‑agnostic hale getirmektir. OTel, tracing, metrics ve logs için ortak kavram ve veri modelleri sağlar.

2.2 Temel bileşenler

• API ve SDK: Uygulama içinde telemetri üretmek için kullanılan diller arası (Java, .NET, Go, Python, JavaScript vb.) kütüphaneler.
• OTLP (OpenTelemetry Protocol): Collector ve exporter'lar arasında veri taşımak için kullanılan ikili/gRPC/HTTP protokolü.
• Collector: Telemetri verisini toplayan, işleyen, filtreleyen ve exporter'lara gönderen merkezi bileşen (agent veya gateway olarak çalışabilir).
• Semantic Conventions: Ortak attribute isimleri (http.method, db.system gibi) ile veri standardizasyonu sağlar.
• Exporters: Telemetri verisini backend'lere (Jaeger, Prometheus, Tempo, Zipkin, commercial APM) gönderen modüller.

2.3 Terminoloji

• Resource: Telemetriyi üreten entity hakkında metadata (service.name, service.version, host.id).
• Span / Trace: Trace bir istek zincirini, span ise trace içindeki tek bir operasyonu temsil eder.
• Metric: Sayısal ölçümler (counter, gauge, histogram).
• Context propagation: Trace id ve ilgili meta verilerin servisler arasında taşınması.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ, BİLEŞENLER VE VERİ AKIŞI

3.1 Yüksek seviyeli mimari

OpenTelemetry pipeline şu şekilde işler: uygulama SDK ile instrument edilir → telemetri SDK tarafından oluşturulur → telemetri Collector'a (agent/gateway) gönderilir veya doğrudan exporter ile backend'e gönderilir → Collector içinde processors ile filtreleme/enrichment/sampling yapılır → exporter'lar backend'e gönderir. Collector, agent veya gateway modunda çalışarak ağ topolojisine göre deployment esnekliği sağlar.

3.2 SDK ve otomatik vs manuel instrumentasyon

SDK'lar genelde iki enstrümantasyon yaklaşımını destekler:

• Automatic instrumentation: Framework ve library seviyelerinde HTTP client/server, DB driver, messaging client gibi popüler kütüphaneler otomatik olarak span/metric üretir. Hızlı ve geniş coverage sağlar fakat uygulama bağlamına özgü veri sınırlı olabilir.
• Manual instrumentation: Kritik iş yollarında geliştiricinin açıkça span/attribute eklediği yöntem. En doğru bağlam ve iş mantığı bilgisi burada sağlanır; ancak emek gerektirir.

3.3 Context propagation

Context propagation, bir isteğin servisler arasında izlenmesini sağlar. OTel W3C Trace Context standardını destekler; HTTP header'lar veya messaging metadata ile trace id ve span id taşınır. Baggage kavramı, istekle ilgili küçük metadata parçalarını taşımaya olanak verir (örneğin, tenant id) fakat baggage'ın boyutu ve performans maliyeti göz önünde tutulmalıdır.

3.4 OpenTelemetry Collector

Collector, OTel ekosisteminin merkezi elemanıdır. Collector şu rolleri üstlenir:

• İçe aktarma (receivers): SDK/agent'lerden OTLP veya diğer formatlarda telemetri alır.
• Processors: sampling, batching, attributes transform, resource detection ve redaction gibi işlemleri uygular.
• Exporters: veriyibackend'lere (Prometheus, Jaeger, Tempo, OTLP/HTTP) gönderir.

Collector, genelde iki biçimde konuşlandırılır: agent (node‑level, her host/pod başına küçük bir collector) ve gateway (kümesel/merkezi collector). Agent düşük latency ve local buffering sağlar; gateway ise merkezi policy uygulama, enrich ve routing imkânı tanır.

3.5 OTLP ve export mekanizmaları

OTLP (OpenTelemetry Protocol) gRPC/HTTP üzerinden ikili (protobuf) veri taşır ve yüksek performanslıdır. SDK'lar OTLP exporter ile Collector'a veya doğrudan backend'lere veri gönderebilir. Ayrıca Prometheus exporter (metrics scrape endpoint'i), Jaeger/Zipkin exporter gibi backend‑özgü exporter'lar bulunur.

3.6 Sampling, batching ve performans

Sampling stratejileri (head/tail/adaptive) telemetri hacmini kontrol etmek için kullanılır. Collector içinde sampling yapılarak yüksek hacimli trace'ler filtrelenebilir. Batching, retry ve buffering ise network ve backend yükünü düzenleyerek performansı korur. Ancak sampling politikası dikkatlice tasarlanmalı—özelikle hata/latency odaklı tail sampling gibi yaklaşımlar faydalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix / Uber / Amazon — neden OTel?

Büyük teknoloji firmaları, heterojen teknoloji yığını ve ölçek nedeniyle vendor‑agnostic, taşınabilir telemetriye ihtiyaç duyar. Netflix ve Uber gibi şirketler, tracing ve metrics entegrasyonunda standardizasyon sağlamak için OTel ekosistemini kullanır veya adapt eder. Bulut sağlayıcıları (AWS, Azure, GCP) da OTel uyumlu ingest yolları sunar; bu durum entegrasyonu kolaylaştırır.

4.2 Startuplar ve hızlı instrumentasyon

Startuplar için OTel, tek bir SDK ile metrics, traces ve logs üretebilme yeteneği sunar; bu sayede erken dönemde telemetry best practice'leri benimsenir ve vendor değiştirme maliyeti düşer. Managed backends veya Grafana Cloud gibi çözümlerle hızlı başlangıç mümkündür.

4.3 Hybrid ve multi‑cloud senaryoları

OpenTelemetry'nin en büyük faydalarından biri verinin standart bir formatta olmasıdır; collector'lar veriyi birden fazla backend'e gönderebilir. Bu, multi‑cloud veya hybrid ortamlarda merkezi gözlemlenebilirlik sağlar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Vendor‑agnostic: Telemetri taşıma ve backend değiştirme kolaylaşır.
• Unified model: Trace, metric ve log modellerinin ortak bir ekosistemde olması korelasyonu kolaylaştırır.
• Collector esnekliği: Central filtering, enrichment ve sampling politikalarını uygulama imkânı verir.

Sınırlamalar

• Olgunluk farkları: Bazı dil SDK'ları veya özellikler diğerlerinden daha olgun olabilir.
• Operational overhead: Collector konfigurasyonu ve pipeline yönetimi ek operasyon gerektirir.
• Performans ve maliyet yönetimi: Yanlış sampling veya yüksek cardinality telemetri maliyetlerini artırabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Semantic Conventions'a uyun: ortak attribute isimleriyle ekipler arası korelasyon kolaylaşır.
• Collector agent + gateway topolojisi: node‑level agent ile local buffering, central gateway ile policy enforcement uygulayın.
• Auto & manual instrumentasyon dengesini koruyun: otomatik instrumentasyonla coverage sağlayıp kritik path'leri manual ile zenginleştirin.

Performans optimizasyonu

• Sampling stratejilerini belirleyin: tail‑based sampling hata odaklı veri toplamak için etkilidir.
• Batching ve retry mekanizmaları ile ağ yükünü düzenleyin; lokal buffering ile kısa ağ kesintilerine dayanıklılık sağlayın.
• Attribute cardinality kontrolü uygulayın; dinamik değerleri baggage/trace yerine log veya başka store'da tutun.

Güvenlik

• Telemetry verisini OTLP üzerinden TLS ile şifreleyin; collector ve backend erişimlerini RBAC ile sınırlandırın.
• PII ve secret'ları collector seviyesinde redaction ile temizleyin.

Ölçeklenebilirlik

• Agent'ları lightweight tutun; heavy processing gateway tarafında yapın.
• Collector pipeline'ında worker/queue modelleri kullanarak backpressure ve autoscaling uygulayın.

8. SIK YAPILAN HATALAR

• Tüm attribute'ları spans/metrics'e koymak — cardinality patlaması ve maliyet artışı.
• Sadece otomatik instrumentasyona güvenmek — iş mantığı bağlamından yoksun traces.
• Sampling stratejisi olmadan tüm trace'leri saklamak — storage ve maliyet problemleri.
• Collector'ı tek bir merkezi noktada çalıştırmak ve agent katmanını ihmal etmek — network gecikmesi ve veri kaybı riski.

9. GELECEK TRENDLER

1. Unified telemetry ve semantic enrichment: Telemetri verisinin daha fazla otomatik zenginleştirme ve standardizasyonla gelmesi bekleniyor.
2. AI‑assisted RCA: Telemetri veri setleri ML modelleriyle işlenerek anomali ve root cause tespitleri otomatik öneri olarak sunulacak.
3. Edge/IoT için hafif‑OTel: Düşük kaynaklı cihazlarda çalışacak light collector'lar ve offline buffer stratejileri gelişecek.
4. Policy as Data for telemetry: Telemetri erişimi, retention ve sampling politikalarının kodlanması ve otomatik uygulanması yaygınlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. OpenTelemetry ile başlamanın en hızlı yolu nedir?

   OpenTelemetry SDK'yı uygulamanıza ekleyip otomatik instrumentation paketlerini aktif hale getirin; OTLP exporter ile bir Collector'a veri gönderin ve küçük bir backend (Jaeger/Tempo/Prometheus) ile uçtan uca akışı test edin.

2. 2. OTLP nedir, neden kullanmalıyım?

   OTLP (OpenTelemetry Protocol), telemetri verisinin taşınması için standart bir protokoldür. gRPC/HTTP seçenekleri ile yüksek performans ve geniş destek sunar; Collector ve backend'ler arası taşınabilirlik sağlar.

3. 3. Collector'ı agent mı yoksa gateway mi çalıştırmalıyım?

   Genelde en iyi pratik: host/pod seviyesinde lightweight agent (local buffering) ve merkezi gateway (policy, enrichment, routing) kombinasyonu. Bu model hem dayanıklılık hem de merkezi yönetim sağlar.

4. 4. Sampling stratejisi nasıl seçilir?

   Başlangıç için head‑based düşük oranlı sampling, kritik hata/latency için tail‑based sampling ile kombinlenebilir. Hata odaklı (error‑triggered) sampling genelde en faydalı sonuçları verir.

5. 5. OpenTelemetry, Prometheus ile nasıl entegre olur?

   Metrics için OTel SDK'ları Prometheus exporter veya collector'ın Prometheus receiver'ı aracılığıyla metrikleri uygun formata dönüştürebilir. Prometheus server scrape modelini kullanmaya devam edebilir ya da OTel Collector'dan Prometheus formatında exposition endpoint sağlayabilirsiniz.

6. 6. Semantic Conventions neden önemli?

   Ortak attribute isimlendirmesi ekipler arasında standard bir leksikon sağlar; arama, dashboard ve analizde tutarlılık ve otomatik korelasyon sağlar.

7. 7. Telemetry verisinde PII nasıl korunur?

   Collector seviyesinde redaction ve masking uygulayın; attribute kullanımını sınırlandırın ve retention/erase politikaları oluşturun. Ayrıca erişimi RBAC ile sınırlandırın.

8. 8. Vendor lock‑in'i nasıl önlerim?

   OpenTelemetry kullanarak üretimdeki telemetriyi standard formatta üretin; Collector ile birden fazla backend'e export etme yeteneği sayesinde vendor değiştirmeyi kolaylaştırabilirsiniz.

Anahtar Kavramlar

OpenTelemetry (OTel)

Metrics, traces ve logs için vendor‑agnostic telemetri standardı ve araç seti.

OTLP

OpenTelemetry Protocol — telemetri verisinin taşınması için kullanılan protokol.

Collector

Telemetriyi toplayan, işleyen ve exporter'lara gönderen merkezi bileşen (agent/gateway).

Semantic Conventions

Ortak attribute adlandırma kuralları—telemetri verisinin tutarlı ve aranabilir olmasını sağlar.

Sampling

Telemetri hacmini kontrol etmek için örnekleme stratejileri (head, tail, adaptive).

Öğrenme Yol Haritası

1. 0–1 ay: OpenTelemetry temel kavramlarını, trace/span modelini ve OTLP'yi öğrenin; örnek bir uygulamayı SDK ile instrument edin.
2. 1–3 ay: Collector kurulumu, pipelines, processors ve exporters ile working flow kurun; tail/head sampling deneyleri yapın.
3. 3–6 ay: Semantic Conventions, resource detection, enrichment ve log/trace/metric korelasyonu üzerinde çalışın; SLO entegrasyonları yapın.
4. 6–12 ay: Large scale deploy, adaptive sampling, AI‑assisted RCA, multi‑tenant ve multi‑cloud ingestion stratejileriyle deneyim kazanın.