DISTRIBUTED-SYSTEMS OBSERVABILITY MICROSERVICES TRACING LOGGING CONTEXT-PROPAGATION OPENTELEMETRY BEST-PRACTICES SYSTEM-DESIGN DEVOPS BACKEND CLOUD-NATIVE

Context Propagation: Membangun Observabilitas End-to-End di Sistem Terdistribusi Anda

⏱️ 12 menit baca
👨‍💻

Context Propagation: Membangun Observabilitas End-to-End di Sistem Terdistribusi Anda

1. Pendahuluan

Pernahkah Anda mencoba men-debug masalah di sistem microservices yang kompleks, di mana satu permintaan pengguna melewati belasan layanan backend yang berbeda? Rasanya seperti mencari jarum di tumpukan jerami, bukan? Setiap layanan mungkin punya lognya sendiri, metriknya sendiri, tapi bagaimana menghubungkan semua potongan informasi itu menjadi satu narasi yang koheren dari awal hingga akhir?

Di sinilah Context Propagation menjadi pahlawan yang sering terlupakan. Dalam arsitektur terdistribusi, di mana permintaan melompat dari satu layanan ke layanan lain, sangat penting untuk membawa serta “konteks” dari permintaan tersebut. Konteks ini bisa berupa ID trace, ID span, informasi autentikasi, atau data lain yang relevan. Tanpa mekanisme yang efektif untuk menyebarkan konteks ini, observabilitas end-to-end—kemampuan untuk melacak dan memahami alur permintaan secara menyeluruh—akan sangat terganggu.

Artikel ini akan membahas secara mendalam apa itu context propagation, mengapa ia sangat krusial untuk observabilitas, bagaimana cara kerjanya, tantangan implementasinya, dan praktik terbaik untuk menerapkannya di sistem terdistribusi Anda. Mari kita bongkar misteri di balik layar agar debugging Anda jadi lebih cepat dan sistem Anda lebih transparan.

2. Apa Itu Context Propagation?

Bayangkan Anda sedang menonton sebuah film laga. Setiap adegan punya cerita dan karakternya sendiri, tapi ada benang merah yang menghubungkan semuanya, yaitu plot utama dan tokoh protagonisnya. Tanpa benang merah itu, film akan terasa seperti kumpulan adegan acak yang tidak berarti.

Dalam sistem terdistribusi, Context Propagation adalah “benang merah” itu. Ini adalah proses meneruskan informasi kontekstual (seperti ID unik untuk sebuah permintaan, informasi pengguna, atau data lain yang relevan) dari satu komponen atau layanan ke layanan berikutnya saat sebuah operasi berlangsung. Tujuannya adalah memastikan bahwa setiap bagian dari sistem yang memproses permintaan yang sama memiliki akses ke konteks yang sama.

Contoh paling umum dari konteks ini adalah Trace ID dan Span ID yang digunakan dalam distributed tracing.

Ketika Layanan A memanggil Layanan B, yang kemudian memanggil Layanan C, context propagation memastikan bahwa Trace ID yang sama diteruskan dari A ke B, dan dari B ke C. Ini memungkinkan kita untuk merekonstruksi seluruh alur permintaan dan melihat bagaimana setiap layanan berkontribusi pada waktu respons total atau di mana potensi masalah terjadi.

3. Mengapa Context Propagation Krusial untuk Observabilitas?

Tanpa context propagation yang tepat, observabilitas end-to-end di sistem terdistribusi akan menjadi mimpi belaka. Ini alasannya:

4. Cara Kerja Context Propagation

Secara umum, context propagation bekerja dengan menyuntikkan (inject) informasi konteks ke dalam “carrier” (pembawa) dan mengekstraknya (extract) di sisi penerima.

a. Carrier: Bagaimana Konteks Dibawa?

Konteks bisa dibawa melalui berbagai cara, tergantung pada protokol komunikasi yang digunakan:

  1. HTTP Headers 📌 Ini adalah metode yang paling umum. Ketika Layanan A memanggil Layanan B melalui HTTP, informasi konteks disisipkan sebagai header HTTP kustom. Contoh header yang umum digunakan oleh OpenTelemetry:

    • traceparent: Berisi Trace ID, Span ID, dan flag sampling.
    • tracestate: Berisi informasi lain yang relevan untuk trace.
    GET /api/data HTTP/1.1
Host: service-b.example.com
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
tracestate: congo=t6mtgf0q7objc9ff

    Ketika Layanan B menerima permintaan ini, ia akan mengekstrak header traceparent dan tracestate untuk melanjutkan trace yang sama.

  2. Message Queue Headers ✉️ Dalam sistem berbasis antrean pesan (seperti Kafka, RabbitMQ, SQS), konteks dapat disisipkan sebagai header pesan atau metadata pesan. Misalnya, saat Layanan A mengirim pesan ke antrean, ia menyertakan Trace ID dalam properti pesan. Saat Layanan B mengonsumsi pesan, ia mengekstrak Trace ID tersebut.

  3. gRPC Metadata 🌐 Untuk komunikasi gRPC, konteks disisipkan sebagai metadata gRPC, yang secara fungsional mirip dengan header HTTP.

  4. Database Query Comments (Jarang, tapi bisa) Dalam beberapa kasus yang sangat spesifik, konteks bisa disisipkan sebagai komentar dalam query database, meskipun ini bukan praktik umum untuk distributed tracing.

b. Inject & Extract: Prosesnya

Prosesnya melibatkan dua langkah utama:

  1. Inject (Menyuntikkan): Sebelum melakukan panggilan keluar (outgoing request) ke layanan lain, layanan saat ini (misalnya, Layanan A) mengambil konteks saat ini dari operasinya (misalnya, Trace ID dan Span ID saat ini) dan menyuntikkannya ke dalam carrier (misalnya, header HTTP) dari permintaan yang akan dikirim.

  2. Extract (Mengekstrak): Saat menerima panggilan masuk (incoming request) dari layanan lain, layanan penerima (misalnya, Layanan B) mengekstrak informasi konteks dari carrier (misalnya, header HTTP) dan menjadikannya konteks saat ini untuk operasi yang akan dilakukannya. Jika tidak ada konteks yang ditemukan, layanan akan membuat konteks baru (Trace ID dan Span ID baru), menandakan dimulainya trace baru.

Dengan proses ini, Trace ID yang sama dapat mengalir melalui seluruh rantai panggilan, memungkinkan kita untuk melihat seluruh “jejak” (trace) dari satu permintaan.

5. Tantangan dalam Mengimplementasikan Context Propagation

Meskipun konsepnya terlihat sederhana, implementasi context propagation bisa menjadi rumit, terutama di sistem yang sudah mapan atau sangat heterogen:

6. Praktik Terbaik dan Tooling dengan OpenTelemetry

Untuk mengatasi tantangan di atas dan mengimplementasikan context propagation secara efektif, OpenTelemetry adalah solusi de facto saat ini.

a. Mengapa OpenTelemetry? 🚀

OpenTelemetry adalah set alat, API, dan SDK vendor-agnostic yang dirancang untuk menginstrumentasi, menghasilkan, mengumpulkan, dan mengekspor telemetri (logs, metrics, traces) dari aplikasi Anda.

b. Cara Kerja OpenTelemetry untuk Context Propagation

Dengan OpenTelemetry, Anda akan menggunakan:

  1. API Context: Untuk mendapatkan dan mengatur konteks saat ini di dalam aplikasi Anda.
  2. Propagator: Komponen yang bertanggung jawab untuk meng-inject dan meng-extract konteks dari carrier (misalnya, HTTP headers). OpenTelemetry menyediakan propagator standar seperti W3CTraceContextPropagator dan BaggagePropagator.
  3. Tracer: Untuk membuat span baru dan mengelola alur trace. Tracer secara otomatis akan mengambil konteks saat ini dan mempropagasikannya ke span baru.

Contoh Sederhana (Node.js dengan Express dan http client):

// service-a.js
const opentelemetry = require('@opentelemetry/api');
const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');
const { ConsoleSpanExporter } = require('@opentelemetry/sdk-trace-base');
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
const { ExpressInstrumentation } = require('@opentelemetry/instrumentation-express');
const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');
const { registerInstrumentations } = require('@opentelemetry/instrumentation');
const http = require('http');
const express = require('express');

// 1. Inisialisasi OpenTelemetry Provider
const provider = new NodeTracerProvider({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'service-a',
  }),
});
provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));
provider.register();

// 2. Register instrumentasi otomatis
registerInstrumentations({
  instrumentations: [
    new HttpInstrumentation(),
    new ExpressInstrumentation(),
  ],
});

const app = express();
const PORT = 3000;

app.get('/call-b', async (req, res) => {
  const currentSpan = opentelemetry.trace.getSpan(opentelemetry.context.active());
  currentSpan.addEvent('Calling Service B');

  // Panggilan ke Service B
  await new Promise((resolve, reject) => {
    http.get('http://localhost:3001/data', (response) => {
      let data = '';
      response.on('data', (chunk) => (data += chunk));
      response.on('end', () => {
        console.log(`Response from Service B: ${data}`);
        res.send(`Service A called Service B. Response: ${data}`);
        resolve();
      });
    }).on('error', (err) => {
      console.error('Error calling Service B:', err.message);
      res.status(500).send('Error calling Service B');
      reject(err);
    });
  });
});

app.listen(PORT, () => {
  console.log(`Service A listening on port ${PORT}`);
});
// service-b.js
const opentelemetry = require('@opentelemetry/api');
const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');
const { ConsoleSpanExporter } = require('@opentelemetry/sdk-trace-base');
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
const { ExpressInstrumentation } = require('@opentelemetry/instrumentation-express');
const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');
const { registerInstrumentations } = require('@opentelemetry/instrumentation');
const express = require('express');

// 1. Inisialisasi OpenTelemetry Provider
const provider = new NodeTracerProvider({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'service-b',
  }),
});
provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));
provider.register();

// 2. Register instrumentasi otomatis
registerInstrumentations({
  instrumentations: [
    new HttpInstrumentation(),
    new ExpressInstrumentation(),
  ],
});

const app = express();
const PORT = 3001;

app.get('/data', (req, res) => {
  const currentSpan = opentelemetry.trace.getSpan(opentelemetry.context.active());
  currentSpan.addEvent('Processing data in Service B');
  console.log('Service B received a request.');
  res.send('Data from Service B');
});

app.listen(PORT, () => {
  console.log(`Service B listening on port ${PORT}`);
});

Dengan instrumentasi otomatis OpenTelemetry, ketika Service A memanggil Service B, HttpInstrumentation di Service A secara otomatis akan meng-inject header traceparent ke permintaan keluar. Lalu, ExpressInstrumentation di Service B akan otomatis mengekstrak header tersebut dan melanjutkan trace yang sama. Anda akan melihat log span dari kedua layanan dengan Trace ID yang sama, menggambarkan alur end-to-end.

c. Tips Praktis untuk Implementasi

Kesimpulan

Context propagation adalah fondasi tak terlihat yang memungkinkan kita memahami kompleksitas sistem terdistribusi. Tanpa itu, upaya observabilitas Anda akan sia-sia, dan debugging akan menjadi mimpi buruk. Dengan mengadopsi standar seperti W3C Trace Context dan memanfaatkan tooling canggih seperti OpenTelemetry, Anda bisa membangun sistem yang tidak hanya skalabel dan tangguh, tetapi juga transparan dan mudah di-debug.

Menerapkan context propagation mungkin memerlukan investasi awal, tetapi manfaat jangka panjangnya dalam hal kecepatan debugging, pemahaman sistem, dan pengalaman developer akan jauh melampaui biayanya. Jadi, jangan biarkan permintaan Anda tersesat di labirin microservices; beri mereka benang merah yang mereka butuhkan!

🔗 Baca Juga