Pendahuluan

Distributed Tracing adalah salah satu masalah yang ditemukan ketika kita berhadapan dengan arsitektur microservice.

Apa latar belakangnya ?

Arsitektur microservice memang menjadi salah satu arsitektur laris manis belakangan ini.

Ide sederhana untuk memecah aplikasi menjadi kelompok-kelompok fungsi terpisah dalam aplikasi-aplikasi kecil.

Komunikasi antara aplikasi-aplikasi kecil (microservice) ini kemudian dilakukan menggunakan protokol standar seperti REST, RPC, dll.

Semua berjalan dengan baik dan lancar, semua orang senang.

Development menjadi lebih cepat, karena modular, tim development bisa berkembang dari 1, 2, 3, bahkan sampai ribuan orang yang dibagi menjadi tim-tim kecil.

Tim bisnis mukanya sumringah ketika produk mereka bisa lauching ke pasar dengan MVP (Most Viable Product) nya.

Tim development (mungkin) bisa memasang tampang senang juga ketika aplikasi sekarang merupakan kumpulan pemanggilan API-API dari microservices yang ada.

Tidak perlu lagi me-maintain code-code yang duplikat di banyak aplikasi.

Tidak perlu lagi membuat ulang dari awal.

Semua API sekarang bisa di share antara banyak aplikasi. Begitupun antara microservice bisa saling panggil-panggilan.

Begitu romantisnya.

Tapi apakah romantisme ini cukup ?

Tentu saja tidak Ferguso.


Lalu..mesti seperti apakah Esmeralda ??

Panggil memanggil antar microservice ini bukan seperti naskah percakapan sinetron yang dibuat untuk hiburan semata.

Panggil memanggil antar microservice ini butuh di monitor/diawasi agar kalau terjadi sesuatu di dalam aplikasi mudah untuk dilacak.

Di aplikasi monolitik, monitoring ini lebih mudah dilakukan karena semua code berada dan dijalankan di lokasi server, memori, cpu yang sama, jadi kalau terjadi kesalahan, akan mudah untuk melihat log error atau stack tracenya, sebelum dianalisa dan ditentukan aksi berikutnya.

Sementara di arsitektur microservice, yang akan kita temui adalah code yang berada dan berjalan di server, memori, cpu yang berbeda.

Tidak hanya itu, bahasa pemrograman bisa jadi berbeda pula untuk tiap microservice, cara menampilkan log nya juga berbeda di tiap microservice.

Dan sekarang dipertajam lagi dengan desain aplikasi berbasiskan serverless, yang kadang disebut dengan nanoservices.

Sementara itu kebutuhan untuk bisa mengawasi dan menemukan dimana letak error ketika terjadi sebuah kesalahan sistem tetap ada dan tetap dibutuhkan untuk melacak lokasi kesalahan atau untuk mengumpulkan data tentang perilaku aplikasi.

Inilah yang dinamakan dengan masalah Distributed Tracing System

Sejarahnya dan solusi

Oke, ada masalah tentunya ada solusi juga kan ??

Iya, tentu saja, sebuah hal yang wajar di kehidupan manusia ini.

Google mengusulkan solusi dari masalah Distributed Tracing System diatas pada bulan April 2010.

Mereka menerbitkan paper mengenai "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure", yaitu solusi dari mereka mengenai mengelola log dan trace dari aplikasi yang terdistribusi.

Semenjak itu bermunculan pula lah paper lain dan ide yang semirip.

Idenya adalah adanya sebuah sistem yang memungkinkan komponen service / software yang banyak dan berbeda untuk melaporkan apa yang mereka lakukan beserta context/ruang lingkupnya.

Data-data ini harus dikirimkan dan dikumpulkan dalam sebuah repository pusat yang akan membuat sebuah gambaran lengkap mengenai sebuah rentetan request data ke banyak service.

Rentetan dari request data ini dibentuk dengan skema tree/pohon yang menggambarkan siapa memanggil siapa dan urutannya.

Di konsep ini, kemudian dikenal istilah :

  • span
  • trace
  • trace context
  • trace collectors

Apa contoh Distributed Tracing ?

Banyak sekali contoh library dari Distributed Tracing yang ada sekarang.

Terkadang memang merupakan library tersendiri, dan terkadang juga sudah termasuk didalam framework, misalnya :

  • Zipkin
  • OpenCensus
  • OpenTracing
  • OpenTelemetry
  • Jaeger
  • Promotheus
  • Micrometer
  • LightStep
  • Instana
  • Apache SkyWalking
  • InspectIT
  • StageMonitor
  • Datadog
  • Wavefront
  • Elastic APM
  • Dropwizard Metrics
  • AWS X-Ray
  • Istio
  • New Relic
  • AppDynamic