Pencatatan OpenTelemetri: Pengantar

Pencatatan OTel menawarkan tim TI struktur pemetaan terpadu dan tidak ambigu untuk mengubah data log dari berbagai sumber, sistem, dan format menjadi model tunggal yang netral bahasa, sambil mempertahankan makna semantik asli.

Dengan model data terstruktur yang bersifat vendor-agnostik, alat observabilitas dapat lebih mudah dan andal dalam mengurai log, melampirkan metadata, dan mengaitkan log dengan metrik dan jejak untuk visibilitas yang mendalam dan menyeluruh.

Pencatatan OTel memungkinkan perusahaan untuk beralih dan mencampur backend observabilitas tanpa menginstrumentasi ulang seluruh arsitektur TI, itulah sebabnya itu telah menjadi standar industri untuk instrumentasi dalam sistem cloud-native modern. Kemampuan ini membantu tim TI dan insinyur keandalan situs (SRE) menghindari kesenjangan observabilitas dan masalah fragmentasi data yang terjadi ketika setiap vendor, tumpukan, dan perangkat memiliki skema pencatatan dan protokol transmisi sendiri.

Pencatatan OTel juga memfasilitasi korelasi sinyal silang otomatis, yang secara dramatis meningkatkan debugging dan mengurangi vendor lock-in observabilitas.

Log OpenTelemetry adalah komponen penting dari OpenTelemetry. OpenTelemetry adalah kerangka pengamatan sumber terbuka yang mencakup kumpulan perangkat pengembangan perangkat lunak (SDK), antarmuka pemrograman aplikasi (API) vendor-agnostik dan alat lain untuk instrumentasi aplikasi, sistem dan perangkat.

Kode instrumentasi dulunya sangat bervariasi, dan tidak ada penyedia komersial 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.

Jika, misalnya, 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. Ini memberikan solusi sumber terbuka, berdasarkan standar berbasis komunitas, untuk mengumpulkan data tentang perilaku dan keamanan sistem, membantu tim menyederhanakan pemantauan dan observabilitas dalam ekosistem terdistribusi.

Pencatatan OpenTelemetry bergantung pada beberapa komponen yang bekerja sama yang membuat, menyusun, mengangkut, dan mengirimkan catatan log sebagai bagian dari pipeline pengamatan terpadu. Hal ini termasuk:

Catatan log adalah struktur data pusat yang mewakili peristiwa log tunggal di OpenTelemetry. Ini mengikuti model data standar yang mendefinisikan bidang dan semantik, sehingga log dari berbagai bahasa dan sistem dapat ditafsirkan secara konsisten oleh backend.

Catatan log muncul seperti baris terstruktur dalam spreadsheet yang menggambarkan satu peristiwa dan menjawab pertanyaan dasar, seperti “apa yang terjadi”, “kapan ini terjadi”, “seberapa penting itu”, dan “dari mana asalnya”.

Model data log adalah templat umum yang diikuti setiap catatan, lintas bahasa, dan sistem. Ini mendefinisikan bidang tingkat atas mana yang ada dan masing-masing artinya.

Model data log umum mengharuskan catatan meliputi:

• Stempel waktu dan stempel waktu pengamatan (kapan peristiwa terjadi dan kapan peristiwa itu terlihat)

• Angka tingkat keparahan dan teks tingkat keparahan (juga disebut tingkat log), yang menggambarkan tingkat keparahan suatu peristiwa

• Isi (pesan log utama, seringkali string pendek atau objek JSON)

• Atribut, yang menambahkan detail yang lebih halus tentang setiap peristiwa (seperti detail pengguna atau HTTP)

• Informasi sumber daya yang mengidentifikasi layanan pemancar dan lingkungan penerapan

• ID jejak dan ID rentang yang menautkan peristiwa ke permintaan tertentu (menyederhanakan korelasi data)

Model data struktur yang diterapkan mengubah log dari layanan dan teknologi yang berbeda menjadi entitas telemetri yang kaya dan dapat dikueri yang terlihat dan berperilaku sama ketika memasuki pipeline observabilitas. Model data log memungkinkan tim TI untuk mengkorelasikan log dengan jejak, mengelompokkannya berdasarkan layanan atau pengguna, dan menjalankan jenis kueri yang sama di seluruh lingkungan TI, alih-alih berurusan dengan array format log yang tidak kompatibel.

Dan karena model log terbuka dan digerakkan oleh komunitas, instrumentasi dan pipeline log OTel bersifat portabel (tidak terikat pada satu produk perangkat lunak sebagai layanan (SaaS) atau agen eksklusif). Mereka bekerja di seluruh kerangka kerja dan platform, yang sangat berharga di lingkungan layanan mikro poliglot.

Logger adalah objek yang menulis catatan log, mirip dengan instance logger dalam kerangka kerja pencatatan lain (seperti Java dan Python). Ketika platform observabilitas mengirimkan perintah “log this error” (catat kesalahan ini) atau “log this info message” (catat pesan info ini), itu mengirim pesan ke Logger.

Bagian yang berbeda dari aplikasi atau sistem dapat memerlukan Logger mereka sendiri (misalnya, satu untuk “checkout” dan satu untuk “pembayaran”), tetapi mereka semua mengikuti aturan yang sama untuk menghasilkan log.

Logger diperoleh dari Penyedia Logger, yang bertanggung jawab untuk membuat Logger dan mengonfigurasinya dengan pipeline, atribut, dan pengekspor yang benar.​ Ketika kode perangkat lunak meminta Logger, Penyedia menyediakan satu yang sudah dikonfigurasi dengan tepat.

Desain ini memungkinkan bagian yang berbeda dari sistem untuk menggunakan logger berbeda yang masih berbagi konfigurasi umum dan semuanya dikelola secara terpusat oleh Penyedia Logger. Ini juga memudahkan tim TI untuk menukar implementasi dan menyesuaikan perilaku logging secara global tanpa memodifikasi setiap situs panggilan.

OTel Collector adalah layanan terpisah yang menerima, memproses, dan mengekspor data telemetri—termasuk catatan log—dari berbagai sumber. Aplikasi mengirimkan log mereka (dan jejak serta metrik) ke Kolektor, yang dapat menerima data dalam berbagai format, menstandarkannya, dan kemudian mengirimkannya ke satu atau beberapa backend.

Kolektor mendukung pipeline log khusus yang dibangun di sekitar tiga subkomponen utama: penerima, prosesor, dan pengekspor.

Penerima menyerap log dari berbagai input, seperti aliran OpenTelemtetry Protocol (OTLP) dan file log dari penerima tailing file. Prosesor melakukan operasi seperti batching, modifikasi atribut, pengayaan konteks (menambahkan metadata pod Kubernetes, misalnya), pemfilteran, dan pengambilan sampel pada catatan log. Pengekspor dalam Kolektor kemudian meneruskan log yang diproses ke satu tujuan atau lebih.

Pengekspor catatan log berada di dalam OTel Collector atau SDK aplikasi dan menentukan di mana dan bagaimana data telemetri dikirimkan ke sistem backend.

Setelah Logs SDK membuat dan memproses catatan log, Pengekspor mengodekan model data log ke dalam protokol atau format tertentu dan mengirimkan catatan ke “konsumen” hilir. Konsumen dapat mencakup Kolektor OTel, solusi pengamatan atau toko sumber terbuka, misalnya.

Pengekspor dapat berbasis dorong (push) atau tarik (pull), dan mereka dapat ditukar dan digabungkan untuk secara bersamaan mengirimkan catatan log yang sama ke backend yang berbeda tanpa memodifikasi kode aplikasi. Fleksibilitas yang diberikan Pengekspor memudahkan perusahaan untuk mengembangkan arsitektur pengamatan mereka saat persyaratan berubah.

Log API dan Log SDK berfungsi seperti outlet pada strip daya: API adalah jenis outlet, dan SDK adalah strip daya yang membawa listrik.

OpenTelemetry API terdiri dari sekumpulan fungsi yang dipanggil kode dan pustaka pencatatan untuk membuat entri log yang seragam. Pada dasarnya, Log API menentukan “bentuk” yang harus diambil log untuk “terhubung” ke OTel. Log API membantu memastikan bahwa panggilan API yang sama akan berfungsi terlepas backend observabilitas atau vendor mana yang dipilih tim TI nanti.

Namun, API hanyalah antarmuka. Itu tidak dapat memutuskan tujuan log atau caranya dikirim. Di situlah OpenTelemetry SDK, atau Log SDK, berperan.

Log SDK mengambil log dari titik akhir API dan melakukan pekerjaan nyata dengannya. Ini menerima catatan log, memperkayanya (dengan menambahkan nama layanan atau lingkungan, misalnya), menggabungkannya menjadi batch dan menyiapkannya untuk dikirim. Kemudian menggunakan Pengekspor untuk mengirim log yang diproses ke Kolektor atau platform log.

Appender log, juga disebut jembatan log, menghubungkan pustaka pencatatan yang ada (seperti Log4j, SLF4J, atau kerangka kerja serupa) ke model data log OpenTelemetry.

Alih-alih pengembang perangkat lunak memanggil Log API secara langsung, mereka dapat mengonfigurasi kerangka kerja pencatatan yang ada untuk menggunakan appender yang mengubah setiap peristiwa log tradisional menjadi catatan log OTel.

Log bridge juga dapat menyuntikkan konteks rentang dan jejak ke dalam catatan log, memungkinkan korelasi antara log dan jejak bahkan ketika kode aplikasi itu sendiri tidak menyadari detail penelusuran.

Propagasi konteks dan mekanisme korelasi adalah komponen penting dari pencatatan OpenTelemetry. Ketika rentang jejak aktif, jembatan pencatatan atau SDK dapat secara otomatis melampirkan ID jejak saat ini dan ID rentang ke setiap catatan log yang dipancarkan.

Korelasi membantu backend observabilitas menghubungkan log dengan jejak terdistribusi yang mewakili permintaan atau alur kerja yang sama. Koneksi ini memungkinkan tim untuk menavigasi dari entri log bermasalah langsung ke jejak yang menunjukkan jalur lengkap permintaan. Ini juga memfasilitasi analisis sinyal silang untuk metrik, jejak, dan log yang berbagi sumber daya dan bidang konteks yang sama.

OTel berbicara tentang “jenis” log dalam beberapa cara berbeda: berdasarkan struktur, berdasarkan sumber dan dengan pengodean atau protokol transmisi.

Log terstruktur memiliki skema yang konsisten, bidang yang sama, dengan nama dan jenis data yang stabil, sehingga alat observabilitas dapat dengan andal mengurai dan mengkuerinya. Log mungkin dikodekan dengan JSON atau format lain, tetapi yang membuatnya terstruktur adalah kumpulan bidang data yang dapat diprediksi.

Log semi-terstruktur berisi beberapa struktur yang dapat dikenali (pasangan nilai kunci atau gumpalan mirip JSON, misalnya), tetapi skema tidak konsisten dari waktu ke waktu. Mereka lebih mudah dibaca mesin daripada teks bentuk bebas, tetapi mereka memerlukan penguraian dan normalisasi tambahan sebelum tim dapat menganalisisnya secara efektif.

Log tidak terstruktur adalah pesan teks bentuk bebas tanpa skema stabil (seperti pernyataan cetak ad hoc atau log server teks biasa). Mereka mudah bagi manusia untuk menulis dan membaca tetapi lebih sulit bagi sistem otomatis untuk mencari, berkorelasi, dan mengumpulkan tanpa penguraian tambahan yang cukup besar. 

Log sistem dan infrastruktur diproduksi oleh sistem operasi, perangkat jaringan, layanan infrastruktur cloud, dan komponen platform lainnya, bukan oleh kode aplikasi. Itu menangkap peristiwa, seperti kesalahan OS, masalah jaringan, dan status infrastruktur, untuk membantu tim memahami kesehatan dan kinerja lingkungan yang mendasarinya

Log aplikasi pertama berasal dari layanan dan aplikasi internal, biasanya melalui SDK OTel, pencatatan pustaka, sidecar (kontainer  aplikasi kedua yang berjalan di samping kontainer utama dan menggunakan sumber daya yang sama) atau agen. Mereka menggambarkan peristiwa bisnis, penanganan permintaan, tindakan pengguna dan kesalahan internal. Mereka dapat diperkaya dengan atribut sumber daya dan ruang lingkup instrumentasi (yang menjelaskan asal log dalam entitas yang menghasilkannya) untuk memberikan gambaran yang lebih lengkap tentang perilaku aplikasi.

Log pihak ketiga dipancarkan oleh layanan eksternal, komponen terkelola, dan produk SaaS yang bergantung pada banyak lingkungan TI perusahaan (API dan database eksternal, misalnya). OTel dapat menyerap log ini bersama log internal sehingga tim TI dapat melihat bagaimana dependensi eksternal mempengaruhi ekosistem.

Log OTLP diwakili dalam model data OTLP native dan dikirim melalui OTLP gRPC atau HTTP. Setiap log distandarisasi untuk netralitas vendor dan korelasi cepat dengan jejak dan metrik.

Log berbasis file ditulis ke file (file log aplikasi atau log akses server web), dan log gaya syslog adalah pesan yang dipancarkan menggunakan protokol syslog. OTel biasanya mengumpulkan log ini dengan menggunakan penerima yang mengekor file atau mendengarkan pesan syslog dan kemudian mengubahnya menjadi catatan log OTel untuk pemrosesan terpadu.

Log HTTP dan JSON dikirimkan melalui HTTP dalam JSON. OpenTelemetry mendukung CSV, Common Log Format (CLF), LTSV, dan pasangan nilai kunci, juga. Format ini diurai oleh kolektor ke dalam model data log OTel umum, sehingga mereka dapat dikueri dan dikorelasikan dengan cara yang sama seperti log OTLP native.

Bayangkan SRE melihat peningkatan kesalahan “checkout gagal” pada dasbor observabilitas untuk layanan mikro checkout. Mereka mungkin memulai proses pemecahan masalah dengan memeriksa log OTel, yang sudah distandarisasi dan menyertakan atribut terstruktur (termasuk jumlah pesanan, jumlah item, dan ID pelacakan) untuk setiap catatan log “pesanan ditempatkan”.

Insinyur dapat dengan cepat memeriksa apakah kegagalan berhubungan dengan volume pesanan tinggi, metode pengiriman tertentu, atau wilayah tertentu, hanya dengan mengkueri atribut log. Mereka juga dapat menyelaraskan jendela waktu di seluruh log, jejak, dan metrik, karena oTel menggunakan stempel waktu dan metadata sumber daya yang konsisten di semua sinyal telemetri.

Insinyur mengonfirmasi bahwa hanya pesanan yang dialihkan ke penyedia pembayaran tertentu yang gagal. Mereka mengikuti jejak kembali ke semua log yang berbagi atribut penyedia itu, tempat mereka menemukan batas waktu sesi berulang. Dengan bukti itu, tim TI dapat dengan cepat mengarahkan insiden ke pemilik yang tepat dan menerapkan strategi mitigasi (gagal ke penyedia lain, misalnya).

Pencatatan OTel berbeda secara signifikan dari logging tradisional dalam pengumpulan, standarisasi, korelasi, dan prosedur transmisi log.  

Sistem logging tradisional berfokus pada agregasi log, pengindeksan, pencarian, dan peringatan berdasarkan pola log. Itu adalah alat yang ampuh untuk pencarian teks dan analisis historis, tetapi biasanya memeriksa log secara terpisah dari data telemetri lainnya.

Pendekatan pencatatan tradisional terutama tentang merekam pesan teks secara lokal, sehingga pengembang dapat men-debug masalah dalam satu aplikasi atau host. Mereka berasumsi bahwa pengguna akan membaca file, memfilternya dan mungkin mengirimkannya ke agregator log di kemudian hari. Mereka juga biasanya menggunakan format ad hoc, seperti baris teks biasa, JSON terstruktur longgar atau pola khusus kerangka kerja tanpa standar lintas layanan.

Dan karena setiap tim pengembangan dapat memilih bidang dan penamaan sendiri, analisis lintas sistem adalah proses yang rumit.

Alat pencatatan log tradisional seringkali tidak menyertakan fitur korelasi atau migrasi bawaan, sehingga korelasi data dan integrasi dengan backend observabilitas memerlukan proses manual dan langkah tambahan. Tim TI harus membuat konvensi khusus dan aturan penguraian untuk menyatukan peristiwa di seluruh layanan, dan mengintegrasikan data log ke dalam tumpukan observabilitas umumnya memerlukan pengirim khusus atau adaptor format.

Pencatatan OpenTelemetry adalah bagian dari kerangka kerja pengamatan terpadu yang memperlakukan log, metrik, dan jejak sebagai sinyal interoperabel kelas pertama yang diatur oleh konvensi semantik bersama. Sejak awal, itu merancang log untuk dikorelasikan dan dianalisis di seluruh sistem terdistribusi, karena tujuannya adalah untuk memahami perilaku sistem menyeluruh.

Ketika pencatatan tradisional bersifat spesifik tumpukan dan backend, pencatatan OTel bersifat agnostik. Ini menyediakan jembatan dan appender sehingga kerangka kerja pencatatan yang ada dapat memancarkan data dalam format OTel tanpa harus menulis ulang setiap panggilan log.

Cakupan dan pendekatan terpadu ini memungkinkan tim TI untuk membuat alur kerja pemecahan masalah yang holistik, di mana mereka dapat berpindah dengan lancar antara dasbor dan jenis data untuk memahami kegagalan yang kompleks dan terdistribusi.

Pencatatan OTel menyediakan log standar dan kaya konteks yang terintegrasi erat dengan jejak dan metrik, membuat pemecahan masalah dan analisis jauh lebih efektif daripada pendekatan tradisional. Manfaatnya meliputi: