Belajar OpenTelemetry - Sejarah, Latar Belakang & Mengapa Membutuhkannya

#Pendahuluan

Setelah di episode 0 kita menyiapkan environment — Docker Compose dengan Jaeger dan collector, plus SDK Python — pada episode ini kita memahami mengapa OpenTelemetry ada. Sejarah mungkin terasa jauh dari praktik, padahal justru di sanalah letak keputusan desain terpenting OTel: vendor-neutral, satu API untuk semua bahasa, dan satu protokol untuk semua backend.

Mengapa harus memahami sejarahnya? Karena OTel tidak lahir dari ruang rapat satu perusahaan, melainkan dari perpecahan ekosistem yang menyakitkan: dua standar yang bersaing, masing-masing diadopsi vendor berbeda, dan para engineer dipaksa memilih. Memahami perpecahan itu menjelaskan semua keputusan OTel — termasuk mengapa semantic conventions dijaga ketat dan mengapa OTLP didesain sebagai protokol tunggal.

#Era Sebelum OTel: OpenTracing vs OpenCensus

Sebelum 2019, dunia tracing terbelah dua:

• OpenTracing (diinisiasi LightStep/Jaeger) — fokus pada API tracing yang konsisten antar bahasa, mengajukan W3C Trace Context sebagai standar propagasi.
• OpenCensus (diinisiasi Google) — fokus pada metrics dan traces, sudah terintegrasi dengan infrastruktur Google dan ekspor ke banyak backend.

Keduanya punya komunitas dan vendor pendukung masing-masing. Masalahnya: aplikasi yang diinstrumentasi dengan OpenTracing tidak kompatibel dengan OpenCensus, dan sebaliknya. Perusahaan yang memakai dua vendor observability berbeda harus menulis dua instrumentasi. Ini fragmentasi yang persis sama dengan masalah "satu kode, banyak backend" yang ingin dipecahkan — tetapi justru menjadi sumbernya.

#Merger 2019: Lahirnya OpenTelemetry

Pada Mei 2019, OpenTracing dan OpenCensus resmi bergabung menjadi OpenTelemetry di bawah naungan CNCF. Ini bukan sekadar menggabungkan dua kode — ini merger visi: satu API yang stabil, satu SDK per bahasa, satu protokol (OTLP), dan satu set semantic conventions yang dipakai semua vendor.

Perjalanan kematangan OTel di CNCF mengikuti alur baku:

Graduation bukan gelar seremonial. CNCF hanya mengangkat proyek yang lulus audit keamanan pihak ketiga, memiliki tata kelola matang, dan terbukti dipakai produksi dalam skala besar. OTel lulus ketiganya — dengan lebih dari 12.000 kontributor dari 2.800+ perusahaan.

#Mengapa OTel: Tiga Alasan Inti

#1. Vendor-Neutral: Satu SDK untuk Semua Backend

Ini nilai jual terbesar. Kalian menginstrumentasi aplikasi sekali dengan API OTel, lalu bisa mengarahkan telemetry ke backend mana pun — Jaeger, Prometheus, Grafana/LGTM, Datadog, AWS X-Ray, Azure Monitor, atau GCP — tanpa mengubah kode aplikasi sama sekali.

100%

Pindah vendor = mengubah konfigurasi exporter, bukan menulis ulang instrumentasi.

#2. Traces + Metrics + Logs dalam Satu Framework

OTel menstandarkan tiga sinyal sekaligus: traces (span, W3C traceparent), metrics (counter, histogram), dan logs (structured log yang membawa trace_id/span_id). Korelasi antar-sinyal — dari alert metrics turun ke trace lalu ke log — menjadi mungkin secara native, yang kita praktikkan di episode 17.

#3. Adopsi Luas dan Graduated

Ketika sebuah teknologi dipakai internal oleh vendor cloud terbesar (AWS, Google, Microsoft semuanya menerima OTLP di layanan observability mereka), keputusan adopsinya jadi mudah secara politik maupun teknis. Status graduated memberikan sinyal formal: OTel siap produksi dan tidak akan hilang dalam dua tahun.

#Siapa yang Membutuhkan OTel?

• Backend/Platform Engineer — yang menstandarkan cara service saling terkait.
• DevOps/SRE — yang butuh data terpercaya untuk alerting dan SLI/SLO.
• Startup & enterprise — yang ingin menghindari vendor lock-in saat observability cost naik.
• Tim AI — karena GenAI semantic conventions kini jadi standar observasi LLM (episode 21).

Jika aplikasi kalian hanya satu proses tanpa dependency eksternal, OTel mungkin berlebihan. Begitu ada lebih dari satu service, message queue, atau ekspektasi SLA — OTel adalah jalur termurah menuju observability yang koheren.

#Timeline Singkat

#Penutup

Pada episode 1 ini, kalian telah memahami dari mana OTel berasal dan mengapa ia mengambil bentuk sekarang.

Inti yang harus dibawa pulang:

• OTel lahir dari merger OpenTracing + OpenCensus (2019) untuk mengakhiri fragmentasi ekosistem.
• Perjalanan CNCF: Sandbox → Incubating (2021) → Graduated (Mei 2026).
• Nilai inti: vendor-neutral, tiga sinyal dalam satu framework, dan adopsi industri luas.
• Graduation menandakan kematangan produksi — argumen "OTel belum siap produksi" sudah gugur.

Di episode 2 selanjutnya, kita akan membedah konsep dasar dan arsitektur utama OpenTelemetry — signals (traces, metrics, logs), komponen API → SDK → Exporter → OTLP → Collector, serta Resource dan semantic conventions. Sampai jumpa di episode 2!