Menambahkan ID Pelanggan ke Setiap Metrik Dapat Membengkakkan Beban Observability Aplikasi

Menambahkan ID Pelanggan ke Setiap Metrik Dapat Membengkakkan Beban Observability Aplikasi

Tim IT ingin lebih cepat mengetahui pelanggan yang mengalami gangguan. Untuk membantu pemeriksaan, ID pelanggan ditambahkan ke berbagai metrik aplikasi, mulai dari jumlah permintaan hingga waktu respons.

Pada awalnya, keputusan tersebut terasa masuk akal. Ketika ada keluhan, tim berharap dapat langsung menyaring data berdasarkan pelanggan yang bersangkutan.

Namun, setelah aplikasi digunakan lebih banyak perusahaan atau akun, data pemantauan ikut membesar. Kebutuhan penyimpanan meningkat, penggunaan memori bertambah, dan biaya layanan observability mulai mendapat perhatian.

Penambahan satu atribut ternyata dapat membawa konsekuensi yang lebih luas. Perusahaan perlu memahami bagaimana detail tersebut disimpan dan apakah manfaatnya sebanding dengan beban pengelolaannya.

Satu Atribut Tambahan Dapat Memperbanyak Data Pemantauan

Observability membantu tim memahami kondisi aplikasi melalui data seperti metrik, catatan kejadian, dan jejak perjalanan permintaan.

Metrik biasanya digunakan untuk melihat pola. Contohnya adalah jumlah permintaan, tingkat kesalahan, atau waktu respons suatu layanan. Agar dapat dianalisis, metrik diberi atribut seperti nama layanan dan status keberhasilan.

Bayangkan aplikasi memiliki metrik jumlah permintaan berdasarkan layanan dan status. Ketika ID pelanggan ditambahkan, setiap pelanggan dapat menghasilkan kelompok pencatatan tersendiri untuk kombinasi yang digunakan.

Jumlah kombinasi atribut yang berbeda ini disebut kardinalitas. Semakin banyak pelanggan yang muncul bersama atribut lain, semakin banyak kombinasi yang perlu ditangani.

Artinya, beban pemantauan tidak hanya dipengaruhi banyaknya transaksi. Dua aplikasi dengan volume transaksi serupa dapat memiliki kebutuhan pengelolaan metrik yang berbeda karena desain atributnya.

Bebannya Dapat Menjalar ke Biaya dan Pekerjaan Tim

Kombinasi metrik yang terus bertambah membutuhkan sumber daya. Pengumpul data dapat menggunakan lebih banyak memori, sementara sistem penyimpanan dan analisis perlu menangani lebih banyak rangkaian data.

Pengaruhnya terhadap tagihan bergantung pada layanan yang dipakai. Ada penyedia yang memperhitungkan jumlah rangkaian metrik aktif, volume data, atau penggunaan sumber daya lainnya. Karena itu, kenaikan biaya tidak selalu sebanding langsung dengan jumlah pelanggan.

Beban juga muncul pada pekerjaan tim. Dashboard menjadi lebih sulit ditinjau, aturan pemantauan perlu diperiksa kembali, dan engineer menghabiskan waktu mengevaluasi data yang sebenarnya jarang digunakan.

Dalam aplikasi bisnis yang terus berkembang, persoalan ini dapat muncul bertahap. Penambahan cabang, pelanggan, dan layanan memperbesar dampak keputusan kecil yang dibuat pada awal pengembangan.

Persoalan seperti ini juga sering kami temukan ketika mendampingi proses pengembangan, integrasi, maupun modernisasi sistem pada perusahaan.

Pembatasan Otomatis Belum Tentu Menjaga Seluruh Rincian

Sebagian teknologi menyediakan pembatasan agar jumlah kombinasi metrik tidak terus menghabiskan memori. Namun, perusahaan perlu memahami konsekuensi pembatasan tersebut.

OpenTelemetry menjelaskan bahwa pada mekanisme overflow metriknya, kombinasi tambahan dapat digabungkan ke satu kelompok penampung. Nilai pengukuran tetap diperhitungkan, tetapi atribut asalnya tidak lagi tersedia pada kelompok tersebut.

Akibatnya, jumlah keseluruhan permintaan bisa tetap benar, sementara penyaringan berdasarkan atribut tertentu tidak lagi mencakup seluruh pengukuran.

Perilaku ini tidak boleh dianggap berlaku sama pada semua platform. Implementasi dan konfigurasi perlu diperiksa sesuai teknologi yang digunakan.

Bagi perusahaan, pelajarannya sederhana: dashboard yang masih menampilkan angka belum membuktikan seluruh rincian tetap lengkap. Kualitas informasi perlu diperiksa sebelum data tersebut dijadikan dasar penilaian layanan.

Detail Pelanggan Perlu Ditempatkan Sesuai Tujuannya

ID pelanggan dapat berguna ketika tim menelusuri keluhan tertentu. Namun, kebutuhan tersebut tidak otomatis mengharuskan identitas pelanggan dimasukkan ke setiap metrik.

Metrik lebih sesuai untuk melihat kondisi dan kecenderungan layanan. Misalnya, apakah proses pembayaran semakin lambat atau tingkat kesalahan meningkat setelah pembaruan aplikasi.

Catatan kejadian atau log dapat menyimpan konteks suatu peristiwa. Sementara itu, trace membantu mengikuti perjalanan permintaan ketika proses melewati beberapa layanan atau integrasi API.

Pembagian ini membantu tim memilih bentuk data berdasarkan pertanyaan yang ingin dijawab. Detail pelanggan tetap dapat tersedia pada tempat yang sesuai, tanpa selalu memperbanyak kombinasi metrik.

Namun, memindahkan detail ke log atau trace juga membutuhkan pertimbangan. Volume, masa simpan, dan aksesnya tetap harus dikelola. Pemindahan tersebut bukan jaminan biaya langsung turun.

Pada layanan tertentu, pemantauan per pelanggan memang dibutuhkan, misalnya untuk mengevaluasi kesepakatan tingkat layanan. Kebutuhan ini sebaiknya dirancang secara khusus dengan cakupan yang terukur.

Apa yang Perlu Dipertimbangkan Perusahaan?

Sebelum menambahkan atribut baru, perusahaan dapat memeriksa beberapa hal berikut.

Mulai dari pertanyaan operasional. Tentukan keputusan apa yang akan dibuat berdasarkan data tersebut. Jika ID pelanggan jarang digunakan dalam analisis metrik, penambahannya perlu dipertimbangkan kembali.

Perkirakan pertumbuhan kombinasi. Evaluasi desain menggunakan perkiraan pelanggan dan layanan beberapa waktu ke depan. Pengujian pada sedikit akun belum tentu menunjukkan beban saat aplikasi berkembang.

Pisahkan pemantauan layanan dan laporan pelanggan. Dashboard operasional membutuhkan informasi untuk mendeteksi gangguan. Laporan penggunaan per pelanggan mungkin lebih tepat menggunakan data transaksi atau sistem analitik yang dirancang untuk kebutuhan tersebut.

Tetapkan penanggung jawab metrik. Perubahan atribut perlu ditinjau bersama tim pengembangan dan operasional. Tujuannya agar setiap fitur baru tidak menambah beban pemantauan tanpa evaluasi.

Nilai biaya bersama manfaat informasinya. Penghematan yang membuat gangguan sulit diketahui dapat merugikan operasional. Sebaliknya, menyimpan semua detail tanpa tujuan juga menambah pekerjaan dan biaya maintenance.

Kesimpulan

Observability aplikasi akan lebih berguna ketika setiap detail dikumpulkan untuk tujuan yang jelas. ID pelanggan dapat membantu penelusuran, tetapi penempatannya pada setiap metrik perlu mempertimbangkan pertumbuhan data, biaya, dan kualitas pemantauan.

Keputusan yang tepat membantu perusahaan menjaga kemampuan mendeteksi gangguan sekaligus mengendalikan beban pengelolaan sistem.

Diskusikan Kebutuhan Sistem Anda bersama Rakit Sembada

Rakit Sembada membantu perusahaan merancang pengembangan aplikasi dan IT Architecture Design yang mempertimbangkan kebutuhan pemantauan, biaya operasional, serta pertumbuhan bisnis.