Belajar Observability dengan LGTM Stack - OpenTelemetry - Vendor-Agnostic Observability Standard

#Pendahuluan

Di episode 2 kalian mengenal tiga pillars observability. Namun ada pertanyaan praktis yang belum terjawab: bagaimana aplikasi kalian menghasilkan telemetry tersebut dengan cara yang konsisten dan tidak terkunci pada satu vendor? Jawabannya adalah OpenTelemetry, atau disingkat OTel.

Episode ini membahas sejarah OpenTelemetry, struktur komponen utamanya, berbagai jenis sinyal yang didukung, serta alasan mengapa ia menjadi standard de facto instrumentasi modern. OTel akan menemani hampir setiap episode berikutnya, karena seluruh sample application di series ini diinstrumentasi memakai OTel SDK.

#OpenTelemetry Fundamentals

#Sejarah Merger OpenTracing dan OpenCensus

Sebelum OTel ada, ekosistem instrumentasi terpecah. OpenTracing mengusung standard API tracing yang vendor-agnostic, sementara OpenCensus yang digagas Google membawa library untuk traces dan metrics dengan pengumpulan data terpadu. Kedua project tersebut memiliki kelebihan masing-masing namun terbelah dua arah.

Pada tahun 2019, keduanya diumumkan merger menjadi OpenTelemetry. Project ini kemudian diakui sebagai CNCF (Cloud Native Computing Foundation) project dan tumbuh menjadi project kedua paling aktif di CNCF setelah Kubernetes. Tujuan utamanya sederhana: satu standard terbuka untuk menghasilkan, memproses, dan mengekspor telemetry.

#Specification vs Implementation

OpenTelemetry secara konseptual dibagi menjadi dua lapisan:

• Specification: aturan abstrak yang menjelaskan API, SDK, data model, dan konvensi semantik. Specification tidak berisi kode yang berjalan.
• Implementation: SDK aktual yang ditulis untuk masing-masing bahasa pemrograman.

Pemisahan ini memastikan konsistensi perilaku antar bahasa. SDK resmi tersedia untuk Go, Java, Python, JavaScript, .NET, Ruby, PHP, Rust, dan lainnya — kalian bisa menginstrumentasi aplikasi dengan bahasa apa pun.

pip show opentelemetry-sdk

Perintah pip show opentelemetry-sdk akan menampilkan metadata SDK yang terinstall. Nama paket semacam ini akan kalian kenali saat praktik di episode 8 dan 14.

#Komponen OTel

#API dan SDK

• API layer: antarmuka yang dipakai developer untuk membuat span, mencatat metrik, dan menulis log. API bersifat stabil dan minim dependensi.
• SDK implementation: implementasi nyata dari API yang mengatur batching, sampling, konfigurasi eksport, dan hook. Aplikasi memakai SDK untuk mengaktifkan API.
• Instrumentation libraries: paket yang secara otomatis menginstrumentasi framework populer seperti HTTP client, database driver, dan message queue.

#OpenTelemetry Collector dan Exporters

OpenTelemetry Collector adalah komponen yang menerima, memproses, dan mengekspor telemetry dari banyak sumber ke banyak tujuan. Kalian akan mendalaminya di episode 16. Sedangkan exporters adalah plugin yang mengirim data ke backend tujuan:

• OTLP exporter: protokol native OTel yang dipahami langsung oleh Tempo, Mimir, dan Loki.
• Prometheus exporter: mengekspos metrik dalam format Prometheus untuk di-scrape.
• Jaeger exporter: mengirim trace ke backend Jaeger bila diperlukan.

app -> OTel SDK -> OTLP -> Collector -> Tempo
                          -> Mimir
                          -> Loki

Alur di atas adalah pola standar: satu Collector melayani tiga backend sekaligus. Perhatikan bahwa Collector -> Tempo terjadi lewat OTLP, sedangkan menuju Mimir dan Loki bisa lewat remote write atau exporter khusus.

#Signal Types

OpenTelemetry mendefinisikan beberapa jenis sinyal telemetry:

• Traces: representasi perjalanan request lintas service, dibangun dari span dan context propagation.
• Metrics: pengukuran numerik, termasuk counter, gauge, histogram, dan cumulative.
• Logs: peristiwa berbasis waktu; OTel menyediakan API log dan juga menerima log dari sumber eksternal.
• Baggage: pasangan key-value yang dikirim bersamaan dengan context untuk kebutuhan lintas service, misalnya user ID untuk keperluan business logic.
• Future signals: profiling dan event sedang dikembangkan menjadi sinyal resmi — profiling sudah digunakan lewat Pyroscope di episode 34.

traces | metrics | logs | baggage

Baggage dibedakan dari trace context karena ia membawa data bisnis, bukan hanya identitas request. Ingat pola traces | metrics | logs | baggage sebagai daftar sinyal yang selalu dipakai.

#Mengapa OpenTelemetry Penting

#Menghindari Vendor Lock-in

Dengan OTel, kalian menulis instrumentasi sekali dan mengekspor ke backend mana pun — Prometheus, Jaeger, Datadog, atau LGTM Stack. Jika suatu hari kalian pindah backend, kode aplikasi tidak perlu diubah.

#Standardisasi dan Auto-instrumentation

• Standardized instrumentation: konvensi semantik OTel memastikan nama span dan atribut konsisten antar tim, sehingga query lintas service menjadi masuk akal.
• Auto-instrumentation capabilities: banyak bahasa menyediakan agen yang menginstrumentasi framework secara otomatis tanpa mengubah kode — contohnya Java agent dan Python auto-instrumentation yang dipakai di episode 14.
• Ecosystem momentum: hampir semua vendor observability kini mendukung OTLP, menjadikan OTel bahasa universal observability.
• Future-proof telemetry collection: karena OTel adalah project open-source paling aktif, investasi skill kalian aman dalam jangka panjang.

#Penutup

Di episode 3 ini kalian memahami bahwa OpenTelemetry adalah standard open-source untuk telemetry yang lahir dari merger OpenTracing dan OpenCensus, mengenal pemisahan specification dan SDK, komponen API, SDK, Collector, dan exporters, serta sinyal yang didukung mulai dari traces hingga baggage.

Inti yang harus dibawa pulang:

• OTel adalah project CNCF hasil merger OpenTracing dan OpenCensus.
• API terpisah dari SDK, dengan SDK per bahasa pemrograman.
• Collector adalah titik pusat penerimaan dan distribusi telemetry.
• OTLP adalah protokol ekspor native yang dipahami backend LGTM.
• OTel menghindari vendor lock-in dan mendukung auto-instrumentation.
• Empat sinyal utama: traces, metrics, logs, dan baggage.

Di episode 4 selanjutnya kita mulai praktik: setting up development environment — menjalankan seluruh LGTM Stack beserta OpenTelemetry Collector dan Grafana Alloy lewat Docker Compose, menghubungkan data source, dan mengirim telemetry pertama dari aplikasi sample. Siapkan terminal kalian, karena mulai sekarang kita banyak mengetik perintah.