Jika aplikasi Anda mengalami isu seperti distribusi traffic tidak merata, kegagalan instans, titik akhir (endpoint) yang lambat, analisis traffic bisnis, atau pemantauan rilis canary, Anda dapat menggunakan Trace Explorer dalam Pemantauan Aplikasi untuk dengan cepat mengidentifikasi kode bermasalah. Topik ini menggunakan lima isu klasik di lingkungan produksi untuk menunjukkan cara menggunakan Trace Explorer dan nilai yang diberikannya.
Informasi latar belakang
Selain menggunakan jejak (trace) untuk menyelidiki anomali pada satu permintaan tunggal atau metrik teragregasi sebelumnya untuk pemantauan dan peringatan layanan, pelacakan terdistribusi juga mendukung analisis pasca-agregasi terhadap data jejak detail. Fitur ini dikenal sebagai Trace Explorer. Dibandingkan dengan menganalisis jejak individual, Trace Explorer membantu Anda mengidentifikasi isu lebih cepat. Dibandingkan dengan grafik pemantauan berbasis metrik teragregasi sebelumnya, Trace Explorer menawarkan fleksibilitas lebih tinggi untuk diagnostik kustom.
Trace Explorer melakukan analisis real-time terhadap seluruh data jejak detail yang tersimpan. Anda dapat secara bebas mengombinasikan kondisi filter dan dimensi agregasi untuk diagnostik kustom dalam berbagai skenario. Misalnya, Anda dapat melihat distribusi deret waktu dari panggilan yang memakan waktu lebih dari 3 detik, memeriksa bagaimana permintaan error tersebar di berbagai mesin, atau memantau perubahan traffic untuk pelanggan VIP.
Isu 1: Distribusi traffic tidak merata
Apa yang harus Anda lakukan ketika salah konfigurasi load balancing mengarahkan volume permintaan tinggi ke beberapa mesin saja, menciptakan "hotspot" yang berdampak pada ketersediaan layanan?
"Hotspot" akibat distribusi traffic tidak merata dapat dengan mudah menyebabkan layanan tidak tersedia. Banyak kasus semacam ini terjadi di lingkungan produksi karena faktor seperti salah konfigurasi load balancing, anomali registrasi layanan yang mencegah node yang direstart untuk kembali online, atau faktor hash DHT yang abnormal.
Risiko terbesar dari ketidakseimbangan traffic adalah kegagalan mendeteksi "hotspot" secara tepat waktu. Gejalanya sering kali berupa respons yang lambat atau error, dan pemantauan tradisional mungkin tidak langsung menunjukkan ketidakseimbangan traffic tersebut. Akibatnya, personel operasional mungkin tidak menganggapnya sebagai penyebab utama, sehingga membuang waktu respons insiden yang berharga dan memperparah masalah.
Dengan Trace Explorer, Anda dapat mengelompokkan data jejak berdasarkan alamat IP untuk memvisualisasikan bagaimana permintaan didistribusikan di seluruh mesin Anda, terutama perubahan distribusi traffic sebelum dan sesudah insiden. Jika sejumlah besar permintaan tiba-tiba terkonsentrasi pada satu atau beberapa mesin, kemungkinan besar itu adalah hotspot akibat distribusi traffic tidak merata. Anda kemudian dapat mengkorelasikannya dengan event perubahan pada saat insiden terjadi untuk dengan cepat mengidentifikasi perubahan yang bermasalah dan melakukan rollback.
Di halaman Trace Explorer, jika Anda melakukan agregasi berdasarkan alamat IP, Anda mungkin menemukan bahwa sebagian besar traffic terkonsentrasi pada mesin opentelemetry-demo-frontend-XX. Di halaman Trace Explorer, atur dimensi agregasi ke alamat IP dan urutkan berdasarkan jumlah permintaan untuk melihat jumlah permintaan, jumlah error, dan durasi rata-rata untuk setiap host. Misalnya, host opentelemetry-demo-frontend memiliki jumlah permintaan hingga 17.000, jauh melebihi host lainnya, yang menunjukkan adanya konsentrasi traffic yang jelas.
Isu 2: Kegagalan instans
Bagaimana cara menyelidiki ketika kegagalan instans—seperti kerusakan kartu jaringan, overcommitment CPU, atau disk penuh—menyebabkan sebagian permintaan gagal atau timeout?
Kegagalan instans sering terjadi, terutama di kluster inti berskala besar, di mana secara statistik hampir tak terhindarkan. Meskipun kegagalan instans mungkin tidak menyebabkan gangguan skala besar, hal ini dapat menyebabkan sejumlah kecil permintaan pengguna gagal atau timeout. Hal tersebut terus-menerus menurunkan pengalaman pengguna dan meningkatkan biaya dukungan, sehingga harus segera ditangani.
Kegagalan instans dapat dikategorikan menjadi kegagalan host dan kegagalan kontainer (atau kegagalan Node dan Pod di lingkungan Kubernetes). Misalnya, overcommitment CPU dan kerusakan perangkat keras adalah isu tingkat host yang memengaruhi semua kontainer di host tersebut. Sebaliknya, isu seperti disk penuh atau error kehabisan memori (out-of-memory) biasanya hanya memengaruhi satu kontainer. Oleh karena itu, saat melakukan troubleshooting kegagalan instans, Anda dapat menganalisis data dari dimensi alamat IP host maupun alamat IP kontainer.
Untuk mengatasi masalah ini, gunakan Trace Explorer untuk pertama-tama memfilter permintaan abnormal atau yang timeout. Kemudian, agregasikan hasilnya berdasarkan alamat IP host atau alamat IP kontainer untuk dengan cepat menentukan apakah kegagalan instans merupakan penyebabnya. Jika permintaan abnormal terkonsentrasi pada satu mesin, Anda dapat mencoba mengganti mesin tersebut untuk pemulihan cepat atau memeriksa metrik sistemnya, seperti apakah disk penuh atau CPU steal time terlalu tinggi. Jika error tersebar di banyak mesin, Anda kemungkinan besar dapat menyingkirkan kegagalan instans dan sebaiknya fokus menganalisis dependensi downstream atau logika aplikasi.
Di halaman Trace Explorer, filter panggilan error atau lambat dan kelompokkan hasilnya berdasarkan alamat IP. Jika panggilan abnormal terkonsentrasi pada mesin tertentu, kemungkinan besar terjadi kegagalan instans. Di halaman Trace Explorer, atur kondisi filter ke statusCode IN (2, 3), pilih alamat IP sebagai dimensi agregasi, dan centang status Error di bagian quick filter di sebelah kiri. Hasil kueri menunjukkan total 2.857 panggilan error, dengan dua host (*.42 dan *.47) masing-masing menghasilkan 1.430 dan 1.425 panggilan, keduanya dengan tingkat error 100%. Error tersebut terkonsentrasi antara pukul 19:21 dan 19:26, yang merupakan ciri khas kegagalan instans.
Isu 3: Mengelola endpoint yang lambat
Bagaimana cara cepat mengidentifikasi endpoint yang lambat dan mengatasi bottleneck kinerja sebelum peluncuran aplikasi baru atau promosi penjualan besar-besaran?
Tuning kinerja sistematis sering kali diperlukan saat meluncurkan aplikasi baru atau mempersiapkan promosi besar. Langkah pertama adalah menganalisis sistem saat ini untuk mengidentifikasi bottleneck kinerja dengan membuat daftar endpoint yang lambat dan seberapa sering terjadinya.
Anda dapat menggunakan Trace Explorer untuk memfilter panggilan dengan durasi melebihi ambang batas tertentu, lalu mengelompokkannya berdasarkan nama endpoint. Hal ini memungkinkan Anda dengan cepat mengidentifikasi daftar endpoint yang lambat beserta polanya. Anda kemudian dapat menangani endpoint yang paling sering lambat satu per satu.
Setelah menemukan endpoint yang lambat, Anda dapat menggunakan jejak terkait, stack metode, dan data kolam thread untuk menemukan akar penyebab panggilan lambat tersebut. Penyebab umum meliputi:
-
Kolam koneksi database atau layanan mikro terlalu kecil, menyebabkan banyak permintaan menunggu koneksi. Hal ini dapat diatasi dengan meningkatkan jumlah maksimum thread pada kolam koneksi.
-
Masalah kueri N+1. Misalnya, satu permintaan eksternal memicu ratusan panggilan internal ke database. Anda dapat menggabungkan permintaan terfragmentasi ini untuk mengurangi waktu transfer jaringan.
-
Ukuran data dari satu permintaan terlalu besar, menyebabkan waktu transfer jaringan dan deserialisasi yang lama, serta berpotensi memicu Full GC. Anda dapat beralih dari kueri penuh ke kueri terpaginasi untuk menghindari permintaan data berlebihan sekaligus.
-
"Hot lock" pada framework logging. Anda dapat beralih dari output log sinkron ke asinkron.
Di halaman Trace Explorer, filter panggilan lambat yang memakan waktu lebih dari 5 detik dan kelompokkan berdasarkan nama endpoint untuk mengidentifikasi pola di antara endpoint yang lambat.
Isu 4: Analisis traffic bisnis
Bagaimana cara menganalisis perubahan traffic dan kualitas layanan untuk pelanggan atau channel utama?
Di lingkungan produksi, layanan sering kali distandardisasi, tetapi segmen bisnis dikelompokkan dan diklasifikasikan. Untuk layanan pesanan yang sama, kita perlu mengkategorikan dan mengagregasi statistik berdasarkan dimensi seperti kategori, channel, dan pengguna untuk operasi detail halus. Misalnya, di channel ritel offline, stabilitas setiap pesanan dan setiap terminal POS dapat menjadi isu publik. Persyaratan SLA untuk channel offline jauh lebih tinggi daripada channel online. Lalu, bagaimana Anda dapat secara akurat memantau status traffic dan kualitas layanan untuk jejak ritel offline dalam sistem layanan e-commerce generik?
Anda dapat menggunakan fitur filtering dan statistik Trace Explorer pada atribut kustom untuk melakukan analisis jejak berorientasi bisnis dengan biaya rendah. Misalnya, Anda dapat menambahkan tag seperti {"attributes.channel": "offline"} ke jejak untuk pesanan offline di layanan titik masuk, lalu menambahkan tag terpisah untuk toko berbeda, kelompok pelanggan, dan kategori produk. Terakhir, dengan memfilter attributes.channel = offline dan menggunakan group by pada tag bisnis berbeda untuk mengagregasi metrik seperti jumlah permintaan, durasi, atau laju error, Anda dapat dengan cepat menganalisis tren traffic dan kualitas layanan untuk setiap skenario bisnis.
Isu 5: Pemantauan rilis canary
Anda melakukan deployment ke 500 mesin dalam 10 batch. Bagaimana cara cepat menentukan apakah ada isu setelah batch rilis canary pertama aktif?
Tiga pilar manajemen perubahan—"canary, monitor, rollback"—sangat penting untuk stabilitas online. Rilis canary bertahap adalah metode utama untuk mengurangi risiko online dan membatasi radius dampak. Jika anomali terdeteksi pada batch canary, deployment harus segera di-rollback alih-alih dilanjutkan. Namun, banyak kegagalan produksi terjadi karena kurangnya pemantauan canary yang efektif.
Misalnya, jika registrasi layanan suatu layanan mikro tidak tersedia, mesin yang direstart tidak dapat mendaftar atau kembali online. Tanpa pemantauan canary, beberapa batch pertama mesin yang direstart mungkin semuanya gagal mendaftar. Seluruh traffic kemudian diarahkan ke mesin aktif yang tersisa. Traffic dan durasi aplikasi secara keseluruhan mungkin tidak berubah signifikan hingga batch terakhir juga gagal mendaftar, yang pada akhirnya menyebabkan seluruh aplikasi tidak tersedia dan memicu insiden produksi besar.
Pada skenario di atas, jika Anda memberi tag traffic dari versi mesin berbeda dengan {"attributes.version": "v1.0.x"}, Anda dapat menggunakan Trace Explorer untuk mengagregasi statistik berdasarkan attributes.version. Hal ini memungkinkan Anda membedakan secara jelas perubahan traffic dan kualitas layanan antar versi atau sebelum dan sesudah rilis, sehingga mencegah anomali batch canary tertutupi oleh metrik pemantauan global.
Batasan Trace Explorer
Meskipun Trace Explorer fleksibel dan dapat memenuhi berbagai kebutuhan diagnostik kustom, fitur ini memiliki beberapa batasan:
-
Analisis data jejak detail berbiaya tinggi.
Trace Explorer mengharuskan Anda melaporkan dan menyimpan data jejak detail se-lengkap mungkin. Jika laju pengambilan sampel rendah dan data detail tidak lengkap, efektivitas Trace Explorer akan sangat berkurang. Untuk menurunkan biaya penyimpanan penuh, Anda dapat men-deploy node data edge di dalam kluster Anda untuk caching dan pemrosesan data sementara guna mengurangi overhead pelaporan lintas jaringan. Atau, Anda dapat menerapkan pemisahan data panas dan dingin di sisi server: lakukan analisis jejak penuh pada penyimpanan panas, dan diagnosa hanya jejak lambat atau error pada penyimpanan dingin.
-
Pasca-agregasi tidak cocok untuk peringatan karena overhead kueri tinggi dan konkurensi rendah.
Trace Explorer melakukan pemindaian dan statistik real-time pada dataset lengkap. Overhead kinerja kueri jauh lebih tinggi dibandingkan metrik teragregasi sebelumnya, sehingga tidak cocok untuk kueri peringatan berkonkurensi tinggi. Sebagai gantinya, gunakan fitur metrik kustom untuk mendorong pernyataan pasca-agregasi ke client guna pengumpulan metrik kustom, yang kemudian dapat digunakan untuk peringatan dan dasbor kustom.
-
Pemberian tag atribut kustom diperlukan untuk memaksimalkan nilai Trace Explorer.
Berbeda dengan metrik teragregasi standar dalam Pemantauan Aplikasi, banyak skenario di Trace Explorer mengharuskan Anda secara manual menginstrumentasi kode dengan tag kustom. Ini adalah cara paling efektif untuk membedakan berbagai skenario bisnis dan memungkinkan analisis yang presisi.
Dokumen terkait
Untuk mendiagnosis masalah secara proaktif, Anda dapat menggunakan fitur peringatan Application Real-Time Monitoring Service (ARMS) untuk membuat peringatan untuk endpoint tertentu atau untuk semua endpoint. Saat terjadi isu, layanan akan mengirim notifikasi ke tim operasional Anda. Untuk mempelajari cara membuat peringatan, lihat Aturan peringatan Pemantauan Aplikasi.