Apakah OpenTelemetry dan Bagaimana Ia Boleh Meningkatkan Kualiti Bahagian Belakang Anda?

Pada masa lalu, apabila kita bercakap tentang bahagian belakang, kita biasanya merujuk kepada satu aplikasi besar dengan pangkalan data tunggal yang besar, dan pembalakan adalah mencukupi untuk pemantauan. Kini, terima kasih kepada teknologi seperti Kubernetes , perkhidmatan mikro telah menjadi standard. Aplikasi lebih banyak dan diedarkan, dan pengelogan tradisional tidak lagi mencukupi untuk menyahpepijat dan mendiagnosis masalah dalam aplikasi kami.

Penyelesaian terbaik untuk mengatur pemantauan ialah OpenTelemetry — kit alat moden yang boleh digunakan untuk penyahpepijatan dan analisis prestasi sistem teragih.

Artikel ini ditujukan untuk profesional IT yang ingin mengembangkan pengetahuan mereka dalam pengoptimuman bahagian belakang. Di bawah, kami akan memperincikan apa itu OpenTelemetry, konsep utamanya, dan masalah yang ia bantu selesaikan. Jika anda berminat dengan cara OpenTelemetry boleh mengubah pendekatan anda untuk memantau dan menyahpepijat sistem bahagian belakang, meningkatkan kebolehpercayaan dan kecekapannya — baca terus.

Sejarah Ringkas OpenTelemetry

Syarikat teknologi besar pertama kali menghadapi cabaran pembalakan dan pengesanan yang diedarkan pada akhir 2000-an. Pada tahun 2010, Google menerbitkan kertas kerja, Dapper, Infrastruktur Pengesanan Sistem Teragih Berskala Besar , yang meletakkan asas untuk alat pengesanan Twitter, Zipkin, dikeluarkan pada 2012.

Pada tahun 2014, Kubernetes muncul, dengan ketara memudahkan pembangunan perkhidmatan mikro dan sistem pengedaran awan yang lain. Ini menyebabkan banyak syarikat menghadapi masalah dengan pengelogan dan pengesanan yang diedarkan dalam perkhidmatan mikro. Untuk menyeragamkan pengesanan teragih, piawaian OpenTracing, yang diterima pakai oleh CNCF, dan projek OpenCensus Google telah dicipta.

Pada 2019, projek OpenTracing dan OpenCensus mengumumkan penggabungan di bawah nama OpenTelemetry. Platform ini menggabungkan amalan terbaik yang terkumpul selama bertahun-tahun, membolehkan penyepaduan yang lancar bagi pengesanan, pengelogan dan metrik ke dalam mana-mana sistem, tanpa mengira kerumitannya.

Hari ini, OpenTelemetry bukan sekadar projek; ia adalah piawaian industri untuk mengumpul dan menghantar data telemetri. Ia dibangunkan dan disokong oleh komuniti pakar dan syarikat peneraju pasaran seperti Google dan Microsoft. Projek ini terus berkembang, memperoleh keupayaan baharu untuk memudahkan proses penyepaduan dan penggunaan.

Apa yang ada di dalam?

OpenTelemetry ialah set amalan dan alatan yang komprehensif yang mentakrifkan isyarat yang boleh dihasilkan oleh aplikasi untuk berinteraksi dengan dunia luar, dan cara isyarat ini boleh dikumpul dan divisualisasikan untuk memantau keadaan aplikasi dan sistem secara keseluruhan. Tiga jenis isyarat utama ialah pengesanan, pengelogan dan pengumpulan metrik .

**Mari kita lihat dengan lebih dekat setiap komponen: \

Konteks

OpenTelemetry memperkenalkan konsep konteks operasi. Konteks terutamanya termasuk atribut seperti `trace_id` (pengecam untuk operasi semasa) dan `span_id` (pengecam untuk sub-permintaan, dengan setiap percubaan semula sub-permintaan mempunyai `span_id` yang unik).

Selain itu, konteks boleh mengandungi maklumat statik, seperti nama nod tempat aplikasi digunakan atau nama persekitaran (prod/qa). Medan ini, yang dikenali sebagai sumber dalam terminologi OpenTelemetry, dilampirkan pada setiap log, metrik atau surih untuk kebolehcarian yang lebih mudah. Konteks juga boleh termasuk data dinamik, seperti pengecam titik akhir semasa ( `http_path: "GET /user/:id/info"` ), yang boleh dilampirkan secara terpilih pada kumpulan log, metrik atau surih.

Konteks OpenTelemetry boleh dihantar antara aplikasi yang berbeza menggunakan protokol penyebaran konteks. Protokol ini terdiri daripada set pengepala yang ditambahkan pada setiap permintaan HTTP atau gRPC atau pengepala mesej untuk baris gilir. Ini membolehkan aplikasi hiliran membina semula konteks operasi daripada pengepala ini.

Berikut ialah beberapa contoh penyebaran konteks:

1. B3-Propagation Ini ialah set pengepala ( x-b3-* ) yang asalnya dibangunkan untuk sistem pengesanan Zipkin. Ia telah disesuaikan ke dalam OpenTracing dan digunakan oleh banyak alat dan perpustakaan. B3-Propagation membawa trace_id / span_id dan bendera yang menunjukkan sama ada pensampelan diperlukan.

   
   

2. Konteks Jejak W3C Dibangunkan oleh kumpulan kerja W3C, piawaian ini menyatukan pelbagai pendekatan penyebaran konteks ke dalam satu piawaian dan merupakan lalai dalam OpenTelemetry. Contoh yang baik untuk menggunakan piawaian ini ialah menjejaki pelaksanaan permintaan yang melalui perkhidmatan mikro yang dilaksanakan dengan teknologi yang berbeza tanpa menjejaskan ketepatan pemantauan dan penyahpepijatan.

Menjejak

Pengesanan ialah proses merakam dan seterusnya menggambarkan garis masa laluan permintaan melalui berbilang perkhidmatan mikro.

Dalam visualisasi, setiap bar dipanggil "span" dan mempunyai "span_id" yang unik. Rentang akar dirujuk sebagai "trace" dan mempunyai "trace_id" , yang berfungsi sebagai pengecam untuk keseluruhan permintaan.

Jenis visualisasi ini membolehkan anda:

• Menganalisis masa pelaksanaan permintaan merentas sistem dan pangkalan data yang berbeza untuk mengenal pasti kesesakan yang memerlukan pengoptimuman.
• Kesan pergantungan kitaran antara perkhidmatan.
• Cari permintaan pendua. Menggunakan data pengesanan, anda juga boleh membina analitik tambahan, seperti membuat peta perkhidmatan mikro atau mengagihkan masa merentas sistem yang berbeza semasa pemprosesan operasi. Walaupun anda tidak menggunakan data surih untuk menggambarkan garis masa, OpenTelemetry masih menghasilkan trace_id dan span_id untuk digunakan dalam isyarat lain.

Log

Walaupun nampak mudah, pembalakan kekal sebagai salah satu alat yang paling berkuasa untuk mendiagnosis masalah. OpenTelemetry meningkatkan pembalakan tradisional dengan menambahkan maklumat kontekstual. Khususnya, jika jejak aktif hadir, atribut `trace_id` dan `span_id` ditambahkan secara automatik pada log, memautkannya ke garis masa jejak. Selain itu, atribut log boleh termasuk maklumat statik daripada konteks OpenTelemetry, seperti pengecam nod, serta maklumat dinamik, seperti pengecam titik akhir HTTP semasa (`http_path: "GET /user/:id"`).

Menggunakan `trace_id`, anda boleh mencari log daripada semua perkhidmatan mikro yang dikaitkan dengan permintaan semasa, manakala `span_id` membolehkan anda membezakan antara sub-permintaan. Sebagai contoh, dalam kes percubaan semula, log daripada percubaan berbeza akan mempunyai `span_id` yang berbeza. Menggunakan pengecam ini membolehkan analisis pantas bagi keseluruhan tingkah laku sistem dalam masa nyata, mempercepatkan diagnosis masalah dan meningkatkan kestabilan dan kebolehpercayaan.

Metrik

Pengumpulan metrik menyediakan data kuantitatif tentang prestasi sistem, seperti kependaman, kadar ralat, penggunaan sumber dan banyak lagi. Pemantauan masa nyata bagi metrik membolehkan anda bertindak balas dengan segera kepada perubahan prestasi, mencegah kegagalan dan keletihan sumber serta memastikan ketersediaan dan kebolehpercayaan aplikasi yang tinggi untuk pengguna.

Penyepaduan dengan sistem storan dan visualisasi metrik seperti Prometheus dan Grafana menjadikannya lebih mudah untuk memvisualisasikan data ini, sekaligus memudahkan pemantauan dengan ketara.

Pengumpul Metrik

Pengumpul metrik OpenTelemetry serasi dengan piawaian Prometheus dan OpenMetrics, membolehkan peralihan mudah kepada penyelesaian OpenTelemetry tanpa perubahan ketara. SDK OpenTelemetry membenarkan contoh trace_id dieksport bersama-sama dengan metrik, menjadikannya mungkin untuk mengaitkan metrik dengan contoh dan jejak log.

Korelasi Isyarat

Bersama-sama, log, metrik dan penjejakan mencipta pandangan menyeluruh tentang keadaan sistem:

• Log memberikan maklumat tentang peristiwa sistem, membolehkan pengenalpastian cepat dan penyelesaian ralat.
• Metrik mencerminkan penunjuk prestasi kualitatif dan kuantitatif sistem, seperti masa tindak balas atau kadar ralat.
• Penjejakan melengkapkan pandangan ini dengan menunjukkan laluan pelaksanaan permintaan melalui pelbagai komponen sistem, membantu memahami perkaitan mereka. Korelasi yang jelas antara log, jejak dan metrik adalah ciri tersendiri OpenTelemetry. Sebagai contoh, Grafana membolehkan pengguna melihat jejak yang sepadan dan metrik permintaan apabila melihat log, meningkatkan kebolehgunaan dan kecekapan platform dengan banyak.

Sebagai tambahan kepada tiga komponen teras, OpenTelemetry merangkumi konsep Persampelan, Bagasi dan pengurusan konteks operasi.

Pensampelan

Dalam sistem beban tinggi, volum log dan jejak menjadi besar, memerlukan sumber yang besar untuk infrastruktur dan penyimpanan data. Untuk menangani isu ini, piawaian OpenTelemetry termasuk pensampelan isyarat — keupayaan untuk mengeksport hanya sebahagian daripada jejak dan log. Sebagai contoh, anda boleh mengeksport isyarat terperinci daripada peratusan permintaan, permintaan jangka panjang atau permintaan ralat. Pendekatan ini membolehkan pensampelan yang mencukupi untuk membina statistik sambil menjimatkan sumber yang penting.

Walau bagaimanapun, jika setiap sistem secara bebas memutuskan permintaan untuk dipantau secara terperinci, kami akan mendapat pandangan berpecah-belah bagi setiap permintaan. Sesetengah sistem mungkin mengeksport data terperinci manakala yang lain mungkin hanya mengeksport sebahagian atau tidak mengeksport langsung.

Untuk menyelesaikan masalah ini, mekanisme penyebaran konteks OpenTelemetry menghantar bendera pensampelan bersama-sama dengan `trace_id`/`span_id`. Ini memastikan bahawa jika perkhidmatan awal yang menerima permintaan pengguna memutuskan bahawa permintaan itu perlu dipantau secara terperinci, semua sistem lain akan mengikutinya. Jika tidak, semua sistem harus mengeksport sebahagian atau tidak isyarat untuk menjimatkan sumber. Pendekatan ini dipanggil "Pensampelan Kepala" — keputusan yang dibuat pada permulaan pemprosesan permintaan, sama ada secara rawak atau berdasarkan beberapa atribut input.

Selain itu, OpenTelemetry menyokong "Pensampelan Ekor," di mana semua aplikasi sentiasa mengeksport semua isyarat secara terperinci, tetapi penimbal perantaraan wujud. Selepas mengumpul semua data, penimbal ini memutuskan sama ada untuk mengekalkan data penuh atau menyimpan hanya sebahagian sampel. Kaedah ini membenarkan sampel yang lebih mewakili setiap kategori permintaan (berjaya/lama/ralat) tetapi memerlukan persediaan infrastruktur tambahan.

Bagasi

Mekanisme Bagasi membenarkan pasangan nilai kunci sewenang-wenangnya dihantar bersama-sama dengan trace_id / span_id , secara automatik menghantar antara semua perkhidmatan mikro semasa pemprosesan permintaan. Ini berguna untuk menghantar maklumat tambahan yang diperlukan sepanjang laluan permintaan—seperti maklumat pengguna atau tetapan persekitaran masa jalan.

Contoh pengepala untuk menghantar bagasi mengikut standard W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Berikut ialah beberapa contoh penggunaan Bagasi:

• Melepasi Maklumat Konteks Perniagaan seperti userId , productId atau deviceId boleh dihantar melalui semua perkhidmatan mikro. Aplikasi boleh log maklumat ini secara automatik, membenarkan carian log mengikut konteks pengguna untuk permintaan asal.

• Tetapan Parameter Konfigurasi Khusus untuk SDK atau infrastruktur.

• Bendera Penghalaan Bendera yang membantu pengimbang beban membuat keputusan penghalaan. Semasa ujian, beberapa permintaan mungkin perlu dihalakan untuk mengejek bahagian belakang. Memandangkan bagasi dihantar secara automatik melalui semua perkhidmatan, tidak perlu membuat protokol tambahan—hanya sediakan peraturan pada pengimbang beban.

  
  

Pelaksanaan Infrastruktur

Melaksanakan OpenTelemetry pada peringkat infrastruktur melibatkan penyepaduan bahagian belakang OpenTelemetry ke dalam seni bina aplikasi dan mengkonfigurasi infrastruktur untuk pengagregatan data.

Proses ini terdiri daripada empat peringkat:

1. Penyepaduan Aplikasi Pada peringkat pertama, OpenTelemetry SDK disepadukan secara langsung ke dalam aplikasi untuk mengumpul metrik, log dan jejak, memastikan aliran data berterusan tentang prestasi setiap komponen sistem.

   
   

2. Mengkonfigurasi Pengeksport Data yang dikumpul dialihkan daripada aplikasi melalui pengeksport ke sistem luaran untuk pemprosesan selanjutnya, seperti pengelogan, pemantauan, pengesanan atau sistem analitik, bergantung pada keperluan anda.

   
   

3. Pengagregatan dan Penyimpanan Peringkat ini mungkin melibatkan menormalkan data, memperkayakannya dengan maklumat tambahan dan menggabungkan data daripada sumber yang berbeza untuk mencipta pandangan bersatu tentang keadaan sistem.

   
   

4. Visualisasi Data Akhir sekali, data yang diproses dipersembahkan sebagai papan pemuka dalam sistem seperti Grafana (untuk metrik dan jejak) atau Kibana (untuk log). Ini membolehkan pasukan menilai kesihatan sistem dengan cepat, mengenal pasti isu dan arah aliran serta menyediakan makluman berdasarkan isyarat yang dijana.

Pelaksanaan Aplikasi

Untuk menyepadukan dengan aplikasi, anda perlu menyambungkan OpenTelemetry SDK yang sesuai untuk bahasa pengaturcaraan yang digunakan atau menggunakan perpustakaan dan rangka kerja yang menyokong OpenTelemetry secara langsung. OpenTelemetry sering melaksanakan antara muka yang digunakan secara meluas daripada perpustakaan yang diketahui, membenarkan penggantian drop-in. Sebagai contoh, pustaka Mikrometer biasanya digunakan untuk pengumpulan metrik dalam ekosistem Java. SDK OpenTelemetry menyediakan pelaksanaan antara muka Mikrometer, membolehkan eksport metrik tanpa mengubah kod aplikasi utama. Selain itu, OpenTelemetry menawarkan pelaksanaan antara muka OpenTracing dan OpenCensus yang lebih lama, memudahkan pemindahan lancar ke OpenTelemetry.

Kesimpulan

Dalam sistem IT, OpenTelemetry boleh menjadi kunci kepada masa depan backend yang boleh dipercayai dan cekap. Alat ini memudahkan penyahpepijatan dan pemantauan dan juga membuka peluang untuk pemahaman yang mendalam tentang prestasi aplikasi dan pengoptimuman pada tahap baharu. Sertai komuniti OpenTelemetry untuk membantu membentuk masa depan di mana pembangunan bahagian belakang lebih mudah dan berkesan!