Distributed Tracing: Pengertian, Cara Kerja, Arsitektur, Komponen, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234

Dipublikasikan:
Distributed Tracing: Pengertian, Cara Kerja, Arsitektur, Komponen, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234

Distributed Tracing: Pengertian, Cara Kerja, Arsitektur, Komponen, Manfaat, Kelebihan, Kekurangan, dan Implementasinya

Ilustrasi Distributed Tracing untuk melacak perjalanan request antar-service pada arsitektur microservices dan Service Mesh.

Dalam arsitektur aplikasi modern, satu request pengguna jarang hanya diproses oleh satu service. Pada sistem berbasis microservices, sebuah request dapat melewati API Gateway, frontend service, backend service, authentication service, database service, hingga service lainnya sebelum menghasilkan response.

Semakin banyak service yang terlibat, semakin sulit mengetahui bagian mana yang menyebabkan error atau latency. Monitoring menggunakan metrics dapat menunjukkan bahwa terjadi peningkatan latency, sedangkan logs dapat memberikan informasi mengenai error tertentu. Namun, administrator Dewa234 juga membutuhkan cara untuk mengikuti perjalanan satu request dari awal hingga akhir.

Solusi untuk kebutuhan tersebut adalah Distributed Tracing. Teknologi ini memungkinkan perjalanan request dilacak melewati berbagai service dalam sistem terdistribusi sehingga administrator dapat mengetahui hubungan antar-service, waktu pemrosesan, serta bagian yang menjadi bottleneck.

Dalam ekosistem Istio, distributed tracing terintegrasi dengan Envoy dan dapat dikonfigurasi menggunakan Telemetry API. Istio juga mendukung beberapa tracing provider dan menyediakan pengaturan sampling serta custom tags. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/))

Apa Itu Distributed Tracing?

Distributed Tracing adalah metode observability yang digunakan untuk melacak perjalanan sebuah request ketika melewati beberapa service dalam sistem terdistribusi.

Distributed tracing sangat berguna pada arsitektur microservices karena setiap service dapat berjalan secara independen dan berada pada container, Pod, Node, atau bahkan cluster yang berbeda.

Dengan distributed tracing, sebuah request dapat direpresentasikan sebagai satu trace yang terdiri dari beberapa span. Setiap span menggambarkan suatu operasi atau bagian perjalanan request pada service tertentu.

Mengapa Distributed Tracing Penting?

Pada aplikasi monolithic, proses debugging relatif lebih sederhana karena sebagian besar fungsi aplikasi berada dalam satu unit. Pada microservices, satu request dapat berpindah dari satu service ke service lainnya.

Jika response menjadi lambat, administrator perlu mengetahui apakah masalah berasal dari API Gateway, service utama, database, external API, atau dependency lainnya.

Distributed tracing membantu menjawab pertanyaan tersebut dengan memperlihatkan perjalanan request secara lebih detail.

  • Mengetahui perjalanan request antar-service.
  • Mengidentifikasi service yang mengalami latency.
  • Mendeteksi bottleneck.
  • Membantu menemukan sumber error.
  • Menganalisis dependency antar-service.
  • Mempermudah troubleshooting microservices.
  • Membantu menganalisis performa aplikasi.
  • Memahami komunikasi dalam Service Mesh.

Konsep Dasar Distributed Tracing

Ada beberapa istilah penting yang perlu dipahami sebelum menggunakan distributed tracing.

Istilah Pengertian
Trace Representasi keseluruhan perjalanan sebuah request.
Span Bagian atau operasi tertentu dari sebuah trace.
Trace ID Identitas yang digunakan untuk menghubungkan span dalam satu perjalanan request.
Span ID Identitas unik untuk suatu span.
Parent Span Span yang menjadi induk dari span lainnya.
Child Span Span yang dibuat sebagai bagian dari operasi parent span.
Sampling Mekanisme menentukan request mana yang akan direkam sebagai trace.
Trace Context Informasi yang diteruskan antar-service agar span dapat dikaitkan dalam satu trace.

Apa Itu Trace?

Trace merupakan representasi lengkap perjalanan sebuah request dari awal hingga akhir.

Misalnya pengguna membuka halaman produk. Request tersebut melewati API Gateway, Product Service, Review Service, dan Database Service.

Seluruh perjalanan tersebut dapat digabung menjadi satu trace. 


Trace ID: abc123

User
  │
  ▼
API Gateway
  │
  ▼
Product Service
  │
  ├────► Review Service
  │
  └────► Database
  │
  ▼
Response

Apa Itu Span?

Span adalah bagian individual dari sebuah trace. Setiap span menggambarkan operasi tertentu yang dilakukan oleh service.

Sebuah trace dapat memiliki banyak span. 


Trace
│
├── Span: API Gateway
│
├── Span: Product Service
│
├── Span: Review Service
│
└── Span: Database

Dengan struktur tersebut, administrator dapat mengetahui berapa lama setiap operasi berlangsung.

Perbedaan Trace dan Span

Aspek Trace Span
Cakupan Keseluruhan perjalanan request. Satu operasi atau bagian request.
Jumlah Satu request dapat memiliki satu trace. Satu trace dapat memiliki banyak span.
Fungsi Melihat alur keseluruhan. Menganalisis bagian tertentu.
Contoh Request pengguna dari gateway hingga database. Query database selama 80 ms.

Bagaimana Cara Kerja Distributed Tracing?

Distributed tracing bekerja dengan membuat dan meneruskan konteks tracing ketika request berpindah dari satu service ke service lainnya.

  1. Client mengirim request.
  2. Request masuk ke service pertama.
  3. Proxy atau aplikasi membuat atau menerima trace context.
  4. Service memproses request dan membuat span.
  5. Trace context diteruskan ke service berikutnya.
  6. Service berikutnya membuat child span yang berhubungan dengan trace tersebut.
  7. Proses berlanjut hingga request selesai.
  8. Span dikirim ke tracing backend.
  9. Tracing backend menggabungkan span menjadi satu trace.
  10. Administrator melihat trace melalui dashboard observability.

Ilustrasi Cara Kerja Distributed Tracing


                    Client
                       │
                       ▼
                API Gateway
                       │
                  Trace ID: A
                       │
                       ▼
                Product Service
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
       Review Service       Database Service
             │                   │
             └─────────┬─────────┘
                       ▼
                    Response

Trace ID: A
   │
   ├── Span 1: API Gateway
   ├── Span 2: Product Service
   ├── Span 3: Review Service
   └── Span 4: Database Service

Arsitektur Distributed Tracing


+--------------------------------------------------+
|                Client Application                |
+--------------------------------------------------+
                       │
                       ▼
+--------------------------------------------------+
|                  API Gateway                    |
|                 Envoy Proxy                     |
+--------------------------------------------------+
                       │
                       ▼
+--------------------------------------------------+
|                 Service A                       |
|                 Envoy Proxy                     |
+--------------------------------------------------+
                       │
              ┌────────┴────────┐
              ▼                 ▼
+---------------------+ +-------------------------+
|     Service B       | |       Service C         |
|     Envoy Proxy     | |       Envoy Proxy       |
+---------------------+ +-------------------------+
              │                 │
              └────────┬────────┘
                       ▼
                Trace Collector
                       │
                       ▼
                Tracing Backend
                       │
                       ▼
                 Observability
                   Dashboard

Komponen Distributed Tracing

Komponen Fungsi
Client Mengawali request.
Service Memproses request dan menjalankan business logic.
Envoy Proxy Menghasilkan dan mengirim data tracing pada lingkungan Istio.
Trace Context Membawa informasi tracing antar-service.
Trace Mewakili keseluruhan perjalanan request.
Span Mewakili operasi tertentu dalam trace.
Collector Menerima dan meneruskan data trace.
Tracing Backend Menyimpan dan memproses trace.
Dashboard Menampilkan trace untuk analisis.

Distributed Tracing pada Istio

Istio menggunakan kemampuan distributed tracing dari Envoy Proxy. Karena traffic aplikasi melewati proxy, Istio dapat menyediakan integrasi tracing tanpa mengharuskan setiap aplikasi membangun seluruh mekanisme observability dari awal.

Istio menyediakan Telemetry API untuk mengatur tracing, termasuk provider, sampling rate, dan custom tags. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/))

Hubungan Telemetry Istio dengan Distributed Tracing

Artikel sebelumnya membahas Telemetry Istio secara keseluruhan. Telemetry mencakup metrics, access logs, dan tracing.

Distributed tracing merupakan pembahasan yang lebih spesifik mengenai bagian tracing tersebut. 


Telemetry Istio
      │
      ├── Metrics
      │
      ├── Access Logs
      │
      └── Distributed Tracing
                 │
                 ├── Trace
                 ├── Span
                 ├── Sampling
                 └── Trace Context

Trace Context

Agar beberapa span dapat digabung menjadi satu trace, informasi tracing perlu diteruskan ketika request berpindah antar-service.

Istio menjelaskan bahwa aplikasi perlu meneruskan header trace context dari request masuk ke request keluar yang dibuat oleh aplikasi. Contoh header yang dapat terlibat antara lain traceparent, tracestate, serta header tracing lain yang sesuai dengan backend yang digunakan. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/))

Mengapa Trace Context Harus Diteruskan?

Bayangkan Service A menerima request dengan Trace ID tertentu kemudian memanggil Service B. Jika informasi tracing tidak diteruskan, backend tracing dapat kesulitan menghubungkan span Service B dengan trace yang sama. 


Tanpa Propagation:

Service A
Trace A

Service B
Trace B

Service C
Trace C


Dengan Propagation:

Service A
    │
    │ Trace A
    ▼
Service B
    │
    │ Trace A
    ▼
Service C

Satu Trace
├── Span A
├── Span B
└── Span C

Trace ID

Trace ID digunakan untuk mengidentifikasi satu perjalanan request. Span yang berada dalam perjalanan request yang sama akan memiliki hubungan dengan Trace ID tersebut.

Dengan Trace ID, administrator dapat mencari satu request tertentu dan melihat service apa saja yang terlibat.

Span ID

Span ID digunakan untuk mengidentifikasi operasi tertentu dalam trace. Satu trace dapat memiliki banyak Span ID. 


Trace ID: 123456

├── Span ID: 001
│     └── API Gateway
│
├── Span ID: 002
│     └── Product Service
│
├── Span ID: 003
│     └── Database
│
└── Span ID: 004
      └── Review Service

Parent Span dan Child Span

Hubungan parent-child membantu menunjukkan struktur perjalanan request. 


Parent Span
API Gateway
      │
      ├── Child Span
      │     Product Service
      │
      └── Child Span
            Review Service
                  │
                  └── Child Span
                        Database

Dengan struktur tersebut, administrator dapat melihat service mana yang memanggil service lainnya.

Distributed Tracing dan Microservices

Distributed tracing sangat relevan dengan microservices karena aplikasi terdiri dari banyak service yang saling berkomunikasi.

Contohnya pada sistem e-commerce:

  • API Gateway.
  • User Service.
  • Product Service.
  • Cart Service.
  • Payment Service.
  • Order Service.
  • Inventory Service.
  • Notification Service.

Satu transaksi pembelian dapat melibatkan sebagian besar service tersebut. Distributed tracing membantu memperlihatkan hubungan dan durasi setiap proses.

Contoh Alur Distributed Tracing E-Commerce


User
 │
 ▼
API Gateway
 │
 ▼
Order Service
 │
 ├────► Product Service
 │
 ├────► Inventory Service
 │
 ├────► Payment Service
 │
 └────► Notification Service
                 │
                 ▼
               Email

Trace:
T1
│
├── Gateway      10 ms
├── Order        25 ms
├── Product      15 ms
├── Inventory    20 ms
├── Payment      120 ms
└── Notification 30 ms

Total ≈ 220 ms

Dari contoh tersebut, Payment Service terlihat memiliki waktu pemrosesan paling tinggi. Administrator dapat melakukan investigasi lebih lanjut pada service tersebut.

Distributed Tracing untuk Troubleshooting

Salah satu manfaat utama distributed tracing adalah membantu menemukan sumber masalah pada sistem yang kompleks.

Misalnya pengguna mengeluhkan halaman produk lambat. Metrics menunjukkan latency meningkat, tetapi belum diketahui service mana yang menjadi penyebabnya.

Dengan tracing, administrator dapat melihat:

  • Request masuk ke API Gateway selama 10 ms.
  • Product Service membutuhkan 20 ms.
  • Review Service membutuhkan 500 ms.
  • Database Review membutuhkan 450 ms.

Dari data tersebut, investigasi dapat diarahkan ke Review Service atau dependency database-nya.

Distributed Tracing untuk Mendeteksi Bottleneck

Bottleneck adalah bagian sistem yang membutuhkan waktu pemrosesan lebih besar dibandingkan komponen lainnya.

Tracing membantu memperlihatkan durasi setiap span sehingga administrator dapat menemukan operasi yang membutuhkan waktu paling lama. 


Request
  │
  ├── Gateway       5 ms
  ├── Service A    10 ms
  ├── Service B   250 ms  ← Bottleneck
  └── Database     20 ms

Distributed Tracing dan Error

Selain latency, trace dapat membantu menghubungkan error dengan perjalanan request.

Contohnya: 


Client
  │
  ▼
API Gateway
  │
  ▼
Order Service
  │
  ▼
Payment Service
  │
  └── HTTP 500
        │
        ▼
   Payment Error

Dengan Trace ID yang sama, administrator dapat mengikuti request dari gateway hingga service yang menghasilkan error.

Tracing Provider

Istio mendukung penggunaan tracing provider melalui extension provider. Dokumentasi Istio saat ini mencantumkan provider seperti OpenTelemetry, Zipkin, Apache SkyWalking, Datadog, dan Stackdriver. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/))

Provider Kegunaan
OpenTelemetry Ekosistem observability terbuka untuk pengumpulan dan pengiriman telemetry.
Zipkin Backend distributed tracing.
Apache SkyWalking Platform observability dan distributed tracing.
Datadog Platform monitoring dan observability.
Stackdriver Integrasi observability pada ekosistem Google Cloud.

Distributed Tracing dengan OpenTelemetry

OpenTelemetry merupakan salah satu pilihan penting dalam ekosistem distributed tracing modern. Istio dapat dikonfigurasi untuk mengirim trace menggunakan OpenTelemetry provider.

Dengan pipeline OpenTelemetry, trace dapat dikirim dari proxy menuju collector sebelum diteruskan ke backend observability yang digunakan organisasi. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/opentelemetry/))

Arsitektur Istio dan OpenTelemetry


Application
    │
    ▼
Envoy Proxy
    │
    │ Trace
    ▼
OpenTelemetry Collector
    │
    ├────► Tracing Backend
    │
    └────► Observability Platform

Sampling pada Distributed Tracing

Pada sistem dengan traffic tinggi, tidak selalu efisien untuk menyimpan seluruh request sebagai trace. Oleh karena itu digunakan sampling.

Sampling menentukan persentase request yang dipilih untuk dibuat atau dilaporkan sebagai trace. Istio mendukung pengaturan sampling menggunakan Telemetry API dan beberapa metode konfigurasi lainnya. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/sampling/))

Contoh Sampling


100.000 Request
       │
       ▼
Sampling 10%
       │
       ▼
10.000 Request
       │
       ▼
Tracing Backend

Semakin tinggi sampling rate, semakin banyak data tracing yang dikumpulkan. Namun, kebutuhan storage, network, dan pemrosesan juga dapat meningkat.

Contoh Konfigurasi Sampling Istio

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-tracing
  namespace: istio-system
spec:
  tracing:
  - providers:
    - name: otel-tracing
    randomSamplingPercentage: 10.00

Contoh tersebut menggunakan Telemetry API untuk memilih provider tracing bernama otel-tracing dan menetapkan random sampling sebesar 10 persen. Nama provider harus sesuai dengan provider yang telah dikonfigurasi pada MeshConfig. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/telemetry-api/))

Default Sampling

Dokumentasi Telemetry API Istio saat ini menyebut nilai default randomSamplingPercentage pada konfigurasi tracing adalah 0%, sedangkan dokumentasi task tracing menjelaskan default sampling pada instalasi/example tertentu dapat menjadi 1%. Karena itu, konfigurasi aktual sebaiknya diperiksa pada deployment Istio yang digunakan daripada mengasumsikan satu nilai default untuk semua instalasi. ([istio.io](https://istio.io/latest/docs/reference/config/telemetry/))

Custom Tags pada Distributed Tracing

Selain informasi tracing standar, Istio Telemetry API dapat menambahkan custom tags ke span. Nilai custom tag dapat berasal dari literal, environment variable, request header, atau formatter yang didukung. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/telemetry-api/))

Contoh Custom Tag

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: tracing-tags
  namespace: istio-system
spec:
  tracing:
  - providers:
    - name: otel-tracing
    customTags:
      environment:
        literal:
          value: "production"

Dengan konfigurasi tersebut, span dapat memiliki informasi tambahan mengenai lingkungan tempat workload berjalan.

Custom Tag dari Request Header

Custom tag juga dapat mengambil nilai dari request header. Pendekatan ini dapat membantu menambahkan konteks tertentu pada trace. 

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: tracing-header
  namespace: istio-system
spec:
  tracing:
  - providers:
    - name: otel-tracing
    customTags:
      user-id:
        header:
          name: user-id
          defaultValue: unknown

Istio menyediakan custom tag berbasis request header melalui konfigurasi Telemetry API. ([istio.io](https://istio.io/latest/docs/reference/config/telemetry/))

Tracing Scope pada Istio

Konfigurasi tracing pada Istio dapat diterapkan pada beberapa tingkat. Hierarki Telemetry API terdiri dari root configuration namespace, namespace, dan workload.

  1. Mesh-level untuk konfigurasi secara luas.
  2. Namespace-level untuk workload pada namespace tertentu.
  3. Workload-level untuk workload tertentu menggunakan selector.

Konfigurasi yang lebih spesifik dapat digunakan untuk menyesuaikan perilaku tracing pada workload tertentu. ([istio.io](https://istio.io/latest/docs/reference/config/telemetry/))

Contoh Workload-Specific Tracing

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: frontend-tracing
  namespace: production
spec:
  selector:
    matchLabels:
      app: frontend
  tracing:
  - providers:
    - name: otel-tracing
    randomSamplingPercentage: 50.00

Konfigurasi tersebut mengarahkan tracing pada workload dengan label app: frontend di namespace production. Workload selector dapat digunakan untuk menerapkan konfigurasi tracing yang lebih spesifik. ([istio.io](https://istio.io/latest/docs/tasks/observability/telemetry/))

Tracing Berdasarkan Traffic Mode

Telemetry API juga menyediakan selector berdasarkan mode traffic. Administrator dapat menyesuaikan konfigurasi tracing untuk traffic client maupun server sesuai kebutuhan. 

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: client-tracing
  namespace: istio-system
spec:
  tracing:
  - match:
      mode: CLIENT
    providers:
    - name: otel-tracing

Konfigurasi seperti ini berguna ketika administrator ingin membedakan perilaku telemetry berdasarkan arah traffic relatif terhadap workload. ([istio.io](https://istio.io/latest/docs/reference/config/telemetry/))

Distributed Tracing dan Kubernetes

Kubernetes menjadi platform penting untuk menjalankan microservices, sedangkan distributed tracing memberikan visibility terhadap request yang berpindah di antara workload Kubernetes.

Dalam lingkungan Kubernetes, satu aplikasi dapat terdiri dari banyak Deployment, Pod, Service, dan Namespace. Distributed tracing membantu memperlihatkan bagaimana komponen-komponen tersebut berinteraksi ketika sebuah request diproses.

Distributed Tracing dan Service Mesh

Service Mesh seperti Istio menempatkan proxy pada jalur komunikasi service. Hal tersebut membuat observability dapat diterapkan pada communication layer. 


Kubernetes
     │
     ▼
Service Mesh
     │
     ▼
Envoy Proxy
     │
     ├── Metrics
     ├── Access Logs
     └── Distributed Tracing
                 │
                 ▼
          Tracing Backend

Distributed Tracing dan Telemetry

Telemetry memberikan gambaran luas mengenai observability, sedangkan distributed tracing memberikan fokus lebih detail pada perjalanan request.

Teknologi Fokus
Metrics Angka dan tren performa.
Access Logs Detail aktivitas request.
Distributed Tracing Perjalanan request antar-service.

Metrics + Logs + Tracing

Ketiga pendekatan tersebut akan menjadi lebih kuat jika digunakan bersama. 


Metrics
   │
   └── Error Rate Naik
             │
             ▼
Logs
   │
   └── HTTP 500 ditemukan
             │
             ▼
Tracing
   │
   └── Service tertentu menjadi sumber masalah

Manfaat Distributed Tracing

  • Mempermudah debugging aplikasi microservices.
  • Mengetahui perjalanan request secara end-to-end.
  • Mendeteksi bottleneck.
  • Menganalisis latency antar-service.
  • Membantu menemukan sumber error.
  • Memahami dependency antar-service.
  • Meningkatkan visibility aplikasi.
  • Mendukung observability cloud-native.
  • Membantu optimasi performa.
  • Mendukung monitoring Service Mesh.

Kelebihan Distributed Tracing

  • Memberikan visibility end-to-end.
  • Cocok untuk arsitektur microservices.
  • Membantu menemukan bottleneck.
  • Dapat menunjukkan hubungan antar-service.
  • Membantu troubleshooting yang kompleks.
  • Dapat dikombinasikan dengan metrics dan logs.
  • Mendukung berbagai tracing provider.
  • Dapat diintegrasikan dengan Service Mesh.

Kekurangan Distributed Tracing

  • Menghasilkan data dalam jumlah besar.
  • Membutuhkan storage untuk trace.
  • Membutuhkan resource untuk collector dan backend.
  • Konfigurasi dapat menjadi kompleks.
  • Trace context harus diteruskan dengan benar.
  • Sampling dapat menyebabkan sebagian request tidak terekam.
  • Pengelolaan tracing pada sistem besar membutuhkan observability strategy yang baik.

Best Practice Distributed Tracing

  • Gunakan sampling yang sesuai dengan volume traffic.
  • Pastikan trace context diteruskan antar-service.
  • Gunakan tracing bersama metrics dan logs.
  • Gunakan collector untuk mengatur pipeline telemetry jika diperlukan.
  • Hindari menyimpan trace secara berlebihan.
  • Gunakan custom tags secara selektif.
  • Pantau penggunaan storage tracing backend.
  • Gunakan workload-specific configuration jika kebutuhan tracing berbeda.
  • Gunakan trace ID untuk menghubungkan investigasi dengan logs.
  • Dokumentasikan tracing architecture agar mudah dipelihara.

Contoh Implementasi Distributed Tracing dengan Istio

Contoh berikut menggambarkan konfigurasi Telemetry API untuk mengarahkan tracing ke OpenTelemetry provider dengan sampling tertentu. 

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-tracing
  namespace: istio-system
spec:
  tracing:
  - providers:
    - name: otel-tracing
    randomSamplingPercentage: 10.00

Provider otel-tracing harus tersedia sebagai extension provider pada konfigurasi Istio. Istio menyediakan konfigurasi tracing melalui Telemetry API dan integrasi OpenTelemetry. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/opentelemetry/))

Contoh Trace pada Aplikasi Microservices


Trace ID: 8f2a1c

[API Gateway]
Duration: 15 ms
       │
       ▼
[User Service]
Duration: 20 ms
       │
       ▼
[Order Service]
Duration: 45 ms
       │
       ├────────► [Inventory Service]
       │              Duration: 30 ms
       │
       └────────► [Payment Service]
                      Duration: 180 ms
                             │
                             ▼
                         HTTP 200

Total Request Duration:
290 ms

Dari contoh tersebut, Payment Service memiliki durasi paling tinggi. Administrator dapat menggunakan informasi tersebut untuk melakukan investigasi lebih lanjut.

Contoh Kasus Troubleshooting

Misalnya sebuah aplikasi e-commerce mengalami keluhan bahwa proses checkout lambat. Metrics menunjukkan latency meningkat dari normalnya 100 ms menjadi 500 ms.

Administrator kemudian membuka distributed tracing dan menemukan: 


Checkout Request
      │
      ├── Gateway       10 ms
      ├── Cart Service  20 ms
      ├── Order Service 30 ms
      ├── Inventory     25 ms
      └── Payment      400 ms
                           │
                           ▼
                      External API

Dari trace tersebut dapat diketahui bahwa sebagian besar waktu digunakan oleh Payment Service atau dependency eksternal yang dipanggilnya.

Dengan informasi tersebut, investigasi dapat diarahkan pada komponen yang tepat tanpa harus memeriksa seluruh service secara manual.

Distributed Tracing untuk High Availability

Distributed tracing juga dapat mendukung strategi High Availability. Ketika service mengalami peningkatan latency atau error, trace dapat membantu administrator memahami dampak gangguan terhadap request yang melewati beberapa service.

Data tersebut dapat digunakan bersama metrics dan alerting untuk membantu mendeteksi masalah lebih awal.

Distributed Tracing untuk DevOps

Dalam workflow DevOps, distributed tracing dapat membantu tim memahami perubahan performa setelah deployment baru.

Misalnya versi baru aplikasi menyebabkan latency meningkat. Tim dapat membandingkan trace sebelum dan setelah deployment untuk mengetahui service atau operasi yang mengalami perubahan.

Distributed Tracing untuk CI/CD

Distributed tracing dapat menjadi bagian dari observability setelah deployment. Setelah versi aplikasi dirilis, metrics dan traces dapat digunakan untuk memantau apakah deployment menghasilkan peningkatan error atau latency.

Dengan demikian, observability tidak hanya digunakan ketika terjadi insiden, tetapi juga dapat menjadi bagian dari siklus pengembangan dan operasional aplikasi.

Perbedaan Distributed Tracing dan Logging

Aspek Logging Distributed Tracing
Fokus Peristiwa atau pesan. Perjalanan request.
Struktur Log event. Trace dan span.
Hubungan Service Tidak selalu terlihat langsung. Menunjukkan hubungan antar-service.
Analisis Latency Terbatas. Sangat membantu.
Use Case Error dan aktivitas. Request flow dan bottleneck.

Perbedaan Distributed Tracing dan Metrics

Aspek Metrics Distributed Tracing
Bentuk Data Numerik. Trace dan span.
Fokus Trend dan kondisi sistem. Perjalanan request.
Contoh 500 request/detik. Request melewati Service A → B → C.
Analisis Bottleneck Memberikan indikasi. Menunjukkan bagian request yang lambat.

Distributed Tracing dan Observability

Observability modern biasanya menggabungkan tiga sumber data utama:

  • Metrics untuk mengetahui kondisi sistem.
  • Logs untuk mengetahui peristiwa dan detail error.
  • Traces untuk mengetahui perjalanan request.

Kombinasi ketiganya memberikan perspektif yang lebih lengkap terhadap aplikasi terdistribusi.

Tantangan Distributed Tracing

  • Volume data tracing dapat sangat besar.
  • Trace context harus diteruskan dengan benar.
  • Sampling perlu disesuaikan dengan kebutuhan.
  • Tracing backend membutuhkan resource.
  • Konfigurasi provider perlu dikelola.
  • Custom tags perlu digunakan secara hati-hati.
  • Arsitektur microservices yang kompleks menghasilkan trace yang kompleks.

Cara Memilih Sampling Rate

Sampling rate sebaiknya tidak ditentukan hanya berdasarkan angka tertentu. Faktor yang perlu dipertimbangkan antara lain volume traffic, kebutuhan troubleshooting, kapasitas tracing backend, storage, serta biaya operasional.

Pada sistem dengan traffic rendah, sampling yang lebih tinggi mungkin masih dapat diterapkan. Pada sistem dengan traffic sangat tinggi, sampling yang lebih rendah dapat membantu mengendalikan volume data.

Alur Lengkap Distributed Tracing


User Request
      │
      ▼
API Gateway
      │
      ▼
Trace Context
      │
      ▼
Service A
      │
      ├──────────► Service B
      │                 │
      │                 ▼
      │              Database
      │
      └──────────► Service C
                        │
                        ▼
                     External API

      │
      ▼
Envoy Proxy
      │
      ▼
Sampling
      │
      ▼
Trace Collector
      │
      ▼
Tracing Backend
      │
      ▼
Dashboard

Baca Juga

Artikel Selanjutnya

Setelah memahami Distributed Tracing, pembahasan berikutnya akan kembali ke konsep yang lebih luas, yaitu Service Mesh. Jika Distributed Tracing berfokus pada pelacakan perjalanan request, Service Mesh membahas lapisan infrastruktur yang mengatur komunikasi antar-service secara lebih menyeluruh.

Dengan demikian, alur pembahasannya menjadi: 


Telemetry Istio
      │
      ▼
Distributed Tracing
      │
      ▼
Service Mesh
      │
      ├── Traffic Management
      ├── Security
      ├── Observability
      └── Service-to-Service Communication

Pertanyaan yang Sering Diajukan (FAQ)

Apa itu Distributed Tracing?

Distributed Tracing adalah metode observability yang digunakan untuk melacak perjalanan request ketika melewati beberapa service dalam sistem terdistribusi.

Apa perbedaan Trace dan Span?

Trace menggambarkan keseluruhan perjalanan request, sedangkan span merupakan bagian atau operasi tertentu dari perjalanan tersebut.

Mengapa Distributed Tracing penting untuk microservices?

Karena satu request pada arsitektur microservices dapat melewati banyak service. Distributed tracing membantu mengetahui hubungan antar-service, latency, error, dan bottleneck dalam perjalanan request.

Apa fungsi Trace ID?

Trace ID digunakan untuk menghubungkan span yang berasal dari perjalanan request yang sama sehingga keseluruhan request dapat dilihat sebagai satu trace.

Apa fungsi Sampling?

Sampling digunakan untuk menentukan persentase request yang akan dipilih untuk tracing. Mekanisme ini membantu mengontrol jumlah data yang dikirim dan disimpan oleh tracing system.

Apakah Istio mendukung Distributed Tracing?

Ya. Istio menyediakan integrasi distributed tracing melalui Envoy dan Telemetry API. Konfigurasi dapat mencakup provider tracing, sampling, serta custom tags. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/))

Apakah aplikasi harus meneruskan trace context?

Ya. Agar span dari beberapa service dapat digabung menjadi satu trace, aplikasi perlu meneruskan informasi trace context dari request masuk ke request keluar yang dibuatnya. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/))

Apakah Distributed Tracing sama dengan Logging?

Tidak. Logging berfokus pada pencatatan peristiwa atau pesan, sedangkan distributed tracing berfokus pada perjalanan request melalui berbagai service.

Apakah Distributed Tracing sama dengan Metrics?

Tidak. Metrics memberikan data numerik mengenai kondisi dan performa sistem, sedangkan distributed tracing menunjukkan perjalanan request secara lebih detail melalui trace dan span.

Apakah Distributed Tracing membutuhkan Istio?

Tidak. Distributed tracing dapat digunakan tanpa Istio. Namun, Istio menyediakan integrasi dengan Envoy dan Telemetry API sehingga tracing dapat menjadi bagian dari observability pada Service Mesh.

Kesimpulan

Distributed Tracing merupakan komponen penting dalam observability aplikasi modern, khususnya pada arsitektur microservices dan sistem terdistribusi. Teknologi ini memungkinkan administrator mengikuti perjalanan request dari satu service ke service lainnya menggunakan konsep trace, span, Trace ID, Span ID, dan trace context.

Dengan distributed tracing, proses troubleshooting menjadi lebih mudah karena administrator dapat mengetahui service mana yang mengalami latency tinggi, error, atau menjadi bottleneck. Informasi tersebut sangat berguna ketika aplikasi terdiri dari banyak service yang saling berkomunikasi.

Dalam ekosistem Istio, distributed tracing terintegrasi dengan Envoy dan dapat dikonfigurasi menggunakan Telemetry API. Administrator dapat menentukan tracing provider, sampling rate, custom tags, serta scope konfigurasi berdasarkan kebutuhan workload. ([istio.io](https://istio.io/latest/docs/tasks/observability/distributed-tracing/telemetry-api/))

Distributed tracing sebaiknya digunakan bersama metrics dan access logs untuk membangun observability yang lebih lengkap. Metrics memberikan gambaran kondisi sistem, logs memberikan detail peristiwa, sedangkan tracing memperlihatkan perjalanan request.

Setelah memahami Telemetry dan Distributed Tracing, langkah berikutnya adalah memahami Service Mesh secara lebih luas. Service Mesh akan menghubungkan pembahasan mengenai traffic management, security, observability, proxy, dan komunikasi antar-service dalam satu arsitektur.

Location: Indonesia

Postingan populer dari blog ini

Istio Egress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234

Dipublikasikan:
Gambar
Istio Egress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234 Istio Egress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya Dalam arsitektur microservices modern, komunikasi aplikasi Dewa234 tidak hanya terjadi antar-service yang berada di dalam Kubernetes atau Service Mesh. Banyak aplikasi juga membutuhkan akses menuju layanan eksternal seperti API pihak ketiga, payment gateway, cloud service, database eksternal, sistem legacy, SaaS, dan berbagai layanan yang berada di luar cluster. Traffic yang keluar dari Service Mesh tersebut dikenal sebagai egress traffic . Jika traffic keluar dibiarkan langsung dari masing-masing workload menuju internet atau jaringan eksternal, administrator dapat mengalami kesulitan dalam melakukan monitoring, pengamanan, logging, dan pengendalian akses. Istio menyediakan Egress Gateway untuk membant...
Baca Selengkapnya →

Istio VirtualService: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234

Dipublikasikan:
Gambar
Istio VirtualService: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234 Istio VirtualService: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya Dalam arsitektur microservices , sebuah aplikasi Dewa234 biasanya terdiri dari banyak service yang saling berkomunikasi. Ketika jumlah service semakin besar, pengelolaan traffic menjadi semakin kompleks. Request tidak selalu harus dikirim secara sederhana ke satu service saja. Dalam kondisi tertentu, traffic perlu diarahkan berdasarkan hostname, URI, header, versi aplikasi, persentase traffic, maupun kondisi tertentu lainnya. Pada Kubernetes biasa, routing traffic umumnya bergantung pada Service, Ingress, load balancer, atau komponen networking lainnya. Namun ketika sebuah organisasi menggunakan Istio Service Mesh , pengelolaan traffic dapat dilakukan dengan aturan yang jauh lebih fleksibel melalui resource ...
Baca Selengkapnya →

Istio Ingress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234

Dipublikasikan:
Gambar
Istio Ingress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234 Istio Ingress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya Dalam arsitektur microservices , tidak semua traffic berasal dari service lain yang berada di dalam cluster. Banyak request berasal dari luar sistem, seperti browser pengguna, aplikasi mobile, partner API, sistem eksternal, maupun client dari jaringan perusahaan. Traffic yang masuk dari luar menuju service yang berada di dalam Service Mesh disebut sebagai ingress traffic . Traffic tersebut membutuhkan titik masuk yang dapat mengatur port, protocol, hostname, TLS, routing, serta berbagai kebijakan keamanan sebelum request diteruskan menuju service internal. Istio menyediakan Ingress Gateway sebagai salah satu komponen yang digunakan untuk menangani traffic masuk ke service mesh. Ingress Gateway berjalan ...
Baca Selengkapnya →