OpenTelemetry berhasil dijalankan, tapi kenapa serumit ini?

• OpenTelemetry (OTel) adalah framework observability dan kumpulan alat
• Alat yang sudah ada sebelumnya mencakup Prometheus (metrik), Logstash (log), dan OpenTracing (tracing terdistribusi)
• OTel menstandarkan tiga sinyal: metrik, log, dan tracing, serta menyediakan OpenTelemetry Protocol (OTLP), OpenTelemetry Collector, dan SDK untuk berbagai bahasa
  • Memenuhi semua kata kunci populer: open source, vendor-independent, language-independent, distributed, zero-code, dan lainnya

Masalah pada OTel

• Log dan metrik mirip dengan alat yang sudah ada sehingga mudah diintegrasikan. Hanya dengan menambahkan konfigurasi, migrasi ke OTel dimungkinkan
• Sulitnya implementasi tracing
  • Context Propagation: diperlukan untuk meneruskan informasi permintaan di antara sistem terdistribusi
    • Unit permintaan dibagi menjadi Trace dan Span
    • Contoh: klik tombol "Beli" → Frontend → Backend → hubungan antar layanan Payment/Shipping direpresentasikan sebagai Span
  • Cara dukungan OTel:
    • Menyediakan berbagai standar Context Propagation (misalnya b3, W3C Trace Context)
  • OTel harus mendukung banyak standar
    • Saat beralih dari OpenTracing lama ke OTel, muncul konflik tak terduga
    • Lightbend Telemetry mendukung log dan metrik OpenTelemetry, tetapi tidak mendukung tracing.

Masalah bentrokan antar API

Masalah integrasi Spring dan Akka

• Spring: untuk bootstrap aplikasi dan pengelolaan konfigurasi
• Akka: digunakan untuk event sourcing, scheduling, clustering, dan lainnya
• Masalah:
  • Saat menggunakan OTel, API tracing milik Spring dan Akka tidak saling berinteraksi
  • Tidak dapat berbagi Trace ID yang sama → hasil tracing menjadi keliru

Solusi: OpenTracing Shim

• Alat untuk mengonversi OTel Tracer menjadi OpenTracing Tracer
• Masalah:
  • Lightbend Telemetry milik Akka tidak sepenuhnya sesuai dengan implementasi OpenTracing
  • Jaeger dan OTel memerlukan SpanContext yang berbeda sehingga terjadi bentrokan

Proses penyelesaian

Integrasi manual OTel dan OpenTracing

• Mengonversi OTel Context secara manual menjadi Jaeger SpanContext:
  • Menyisipkan konteks OTel ke dalam Java Map
  • Mengekstrak map tersebut ke Jaeger SpanContext lalu mengaturnya secara manual
• Contoh kode:

  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);  
  

• Hasil:
  • Integrasi data tracing antara Spring dan Akka berhasil
  • Trace antar batas HTTP terhubung dengan benar

Kesimpulan

Penyebab kerumitan

• Upaya mengintegrasikan dua library tracing yang berbeda
• Standar yang disediakan OpenTelemetry berguna, tetapi tetap ada kemungkinan bentrok dengan alat yang sudah ada

Nilai OpenTelemetry

• OpenTelemetry memainkan peran penting dalam standarisasi observability
• Proyek open source yang kompleks tetapi kuat

Tantangan ke depan

• Perlu memastikan bahwa Trace Context milik Akka diteruskan dengan benar antar thread
• Pengujian tambahan dan umpan balik sangat penting untuk perbaikan proyek

[GN⁺]

Opini Hacker News

• Saat mempelajari dan melakukan porting Otel, rasanya seperti kembali ke dunia Java. Menjelajahi kodenya terasa seperti EnterpriseFizzBuzz dan sama sekali tidak mudah ditemukan. Di NodeJS, penggunaan CPU sekitar 4 kali lebih tinggi dibanding StatsD, dan ini dikurangi lewat agregasi internal. OTEL tidak ramah terhadap bahasa yang menggunakan satu proses per inti. Lebih baik memakai Prometheus.

• Otel bisa terasa rumit karena adanya SDK, agen, dan API dari berbagai penyedia observabilitas. OpenTelemetry akhirnya dipakai sebagai standar, dan patut diapresiasi bahwa Grafana mengadopsi OpenTelemetry. Harga Datadog menjadi tak terkendali di antara perusahaan menengah dan perusahaan besar. Dokumentasinya bisa dibuat lebih baik, dan dokumen onboarding berbeda menurut bahasa pemrograman. Saya membuat paket untuk memulai OpenTelemetry dengan cepat di stack NodeJS/Typescript beserta contoh stack Grafana.

• Dalam pengembangan lokal saya ingin dukungan log, trace, dan metrik, tetapi tidak ingin menjalankan banyak image Docker. Tim .NET merilis .NET Aspire, dan di stack pengembangan lokal semua itu bisa divisualisasikan dengan mudah. Saat deploy ke k8s, jika endpoint OTEL dihubungkan ke agen DataDog, semuanya bekerja. Saya menghindari library tracing dan SDK khusus milik DataDog dan memakai OTEL.

• OpenTelemetry bisa menjadi rumit sesuai kebutuhan. Tim kami memakainya secara sederhana, menggunakan instrumentasi manual untuk memilih dengan cermat apa yang ingin diamati. Kami memakai dua backend: satu layanan pihak ketiga yang murah, dan satu instalasi Jaeger untuk pengembangan lokal.

• Saat menggunakan Otel di Python, lebih baik memakai klien Logfire. Klien buatan tim Pydantic itu jauh lebih baik dan lebih sederhana daripada library Otel resmi.

• Banyak web framework menangani sebagian besar instrumentasi secara otomatis. Dengan memakai opentelemetry-js dan melakukan self-host sesuatu seperti Signoz, Anda bisa mendapatkan banyak data dalam waktu kurang dari satu jam.

• Saya memulai proyek open source yang bisa dijalankan dengan satu perintah untuk mempermudah adopsi OpenTelemetry.

• Di Python, jika memakai stack standar, semuanya bisa dilacak otomatis hanya dengan beberapa import. Otel rumit karena dirancang untuk perusahaan-perusahaan yang menjual software yang kompatibel dengan Otel.

• OpenTelemetry berawal dari tracing, tetapi untuk metrik dan log lebih baik diserahkan ke solusi khusus. Upaya menaruh semuanya di bawah satu payung terasa seperti masalah "abstraksi bocor". Database SQL juga bisa melakukan banyak hal sekaligus, tetapi bukan berarti itu harus dilakukan.