Apa itu metrik OpenTelemetry?

Seperti log dan pelacakan OpenTelemetry dan metrik, metrik OTel menyediakan sinyal telemetri standar yang menggunakan model data umum yang netral bahasa dan protokol transmisi—tepatnya OpenTelemtetry Protocol (OTLP)—untuk menyerap data dari berbagai sumber, sistem, dan format dan mengirimkannya ke backend observabilitas . 

Metrik OTEL mengandalkan instrumentasi OpenTelemetry untuk mengumpulkan data deret waktu—seperti penggunaan CPU  dan memori, throughput, tingkat kesalahan, jumlah permintaan, dan waktu respons—dari aplikasi dan komponen infrastruktur saat berjalan. Setelah pengembang instrumen kode untuk merekam metrik yang diperlukan, oTel memungkinkan metrik tersebut untuk dikumpulkan dan diekspor ke (atau setiap) alat observabilitas backend untuk penyimpanan, kueri, dan visualisasi, semuanya tanpa mengubah instrumentasi.

Metrik biasanya merupakan sinyal telemetri pertama yang mengungkapkan masalah sistem. Dalam kerangka kerja oTEL, mereka terintegrasi dengan log (catatan abadi dari peristiwa sistem diskrit) dan jejak (perjalanan menyeluruh dari permintaan data) yang mengandalkan konsep dan metadata yang sama.

Dinamika ini memungkinkan pengembang dan insinyur keandalan situs (SRE) menggunakan metrik sebagai sistem peringatan dini tingkat tinggi. Mereka dapat mengikuti jalur lengkap kegagalan (termasuk metrik untuk setiap layanan yang berinteraksi dengan komponen yang gagal) dalam satu tampilan yang koheren dan dengan cepat beralih ke jejak dan log untuk analisis akar masalah.

Dalam praktiknya, ini berarti tim TI dapat beralih dari “ titik akhir ini lambat “ ke “permintaan dan dependensi spesifik ini adalah masalahnya “ hanya dalam beberapa klik.

Selain itu, protokol standardisasi oTel memfasilitasi korelasi sinyal otomatis di seluruh vendor observabilitas, memberi perusahaan fleksibilitas untuk mengganti alat observabilitas kapan pun mereka memilih atau menggunakan beberapa alat secara bersamaan.

Metrik OpenTelemetry adalah komponen dasar dari OpenTeleMetry. OpenTelemetry adalah kerangka kerja observabilitas sumber terbuka yang mencakup kumpulan kit pengembangan perangkat lunak (SDK), antarmuka pemrograman aplikasi (API) yang netral terhadap vendor dan alat-alat lain untuk instrumentasi aplikasi, sistem, dan perangkat.

Kode instrumentasi digunakan sangat bervariasi, dan tidak ada penyedia komersial tunggal yang menawarkan alat yang mampu mengumpulkan data dari setiap aplikasi dan layanan di jaringan. Kesenjangan fungsionalitas ini menyulitkan (dan seringkali, tidak mungkin) bagi tim untuk mengumpulkan data dari bahasa pemrograman, format, dan waktu proses yang berbeda.

Pendekatan observabilitas tradisional juga membuat perubahan infrastruktur dan komponen backend menjadi proses yang memakan waktu dan padat karya.

Katakanlah tim pengembangan ingin mengganti alat backend. Mereka harus sepenuhnya mengubah kode mereka dan mengonfigurasi agen baru (komponen perangkat lunak yang menjalankan tugas pembuatan dan rilis otomatis) untuk mengirim data telemetri ke server baru. Pendekatan terfragmentasi menciptakan silo data dan kebingungan, sehingga sulit untuk menyelesaikan masalah kinerja secara efektif.

OpenTelemetry merupakan kemajuan yang signifikan dalam alat observabilitas karena alat ini menstandardisasikan cara data telemetri dikumpulkan, dianalisis, dan dikirim ke platform backend. OpenTelemetry memberikan solusi sumber terbuka —berdasarkan standar berbasis komunitas—untuk mengumpulkan data tentang perilaku dan keamanan sistem, membantu tim merampingkan pemantauan dan observabilitas dalam ekosistem terdistribusi.

Metrik OpenTelemetry bergantung pada sekelompok komponen terkait yang bersama-sama menentukan bagaimana metrik diproduksi, dijelaskan, dan dikirim ke backend observabilitas. Termasuk:

Instrumen adalah alat yang digunakan kode untuk merekam nilai metrik. Mereka merekam nilai dalam dua cara: secara sinkron (langsung di jalur eksekusi, saat kode berjalan) dan secara asinkron (setiap kali SDK meminta nilai dari kode).

Karena berjalan sejalan dengan operasi, instrumen sinkron dapat menangkap konteks dan atribut jejak saat ini tentang peristiwa, membuat metrik yang mereka kumpulkan lebih mudah dikorelasikan dengan log dan jejak.

Instrumen asinkron diperbarui menggunakan fungsi callback berbasis pull yang dipanggil secara berkala oleh SDK berdasarkan interval pengumpulan yang telah ditetapkan sebelumnya. Instrumen-instrumen ini berguna untuk merekam nilai-nilai yang diambil sampelnya secara berkala, bukan setiap kali pengguna meminta (misalnya, penggunaan CPU atau memori). 

Instrumentasi oTel berada di antara logika aplikasi dan pipeline metrik, mengubah peristiwa, seperti “permintaan HTTP selesai,” menjadi pengukuran terstruktur yang dapat digabungkan dan diekspor oleh SDK. Setiap jenis instrumen metrik dioptimalkan untuk pola pengukuran tertentu dan memiliki strategi agregasi terkait yang menjelaskan bagaimana SDK harus menggabungkan pengukuran individual ke dalam metrik yang diekspor.

Jenis instrumen umum adalah:

• Penghitung adalah instrumen sinkron yang merekam kenaikan yang meningkat dari waktu ke waktu (seperti jumlah total permintaan atau total byte yang dikirim sejak proses dimulai). Penghitung juga monoton, jadi setiap kali mereka merekam pengukuran baru, mereka menambahkannya ke nilai yang ada alih-alih mengganti nilai yang ada.

• Penghitung UpDown adalah instrumen sinkron yang merekam nilai yang dapat meningkat atau berkurang seiring waktu (jumlah pengguna aktif atau ukuran antrean, misalnya). Tidak seperti Counter standar, Penghitung UpDown tidak monoton, sehingga mereka menyesuaikan total naik atau turun dengan mengganti nilai yang ada.

• Penghitung Asinkron dan Penghitung UpDown Asinkron mirip dengan rekan-rekan sinkronnya, tetapi mereka mencatat nilai sekali per ekspor alih-alih mengumpulkannya selama eksekusi kode.

• Pengukur adalah instrumen sinkron yang mencatat nilai yang dapat bertambah atau berkurang secara acak pada setiap pengiriman data, mewakili nilai pada saat data tersebut dikumpulkan dari kode. Selain pengukur sinkron, pengumpulan metrik memerlukan pengukur yang dapat diamati, yang merupakan instrumen asinkron yang menarik nilai saat ini setiap kali backend metrik mengumpulkan data.
  
  Pengukur menangkap snapshot nilai dengan cara yang sama seperti kamera menangkap snapshot subjek yang dituju. Dan karena pengukur bersifat non-kumulatif, alat ini biasanya diterapkan pada nilai non-aditif di mana penjumlahan tidak masuk akal (penggunaan memori atau suhu, misalnya).  

• Histogram adalah instrumen sinkron yang digunakan untuk merekam distribusi pengukuran di berbagai rentang nilai, bukan hanya melacak satu metrik (seperti nilai total atau nilai saat ini). Alat ini memasukkan nilai ke dalam “bucket”, memungkinkan tim TI menghitung persentil dan memahami distribusi nilai untuk metrik seperti durasi permintaan, latensi, dan ukuran muatan.

oTel mendefinisikan model data metrik standar dan deret waktu yang mengubah peristiwa metrik individu menjadi rangkaian angka berbasis waktu yang bersih, dapat dikueri, yang dapat disimpan dan dianalisis oleh tim TI dalam platform pengamatan.

OpenTelemetry menjelaskan metrik dengan menggunakan tiga model terkait: model Peristiwa (pengukuran mentah dari instrumen), model aliran OTLP (bagaimana pengukuran tersebut dibundel dan dikirim) dan model deret waktu (bagaimana backend menyimpannya).

Dalam praktiknya, kode aplikasi merekam peristiwa menggunakan model Peristiwa, SDK/kolektor mengubahnya menjadi aliran OTLP dan platform backend menyimpannya sebagai deret waktu, seperti “permintaan per detik untuk layanan X dengan status 200" dari waktu ke waktu.

Konvensi semantik—juga disebut konvensi penamaan—mendefinisikan nama standar, unit, dan kunci atribut untuk metrik umum sehingga layanan dan perpustakaan yang berbeda menghasilkan telemetri yang konsisten. Misalnya, konvensi meresepkan nama seperti “http.server.duration” untuk permintaan latensi HTTP server dan merekomendasikan unit seperti detik atau milidetik untuk durasi.

Menggunakan konvensi semantik oTel memungkinkan tim untuk memasukkan metrik ke dasbor bawaan dan sistem peringatan yang mengharapkan skema tertentu, yang mengurangi waktu yang mereka habiskan untuk melakukan pekerjaan konfigurasi khusus. Solusi ini juga membuat kolaborasi lintas tim lebih mudah karena semua orang berbicara “bahasa metrik” yang sama di seluruh layanan mikro.

Selain itu, fitur propagasi konteks dapat menghubungkan metrik dengan jejak terkait (dengan menggunakan contoh) dan log dengan membawa konteks bersama, seperti pengidentifikasi jejak atau rentang, melintasi batas.

Misalnya, propagator oTel dapat mengekstrak konteks masuk dari pengendali permintaan, memulai rentang pelacakan dengannya, dan menggunakan konteks yang sama untuk merekam metrik latensi dan menulis entri log. Dengan begitu, titik metrik dan garis log ditandai dengan jejak saat ini.

Saat kode aplikasi membuat panggilan hilir, propagator menyuntikkan konteks yang sama ke dalam permintaan keluar. Kode tersebut mengekstraknya, memulai span anakannya sendiri, dan menggunakan konteks tersebut untuk metrik dan log-nya sendiri, yang menjaga agar semuanya dari kedua layanan tetap terhubung ke jejak menyeluruh yang sama.

Atribut — juga dikenal sebagai label, tag, atau dimensi—adalah pasangan kunci-nilai yang melekat pada pengukuran individu atau titik data agregat. Mereka sepenuhnya atau sebagian mendefinisikan deret waktu di samping nama metrik, jenis agregasi dan unit. Tanpa atribut, semua pengukuran untuk metrik akan runtuh menjadi satu seri yang tidak terdiferensiasi.

Menambahkan atribut (seperti nama layanan, titik akhir, kode status HTTP, wilayah, atau ID penyewa) mengubah metrik sederhana menjadi aliran metrik khusus dimensi yang dapat diiris dan dipotong oleh tim dalam alat pengamatan. Tim bisa mendapatkan tampilan resolusi tinggi yang difilter atau dikelompokkan berdasarkan dimensi apa pun yang mereka pilih.

Desain atribut yang baik juga menyeimbangkan detail dengan kardinalitas metrik (jumlah nilai unik yang dapat diambil atribut), sehingga tim dapat menghindari ledakan label sambil tetap menjalankan kueri yang berguna.

Pengukuran adalah pembacaan tingkat peristiwa tunggal yang diambil oleh instrumen pada titik waktu tertentu dan sering disertai dengan atribut. Misalnya, ketika satu permintaan HTTP selesai, Anda dapat merekam latensi 120 milidetik dengan atribut seperti route=”/login” dan status_code=200 yang mewakili rute dan kode status.

Setiap rekaman individu adalah pengukuran terpisah yang menggambarkan apa yang terjadi selama satu operasi itu.

Pengukuran disimpan sebentar di dalam SDK, yang kemudian mengubah pengukuran mentah menjadi titik data dalam aliran metrik yang lebih besar. Alih-alih menampilkan setiap permintaan tunggal, titik data agregat mungkin menunjukkan “untuk rute /login dengan status 200, dari 10.00.00-10.00.10, ada 500 permintaan dengan total durasi 25 detik.” Titik data inilah yang akhirnya diekspor ke dan disimpan di backend observabilitas.

API metrik OpenTelemetry adalah kumpulan antarmuka yang dipanggil kode aplikasi untuk menghasilkan metrik. Ini dirancang untuk menjadi instrumentasi agnostik vendor, memisahkan dari implementasi SDK konkret. Tim TI dapat menulis instrumentasi sekali (dengan menggunakan API standar) dan kemudian menukar SDK, eksportir, dan backend tanpa mengambil langkah tambahan.

Tiga antarmuka inti membentuk struktur API metrik OTel: Penyedia Meter, Meter, dan instrumen metrik.

Penyedia Meter adalah titik masuk API dan bertanggung jawab untuk membuat instance meter. Alat ini menentukan pembaca dan eksportir metrik mana yang akan digunakan, tampilan dan agregasi apa yang akan diterapkan dan seberapa sering mengumpulkan dan mengekspor data. Penyedia Meter biasanya memuat satu kali selama startup aplikasi (seringkali sebagai penyedia global), sehingga semua Meter dan instrumen berbagi definisi sumber daya yang konsisten dan saluran ekspor.

Meter adalah objek yang digunakan kode aplikasi untuk membuat penghitung, histogram, dan pengukur. Setiap Meter biasanya diberi nama untuk perpustakaan atau layanan (misalnya, “bank.payment”), sehingga metrik yang berasal dari kode itu dapat dikelompokkan dan diidentifikasi secara konsisten.

Pengukur tidak menyimpan data itu sendiri; sebaliknya, alat ini berfungsi sebagai pabrik untuk instrumen dan meneruskan pengukuran yang direkam ke SDK yang mendasarinya untuk agregasi dan ekspor. Karena Meter diperoleh dari Penyedia Meter, mereka selalu beroperasi dengan konfigurasi, tampilan, dan Eksportir yang ditentukan oleh Penyedia.

Instrumen kemudian memberikan instruksi sehingga kode dapat melaporkan pengukuran dengan atribut.

OpenTelemetry SDK adalah implementasi konkret dari OpenTelemetry API yang mengubah panggilan API menjadi titik data telemetri aktual. Ini menyediakan pustaka khusus bahasa (seperti Java atau Python) yang mengumpulkan, menggabungkan, dan menyiapkan data metrik untuk ekspor.

SDK mengelola siklus hidup instrumentasi, menangani penyimpanan dalam memori untuk pengukuran, menjalankan callback untuk instrumen asinkron, menerapkan agregasi dan tampilan yang dikonfigurasi, serta mengontrol interval pengumpulan metrik (biasanya 10–60 detik).

Di dalam SDK, prosesor menerapkan agregasi dan logika tambahan, termasuk pemfilteran, pembatasan kecepatan, atau transformasi aliran metrik sebelum mengirimkannya ke depan.

Eksportir mengonversi titik data metrik yang diproses menjadi format khusus backend dan mengirimkannya ke backend eksternal atau platform observabilitas dengan menggunakan protokol yang didukung (seperti OTLP).

Tim mungkin memilih untuk menggabungkan beberapa Eksportir dalam SDK untuk dukungan multi-backend di lingkungan yang memerlukan ketersediaan dan redundansi tinggi. Dalam kasus ini, Pengumpul OpenTelemetry bertindak sebagai proksi pintar yang dapat mengirim metrik ke beberapa backend secara bersamaan, mencoba lagi upaya ekspor, atau mengautentikasi data dalam skala besar. 

Agregasi menentukan bagaimana pengukuran individu mentah digabungkan secara matematis ke dalam statistik ringkasan yang disimpan dan kueri backend sebagai titik data deret waktu. Data mentah dikumpulkan oleh agregator SDK menjadi satu titik data per interval pengumpulan untuk setiap deret waktu yang unik.

Pola agregasi umum meliputi:

• Jumlah, yang menjumlahkan semua nilai untuk kuantitas kumulatif (seperti byte yang ditransfer).

• LastValue, yang hanya menyimpan pengukuran terbaru, membuang yang sebelumnya.

• Agregasi histogram, yang mengelompokkan nilai ke dalam bucket sehingga tim dapat menghitung persentil dan deteksi outlier.

• Drop, yang membuang semua nilai untuk perlindungan terhadap data kardinalitas tinggi (data dengan jumlah nilai unik yang tinggi).

Agregasi juga membawa metadata temporalitas, yang memberi tahu backend bagaimana menafsirkan nilai metrik dari waktu ke waktu. Dua jenis utamanya adalah:

• Nilai kumulatif mencerminkan total sejak proses dimulai. Nilai-nilai ini hanya akan direset ketika proses dimulai ulang, dan backend menghitung tingkat dengan mengurangi titik data.

• Nilai delta mencerminkan perubahan sejak pengumpulan data terakhir. Backend dapat menjumlahkan delta secara langsung untuk menentukan tarif.

SDK secara otomatis menerapkan agregasi yang tepat berdasarkan jenis instrumen. Instrumen ini juga memungkinkan tim TI beralih dari metrik total sederhana ke histogram yang lebih informatif atau algoritma analisis lainnya tanpa perlu melakukan perubahan pada instrumentasi yang telah diterapkan.

Metrik memberikan visibilitas terhadap tren sekaligus memicu peringatan, trace menunjukkan jalur yang dilalui setiap permintaan, sedangkan log menyediakan konteks terperinci pada tingkat peristiwa untuk membantu analisis dan pemecahan masalah. Mengorelasikan metrik dengan jejak dan log menghubungkan tiga sinyal pengamatan utama (dikenal sebagai “pilar observabilitas”) sehingga tim bisa mendapatkan tampilan berlapis perilaku sistem.

Sebagai contoh, metrik dapat menunjukkan tren agregat seperti "tingkat kesalahan melonjak pada pukul 14.15," tetapi metrik tersebut tidak dapat mengungkapkan permintaan mana yang gagal atau mengapa. Jejak memberikan gambaran tentang jalur permintaan individual yang bermasalah di berbagai layanan, tetapi tanpa metrik, jejak tersebut tidak dapat membantu tim menentukan apakah permintaan yang buruk merupakan outlier atau masalah sistemik. Log memberikan pesan kesalahan dan peristiwa terperinci, tetapi tanpa konteks mereka hanya kebisingan.

Mengorelasikan ketiga sinyal memungkinkan tim TI untuk pindah dengan lancar dari tren metrik ke jejak yang terpengaruh dan log terkait dalam hitungan detik.

Metrik oTel berbeda secara fundamental dari metrik tradisional. Metrik tradisional biasanya mengacu pada pendekatan pemantauan lama yang berfokus pada penghitung sederhana yang telah ditentukan sebelumnya untuk penggunaan sumber daya. Metrik ini berfokus pada pengukuran di tingkat host atau pengukuran yang spesifik untuk aplikasi. 

Metrik OpenTelemetry, sebaliknya, merupakan bagian dari kerangka kerja terpadu, vendor-agnostik yang menstandardisasi pengumpulan di seluruh jejak, log, dan metrik untuk lingkungan TI terdistribusi. Metrik ini membangun metrik tradisional dengan menyediakan model data dan instrumentasi yang lebih fleksibel, termasuk UpDownCounters untuk perubahan dua arah dan histogram yang mendukung bucket eksponensial. Solusi ini juga menyediakan atribut eksplisit, unit, dan stempel waktu untuk memperkaya metrik.

Metrik oTel juga berbeda dari metrik tradisional dalam hal desain, metode pengumpulan dan penerapannya pada sistem modern.

Metrik tradisional dibangun di atas model seluruh tumpukan yang kaku, dengan proses pengumpulan, penyimpanan, dan kueri data yang saling terikat erat dan umumnya hanya memanfaatkan nilai kumulatif yang dihasilkan oleh penghitung, pengukur, ringkasan, dan histogram dasar yang menggunakan bucket eksplisit (sehingga pengelompokan bucket yang harus dikonfigurasi secara manual).

Metrik OpenTelemetry menggunakan desain tiga lapis modular—dengan API, SDK, dan protokol—yang memisahkan pembuatan sinyal dari pemrosesan dan ekspor. Konfigurasi ini memungkinkan metrik oTel untuk mendukung fitur-fitur lanjutan, seperti temporalitas delta, nilai integer, metadata minimum dan maksimum pada histogram dan histogram eksponensial untuk penskalaan dinamis.

Pendekatan tradisional bergantung pada pengikisan data berbasis tarik dari titik akhir API yang terbuka, terutama untuk metrik secara terpisah. Pendekatan ini menggunakan instrumentasi manual dan menawarkan dukungan terbatas untuk jejak atau log, yang mengarah ke jaringan pipa telemetri dan pengamatan yang terfragmentasi.

OpenTelemetry menggunakan OTLP (protokol biner) untuk pengumpulan data berbasis push, memungkinkan pengumpulan jejak, metrik, dan log terpadu melalui instrumentasi otomatis dan manual. OTel juga menyediakan Collector untuk memfasilitasi transformasi data, batching, dan routing ke alat backend, yang membantu tim TI mengatasi masalah penyimpanan aplikasi.

Data telemetri tradisional bekerja dengan baik untuk pengaturan monolitik yang sederhana. Namun, hal ini menjadi kurang efektif di lingkungan layanan mikro karena kemampuan pelacakan yang buruk, vendor lock-in, dan sinyal yang terisolasi sehingga mengaburkan dependensi dan gagal mengungkap kegagalan berantai.

OpenTelemetry unggul dalam lingkungan terdistribusi cloud-native, karena menyediakan telemetri agnostik vendor yang berkorelasi untuk visibilitas menyeluruh ke dalam aliran permintaan lintas layanan, hambatan latensi, dan diagnostik sumber daya. OTel juga mendukung pengambilan sampel dan integrasi alat hybrid, yang membantu skala telemetri dan instrumentasi bersama lingkungan TI. 

Metrik OpenTelemetry menyediakan pengukuran kuantitatif standar yang membantu meningkatkan pengamatan dalam arsitektur modern. Metrik ini menawarkan insight terperinci tentang kinerja sistem, memungkinkan pengembang dan insinyur untuk menerapkan resolusi masalah proaktif dan strategi pengoptimalan.

Manfaat lainnya termasuk: