Apa itu OpenTelemetry dan Bagaimana Itu Dapat Meningkatkan Kualitas Backend Anda?

Dulu, saat kita berbicara tentang backend, kita biasanya merujuk pada satu aplikasi besar dengan satu database besar, dan pencatatan log sudah cukup untuk pemantauan. Kini, berkat teknologi seperti Kubernetes , layanan mikro telah menjadi standar. Aplikasi lebih banyak jumlahnya dan terdistribusi, dan pencatatan log tradisional tidak lagi cukup untuk men-debug dan mendiagnosis masalah dalam aplikasi kita.

Solusi terbaik untuk mengatur pemantauan adalah OpenTelemetry — perangkat modern yang dapat digunakan untuk debugging dan analisis kinerja sistem terdistribusi.

Artikel ini ditujukan bagi para profesional TI yang ingin memperluas pengetahuan mereka dalam optimasi backend. Di bawah ini, kami akan merinci apa itu OpenTelemetry, konsep utamanya, dan masalah yang dapat dipecahkannya. Jika Anda tertarik dengan bagaimana OpenTelemetry dapat mengubah pendekatan Anda dalam memantau dan men-debug sistem backend, meningkatkan keandalan dan efisiensinya — baca terus.

Sejarah Singkat OpenTelemetry

Perusahaan teknologi besar pertama kali menghadapi tantangan pencatatan dan penelusuran terdistribusi pada akhir tahun 2000-an. Pada tahun 2010, Google menerbitkan sebuah makalah, Dapper, Infrastruktur Penelusuran Sistem Terdistribusi Skala Besar , yang meletakkan dasar bagi alat pelacakan Twitter, Zipkin, yang dirilis pada tahun 2012.

Pada tahun 2014, Kubernetes muncul, yang secara signifikan menyederhanakan pengembangan layanan mikro dan sistem terdistribusi cloud lainnya. Hal ini menyebabkan banyak perusahaan mengalami masalah dengan pencatatan dan pelacakan terdistribusi dalam layanan mikro. Untuk menstandardisasi pelacakan terdistribusi, standar OpenTracing, yang diadopsi oleh CNCF, dan proyek OpenCensus Google dibuat.

Pada tahun 2019, proyek OpenTracing dan OpenCensus mengumumkan penggabungan dengan nama OpenTelemetry. Platform ini menggabungkan praktik terbaik yang terkumpul selama bertahun-tahun, sehingga memungkinkan integrasi pelacakan, pencatatan, dan metrik yang lancar ke dalam sistem apa pun, terlepas dari kompleksitasnya.

Saat ini, OpenTelemetry bukan sekadar proyek; ini adalah standar industri untuk mengumpulkan dan mengirimkan data telemetri. Proyek ini dikembangkan dan didukung oleh komunitas spesialis dan perusahaan terkemuka di pasar seperti Google dan Microsoft. Proyek ini terus berkembang, memperoleh kemampuan baru untuk menyederhanakan proses integrasi dan penggunaan.

Apa isinya?

OpenTelemetry adalah seperangkat praktik dan alat yang komprehensif yang menentukan sinyal apa yang dapat dihasilkan aplikasi untuk berinteraksi dengan dunia luar, dan bagaimana sinyal ini dapat dikumpulkan dan divisualisasikan untuk memantau status aplikasi dan sistem secara keseluruhan. Tiga jenis sinyal utama adalah pelacakan, pencatatan , dan pengumpulan metrik .

**Mari kita lihat lebih dekat setiap komponen: \

Konteks

OpenTelemetry memperkenalkan konsep konteks operasi. Konteks terutama mencakup atribut seperti `trace_id` (pengidentifikasi untuk operasi saat ini) dan `span_id` (pengidentifikasi untuk sub-permintaan, dengan setiap percobaan ulang sub-permintaan memiliki `span_id` yang unik).

Selain itu, konteks dapat berisi informasi statis, seperti nama node tempat aplikasi diterapkan atau nama lingkungan (prod/qa). Kolom ini, yang dikenal sebagai sumber daya dalam terminologi OpenTelemetry, dilampirkan ke setiap log, metrik, atau jejak untuk memudahkan pencarian. Konteks juga dapat menyertakan data dinamis, seperti pengenal titik akhir saat ini ( `http_path: "GET /user/:id/info"` ), yang dapat dilampirkan secara selektif ke grup log, metrik, atau jejak.

Konteks OpenTelemetry dapat diteruskan di antara berbagai aplikasi menggunakan protokol penyebaran konteks. Protokol ini terdiri dari kumpulan header yang ditambahkan ke setiap permintaan HTTP atau gRPC atau header pesan untuk antrean. Hal ini memungkinkan aplikasi hilir untuk merekonstruksi konteks operasi dari header ini.

Berikut adalah beberapa contoh propagasi konteks:

1. B3-Propagation Ini adalah sekumpulan header ( x-b3-* ) yang awalnya dikembangkan untuk sistem pelacakan Zipkin. Header ini diadaptasi ke dalam OpenTracing dan digunakan oleh banyak alat dan pustaka. B3-Propagation membawa trace_id / span_id dan sebuah tanda yang menunjukkan apakah pengambilan sampel diperlukan.

   
   

2. W3C Trace Context Dikembangkan oleh kelompok kerja W3C, standar ini menyatukan berbagai pendekatan propagasi konteks ke dalam satu standar dan merupakan standar bawaan dalam OpenTelemetry. Contoh penerapan standar ini adalah pelacakan eksekusi permintaan yang melewati layanan mikro yang diimplementasikan dengan teknologi berbeda tanpa mengorbankan akurasi pemantauan dan debugging.

Pelacakan

Penelusuran adalah proses perekaman dan kemudian memvisualisasikan garis waktu jalur permintaan melalui beberapa layanan mikro.

Dalam visualisasi, setiap bar disebut "span" dan memiliki "span_id" yang unik. Span akar disebut sebagai "trace" dan memiliki "trace_id" yang berfungsi sebagai pengenal untuk seluruh permintaan.

Jenis visualisasi ini memungkinkan Anda untuk:

• Menganalisis waktu eksekusi permintaan di berbagai sistem dan basis data untuk mengidentifikasi hambatan yang memerlukan pengoptimalan.
• Mendeteksi ketergantungan siklus antara layanan.
• Temukan permintaan duplikat. Dengan menggunakan data pelacakan, Anda juga dapat membuat analitik tambahan, seperti membuat peta layanan mikro atau mendistribusikan waktu di berbagai sistem selama pemrosesan operasi. Bahkan jika Anda tidak menggunakan data pelacakan untuk memvisualisasikan garis waktu, OpenTelemetry tetap menghasilkan trace_id dan span_id untuk digunakan dalam sinyal lain.

Catatan

Meskipun tampak sederhana, pencatatan log tetap menjadi salah satu alat paling ampuh untuk mendiagnosis masalah. OpenTelemetry menyempurnakan pencatatan log tradisional dengan menambahkan informasi kontekstual. Secara khusus, jika jejak aktif ada, atribut `trace_id` dan `span_id` secara otomatis ditambahkan ke log, yang menautkannya ke linimasa jejak. Selain itu, atribut log dapat mencakup informasi statis dari konteks OpenTelemetry, seperti pengenal simpul, serta informasi dinamis, seperti pengenal titik akhir HTTP saat ini (`http_path: "GET /user/:id"`).

Dengan menggunakan `trace_id`, Anda dapat menemukan log dari semua layanan mikro yang terkait dengan permintaan saat ini, sementara `span_id` memungkinkan Anda membedakan antara sub-permintaan. Misalnya, dalam kasus percobaan ulang, log dari berbagai percobaan akan memiliki `span_id` yang berbeda. Penggunaan pengenal ini memungkinkan analisis cepat terhadap seluruh perilaku sistem secara real-time, mempercepat diagnosis masalah, dan meningkatkan stabilitas serta keandalan.

Metrik

Pengumpulan metrik menyediakan data kuantitatif tentang kinerja sistem, seperti latensi, tingkat kesalahan, penggunaan sumber daya, dan banyak lagi. Pemantauan metrik secara real-time memungkinkan Anda untuk segera menanggapi perubahan kinerja, mencegah kegagalan dan kehabisan sumber daya, serta memastikan ketersediaan dan keandalan aplikasi yang tinggi bagi pengguna.

Integrasi dengan sistem penyimpanan dan visualisasi metrik seperti Prometheus dan Grafana memudahkan visualisasi data ini, sehingga menyederhanakan pemantauan secara signifikan.

Kolektor Metrik

Pengumpul metrik OpenTelemetry kompatibel dengan standar Prometheus dan OpenMetrics, yang memungkinkan transisi mudah ke solusi OpenTelemetry tanpa perubahan signifikan. SDK OpenTelemetry memungkinkan contoh trace_id diekspor bersama metrik, sehingga memungkinkan untuk menghubungkan metrik dengan contoh log dan jejak.

Korelasi Sinyal

Bersama-sama, log, metrik, dan penelusuran menciptakan pandangan komprehensif tentang status sistem:

• Log menyediakan informasi tentang kejadian sistem, yang memungkinkan identifikasi dan penyelesaian kesalahan secara cepat.
• Metrik mencerminkan indikator kinerja kualitatif dan kuantitatif suatu sistem, seperti waktu respons atau tingkat kesalahan.
• Penelusuran melengkapi tampilan ini dengan menunjukkan jalur eksekusi permintaan melalui berbagai komponen sistem, membantu memahami hubungan timbal baliknya. Korelasi yang jelas antara log, jejak, dan metrik merupakan fitur khas OpenTelemetry. Misalnya, Grafana memungkinkan pengguna untuk melihat jejak dan metrik permintaan yang sesuai saat melihat log, yang sangat meningkatkan kegunaan dan efisiensi platform.

Selain tiga komponen inti, OpenTelemetry menyertakan konsep Pengambilan Sampel, Bagasi, dan manajemen konteks operasi.

Contoh

Dalam sistem dengan beban tinggi, volume log dan jejak menjadi sangat besar, sehingga memerlukan sumber daya yang besar untuk infrastruktur dan penyimpanan data. Untuk mengatasi masalah ini, standar OpenTelemetry mencakup pengambilan sampel sinyal — kemampuan untuk mengekspor hanya sebagian jejak dan log. Misalnya, Anda dapat mengekspor sinyal terperinci dari persentase permintaan, permintaan yang berjalan lama, atau permintaan kesalahan. Pendekatan ini memungkinkan pengambilan sampel yang cukup untuk membangun statistik sekaligus menghemat sumber daya yang signifikan.

Namun, jika setiap sistem secara independen memutuskan permintaan mana yang akan dipantau secara terperinci, kita akan mendapatkan tampilan yang terfragmentasi dari setiap permintaan. Beberapa sistem dapat mengekspor data terperinci sementara yang lain mungkin hanya mengekspor sebagian atau tidak mengekspor sama sekali.

Untuk mengatasi masalah ini, mekanisme propagasi konteks OpenTelemetry mengirimkan tanda pengambilan sampel bersama dengan `trace_id`/`span_id`. Ini memastikan bahwa jika layanan awal yang menerima permintaan pengguna memutuskan bahwa permintaan tersebut harus dipantau secara terperinci, semua sistem lain akan mengikutinya. Jika tidak, semua sistem harus mengekspor sinyal sebagian atau tidak untuk menghemat sumber daya. Pendekatan ini disebut "Head Sampling" — keputusan yang dibuat di awal pemrosesan permintaan, baik secara acak atau berdasarkan beberapa atribut input.

Selain itu, OpenTelemetry mendukung "Tail Sampling," di mana semua aplikasi selalu mengekspor semua sinyal secara terperinci, tetapi ada buffer perantara. Setelah mengumpulkan semua data, buffer ini memutuskan apakah akan menyimpan data lengkap atau hanya menyimpan sebagian sampel. Metode ini memungkinkan sampel yang lebih representatif dari setiap kategori permintaan (berhasil/panjang/gagal) tetapi memerlukan pengaturan infrastruktur tambahan.

Bagasi

Mekanisme Baggage memungkinkan pasangan kunci-nilai acak untuk ditransmisikan bersama trace_id / span_id , yang secara otomatis diteruskan di antara semua layanan mikro selama pemrosesan permintaan. Ini berguna untuk mentransmisikan informasi tambahan yang dibutuhkan di seluruh jalur permintaan—seperti informasi pengguna atau pengaturan lingkungan runtime.

Contoh header untuk mengirimkan bagasi sesuai standar W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Berikut beberapa contoh penggunaan Bagasi:

• Informasi Konteks Bisnis seperti userId , productId , atau deviceId dapat diteruskan melalui semua layanan mikro. Aplikasi dapat secara otomatis mencatat informasi ini, yang memungkinkan pencarian log berdasarkan konteks pengguna untuk permintaan awal.

• Pengaturan Parameter Konfigurasi Khusus untuk SDK atau infrastruktur.

• Bendera Perutean Bendera yang membantu penyeimbang beban membuat keputusan perutean. Selama pengujian, beberapa permintaan mungkin perlu dirutekan ke backend tiruan. Karena bagasi ditransmisikan secara otomatis melalui semua layanan, tidak perlu membuat protokol tambahan—cukup atur aturan pada penyeimbang beban.

  
  

Implementasi Infrastruktur

Penerapan OpenTelemetry pada tingkat infrastruktur melibatkan pengintegrasian backend OpenTelemetry ke dalam arsitektur aplikasi dan konfigurasi infrastruktur untuk agregasi data.

Prosesnya terdiri dari empat tahap:

1. Integrasi Aplikasi Pada tahap pertama, SDK OpenTelemetry diintegrasikan langsung ke dalam aplikasi untuk mengumpulkan metrik, log, dan jejak, memastikan aliran data yang berkelanjutan tentang kinerja setiap komponen sistem.

   
   

2. Mengonfigurasi Eksportir Data yang dikumpulkan dirutekan dari aplikasi melalui eksportir ke sistem eksternal untuk diproses lebih lanjut, seperti sistem pencatatan, pemantauan, pelacakan, atau analitik, tergantung pada kebutuhan Anda.

   
   

3. Agregasi dan Penyimpanan Tahap ini mungkin melibatkan normalisasi data, memperkayanya dengan informasi tambahan, dan menggabungkan data dari berbagai sumber untuk membuat tampilan terpadu tentang status sistem.

   
   

4. Visualisasi Data Terakhir, data yang diproses disajikan sebagai dasbor dalam sistem seperti Grafana (untuk metrik dan jejak) atau Kibana (untuk log). Hal ini memungkinkan tim untuk menilai kesehatan sistem dengan cepat, mengidentifikasi masalah dan tren, serta menyiapkan peringatan berdasarkan sinyal yang dihasilkan.

Implementasi Aplikasi

Untuk melakukan integrasi dengan aplikasi, Anda perlu menghubungkan OpenTelemetry SDK yang sesuai untuk bahasa pemrograman yang digunakan atau menggunakan pustaka dan kerangka kerja yang secara langsung mendukung OpenTelemetry. OpenTelemetry sering kali mengimplementasikan antarmuka yang banyak digunakan dari pustaka yang dikenal, yang memungkinkan penggantian secara langsung. Misalnya, pustaka Micrometer umumnya digunakan untuk pengumpulan metrik dalam ekosistem Java. OpenTelemetry SDK menyediakan implementasi antarmuka Micrometer, yang memungkinkan ekspor metrik tanpa mengubah kode aplikasi utama. Selain itu, OpenTelemetry menawarkan implementasi antarmuka OpenTracing dan OpenCensus yang lebih lama, yang memfasilitasi migrasi yang lancar ke OpenTelemetry.

Kesimpulan

Dalam sistem TI, OpenTelemetry dapat menjadi kunci masa depan backend yang andal dan efisien. Alat ini menyederhanakan debugging dan pemantauan dan juga membuka peluang untuk pemahaman mendalam tentang kinerja dan pengoptimalan aplikasi pada tingkat yang baru. Bergabunglah dengan komunitas OpenTelemetry untuk membantu membentuk masa depan di mana pengembangan backend lebih sederhana dan lebih efektif!