Jika aplikasi Anda mengalami masalah seperti lalu lintas tidak merata, kegagalan instance, atau antarmuka lambat, Anda dapat menggunakan Trace Explorer untuk dengan cepat menemukan kode yang bermasalah. Trace Explorer juga membantu Anda menganalisis statistik lalu lintas layanan dan memantau rilis canary. Topik ini menjelaskan cara menggunakan Trace Explorer dalam lima skenario.
Informasi latar belakang
Teknologi pelacakan Application Real-Time Monitoring Service (ARMS) memungkinkan Anda memecahkan kesalahan permintaan tunggal berdasarkan jejak dan menggunakan metrik jejak pra-agregasi untuk pemantauan serta peringatan layanan. Selain itu, fitur Trace Explorer disediakan untuk membantu Anda menganalisis data jejak pasca-agregasi. Dibandingkan dengan jejak dan bagan pemantauan pra-agregasi, Trace Explorer mengidentifikasi masalah dan menerapkan diagnostik kustom secara lebih efisien dan fleksibel.
Trace Explorer memungkinkan Anda menggabungkan kondisi filter dan dimensi agregasi untuk analisis real-time berdasarkan data jejak penuh yang tersimpan. Ini dapat memenuhi persyaratan diagnostik kustom dalam berbagai skenario. Misalnya, Anda dapat melihat grafik deret waktu panggilan lambat yang membutuhkan lebih dari 3 detik, distribusi permintaan tidak valid pada instance berbeda, atau perubahan lalu lintas pelanggan VIP.
Skenario 1: Distribusi lalu lintas tidak merata
Mengapa SLB mengarahkan lebih banyak lalu lintas ke beberapa instance daripada yang lain? Apa yang dapat saya lakukan untuk memperbaikinya?
Server Load Balancer (SLB) mengarahkan lebih banyak lalu lintas ke beberapa instance karena berbagai alasan, seperti konfigurasi SLB yang tidak valid, kegagalan restart node akibat kesalahan registri, dan kesalahan faktor beban tabel hash terdistribusi (DHT). Distribusi lalu lintas tidak merata dapat menyebabkan layanan menjadi tidak tersedia.
Jika terjadi distribusi lalu lintas tidak merata, layanan menjadi lebih lambat dan kesalahan dikembalikan. Saat memecahkan masalah umum dalam kasus-kasus ini, Anda mungkin tidak dapat mengidentifikasi masalah tepat waktu.
Trace Explorer memungkinkan Anda melihat data jejak yang dikelompokkan berdasarkan alamat IP, termasuk instance tempat permintaan didistribusikan dan perubahan distribusi lalu lintas setelah masalah terjadi. Jika sejumlah besar permintaan terkonsentrasi pada satu atau beberapa instance, ini mungkin disebabkan oleh distribusi lalu lintas tidak merata. Anda dapat memecahkan masalah berdasarkan perubahan distribusi lalu lintas dan mengembalikannya tepat waktu.
Di halaman Trace Explorer, kelompokkan data jejak berdasarkan alamat IP. Sebagian besar lalu lintas terkonsentrasi pada instance opentelemetry-demo-frontend-XX, seperti ditunjukkan pada gambar berikut.
Skenario 2: Kegagalan instance
Bagaimana cara memecahkan masalah kegagalan instance?
Kegagalan instance seperti kerusakan kartu antarmuka jaringan, overcommitment CPU, dan penggunaan disk yang terbebani dapat terjadi kapan saja. Kegagalan instance tidak selalu menyebabkan ketidaktersediaan layanan yang parah, tetapi dapat menyebabkan beberapa kegagalan permintaan atau timeout, yang mempengaruhi pengalaman pengguna dan meningkatkan biaya dukungan teknis. Jika Anda mengidentifikasi kegagalan instance, Anda harus memperbaikinya sesegera mungkin.
Kegagalan instance dibagi menjadi dua jenis: kegagalan host dan kegagalan kontainer. Jika Anda menggunakan lingkungan Kubernetes, kegagalan instance mencakup kegagalan node dan kegagalan pod. Overcommitment CPU dan kerusakan perangkat keras adalah kegagalan host, yang mempengaruhi semua kontainer. Kegagalan kontainer seperti penggunaan disk yang terbebani dan kebocoran memori hanya mempengaruhi satu kontainer. Oleh karena itu, Anda dapat memecahkan masalah kegagalan instance berdasarkan alamat IP host dan alamat IP kontainer.
Untuk memeriksa apakah kegagalan instance terjadi, Anda dapat menanyakan permintaan gagal atau timeout menggunakan Trace Explorer, lalu melakukan analisis agregasi berdasarkan alamat IP host atau alamat IP kontainer. Jika permintaan tidak valid terkonsentrasi pada satu instance, Anda dapat menggunakan instance lain untuk pemulihan cepat, atau memeriksa parameter sistem instance, seperti penggunaan disk dan waktu curi CPU. Jika permintaan tidak valid tersebar di beberapa instance, ini bukan kegagalan instance. Layanan hilir atau logika program mungkin memiliki kesalahan.
Di halaman Trace Explorer, tanyakan permintaan gagal atau timeout dan kelompokkan permintaan berdasarkan alamat IP. Jika permintaan ini terkonsentrasi pada instance tertentu, instance tersebut mungkin gagal.
Skenario 3: Antarmuka lambat
Bagaimana cara menanyakan antarmuka lambat sebelum merilis aplikasi atau menerapkan promosi?
Optimasi kinerja komprehensif diperlukan sebelum aplikasi dirilis atau promosi diterapkan. Anda harus terlebih dahulu mengidentifikasi hambatan kinerja dan menanyakan daftar serta frekuensi antarmuka lambat.
Untuk memecahkan masalah antarmuka lambat, Anda dapat menggunakan Trace Explorer untuk menanyakan antarmuka yang mengonsumsi lebih banyak waktu daripada nilai tertentu, dan mengelompokkannya berdasarkan nama.
Kemudian, Anda dapat menganalisis alasan antarmuka lambat berdasarkan jejak, tumpukan metode, dan kolam thread. Antarmuka lambat mungkin terjadi karena alasan berikut:
Kolam koneksi database atau layanan mikro terlalu kecil dan sejumlah besar permintaan sedang menunggu koneksi. Anda dapat meningkatkan jumlah maksimum thread dalam kolam koneksi.
Permintaan eksternal dan internal dikirim pada saat yang sama. Anda dapat menggabungkan permintaan ini untuk mengurangi waktu yang dikonsumsi untuk transmisi jaringan.
Permintaan tunggal berisi sejumlah besar data. Dalam hal ini, transmisi jaringan dan deserialisasi mungkin memakan waktu lama dan menyebabkan pengumpulan sampah penuh (GCs). Anda dapat mengganti kueri penuh dengan kueri halaman.
Efisiensi pencatatan log sinkron rendah. Anda dapat mengganti pencatatan log sinkron dengan pencatatan log asinkron.
Di halaman Trace Explorer, tanyakan antarmuka lambat yang membutuhkan lebih dari 5 detik dan kelompokkan berdasarkan alamat IP.
Skenario 4: Statistik lalu lintas layanan
Bagaimana cara menganalisis perubahan lalu lintas dan kualitas layanan pelanggan utama atau toko?
Layanan itu rumit dan halus. Jika Anda perlu menganalisis layanan, Anda mungkin perlu mempertimbangkan berbagai dimensi, seperti kategori, toko, dan pengguna. Misalnya, untuk toko ritel fisik, pesanan salah atau mesin POS rusak dapat menyebabkan krisis hubungan masyarakat (PR). Toko fisik memiliki persyaratan service level agreement (SLA) yang lebih tinggi daripada toko online. Oleh karena itu, Anda mungkin perlu memantau perubahan lalu lintas dan kualitas layanan toko ritel fisik.
Anda dapat menanyakan dan menganalisis data jejak dengan menetapkan atribut sebagai kondisi filter. Misalnya, Anda dapat menentukan atribut {"attributes.channel": "offline"} untuk pesanan offline. Anda juga dapat menentukan atribut lain untuk membedakan toko, pengguna, dan kategori. Anda dapat menanyakan jejak yang attributes channel-nya diatur ke offline, dan kelompok jejak berdasarkan jumlah permintaan, waktu, dan tingkat kesalahan. Dengan cara ini, Anda dapat menganalisis perubahan lalu lintas dan kualitas layanan pelanggan atau toko.
Skenario 5: Pemantauan rilis canary
Saya ingin merilis 500 instance dalam 10 batch. Bagaimana cara mengidentifikasi kesalahan setelah batch pertama?
Untuk memastikan stabilitas aplikasi, Anda dapat menerapkan rilis canary, pemantauan, dan rollback. Rilis canary adalah metode kunci untuk memastikan stabilitas aplikasi. Jika Anda mengidentifikasi kesalahan setelah merilis beberapa batch instance, Anda harus mengembalikan rilis. Kurangnya pemantauan rilis canary yang efektif dapat menyebabkan kegagalan layanan.
Sebagai contoh, jika registri layanan mikro gagal, Anda tidak dapat mendaftarkan layanan mikro pada instance yang perlu Anda mulai ulang atau rilis. Namun, Anda tidak dapat mengidentifikasi kesalahan karena kurangnya pemantauan rilis canary. Ini karena lalu lintas keseluruhan atau durasi layanan tidak memiliki perubahan yang tidak terduga. Anda tidak dapat mendaftarkan layanan mikro pada semua batch instance. Dalam hal ini, layanan menjadi tidak tersedia.
Dalam contoh di atas, Anda dapat menentukan atribut {"attributes.version": "v1.0.x"} untuk versi instance yang berbeda, dan menggunakan Trace Explorer untuk menanyakan jejak berdasarkan attributes.version. Dengan cara ini, Anda dapat membedakan perubahan lalu lintas dan kualitas layanan versi instance yang berbeda sebelum dan sesudah rilis. Oleh karena itu, Anda dapat memantau rilis canary secara real-time.
Batasan
Trace Explorer dapat memenuhi persyaratan diagnostik kustom dalam skenario yang berbeda. Namun, ia memiliki batasan berikut:
Biaya analisis berdasarkan data jejak rinci tinggi.
Untuk memastikan akurasi analisis, Anda perlu mengunggah data jejak penuh ke Trace Explorer. Namun, ini mungkin menimbulkan biaya penyimpanan yang tinggi. Untuk mengurangi biaya penyimpanan, terutama biaya penyimpanan yang timbul di seluruh jaringan, Anda dapat menerapkan node tepi di kluster pengguna untuk sementara menyimpan cache dan memproses data. Anda juga dapat menyimpan data panas dan dingin secara terpisah di server. Kemudian, gunakan Trace Explorer untuk menganalisis data panas. Untuk data dingin, Anda hanya dapat menganalisis jejak lambat dan tidak valid.
Analisis pasca-agregasi tidak cocok untuk peringatan karena memiliki overhead kinerja tinggi dan konkurensi rendah.
Trace Explorer memindai data penuh dan menghasilkan statistik secara real-time. Overhead kinerja kueri jauh lebih besar daripada statistik pra-agregasi. Oleh karena itu, Trace Explorer tidak cocok untuk peringatan, yang memerlukan konkurensi tinggi. Anda perlu menyesuaikan metrik dan menjalankan pernyataan analisis pasca-agregasi di klien untuk menghasilkan statistik jejak. Dengan cara ini, Anda dapat menyesuaikan peringatan dan dasbor.
Trace Explorer memerlukan Anda untuk menentukan atribut secara manual.
Trace Explorer berbeda dari metrik pra-agregasi umum pemantauan aplikasi. Untuk membedakan skenario bisnis dan melakukan analisis yang akurat, Anda perlu menentukan berbagai atribut secara manual.
Referensi
Anda dapat mengonfigurasi peringatan untuk satu atau lebih antarmuka. Dengan cara ini, notifikasi peringatan dikirim ke tim O&M saat pengecualian terjadi. Untuk informasi lebih lanjut, lihat Aturan Peringatan Pemantauan Aplikasi.