(0275) 2974 127
Dalam lingkungan DevOps, aplikasi tidak lagi berjalan hanya pada satu server. Aplikasi modern dapat terdiri dari container, microservices, database, API, cloud infrastructure, hingga berbagai layanan pihak ketiga. Semakin kompleks infrastrukturnya, semakin sulit pula mengetahui apa yang sebenarnya terjadi ketika aplikasi mengalami masalah.
Misalnya, sebuah API tiba-tiba mengalami peningkatan response time. Masalah tersebut bisa berasal dari aplikasi, database, jaringan, service lain, atau resource server yang terbatas. Tanpa data observability yang memadai, tim DevOps harus memeriksa banyak komponen secara manual.
Salah satu teknologi yang dapat membantu mengatasi masalah tersebut adalah OpenTelemetry. OpenTelemetry menyediakan framework open source dan vendor-neutral untuk melakukan instrumentation, menghasilkan, mengumpulkan, serta mengekspor data telemetry seperti traces, metrics, dan logs.
OpenTelemetry atau OTel adalah framework observability open source yang digunakan untuk menghasilkan, mengumpulkan, memproses, dan mengekspor data telemetry dari aplikasi maupun infrastruktur.
OpenTelemetry bukan sebuah dashboard monitoring atau tempat penyimpanan data. OpenTelemetry berfungsi sebagai lapisan untuk menghasilkan dan mengirim telemetry ke sistem observability yang digunakan perusahaan.
Pendekatan ini membuat aplikasi tidak harus bergantung pada satu vendor observability tertentu. Data yang dikumpulkan dapat dikirim ke berbagai backend yang mendukung OpenTelemetry, termasuk solusi open source maupun layanan komersial.
Dalam konteks DevOps, OpenTelemetry membantu tim mendapatkan gambaran yang lebih jelas mengenai kondisi aplikasi dan infrastrukturnya sehingga proses monitoring, troubleshooting, dan analisis performa dapat dilakukan dengan lebih terstruktur.
DevOps menggabungkan proses development dan operations agar software dapat dikembangkan serta dikirimkan secara lebih cepat dan berkelanjutan. Namun, kecepatan deployment juga meningkatkan kebutuhan terhadap observability.
Ketika aplikasi hanya terdiri dari satu service, mencari sumber masalah mungkin relatif mudah. Namun, ketika sistem berkembang menjadi puluhan atau bahkan ratusan service, satu request pengguna dapat melewati banyak komponen sebelum menghasilkan respons.
Dalam kondisi tersebut, metrics saja terkadang belum cukup. Tim perlu mengetahui perjalanan request, aktivitas setiap service, serta hubungan antara berbagai event yang terjadi.
OpenTelemetry membantu menyediakan telemetry yang dapat digunakan untuk memahami perilaku sistem tersebut. Dokumentasi resminya menjelaskan bahwa observability memungkinkan tim memahami sistem dari sisi eksternal dan membantu menjawab pertanyaan seperti “mengapa hal ini terjadi?” ketika muncul masalah yang tidak mudah diprediksi.
Telemetry adalah data yang menggambarkan aktivitas dan kondisi sebuah sistem. Dalam OpenTelemetry, telemetry terutama berkaitan dengan beberapa jenis signal yang dapat digunakan untuk memahami aplikasi dan infrastrukturnya.
OpenTelemetry juga memiliki konsep Baggage untuk membawa informasi kontekstual antar-komponen. Selain itu, profiles sedang dikembangkan sebagai bagian dari ekosistem telemetry.
1. Traces
Trace menggambarkan perjalanan sebuah request melalui berbagai komponen sistem. Misalnya, ketika pengguna membuka halaman checkout:
User → API Gateway → Checkout Service → Payment Service → Database
Dengan distributed tracing, tim DevOps dapat melihat bagaimana request tersebut berjalan dari satu service ke service lainnya. Trace terdiri dari beberapa span. Setiap span dapat merepresentasikan suatu operasi tertentu, misalnya pemanggilan API, query database, atau komunikasi dengan service lain. Informasi ini sangat berguna ketika sebuah request mengalami keterlambatan karena tim dapat melihat bagian mana yang membutuhkan waktu paling lama.
2. Metrics
Metrics merupakan data numerik yang menggambarkan kondisi sistem pada waktu tertentu. Contohnya:
Metrics berguna untuk melihat pola performa sistem dan mendeteksi perubahan yang tidak normal. Misalnya, ketika error rate meningkat dari 1% menjadi 15%, tim dapat segera mengetahui bahwa terdapat perubahan signifikan pada kondisi aplikasi.
3. Logs
Logs merupakan catatan aktivitas yang dihasilkan aplikasi atau komponen sistem. Contohnya:
OpenTelemetry menyediakan pendekatan untuk menghubungkan logs dengan signal observability lainnya sehingga informasi yang sebelumnya tersebar dapat dianalisis secara lebih terintegrasi.
Ketiga signal tersebut memiliki fungsi berbeda, tetapi dapat digunakan secara bersama-sama.
| Signal | Fokus Utama | Contoh | Kegunaan |
|---|---|---|---|
| Traces | Perjalanan request | Request API dari service A ke B | Menemukan bottleneck |
| Metrics | Kondisi numerik sistem | CPU, latency, error rate | Memantau performa |
| Logs | Catatan kejadian | Error database | Mengetahui detail suatu event |
| Baggage | Informasi kontekstual | Metadata yang dibawa antar-service | Menambahkan konteks pada telemetry |
Ketika ketiganya digunakan bersama, tim dapat memperoleh perspektif yang lebih lengkap. Sebagai contoh, metrics dapat menunjukkan bahwa latency meningkat. Trace kemudian dapat menunjukkan service mana yang lambat, sedangkan logs dapat membantu menjelaskan error yang terjadi pada service tersebut.
Secara sederhana, alur OpenTelemetry dapat digambarkan sebagai: Application → Instrumentation → OpenTelemetry SDK → Collector → Backend Observability
Namun, tidak semua implementasi harus menggunakan Collector. Telemetry juga dapat diekspor langsung dari aplikasi ke backend tertentu. OpenTelemetry mendukung kedua pendekatan tersebut.
1. Instrumentation
Langkah pertama adalah melakukan instrumentation terhadap aplikasi atau sistem. Instrumentation memungkinkan aplikasi menghasilkan telemetry seperti traces, metrics, dan logs. OpenTelemetry menyediakan dua pendekatan utama:
Code-based instrumentation memberikan kontrol yang lebih mendalam karena developer dapat menentukan telemetry yang ingin dihasilkan dari kode aplikasi. Sementara itu, zero-code instrumentation dapat digunakan untuk memperoleh telemetry tanpa harus melakukan perubahan besar pada source code aplikasi.
2. OpenTelemetry API dan SDK
Setelah instrumentation diterapkan, OpenTelemetry API dan SDK membantu aplikasi menghasilkan serta mengelola telemetry. API menyediakan interface yang digunakan untuk instrumentation, sedangkan SDK menyediakan implementasi dan mekanisme konfigurasi, pemrosesan, serta export telemetry. OpenTelemetry menyediakan implementasi untuk berbagai bahasa pemrograman, termasuk Java, Python, Go, JavaScript/TypeScript, .NET, PHP, Ruby, Rust, dan bahasa lainnya.
3. OpenTelemetry Collector
OpenTelemetry Collector merupakan komponen yang menerima, memproses, dan mengekspor telemetry ke berbagai backend. Collector dapat digunakan sebagai perantara sehingga aplikasi tidak harus berkomunikasi langsung dengan setiap backend observability. Dalam Collector terdapat beberapa komponen utama, yaitu:
Receiver menerima telemetry, processor dapat memproses atau memodifikasi data, sedangkan exporter mengirimkan data ke tujuan tertentu.
4. Backend Observability
Setelah diproses, telemetry dapat dikirimkan ke backend untuk disimpan, dianalisis, dan divisualisasikan. Contohnya dapat berupa:
OpenTelemetry sendiri bukan backend observability. Fungsi penyimpanan dan visualisasi sengaja diserahkan kepada sistem lain.
OpenTelemetry Collector merupakan salah satu komponen penting dalam arsitektur OpenTelemetry. Collector dapat menerima telemetry dari berbagai sumber, kemudian melakukan pemrosesan sebelum mengirimkannya ke satu atau beberapa tujuan. Alur sederhananya adalah:
Arsitektur pipeline seperti ini membuat pengelolaan telemetry menjadi lebih fleksibel karena proses penerimaan, pemrosesan, dan pengiriman dapat dikonfigurasi secara terpisah.
OTLP atau OpenTelemetry Protocol merupakan protokol yang digunakan OpenTelemetry untuk mengirim data telemetry. OTLP dirancang agar data telemetry dapat dikirim dengan format dan mekanisme yang konsisten antara aplikasi, Collector, dan backend yang mendukungnya.
OpenTelemetry menyediakan OTLP exporter melalui HTTP maupun gRPC. Keduanya termasuk exporter yang berstatus stable dalam daftar komponen Collector saat ini. Keberadaan OTLP membantu mengurangi ketergantungan terhadap format proprietary dari vendor tertentu.
Dalam lingkungan DevOps, OpenTelemetry dapat ditempatkan di antara aplikasi dan sistem observability.
Contohnya: Developer → Application → OpenTelemetry → Collector → Observability Backend → Dashboard/Alert
Ketika developer melakukan deployment aplikasi baru, instrumentation dapat menghasilkan telemetry dari aplikasi tersebut. Telemetry kemudian dikirim ke Collector. Collector memproses data sebelum meneruskannya ke backend yang digunakan tim.
Dari backend tersebut, tim dapat melakukan monitoring dan troubleshooting berdasarkan data yang tersedia. Pendekatan ini membuat observability menjadi bagian dari proses pengembangan dan operasional, bukan hanya aktivitas yang dilakukan setelah aplikasi mengalami masalah.
Misalnya sebuah perusahaan memiliki aplikasi e-commerce berbasis microservices. Arsitekturnya terdiri dari:
Seorang pengguna melakukan checkout.
Request tersebut dapat melewati beberapa service: Checkout → Cart → Payment → Database
Kemudian pengguna mengeluhkan bahwa proses pembayaran terasa lambat. Dengan distributed tracing, tim DevOps dapat melihat perjalanan request tersebut dan menemukan bahwa Payment Service membutuhkan waktu lebih lama dibandingkan service lainnya.
Metrics kemudian menunjukkan bahwa latency Payment Service meningkat secara signifikan. Logs dari service tersebut mungkin menunjukkan adanya timeout ketika berkomunikasi dengan payment provider. Dari ketiga informasi tersebut, tim memiliki konteks yang lebih lengkap untuk melakukan troubleshooting dibandingkan hanya melihat satu jenis data.
1. Mempermudah Troubleshooting
Telemetry membantu tim melihat apa yang terjadi pada aplikasi ketika muncul masalah. Distributed tracing khususnya dapat membantu menemukan service atau operasi yang menjadi sumber latency dalam sistem yang kompleks.
2. Meningkatkan Visibility
OpenTelemetry memungkinkan tim memperoleh data observability dari berbagai aplikasi dan komponen menggunakan pendekatan yang lebih seragam. Hal ini sangat berguna pada lingkungan cloud native dan microservices.
3. Mengurangi Ketergantungan pada Vendor
Karena OpenTelemetry bersifat vendor-neutral, aplikasi dapat menggunakan standar telemetry yang sama dan mengirimkannya ke berbagai backend yang kompatibel. Hal ini dapat memberikan fleksibilitas ketika perusahaan ingin mengganti atau menambahkan platform observability.
4. Mendukung Distributed Tracing
Dalam sistem microservices, sebuah request dapat melewati banyak service. Tracing membantu mengikuti perjalanan request tersebut sehingga tim dapat mengetahui bagaimana setiap komponen berkontribusi terhadap hasil akhir.
5. Mendukung Observability yang Lebih Terintegrasi
Metrics, traces, dan logs dapat digunakan bersama untuk memahami kondisi sistem dari berbagai perspektif. Korelasi antar-signal membantu tim menghubungkan kondisi numerik, perjalanan request, dan detail event yang terjadi.
6. Mendukung Automasi Observability
OpenTelemetry menyediakan instrumentation dan Collector yang dapat diintegrasikan ke lingkungan pengembangan serta operasional. Hal ini dapat membantu perusahaan membangun proses observability yang lebih konsisten pada berbagai service dan environment.
OpenTelemetry dan monitoring tradisional tidak selalu harus diposisikan sebagai dua teknologi yang saling menggantikan. OpenTelemetry lebih tepat dipahami sebagai framework dan toolkit untuk menghasilkan, mengumpulkan, serta mengekspor telemetry, sedangkan monitoring atau observability platform dapat menjadi tempat telemetry tersebut dianalisis dan divisualisasikan.
| Aspek | Monitoring Tradisional | OpenTelemetry |
|---|---|---|
| Fokus | Pemantauan kondisi sistem | Pengumpulan dan standardisasi telemetry |
| Data | Sering bergantung pada tools tertentu | Traces, metrics, logs, dan context |
| Instrumentation | Bisa berbeda berdasarkan tools | Menggunakan API/SDK OpenTelemetry |
| Vendor dependency | Dapat lebih tinggi | Dirancang vendor-neutral |
| Backend | Biasanya terikat dengan platform tertentu | Dapat dikirim ke berbagai backend |
| Distributed tracing | Tergantung solusi | Menjadi bagian utama observability |
| Collector | Tidak selalu tersedia | OpenTelemetry Collector menjadi komponen opsional penting |
Prometheus merupakan salah satu teknologi yang populer untuk metrics dan monitoring, sedangkan OpenTelemetry memiliki cakupan observability yang lebih luas.
| Aspek | OpenTelemetry | Prometheus |
|---|---|---|
| Fokus utama | Observability telemetry | Monitoring metrics |
| Traces | Ya | Bukan fokus utama |
| Metrics | Ya | Ya |
| Logs | Didukung | Bukan fokus utama |
| Distributed tracing | Ya | Bukan fungsi utamanya |
| Vendor-neutral | Ya | Ya |
| Collector | OpenTelemetry Collector | Prometheus server/scraping ecosystem |
| Peran | Instrumentation, collection, processing, export | Collection, storage, querying metrics |
Beberapa kelebihan yang membuat OpenTelemetry banyak digunakan dalam lingkungan modern antara lain:
OpenTelemetry dirancang agar telemetry tidak bergantung pada satu vendor observability tertentu. Data dapat diekspor ke berbagai backend yang kompatibel.
OpenTelemetry merupakan proyek open source yang berada dalam ekosistem Cloud Native Computing Foundation (CNCF). Proyek ini berasal dari penggabungan OpenTracing dan OpenCensus.
OpenTelemetry memiliki dukungan instrumentation untuk berbagai bahasa pemrograman dan framework sehingga dapat diterapkan pada beragam jenis aplikasi.
Telemetry dapat dikirim langsung ke backend atau melalui Collector. Collector juga dapat dikonfigurasi untuk menerima, memproses, dan mengekspor data ke beberapa tujuan.
Kemampuan distributed tracing dan context propagation membuat OpenTelemetry relevan untuk aplikasi yang terdiri dari banyak service.
Meskipun memiliki banyak kelebihan, implementasi OpenTelemetry tetap membutuhkan perencanaan.
Pada sistem sederhana, implementasinya relatif mudah. Namun, ketika jumlah service, environment, dan backend bertambah, konfigurasi instrumentation dan Collector dapat menjadi lebih kompleks.
Jika seluruh request dan event dikumpulkan tanpa pengaturan yang tepat, volume telemetry dapat meningkat dengan cepat. Karena itu, perusahaan perlu mempertimbangkan sampling, filtering, retention, dan biaya penyimpanan.
Memasang OpenTelemetry tidak otomatis membuat sistem menjadi observable. Tim tetap perlu memahami signal yang dikumpulkan, menentukan data yang relevan, membuat dashboard, serta menetapkan alert yang berguna.
OpenTelemetry bukan tempat utama untuk menyimpan atau memvisualisasikan data. Perusahaan tetap membutuhkan backend observability untuk melakukan analisis terhadap telemetry yang dikumpulkan.
OpenTelemetry semakin berguna ketika aplikasi memiliki karakteristik seperti:
Untuk aplikasi sederhana yang hanya terdiri dari satu service, kebutuhan observability mungkin belum terlalu kompleks. Namun, menerapkan standar instrumentation sejak awal dapat membantu ketika aplikasi berkembang.
Implementasi sebaiknya dilakukan secara bertahap agar tim dapat memahami manfaat dan dampaknya.
1. Identifikasi Sistem yang Akan Dipantau
Tentukan aplikasi, service, database, dan komponen infrastruktur yang paling penting untuk dipantau. Tidak semua komponen harus langsung diinstrumentasi sekaligus.
2. Tentukan Signal yang Dibutuhkan
Tentukan apakah kebutuhan utama berada pada:
Untuk aplikasi microservices, distributed tracing biasanya menjadi salah satu prioritas penting.
3. Pilih Metode Instrumentation
Tim dapat menggunakan instrumentation berbasis kode atau zero-code instrumentation sesuai kebutuhan. OpenTelemetry menyediakan keduanya.
4. Konfigurasi SDK
SDK kemudian dikonfigurasi untuk menghasilkan dan mengekspor telemetry sesuai kebutuhan aplikasi.
5. Gunakan Collector
Untuk lingkungan production, Collector dapat digunakan sebagai lapisan perantara untuk menerima, memproses, dan meneruskan telemetry.
6. Hubungkan dengan Backend
Telemetry kemudian dikirim ke backend observability yang digunakan organisasi.
7. Buat Dashboard dan Alert
Data yang dikumpulkan perlu diterjemahkan menjadi informasi yang dapat digunakan tim. Dashboard dapat menampilkan metrics penting, sedangkan alert dapat digunakan untuk memberi tahu tim ketika kondisi tertentu terjadi.
8. Evaluasi Data Telemetry
Setelah implementasi berjalan, lakukan evaluasi terhadap volume dan kualitas telemetry. Hapus atau filter data yang tidak diperlukan dan pastikan informasi penting tetap tersedia.
OpenTelemetry juga relevan dengan Kubernetes karena banyak aplikasi cloud native berjalan dalam container dan terdiri dari berbagai service.
Dalam lingkungan Kubernetes, telemetry dapat dikumpulkan dari aplikasi dan komponen yang berjalan di dalam cluster. OpenTelemetry juga menyediakan OpenTelemetry Operator sebagai salah satu komponen ekosistem untuk membantu mengelola OpenTelemetry pada Kubernetes.
Dengan kombinasi Kubernetes dan OpenTelemetry, tim dapat membangun observability untuk aplikasi yang bersifat dinamis, termasuk service yang dapat dibuat, dihentikan, atau dipindahkan secara otomatis.
OpenTelemetry juga dapat menjadi bagian dari praktik DevOps yang lebih luas. Dalam pipeline CI/CD, aplikasi yang baru dibangun dapat diuji dan kemudian dideploy dengan instrumentation yang sudah disiapkan. Setelah deployment, telemetry dapat membantu tim melihat apakah perubahan tersebut berdampak terhadap:
Dengan demikian, observability tidak hanya digunakan untuk menangani incident, tetapi juga dapat membantu mengevaluasi dampak perubahan aplikasi setelah deployment.
Agar implementasinya tetap efektif, beberapa praktik berikut dapat diterapkan.
Tidak perlu langsung melakukan instrumentation terhadap seluruh sistem. Mulailah dari aplikasi atau service yang paling kritis.
Gunakan penamaan atribut yang konsisten agar telemetry dari berbagai service lebih mudah dianalisis.
Distributed tracing dapat menghasilkan data dalam jumlah besar. Sampling dapat digunakan untuk mengontrol volume telemetry tanpa kehilangan seluruh informasi penting.
Telemetry dapat mengandung informasi yang sensitif. Pastikan data seperti password, token, credential, atau informasi pribadi tidak ikut dikirim ke backend observability.
Salah satu manfaat OpenTelemetry adalah fleksibilitas backend. Hindari membuat aplikasi terlalu bergantung pada implementasi vendor tertentu jika kebutuhan bisnis mengharuskan fleksibilitas.
Collector dapat menjadi lapisan yang membantu memusatkan pemrosesan telemetry. Namun, konfigurasi harus dirancang agar tidak menjadi single point of failure atau bottleneck.
OpenTelemetry adalah framework observability open source dan vendor-neutral yang membantu aplikasi menghasilkan, mengumpulkan, memproses, dan mengekspor telemetry seperti traces, metrics, dan logs. Dalam DevOps, OpenTelemetry membantu tim memahami kondisi aplikasi dan sistem secara lebih menyeluruh, terutama pada lingkungan cloud native dan microservices.
OpenTelemetry bukan dashboard atau backend observability. Framework ini bekerja bersama berbagai platform untuk menyediakan data yang dapat digunakan dalam monitoring, troubleshooting, performance analysis, dan peningkatan reliability.
Dengan instrumentation, API dan SDK, OpenTelemetry Collector, serta protokol seperti OTLP, perusahaan dapat membangun fondasi observability yang lebih fleksibel. Penerapannya sebaiknya dilakukan secara bertahap dengan memperhatikan kebutuhan telemetry, volume data, keamanan, dan backend yang digunakan.
Untuk mendapatkan informasi lainnya seputar DevOps, cloud computing, cybersecurity, website, hosting, dan teknologi terbaru, kunjungi Blog Hosteko sebagai sumber berbagai panduan teknologi. Untuk kebutuhan infrastruktur website dan layanan hosting, Anda juga dapat mengenal Hosteko Hosting Indonesia.
VPN banyak digunakan sebagai salah satu teknologi untuk meningkatkan privasi dan keamanan ketika menjelajah internet.…
Di tengah persaingan bisnis yang semakin ketat, pertumbuhan pendapatan tidak hanya bergantung pada kemampuan tim…
Shift-Left Security dapat membantu organisasi memasukkan keamanan lebih awal ke dalam proses pengembangan software. Namun,…
Bisnis digital semakin bergantung pada berbagai proses yang harus dilakukan secara cepat dan konsisten. Mulai…
Riset keyword merupakan salah satu tahap penting dalam strategi SEO. Dengan mengetahui kata atau frasa…
Setelah memahami konsep, alur kerja, serta tools yang digunakan, langkah berikutnya adalah menerapkan Shift-Left Security…