OpenTelemetry Nedir? Log, Metric ve Trace Verileri Nasıl Birleştirilir?

Bir yazılım sistemi farklı dillerde geliştirilmiş servislerden, sanal makinelerden, container’lardan, veritabanlarından ve üçüncü taraf API’lerden oluştuğunda telemetri verisi de parçalanır. Bir servis kendi log formatını kullanırken diğeri farklı metric isimleri üretebilir; trace verisi ise yalnızca bazı bileşenlerde bulunabilir. Her gözlemleme sağlayıcısı için ayrı agent ve özel entegrasyon kullanmak, sistemi belirli bir ürüne bağımlı hâle getirir.

OpenTelemetry, uygulamaların log, metric ve trace gibi telemetri sinyallerini ortak standartlarla üretmesini, taşımasını, işlemesini ve seçilen gözlemleme sistemlerine aktarmasını sağlar. OTel olarak da anılan proje bir dashboard, alarm ürünü veya kalıcı veri deposu değildir. Uygulama ile observability backend’i arasında açık ve taşınabilir bir telemetri katmanı kurar.

OpenTelemetry nedir?

OpenTelemetry; telemetri verilerini instrument etmek, üretmek, toplamak ve dışa aktarmak için kullanılan vendor-neutral, açık kaynaklı bir observability framework’üdür. Resmî dokümantasyon, projenin traces, metrics ve logs sinyallerini ortak bir ekosistem içinde ele aldığını belirtir OpenTelemetry Dokümantasyonu. Uygulama kodu, çalışma ortamı ve veri toplama katmanı arasında standart API’ler, SDK’lar, veri modeli, semantic conventions, propagation mekanizmaları ve OTLP protokolü sunar.

OpenTelemetry’nin temel amacı tek bir sağlayıcının panelini çoğaltmak değildir. Aynı uygulama telemetrisinin farklı açık kaynak veya ticari backend’lere taşınabilmesini, sağlayıcı değişikliğinde uygulama kodunun tamamen yeniden instrument edilmemesini ve çok dilli servislerin ortak bağlamla izlenmesini hedefler.

OpenTelemetry ne değildir?

OpenTelemetry’nin rolü yanlış tanımlandığında altyapıdan gerçekçi olmayan beklentiler oluşur. OTel veriyi toplar ve taşır; fakat tek başına veriyi uzun süre saklayan, dashboard oluşturan, sorgu çalıştıran veya olay yönetimi yapan nihai platform değildir. Bu görevler Prometheus uyumlu metric depoları, log arama sistemleri, trace backend’leri veya bütünleşik observability ürünleri tarafından yerine getirilir.

• OpenTelemetry tek başına bir monitoring paneli değildir.
• Kalıcı log, metric veya trace veritabanı değildir.
• Her uygulama için otomatik olarak doğru iş metric’lerini üretmez.
• Hatalı veya eksik instrumentation’ı yalnızca Collector kurarak düzeltmez.
• Backend seçimini ortadan kaldırmaz; uygulamayı backend’den daha bağımsız hâle getirir.

Bu ayrım önemlidir: OTel başarılı kurulsa bile ekip hangi kullanıcı akışını izleyeceğini, hangi telemetriyi saklayacağını ve hangi durumda alarm üreteceğini ayrıca planlamalıdır.

OpenTelemetry mimarisinin temel bileşenleri nelerdir?

OpenTelemetry mimarisi uygulama içindeki instrumentation katmanından telemetrinin gönderildiği backend’e kadar birkaç bileşenden oluşur. Her projede bütün bileşenlerin aynı şekilde kullanılması gerekmez; fakat rollerin ayrılması tasarımı anlaşılır hâle getirir.

Bu bileşenlerin birlikte tasarlanması özellikle çok servisli yazılım geliştirme projelerinde telemetri parçalanmasını azaltır. Ancak küçük bir uygulamada doğrudan OTLP exporter kullanmak yeterliyken daha büyük sistemlerde Collector katmanı genellikle daha yönetilebilir olur.

Log, metric ve trace verileri nasıl birleştirilir?

OpenTelemetry üç sinyali tek bir büyük veri türüne dönüştürmez. Logs, metrics ve traces kendi veri modellerini korur; birleştirme, ortak resource bilgileri, semantic conventions, zaman, servis adı ve trace context gibi alanlarla korelasyon kurulması anlamına gelir. Böylece metric üzerindeki hata artışından örnek bir trace’e, trace üzerindeki hatalı span’den aynı isteğin log kayıtlarına geçilebilir.

1. Ortak resource tanımlanır: Service name, environment, version, host ve deployment bilgileri bütün sinyallere eklenir.
2. Standart isimler kullanılır: HTTP, database ve messaging attribute’ları semantic conventions’a göre üretilir.
3. Trace context taşınır: Servisler aynı isteğe ait span’leri ortak trace ID altında ilişkilendirir.
4. Log korelasyonu kurulur: Aktif trace ve span kimliği uygun log kayıtlarına eklenir.
5. Metric örnekleri bağlanır: Desteklenen yapılarda exemplar, toplu metric ile belirli trace örneği arasında geçiş sağlar.
6. Collector’da zenginleştirme yapılır: Ortam, cluster veya tenant gibi güvenli bağlamlar merkezi olarak eklenebilir.
7. Backend’lerde ortak filtreleme sağlanır: Aynı service.name, deployment.environment ve sürüm alanları sinyaller arasında kullanılır.

OpenTelemetry logging spesifikasyonu, mevcut logging kütüphaneleriyle trace context’in loglara enjekte edilmesini ve logların OTLP üzerinden iletilmesini destekler OpenTelemetry Logging. Birleştirmenin değeri, bütün sinyalleri aynı dosyaya yazmaktan değil; aynı operasyonel bağlamla sorgulanabilir hâle getirmekten doğar.

Instrumentation nasıl yapılır: zero-code mu code-based mi?

OpenTelemetry iki temel instrumentation yaklaşımı sunar. Zero-code instrumentation, uygulama kaynak kodunu doğrudan değiştirmeden agent, runtime hook, monkey patching veya benzeri mekanizmalarla framework ve kütüphane çağrılarını izler. Code-based instrumentation ise uygulamanın iş mantığına özel tracer, meter ve event üretmek için API ve SDK kullanımını içerir.

Resmî instrumentation rehberi iki yaklaşımın birlikte kullanılabileceğini; zero-code çözümün uygulamanın kenarlarındaki çağrıları, code-based yaklaşımın ise uygulama içindeki daha zengin bağlamı sağlayabildiğini açıklar OpenTelemetry Instrumentation. Pratikte ağ, framework ve veritabanı katmanında otomatik; ödeme onayı, teklif hesaplama veya stok rezervasyonu gibi kritik domain işlemlerinde sınırlı manuel instrumentation daha dengeli sonuç verir.

OpenTelemetry Collector nedir?

OpenTelemetry Collector, telemetriyi vendor-neutral biçimde alan, işleyen ve dışa aktaran bağımsız bir süreçtir. Uygulamaların her backend için ayrı agent ve özel exporter yönetmesi yerine ortak bir veri toplama katmanı sunar. Resmî Collector dokümantasyonu; traces, metrics ve logs sinyallerini tek bir çalıştırılabilir yapı içinde birleştirmeyi ve birden fazla açık kaynak veya ticari hedefe göndermeyi Collector’ın ana amaçları arasında gösterir OpenTelemetry Collector.

Collector zorunlu değildir. Küçük bir uygulama telemetriyi doğrudan OTLP destekleyen backend’e gönderebilir. Ancak credential yönetimi, batching, retry, filtreleme, sampling, veri zenginleştirme veya birden fazla hedef gerektiğinde Collector uygulama kodundan operasyonel sorumlulukları ayırır.

Collector pipeline nasıl çalışır?

Collector telemetri akışını pipeline’larla yönetir. Temel pipeline receiver, isteğe bağlı processor ve exporter bileşenlerinden oluşur. Resmî mimari dokümanı Collector’ın telemetriyi bu sıralamayla aldığını, işlediğini ve dış sistemlere gönderdiğini belirtir OpenTelemetry Collector Architecture.

• Receivers: OTLP, Prometheus, Jaeger, file log veya diğer desteklenen kaynaklardan veri alır.
• Processors: Batch, memory limit, attribute düzenleme, filtreleme, sampling veya kaynak tanıma işlemlerini yapar.
• Exporters: İşlenmiş veriyi observability backend’ine, başka Collector’a veya uygun hedefe gönderir.
• Connectors: İki pipeline arasında hem exporter hem receiver gibi davranarak sinyaller arası akış kurabilir.
• Extensions: Health check, authentication ve yönetim gibi telemetri pipeline’ı dışındaki yetenekleri sağlar.

Aynı Collector içinde trace, metric ve log için ayrı pipeline’lar tanımlanabilir. Bir receiver birden fazla pipeline’da, bir exporter da birden fazla sinyal için kullanılabilir. Buna rağmen her sinyalin işlem ihtiyaçları aynı değildir; örneğin tail sampling trace pipeline’ına, metric aggregation ise metric pipeline’ına özgü olabilir.

OTLP nedir ve neden önemlidir?

OTLP, OpenTelemetry Protocol ifadesinin kısaltmasıdır. Telemetri kaynakları, Collector ve backend’ler arasında verinin nasıl kodlanacağını ve taşınacağını tanımlar. Güncel OTLP spesifikasyonunda trace, metric ve log sinyalleri stable durumdadır; protokol gRPC ve HTTP taşıma seçeneklerini destekler OTLP Specification.

OTLP’nin avantajı her backend için farklı özel format üretme ihtiyacını azaltmasıdır. Uygulamalar ortak bir exporter modeliyle Collector’a veri gönderir; hedefe özgü dönüşüm ve credential yönetimi Collector’da yapılabilir. OTLP/gRPC için varsayılan port 4317, OTLP/HTTP için yaygın varsayılan port 4318’dir; ancak gerçek dağıtımda endpoint ve güvenlik yapılandırması açıkça tanımlanmalıdır.

Protokol desteği vendor bağımsızlığını güçlendirir fakat otomatik olarak kusursuz taşınabilirlik sağlamaz. Backend’lerin attribute sınırları, sorgu dili, saklama modeli, dashboard’ları ve desteklediği sinyal özellikleri farklı olabilir. Geçiş planında yalnız veri gönderiminin değil, sorgu ve operasyon süreçlerinin de test edilmesi gerekir.

Resource ve semantic conventions neden önemlidir?

Bir trace, metric veya log kaydının hangi servise ait olduğu tutarlı biçimde bilinmiyorsa sinyalleri birleştirmek zorlaşır. Resource; telemetriyi üreten servis, süreç, host, container veya cloud kaynağını tanımlar. service.name, deployment environment ve service version gibi alanlar bütün sinyallerde aynı değer ve anlamla kullanılmalıdır.

Semantic conventions ise HTTP yöntemi, veritabanı sistemi, RPC servisi, mesajlaşma hedefi ve hata bilgisi gibi alanlar için ortak isim ve anlam kuralları sağlar. Farklı ekipler aynı kavrama farklı attribute adları verdiğinde dashboard, filtre ve alarm kuralları parçalanır. Standartlar, çok dilli servislerin aynı operasyon modelinde sorgulanabilmesini kolaylaştırır.

OpenTelemetry’nin gerçek taşınabilirliği yalnız OTLP ile veri göndermekten değil; resource alanları ve semantic conventions sayesinde verinin farklı servislerde aynı anlamı taşımasından oluşur.

Collector doğrudan mı, agent mı, gateway mi kullanılmalı?

Collector tek bir dağıtım biçimine bağlı değildir. Uygulamanın yanında agent olarak, cluster veya ortam başına merkezi gateway olarak ya da iki katman birlikte çalışacak şekilde konumlandırılabilir. Seçim; ağ topolojisi, veri hacmi, güvenlik sınırları ve yönetim sorumluluğuna göre yapılmalıdır.

Collector dağıtım desenleri resmî dokümantasyonda agent ve gateway dâhil farklı kullanım biçimleriyle ele alınır OpenTelemetry Collector Deployment. Küçük sistemde en sade yapı seçilmeli; merkezi katman ancak sağladığı politika ve operasyon faydası ek karmaşıklığı haklı çıkarıyorsa eklenmelidir.

OpenTelemetry vendor lock-in’i tamamen ortadan kaldırır mı?

OpenTelemetry uygulama kodu ile backend arasındaki doğrudan bağımlılığı önemli ölçüde azaltabilir. Instrumentation, context propagation ve OTLP export ortak standartlara dayandığında telemetri farklı hedeflere yönlendirilebilir. Collector aynı veriyi geçiş döneminde iki backend’e fan-out ederek karşılaştırma yapmayı da mümkün kılar.

Buna rağmen tam bağımsızlık yalnız veri taşıma katmanıyla sağlanmaz. Dashboard’lar, sorgular, alarm kuralları, saklama politikaları, tail sampling özellikleri ve maliyet modeli backend’e özgü olabilir. Ayrıca özel exporter veya sağlayıcıya özgü attribute kullanımı taşınabilirliği azaltabilir. OTel, lock-in’i sıfırlayan bir düğme değil; bağımlılığın uygulama instrumentation katmanına yayılmasını önleyen mimari sınırdır.

Telemetri maliyeti ve performansı nasıl kontrol edilir?

Her log satırını, bütün trace’leri ve sınırsız metric label kombinasyonunu saklamak sürdürülebilir değildir. Yüksek cardinality, özellikle kullanıcı ID, tam URL, sorgu metni veya rastgele değerlerin metric attribute’u yapılmasıyla hızla büyür. Güncel OpenTelemetry Metrics dokümantasyonu, SDK’ların metric stream başına izlenen benzersiz attribute kombinasyonlarına cardinality sınırı uygulayabildiğini belirtir OpenTelemetry Metrics.

• Metric attribute’larında sınırlı ve öngörülebilir değer kümeleri kullanın.
• Trace’lerde hatalı ve yavaş işlemleri koruyan sampling politikası belirleyin.
• Collector’da batch processor ile küçük export isteklerini birleştirin.
• Memory limiter ve queue ayarlarını Collector kapasitesine göre yapılandırın.
• Debug loglarını sürekli production seviyesinde tutmayın.
• Farklı veri sınıfları için ayrı saklama süreleri belirleyin.
• Telemetri kaybı, export hatası ve Collector backpressure durumlarını ayrıca izleyin.

Observability altyapısı uygulamayı yavaşlatmamalı ve arıza sırasında yeni bir darboğaz oluşturmamalıdır. SDK ve Collector kaynak kullanımı yük testleriyle ölçülmeli; exporter kesintisinin uygulama isteğini engellemediği doğrulanmalıdır.

Güvenlik ve kişisel veri açısından nelere dikkat edilmeli?

Telemetri verisi URL, kullanıcı girdisi, hata mesajı, database statement veya header içeriği nedeniyle hassas bilgi taşıyabilir. Parola, access token, kart bilgisi, oturum cookie’si ve gereksiz kişisel veri log, span attribute veya baggage alanlarına yazılmamalıdır. Collector processor’ları merkezi maskeleme ve silme için kullanılabilir; ancak en güvenli yaklaşım hassas veriyi kaynağında üretmemektir.

OTLP endpoint’leri TLS ve uygun authentication ile korunmalı, Collector yönetim portları internete açık bırakılmamalı ve backend credential’ları uygulama koduna gömülmemelidir. Resource veya attribute olarak tenant bilgisi kullanıldığında yetki ayrımı veri görüntüleme katmanında da korunmalıdır. Telemetri erişimi, production veritabanı erişimi kadar dikkatli yönetilmelidir.

OpenTelemetry kurulumunda sık yapılan hatalar

• OpenTelemetry’yi backend sanmak: Veri depolama, sorgu ve dashboard ihtiyaçları plansız kalır.
• service.name standardı oluşturmamak: Aynı servis farklı adlarla görünür ve sinyal korelasyonu bozulur.
• Yalnız otomatik instrumentation’a güvenmek: Teknik çağrılar görünürken kritik iş adımları ölçülmez.
• Collector’a her veriyi kontrolsüz göndermek: Cardinality, maliyet ve hassas veri riski büyür.
• Context propagation’ı test etmemek: Servisler trace üretir fakat uçtan uca ilişki kurulamaz.
• Processor sırasını önemsememek: Filtreleme, zenginleştirme ve sampling beklenmeyen veri üzerinde çalışabilir.
• Collector’ı tek hata noktası yapmak: Kapasite, queue, retry ve yüksek erişilebilirlik planlanmaz.
• Backend’e özgü alanları her yere yaymak: Vendor değişikliğinde uygulama ve dashboard dönüşümü zorlaşır.

Yeni servis, SDK sürümü veya backend değişikliği telemetri pipeline’ını etkileyebileceği için yapılandırmalar sürüm kontrolünde tutulmalı ve düzenli doğrulama yazılım bakım sürecinin bir parçası olmalıdır.

OpenTelemetry uygulama kontrol listesi

1. Kritik kullanıcı akışlarını ve cevaplanması gereken operasyon sorularını belirleyin.
2. Log, metric ve trace sinyalleri için kapsam ile saklama hedeflerini ayırın.
3. Service name, environment, version ve ortak resource standardını oluşturun.
4. Zero-code instrumentation ile elde edilecek temel görünürlüğü test edin.
5. Kritik domain işlemleri için sınırlı code-based instrumentation planlayın.
6. Context propagation’ın HTTP, RPC ve mesaj kuyruğu sınırlarında devam ettiğini doğrulayın.
7. Doğrudan export, agent veya gateway Collector modelini kapasiteye göre seçin.
8. Receiver, processor ve exporter pipeline’larını sürüm kontrollü yapılandırın.
9. Cardinality, sampling, batch, queue ve memory limit politikalarını tanımlayın.
10. Hassas veri filtreleri, TLS, authentication ve erişim yetkilerini test edin.
11. Trace–log korelasyonu ve metric’ten trace örneğine geçişi backend’de doğrulayın.
12. Collector ve exporter sağlığını ayrı monitoring göstergeleriyle izleyin.

Kurulum, yalnız bir SDK ekleme görevi olarak görülmemelidir. Telemetri adlandırması, güvenlik, maliyet ve operasyon sahipliği birlikte tasarlandığında OpenTelemetry uzun vadeli değer üretir. Çok sayıda entegrasyon ve servis içeren projelerde bu tasarım özel yazılım mimarisinin başlangıç kararları arasında yer almalıdır.

Sonuç: Telemetri üretimini backend seçiminden ayırın

OpenTelemetry; uygulama API ve SDK’larından başlayan, context propagation ve semantic conventions ile veriyi anlamlı hâle getiren, OTLP üzerinden Collector’a taşıyan açık bir telemetri ekosistemidir. Collector receiver, processor ve exporter pipeline’larıyla log, metric ve trace verilerini işler; seçilen bir veya daha fazla backend’e yönlendirir.

Başarılı uygulamanın ölçütü en fazla veriyi toplamak değildir. Aynı servis ve işlem bağlamında sinyaller arasında geçiş yapabilmek, kritik sorunları teşhis edecek kadar veri üretmek ve bunu maliyet ile güvenlik sınırları içinde sürdürebilmektir. OpenTelemetry bu hedef için standart altyapıyı sağlar; doğru kapsam ve operasyon tasarımı ise projeye aittir.