Belajar OpenTelemetry - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Setelah memahami sejarah dan alasan OTel ada di episode 1, sekarang kita membedah arsitektur dan bahasa yang dipakai sepanjang series. Dua hal ini wajib dikuasai sebelum menulis baris kode instrumentasi: signals (apa yang dikumpulkan) dan komponen (siapa melakukan apa).

Ini penting karena kebanyakan debugging observability gagal di lapisan paling dasar: orang mengira masalah di SDK padahal ada di pipeline collector, atau mengira data "hilang" padahal hanya salah semantic conventions. Dengan menguasai arsitektur, kalian bisa langsung menunjuk lapisan yang bermasalah.

#Signals: Bahan Baku Observability

OTel menstandarkan tiga sinyal utama (plus profiling sebagai sinyal keempat yang sedang berkembang). Setiap sinyal punya model data sendiri.

#Traces

Trace adalah perjalanan satu request melewati banyak service, tersusun dari span. Satu span mewakili satu unit kerja — misalnya "memproses HTTP request" atau "query database" — dan membawa:

• Trace ID — identitas unik seluruh perjalanan request.
• Span ID — identitas span individu; span anak merekam parent_span_id.
• Timestamp & duration — waktu mulai dan lama eksekusi.
• Attributes, events, status — metadata yang kita bahas di episode 4.

Trace diidentifikasi lintas service lewat W3C traceparent header yang memuat trace-id dan span-id — ini fondasi korelasi di episode 4 dan 15.

#Metrics

Metrics adalah agregasi angka yang mengukur perilaku sistem dalam rentang waktu: request per detik, latensi P95, error rate, penggunaan CPU. Tipe instrument dasarnya:

• Counter — naik monoton (jumlah request).
• UpDownCounter — bisa naik dan turun (jumlah koneksi aktif).
• Histogram — distribusi nilai (latensi request).
• Gauge — nilai snapshot yang bisa berubah (suhu CPU).

Kita bedah tipe dan cara pengukurannya di episode 5.

#Logs

Logs adalah catatan kejadian diskrit — paling tua dan paling banyak dipakai. OTel menstandarkan format structured log yang bisa membawa trace_id dan span_id, sehingga log bisa langsung dikaitkan ke trace yang sedang berlangsung. Detailnya di episode 6.

#Komponen Arsitektur

Arsitektur OTel adalah pipeline berlapis. Pahami alurnya sekali, dan seluruh series ini jadi mengalir:

#API — Kontrak yang Stabil

API adalah antarmuka pemrograman yang kalian panggil di kode: Tracer, Meter, Logger, Context, Propagation. Aturan emasnya: API harus tanpa perilaku (no-op) jika SDK tidak terpasang — artinya aplikasi tetap jalan normal meski belum dikonfigurasi observability. Ini yang membuat API bisa dipanggil sejak hari pertama tanpa biaya overhead.

#SDK — Implementasi yang Dikonfigurasi

SDK adalah implementasi nyata API: mengelola provider, membangun spans sesuai pipeline, melakukan sampling, batching, dan menyerahkan data ke exporter. Di sinilah konfigurasi hidup — endpoint, resource, sampling rate, export interval. API dan SDK dipisah supaya satu API bisa dipakai dengan berbagai perilaku SDK.

#Exporter — Pintu Keluar

Exporter mengubah span/metric/log SDK menjadi format wire (protobuf OTLP) dan mengirimkannya ke tujuan: Collector, backend langsung, atau file. Exporter bertanggung jawab atas retry dan backoff saat jaringan gagal — yang kita bedah di episode 14.

#OTLP — Protokol Standar

OTLP (OpenTelemetry Protocol) adalah protokol resmi OTel, encoding protobuf, dengan dua varian transport:

• OTLP/gRPC — port 4317.
• OTLP/HTTP — port 4318 (bisa protobuf atau JSON).

Versi saat ini adalah OTLP v1.10.0 (stabil sejak 9 Maret 2026). Kita dalami protokol ini di episode 8.

#Collector — Router Data

Collector adalah daemon yang menerima telemetry dari banyak aplikasi, memprosesnya (filter, batch, redaksi), lalu meneruskan ke satu atau banyak backend. Ia memisahkan produksi telemetry (di aplikasi) dari konsumsi telemetry (di backend). Arsitektur collector kita bedah penuh di episode 9.

#Resource: Identitas Data

Setiap telemetry membawa Resource — atribut yang mengidentifikasi siapa yang menghasilkan data ini: service.name, service.version, host.name, deployment.environment, dan atribut Kubernetes seperti k8s.pod.name. Resource adalah dasar pemfilteran dan grouping di backend. Tanpa Resource yang benar, telemetry dari semua service akan tercampur tak terbaca.

Contoh pembentukan resource di Python:

from opentelemetry.sdk.resources import Resource, SERVICE_NAME
 
resource = Resource.create({
    SERVICE_NAME: "payment-service",
    "service.version": "1.4.0",
    "deployment.environment": "production",
})

#Semantic Conventions: Bahasa Bersama

Semantic Conventions adalah katalog penamaan standar untuk attributes, span names, dan metric names — misalnya http.request.method, http.response.status_code, db.system, messaging.system. Tujuannya: data dari bahasa dan framework berbeda tetap bisa dibandingkan di satu dashboard. Alasan mengapa penamaan ini begitu dijaga akan kita dalami di episode 7.

#Peta Pemahaman Series

Sekarang kalian bisa melihat peta besar series ini:

• Episode 3-6: instrumentasi — API/SDK (3), traces (4), metrics (5), logs (6).
• Episode 7-8: bahasa bersama — resource & semantic conventions (7), OTLP (8).
• Episode 9-14: Collector — arsitektur (9), config (10), receivers/exporters (11), processors (12), sampling (13), reliability (14).
• Episode 15-17: lintas layanan, keamanan, korelasi tiga pilar.
• Episode 18-22: Kubernetes, performa, multi-backend, AI observability, dan refleksi.

#Penutup

Pada episode 2 ini, kalian telah menguasai dua fondasi OTel: signals dan komponen arsitektur.

Inti yang harus dibawa pulang:

• Tiga sinyal: traces (span), metrics (angka agregat), logs (event diskrit).
• Alur data: API → SDK → Exporter → OTLP → Collector → Backend.
• OTLP dua jalur: gRPC 4317 dan HTTP 4318, protobuf, stabil di v1.10.0.
• Resource memberi identitas data; semantic conventions memberi bahasa bersama.

Di episode 3 selanjutnya, kita akan membahas instrumentasi: API, SDK, dan auto-instrumentation — perbedaan peran API vs SDK, lalu membandingkan agent otomatis (Java agent, Python opentelemetry-instrument, Node.js) dengan instrumentasi manual span dan attribute. Sampai jumpa di episode 3!