Halo 👋

Setelah paham kenapa observability itu penting banget, biasanya pertanyaan berikutnya adalah:

gimana cara nerapinnya dengan rapi, modern, dan nggak bikin kita ke-lock ke satu vendor tertentu?

Nah, di sinilah OpenTelemetry masuk.

Kalau observability itu pendekatannya buat memahami sistem, maka OpenTelemetry adalah salah satu fondasi teknis yang bantu kita menerapkan pendekatan itu di aplikasi beneran.

Apa Itu OpenTelemetry?

OpenTelemetry, yang sering juga disingkat OTel, adalah standar terbuka buat menghasilkan, mengumpulkan, dan mengirim data telemetry dari aplikasi.

Data telemetry ini biasanya mencakup:

  • traces
  • metrics
  • logs

Tujuannya adalah supaya aplikasi bisa ngirim data observability dengan format dan pendekatan yang lebih konsisten, tanpa terlalu bergantung ke satu vendor tertentu.

Simpelnya, OpenTelemetry bantu engineer melakukan instrumentasi aplikasi dengan cara yang lebih portabel dan lebih aman buat jangka panjang.

Kenapa Kita Butuh OpenTelemetry?

Sebelum ada pendekatan standar kayak OpenTelemetry, tim observability biasanya sering ketemu masalah kayak:

  • tiap vendor punya agent dan format masing-masing
  • implementasi observability jadi nggak konsisten
  • pindah vendor itu ribet banget
  • instrumentasi aplikasi sering harus dirombak kalau ganti tools

Contohnya, sebuah tim mungkin awalnya pakai satu observability backend, terus beberapa bulan kemudian pengen coba platform lain. Tanpa standar yang jelas, perubahan kayak gitu bisa bikin banyak kerja ulang di sisi aplikasi.

OpenTelemetry hadir buat ngurangin ribetnya itu.

Telemetry Data: Sebenarnya Kita Ngumpulin Apa?

Biar lebih kebayang, mari lihat tiga jenis data utama yang paling sering dibahas dalam observability modern.

1. Traces

Traces dipakai buat ngikutin perjalanan satu request waktu dia lewat beberapa komponen di dalam sistem.

Misalnya:

  • request masuk ke API gateway
  • diterusin ke auth service
  • diterusin ke user service
  • user service query ke database
  • response balik ke client

Dengan trace, kita bisa lihat alur request itu dari ujung ke ujung.

2. Metrics

Metrics adalah angka-angka yang menggambarkan kondisi sistem dari waktu ke waktu.

Contohnya:

  • latency
  • throughput
  • error rate
  • CPU usage
  • memory usage

Metrics kepakai banget buat alerting, analisis tren, dan dashboard monitoring.

3. Logs

Logs adalah catatan detail dari event-event yang terjadi di dalam sistem.

Contohnya:

  • request diterima
  • token tidak valid
  • query gagal
  • panic berhasil di-recover
  • background job selesai dijalankan

Dalam praktiknya, logs, metrics, dan traces itu saling melengkapi.

OpenTelemetry Itu Tool atau Standar?

Banyak orang yang baru masuk ke dunia observability ngira OpenTelemetry itu dashboard atau aplikasi UI. Padahal bukan.

OpenTelemetry bukan tool visualisasi kayak Grafana, dan juga bukan tracing UI kayak Jaeger.

OpenTelemetry lebih pas dipahami sebagai:

  • standar
  • API
  • SDK
  • ekosistem instrumentasi

Jadi, OpenTelemetry bantu aplikasi buat menghasilkan dan mengirim data telemetry.
Tapi buat nyimpen dan nampilin data itu, biasanya kita tetap butuh observability backend lain.

Komponen Utama OpenTelemetry

Biar lebih gampang dipahami, ini beberapa komponen penting dalam ekosistem OpenTelemetry.

API

API adalah antarmuka yang dipakai developer waktu instrumentasi kode.

Misalnya, waktu kita mau bikin trace atau span di dalam kode, kita berinteraksi lewat API ini.

SDK

SDK yang menangani implementasi teknis dari data telemetry itu.

Biasanya, di sinilah logic untuk hal-hal seperti ini berada:

  • gimana span dibuat
  • gimana data dikumpulkan
  • gimana sampling dilakukan
  • gimana data diekspor

Instrumentation

Instrumentation adalah proses menambahkan kemampuan observability ke aplikasi.

Biasanya ada dua cara:

  • manual instrumentation
    Developer nambahin span, event, atau attribute langsung di dalam kode.

  • automatic instrumentation
    Library atau framework tertentu diinstrumentasi secara otomatis.

Exporter

Exporter bertugas buat ngirim data telemetry ke tujuan tertentu.

Contohnya, data trace bisa dikirim ke tracing backend atau ke collector.

Collector

OpenTelemetry Collector adalah komponen terpisah yang bisa menerima, memproses, lalu meneruskan data telemetry ke berbagai backend.

Collector sering dipakai supaya aplikasi nggak perlu ngomong langsung ke banyak sistem observability sekaligus.

Alurnya Kerja Kayak Gimana?

Secara sederhana, alur kerja OpenTelemetry biasanya kayak gini:

  1. aplikasi menghasilkan data telemetry
  2. data diproses oleh OpenTelemetry SDK
  3. data dikirim lewat exporter atau collector
  4. observability backend menerima dan menampilkan data

Kalau dibikin mental model, alurnya jadi seperti ini:

Application → OpenTelemetry → Collector / Exporter → Observability Backend

Backend-nya bisa beda-beda tergantung kebutuhan. Yang penting, aplikasinya udah diinstrumentasi dengan pendekatan yang lebih standar.

Kenapa OpenTelemetry Makin Penting?

Ada beberapa alasan kenapa OpenTelemetry makin relevan, terutama buat backend engineer dan tim SRE.

1. Vendor-neutral

OpenTelemetry nggak dibuat buat ngunci user ke satu platform tertentu. Ini penting banget buat menghindari vendor lock-in.

2. Instrumentasi lebih konsisten

Dengan pendekatan yang standar, instrumentasi antar service dan antar bahasa pemrograman jadi jauh lebih konsisten.

3. Cocok buat arsitektur modern

Di sistem yang isinya banyak service, container, dan runtime yang beda-beda, punya standar yang konsisten itu sangat membantu.

4. Lebih gampang diskalakan

Semakin besar sistem, biasanya kebutuhan observability juga makin besar. OpenTelemetry ngasih fondasi yang fleksibel buat kebutuhan jangka panjang.

OpenTelemetry dan Distributed Tracing

Salah satu use case OpenTelemetry yang paling populer adalah distributed tracing.

Kenapa?

Karena distributed tracing menjawab salah satu masalah paling umum di sistem modern:
gimana cara ngelacak satu request yang lewat banyak service?

OpenTelemetry memungkinkan tiap bagian sistem nambahin context ke perjalanan request itu, jadi alurnya bisa kelihatan dengan jelas.

Nanti trace ini bisa dikirim ke backend seperti Jaeger buat divisualisasikan.

OpenTelemetry vs Jaeger: Bedanya Apa?

Ini pertanyaan yang sering banget muncul.

Jawaban singkatnya:

  • OpenTelemetry: standar dan tooling buat menghasilkan dan mengekspor data telemetry
  • Jaeger: backend / UI buat menyimpan dan menampilkan traces

Jadi, keduanya bukan kompetitor langsung.
Malah, sering banget dipakai barengan.

OpenTelemetry bantu aplikasi bikin trace.
Jaeger bantu kita melihat trace itu.

Kapan Engineer Perlu Belajar OpenTelemetry?

Kalau lu kerja di area-area seperti ini, OpenTelemetry sangat layak buat dipelajari:

  • backend development
  • microservices
  • platform engineering
  • cloud-native systems
  • SRE
  • performance troubleshooting
  • incident investigation

Bahkan di aplikasi yang belum terlalu besar pun, paham OpenTelemetry dari awal bisa bantu lu bangun fondasi observability yang jauh lebih bagus.

Penutup

OpenTelemetry adalah salah satu fondasi penting dalam observability modern.

Dia bukan dashboard, bukan vendor, dan bukan cuma library tracing biasa. OpenTelemetry adalah standar terbuka yang bantu aplikasi menghasilkan data telemetry dengan cara yang lebih konsisten, lebih portabel, dan siap dikirim ke berbagai observability backend.

Kalau observability bantu kita memahami apa yang terjadi di dalam sistem, maka OpenTelemetry bantu aplikasi "ngomong dengan bahasa yang lebih standar" supaya pemahaman itu bisa benar-benar terwujud.

Di artikel berikutnya, kita bakal bahas lebih dalam soal distributed tracing: apa itu trace, apa itu span, dan gimana satu request bisa dilacak dari satu service ke service lainnya.

Selamat membaca 🚀