OpenTelemetry telah muncul sebagai standar yang menjanjikan untuk observabilitas aplikasi, menawarkan pengembang cara terpadu untuk mengumpulkan traces, metrics, dan logs. Namun, seiring semakin banyak organisasi yang mencoba mengimplementasikan teknologi ini, tantangan signifikan mulai muncul yang melampaui kompleksitas pengaturan awal.
Komponen Inti OpenTelemetry
| Komponen | Deskripsi |
|---|---|
| Trace | Perjalanan lengkap permintaan dari ujung ke ujung |
| Span | Unit kerja dasar dalam sebuah trace |
| Context | Metadata yang dibawa bersama permintaan |
| Attributes | Pasangan kunci-nilai yang mendeskripsikan span |
| Events | Pesan log yang dilampirkan ke span |
| Links | Koneksi antara span dalam trace yang berbeda |
Biaya Penyimpanan Menjadi Kekhawatiran Utama
Salah satu masalah paling mendesak yang dihadapi adopter OpenTelemetry adalah jumlah data yang sangat besar yang dihasilkan oleh tracing komprehensif. Organisasi menemukan bahwa menyimpan data trace selama berminggu-minggu dapat memerlukan puluhan terabyte ruang penyimpanan. Hal ini telah memicu diskusi sengit tentang strategi sampling, di mana tim harus menyeimbangkan antara menangkap data yang cukup untuk analisis yang bermakna dan mengelola biaya penyimpanan.
Komunitas telah mengembangkan berbagai pendekatan untuk mengatasi tantangan ini. Beberapa mengadvokasi sampling kondisional yang menangkap semua error traces sambil melakukan sampling hanya pada persentase kecil dari request yang berhasil. Yang lain berpendapat untuk mempertahankan kemampuan logging penuh di lingkungan produksi, meskipun melibatkan biaya yang signifikan.
Lingkup Terbatas di Luar Aplikasi Web
Keterbatasan signifikan lainnya yang membuat frustrasi pengembang adalah fokus sempit OpenTelemetry pada layanan backend web. Framework ini kesulitan dengan skenario di luar pola request-response HTTP tradisional. Aplikasi desktop, batch job yang berjalan lama, dan beban kerja khusus seperti komputasi yang dipercepat GPU sering memerlukan solusi kreatif atau tidak cocok dengan asumsi desain OpenTelemetry .
Batch job yang berjalan lama menghadirkan tantangan khusus karena span hanya dikirimkan setelah selesai. Ini berarti tidak ada cara untuk melacak progress selama eksekusi untuk job yang mungkin berjalan selama berjam-jam atau berhari-hari, membuat framework ini hampir tidak dapat digunakan untuk skenario tersebut.
Jenis Span dan Kasus Penggunaan
| Jenis Span | Tujuan | Contoh Kasus Penggunaan |
|---|---|---|
| INTERNAL | Operasi internal aplikasi | Pemanggilan fungsi, logika bisnis |
| CLIENT | Permintaan keluar ke layanan eksternal | Permintaan HTTP, query database |
| SERVER | Menangani permintaan masuk | Endpoint server HTTP |
| PRODUCER | Menerbitkan pesan | Penerbitan pesan Kafka |
| CONSUMER | Memproses pesan | Konsumsi pesan Kafka |
Overhead Pengembangan dan Kompleksitas
Beban implementasi juga mendapat kritik dari pengembang yang merasa menghabiskan waktu signifikan pada kode telemetry daripada fitur inti. Meskipun auto-instrumentation dapat membantu mengurangi overhead ini untuk beberapa framework, instrumentasi manual masih memerlukan kode tambahan yang substansial dan upaya mental.
Jumlah kode tambahan yang dibutuhkan sangat mengerikan. Kami sekarang harus menghabiskan lebih banyak energi otak untuk telemetry saat mengerjakan fitur.
Namun, pendukung berpendapat bahwa investasi awal ini memberikan keuntungan saat troubleshooting masalah kompleks, terutama dalam sistem terdistribusi di mana masalah bisa sulit direproduksi dan didiagnosis.
Anti-Pattern Implementasi yang Umum Terjadi
- Root span tidak memiliki spesifikasi SpanKind
- Nama span yang terlalu bertele-tele sehingga mengurangi kardinalitas
- Informasi error yang hilang dalam atribut span
- Pemetaan dependensi yang tidak lengkap antar span
- Menyimpan data PII sensitif dalam atribut
- Memory leak akibat span yang tidak dilepaskan
Inkonsistensi Implementasi Vendor
Meskipun tujuan OpenTelemetry adalah standardisasi, implementasi dunia nyata bervariasi secara signifikan antara vendor yang berbeda. Hal ini telah menyebabkan masalah kompatibilitas dan peningkatan kompleksitas ketika organisasi mencoba beralih antara platform observabilitas yang berbeda atau mengintegrasikan beberapa alat.
Komunitas terus bekerja untuk mengatasi tantangan-tantangan ini, dengan perbaikan berkelanjutan pada dokumentasi, tooling, dan dukungan framework. Namun, diskusi ini menyoroti kesenjangan antara visi ambisius OpenTelemetry dan realitas praktis implementasi dalam lingkungan produksi yang beragam.
Reference: What are Traces and Spans in OpenTelemetry: A Practical Guide