OpenTelemetry çalıştırmayı başardım, peki neden bu kadar karmaşıktı?

• OpenTelemetry (OTel), bir gözlemlenebilirlik çerçevesi ve araç setidir
• Mevcut araçlar arasında Prometheus (metrikler), Logstash (loglar), OpenTracing (dağıtık izleme) bulunur
• OTel; metrikler, loglar ve izler olmak üzere üç sinyali standartlaştırır ve OpenTelemetry Protocol (OTLP), OpenTelemetry Collector ve çeşitli dil SDK'leri sunar
  • Açık kaynak, üreticiden bağımsız, dilden bağımsız, dağıtık, zero-code gibi tüm popüler terimleri karşılar

OTel'in sorunları

• Loglar ve metrikler mevcut araçlara benzediği için kolayca entegre edilebilir. Yalnızca yapılandırma ekleyerek OTel'e geçiş mümkün
• İzleme uygulamasının zorluğu
  • Context Propagation: Dağıtık sistemler arasında istek bilgisini iletmek için gereklidir
    • İstek birimi Trace ve Span olarak ayrılır
    • Örnek: "Satın al" düğmesine tıklama → Frontend → Backend → Payment/Shipping servisleri arasındaki ilişki Span olarak ifade edilir
  • OTel'in destek yaklaşımı:
    • Çeşitli Context Propagation standartları sunar (ör. b3, W3C Trace Context)
  • OTel birden çok standardı desteklemek zorundadır
    • Mevcut OpenTracing'den OTel'e geçerken beklenmedik çakışmalar ortaya çıkar
    • Lightbend Telemetry, OpenTelemetry loglarını ve metriklerini destekler ancak izlemeyi desteklemez.

API'ler arası çakışma sorunu

Spring ve Akka entegrasyon sorunu

• Spring: Uygulama bootstrap süreci ve yapılandırma yönetimi
• Akka: Event sourcing, zamanlama ve clustering gibi kullanım alanları
• Sorun:
  • OTel kullanıldığında Spring ve Akka'nın izleme API'leri birbiriyle etkileşime girmiyor
  • Aynı Trace ID'yi paylaşamıyorlar → hatalı izleme sonuçları

Çözüm: OpenTracing Shim

• OTel Tracer'ı OpenTracing Tracer'a dönüştüren araç
• Sorun:
  • Akka'nın Lightbend Telemetry'si OpenTracing implementasyonuna uyum sağlayamıyor
  • Jaeger ve OTel farklı SpanContext'ler istediği için çakışma oluşuyor

Çözüm süreci

OTel ve OpenTracing'in manuel entegrasyonu

• OTel Context'ini manuel olarak Jaeger SpanContext'ine dönüştürme:
  • OTel Context'i Java Map'e ekleme
  • İlgili map'i Jaeger SpanContext'e extract edip manuel olarak ayarlama
• Kod örneği:

  var otelContext = new HashMap<>();  
  GlobalOpenTelemetry.get().getPropagators().getTextMapPropagator()  
      .inject(Context.current(), otelContext, (carrier, key, value) -> carrier.put(key, value));  
  var openTracingContext = new TextMapCodec(false).extract(new TextMapAdapter(otelContext));  
  GlobalExtendedTracer.get().local().activateContext(openTracingContext);  
  

• Sonuç:
  • Spring ile Akka arasındaki izleme verileri başarıyla birleştirildi
  • HTTP sınırları arasındaki Trace düzgün şekilde bağlandı

Sonuç

Karmaşıklığın nedeni

• İki farklı izleme kütüphanesini entegre etme girişimi
• OpenTelemetry'nin sunduğu standartlar yararlı olsa da mevcut araçlarla çakışma ihtimali var

OpenTelemetry'nin değeri

• OpenTelemetry, gözlemlenebilirliğin standartlaşmasında önemli bir rol oynar
• Karmaşık ama güçlü bir açık kaynak proje

Gelecekteki görevler

• Akka'nın Trace Context'inin thread'ler arasında doğru şekilde iletilip iletilmediğinin doğrulanması gerekiyor
• Projeyi iyileştirmek için ek testler ve geri bildirim şart

[GN⁺]

Hacker News yorumu

• Otel'i öğrenip port ederken kendimi Java dünyasına geri dönmüş gibi hissettim. Kodu gezerken EnterpriseFizzBuzz hissi veriyordu ve keşfedilebilirlik diye bir şey yoktu. NodeJS'te StatsD'ye kıyasla yaklaşık 4 kat CPU kullanımı vardı; bunu kendi toplulaştırmamızla azalttık. OTEL, çekirdek başına tek süreç kullanan dillere düşmanca davranıyor. Prometheus kullanmak daha iyi.

• Otel, farklı gözlemlenebilirlik sağlayıcılarının sunduğu SDK'ler, ajanlar ve API'ler nedeniyle karmaşık gelebilir. OpenTelemetry fiilen standart haline geldi ve Grafana'nın OpenTelemetry'yi benimsemesini takdir ediyorum. Datadog'un fiyatlandırması, orta ölçekli şirketlerle büyük şirketler arasındaki noktada kontrolden çıktı. Dokümantasyon daha iyi olabilir ve programlama diline göre onboarding belgeleri farklılık gösteriyor. NodeJS/Typescript yığını için OpenTelemetry'ye hızlı başlamayı sağlayan bir paket ve örnek bir Grafana stack'i hazırladım.

• Yerel geliştirmede log, trace ve metric desteği istiyordum ama bir sürü Docker imajı çalıştırmak istemedim. .NET ekibi .NET Aspire'ı çıkardı ve bununla yerel geliştirme stack'inde her şeyi kolayca görselleştirebiliyorsunuz. k8s'e deploy ederken OTEL endpoint'ini DataDog ajanına bağladığınızda her şey çalışıyor. DataDog'un özel trace kütüphaneleri ve SDK'lerinden kaçınıp OTEL kullanıyoruz.

• OpenTelemetry, ihtiyaca göre karmaşık olabilir. Bizim ekip onu basit kullanıyor ve manuel enstrümantasyonla neyi gözlemleyeceğimizi dikkatle seçiyoruz. İki backend kullanıyoruz; biri ucuz bir üçüncü taraf hizmet, diğeri ise yerel geliştirme için bir Jaeger kurulumu.

• Python'da Otel kullanırken Logfire istemcisini tercih etmek iyi olur. Pydantic ekibinin yaptığı istemci, resmi Otel kütüphanesinden çok daha iyi ve daha basit.

• Birçok web framework'ü enstrümantasyonun büyük kısmını otomatik hallediyor. opentelemetry-js kullanıp Signoz benzeri bir şeyi self-host ederseniz, bir saatten kısa sürede çok fazla veri elde edebilirsiniz.

• OpenTelemetry'nin benimsenmesini kolaylaştırmak için tek komutla çalıştırılabilen bir açık kaynak proje başlattım.

• Python'da standart stack'i kullanırsanız yalnızca birkaç import ile her şeyi otomatik olarak izleyebilirsiniz. Otel karmaşık, çünkü Otel uyumlu yazılım satan şirketler için tasarlanmış.

• OpenTelemetry trace ile başladı, ancak metric ve log işlerini uzman çözümlere bırakmak daha iyi. Her şeyi tek bir çatı altında toplama çabası, "sızdıran soyutlama" problemi gibi hissettiriyor. SQL veritabanları da aynı anda her şeyi yapabilir, ama bu yapmaları gerektiği anlamına gelmez.