Setelah Anda menginstal agen Application Real-Time Monitoring Service (ARMS) untuk suatu aplikasi, ARMS mulai memantau aplikasi tersebut. Anda dapat melihat informasi mengenai dependensi aplikasi pada halaman Dependensi, termasuk panggilan eksternal, panggilan database, dan antrian pesan.
Prasyarat
Agen ARMS telah diinstal untuk aplikasi tersebut.
Pemantauan Aplikasi menyediakan halaman detail aplikasi baru bagi pengguna yang telah mengaktifkan mode penagihan baru.
Jika Anda belum mengaktifkan mode penagihan baru, klik Switch to New Version pada halaman Application List untuk melihat halaman detail aplikasi baru.
Lihat dependensi aplikasi
Masuk ke Konsol ARMS. Di panel navigasi sebelah kiri, pilih .
Di bilah navigasi atas, klik Dependencies.
Pada bagian Filter Cepat (ikon 1), Anda dapat mencari grafik dan dependensi berdasarkan Request Type, Request Destination, dan Host.
Pada bagian grafik tren (ikon 2), Anda dapat melihat deret waktu permintaan yang dikirim oleh aplikasi ke dependensi, jumlah kesalahan, dan durasi rata-rata dalam periode waktu tertentu.
Klik ikon
. Pada kotak dialog yang muncul, Anda dapat melihat data metrik dalam periode waktu tertentu atau membandingkan data metrik dalam periode waktu yang sama di tanggal berbeda. Anda dapat mengklik ikon 
untuk menampilkan data dalam bentuk grafik kolom atau grafik tren.Pada bagian daftar layanan (ikon 3), Anda dapat melihat nama, jenis, dan metrik utama dari setiap permintaan yang ditentukan oleh Metode RED: laju, kesalahan, dan durasi.
Pada daftar layanan, Anda dapat melakukan operasi berikut:
Klik nama dependensi, atau klik Details, SQL Analysis, atau Exceptions di kolom Actions untuk melihat detail dependensi tersebut. Untuk informasi selengkapnya, lihat Detail dependensi.
Klik Traces di kolom Actions untuk melihat detail jejak dependensi. Untuk informasi selengkapnya, lihat Trace Explorer.
Kerangka kerja yang didukung
Detail dependensi
Panggilan eksternal
Ikhtisar
Pada tab Ikhtisar, Anda dapat melihat jumlah permintaan, jumlah kesalahan, dan durasi rata-rata dari titik akhir atau layanan, serta deret waktu panggilan lambat.
Trace explorer
Trace Explorer memungkinkan Anda menggabungkan kondisi filter dan dimensi agregasi untuk analisis real-time berdasarkan data jejak lengkap yang disimpan. Hal ini dapat memenuhi kebutuhan diagnostik kustom dalam berbagai skenario. Untuk informasi selengkapnya, lihat Trace Explorer.
Penerbitan pesan
Penerbitan pesan untuk aplikasi Python tidak dapat dilihat.
Ikhtisar
Pada tab Ikhtisar, Anda dapat melihat jumlah permintaan, jumlah kesalahan, dan durasi rata-rata dari sebuah pesan, serta deret waktu panggilan lambat.
Statistik pengiriman
Pada tab Delivery Statistics, Anda dapat melihat detail pengiriman pesan ke topik dari perspektif pengirim pesan, termasuk jumlah permintaan, jumlah kesalahan, dan durasi.
Trace explorer
Trace Explorer memungkinkan Anda menggabungkan kondisi filter dan dimensi agregasi untuk analisis real-time berdasarkan data jejak lengkap yang disimpan. Hal ini dapat memenuhi kebutuhan diagnostik kustom dalam berbagai skenario. Untuk informasi selengkapnya, lihat Trace Explorer.
Panggilan database
Panggilan database untuk aplikasi Python tidak dapat dilihat.
Ikhtisar
Pada tab Ikhtisar, Anda dapat melihat jumlah permintaan, jumlah kesalahan, dan durasi rata-rata dari instans database yang dipanggil oleh aplikasi, serta deret waktu panggilan lambat.
Analisis SQL
Pada tab SQL analysis, Anda dapat melihat tren jumlah permintaan, jumlah kesalahan, dan durasi rata-rata dari instans database, serta deret waktu pernyataan SQL. Pada tab ini, Anda dapat menemukan pernyataan SQL yang menyebabkan layanan merespons secara lambat.
Bidang Return Size hanya tersedia untuk MySQL v5.x dan hanya didukung oleh agen ARMS v2.7.1.3 atau yang lebih baru.
Anda dapat mengklik Traces di kolom Actions untuk melihat jejak pernyataan SQL. Untuk informasi selengkapnya, lihat Trace Explorer.
Exceptions
Pada tab Exceptions, Anda dapat melihat jumlah kali setiap exception dilemparkan saat aplikasi memanggil database dalam periode waktu tertentu, serta detail exception tersebut. Untuk informasi selengkapnya, lihat Analisis exception.
Source of Request
Pada tab Source of Request, Anda dapat melihat deret waktu waktu respons, jumlah permintaan, dan jumlah kesalahan dari antarmuka tempat aplikasi memanggil database.
Trace explorer
Trace Explorer memungkinkan Anda menggabungkan kondisi filter dan dimensi agregasi untuk analisis real-time berdasarkan data jejak lengkap yang disimpan. Hal ini dapat memenuhi kebutuhan diagnostik kustom dalam berbagai skenario. Untuk informasi selengkapnya, lihat Trace Explorer.
FAQ
Database
Mengapa panggilan database tidak memiliki data?
Kemungkinan penyebab:
Database tersebut tidak ada dalam daftar database yang didukung oleh ARMS. Untuk informasi tentang database yang didukung, lihat Komponen dan kerangka kerja Java yang didukung oleh ARMS.
Agen ARMS versi sebelum v4.x tidak mendukung database yang dipanggil secara asinkron atau tanpa titik masuk.
Mengapa Konsol ARMS menampilkan panggilan database lambat yang tidak terlihat di sisi server database?
ARMS memantau dari perspektif klien, mencakup seluruh proses mulai dari permintaan diajukan dalam aplikasi, dikirim melalui jaringan ke server, diproses oleh server, hingga tanggapan dikirim kembali ke klien. Oleh karena itu, metrik database yang dikumpulkan oleh ARMS dapat dipengaruhi oleh faktor-faktor seperti pengumpulan sampah dan latensi jaringan, yang dapat menghasilkan nilai lebih tinggi dibandingkan dengan yang diamati di sisi server. Selain itu, ARMS menentukan apakah suatu panggilan lambat berdasarkan Slow SQL Threshold yang dikonfigurasi pada halaman Custom Configuration, dengan ambang batas default 500 ms, yang mungkin berbeda dari pengaturan di sisi server.
Mengapa volume panggilan database yang terlihat di Konsol ARMS berbeda dengan volume panggilan yang diamati oleh pemantauan server database?
Database mungkin diakses oleh beberapa aplikasi. Konsol ARMS hanya dapat menampilkan volume panggilan dari aplikasi saat ini dan tidak menampilkan volume panggilan dari aplikasi lain yang mengakses database yang sama.
Mengapa beberapa panggilan eksternal tidak terekam?
Pada agen versi 3.x, penyebabnya mungkin sebagai berikut:
Panggilan eksternal tanpa titik masuk.
Secara default, agen versi 3.x hanya mengumpulkan panggilan eksternal yang dieksekusi dalam alur pemrosesan antarmuka HTTP, antarmuka RPC, tugas terjadwal, dan konsumsi pesan. Misalnya, mengakses database atau mengirim permintaan HTTP. Panggilan eksternal yang dieksekusi langsung melalui kolam thread secara terjadwal akan diabaikan selama pengumpulan.
Panggilan eksternal dengan titik masuk, tetapi terjadi pergantian thread saat mengeksekusi panggilan eksternal yang sebenarnya.
Karena agen versi 3.x tidak mendukung propagasi konteks asinkron otomatis, tidak ada konteks jejak setelah pergantian thread, dan dalam kasus ini, pengumpulan juga akan diabaikan.
Kedua situasi tersebut dapat diselesaikan dengan meningkatkan agen ke versi 4.x.
Mengapa panggilan eksternal memiliki data undefined?
Versi agen 3.1.x dan sebelumnya memiliki cacat dalam instrumentasi Dubbo, yang menyebabkan kegagalan saat memperoleh alamat IP peer. Masalah ini telah diperbaiki pada versi 3.2.x.
Mengapa kunci panggilan Redis menampilkan teks acak?
Hal ini disebabkan oleh masalah instrumentasi dalam kerangka kerja Lettuce yang mengakibatkan nilai kunci salah. Anda dapat mengabaikan bagian yang acak tersebut, karena bagian lainnya merupakan nilai yang valid.
Mengapa tidak ada data saat melompat dari pernyataan SQL ke halaman Trace Explorer?
Penyebab: Untuk menghindari biaya dan beban kinerja akibat pelaporan data dalam jumlah besar pada skenario ekstrem, agen ARMS secara default mengaktifkan kompresi Span. Ketika beberapa child Span dari ParentSpan memiliki SpanName yang sama, hanya satu child Span yang akan direkam, dan atribut child Span tersebut akan mencatat jumlah child Span serupa, jumlah total durasinya, durasi maksimum, dan durasi minimum. Situasi ini menyebabkan hilangnya informasi dari Span yang dikompresi, dan demikian pula, pernyataan SQL dalam Span yang dikompresi tidak dapat langsung dikueri pada halaman Trace Explorer.
Solusi: Nonaktifkan kompresi jejak.
Setelah menonaktifkan kompresi, ketika antarmuka aplikasi melakukan banyak operasi pada komponen seperti database atau Redis, hal ini akan menyebabkan peningkatan jumlah data yang dilaporkan, dan logika sampling kesalahan serta lambat dari ARMS akan menjadi tidak efektif.
Penerbitan pesan
Apa perbedaan antara data pada halaman Langganan Pesan/Penerbitan Pesan dan data dari panel pemantauan mandiri instans antrian pesan?
Data pada halaman Langganan Pesan/Penerbitan Pesan mencerminkan berbagai metrik kinerja ketika aplikasi yang dipilih bertindak sebagai konsumen atau produsen, menyajikan data pemantauan dari perspektif klien. Data panel pemantauan untuk instans antrian pesan, di sisi lain, menunjukkan metrik kinerja yang terkait dengan topik, yaitu data dari perspektif server.
Apa format SpanName untuk mengirim dan menerima pesan?
Jenis pesan | Agen ARMS sebelum v4.x | Agen ARMS v4.x dan seterusnya |
Pengiriman pesan RocketMQ/ONS | Tidak ada span yang dibuat. Hanya stack metode yang direkam. |
|
Penerimaan pesan RocketMQ/ONS |
|
|
Pengiriman pesan Kafka | Tidak ada span yang dibuat. Hanya stack metode yang direkam. |
|
Penerimaan pesan Kafka |
|
|
Pengiriman pesan RabbitMQ | Tidak ada span yang dibuat. Hanya stack metode yang direkam. |
|
Penerimaan pesan RabbitMQ |
|
|
Apakah agen ARMS untuk Java mendukung Spring Cloud Alibaba RocketMQ?
Agen ARMS v4.x dan yang lebih baru mendukung kerangka kerja ini. Jika versi agen Anda sebelum 4.x, tingkatkan.
Apa arti dan satuan metrik "Message Delay" dalam pemantauan antrian pesan?
Message delay mengacu pada total waktu yang dibutuhkan sejak pesan dibuat hingga dikonsumsi oleh Consumer. Satuan metrik ini adalah milidetik (ms). Saat ini, metrik ini hanya didukung untuk pengumpulan oleh RocketMQ Client dan ONS Client.
Mengapa aplikasi memiliki logika consumer tetapi tidak ada data jejak atau metrik terkait consumer?
Kemungkinan karena versi agen lebih rendah dari 4.x, dan ekspresi lambda digunakan untuk mendefinisikan logika konsumsi dalam messageListener.
Karena kegagalan peningkatan kelas untuk ekspresi lambda pada versi agen 2.x dan 3.x, Anda dapat menghindari masalah ini dengan meningkatkan agen ke v4.x.
Mengapa saya menerima pesan kesalahan "Magic v1 does not support record headers" saat menghubungkan Kafka Clients ke agen ARMS untuk Java?
Agen ARMS untuk Java menggunakan bidang Header pesan Kafka untuk meneruskan konteks jejak. Namun, pada versi Kafka sebelum 0.11.0.0 (baik Client maupun Broker), isi pesan Kafka tidak mendukung bidang Header. Jika broker atau klien Kafka Anda berada di bawah versi ini, segera migrasikan ke versi 0.11.0.0 atau yang lebih tinggi.Jika Anda belum dapat melakukan migrasi saat ini, untuk agen sebelum v4.x, Anda dapat menonaktifkan peningkatan komponen Kafka (sakelar kafka-plugin) di bagian Probe switch settings pada tab Custom Configuration. Untuk agen v4.x dan yang lebih baru, Anda dapat menambahkan parameter JVM -Dotel.instrumentation.kafka.producer-propagation.enabled=false saat memulai layanan untuk mencegah masalah tersebut.
Mengapa jejak tidak memiliki Span untuk menerima atau mengirim pesan?
Periksa apakah SDK Klien antrian pesan yang digunakan oleh aplikasi Producer dan Consumer Anda berada dalam rentang yang didukung oleh ARMS. Untuk informasi selengkapnya, lihat Komponen dan kerangka kerja Java yang didukung oleh ARMS.
Pastikan bahwa aplikasi Producer dan Consumer Anda dipantau oleh Pemantauan Aplikasi atau Managed Service for OpenTelemetry, dengan sakelar agen dan sakelar plugin diaktifkan dengan benar, serta melaporkan ke wilayah yang sama. Span untuk mengirim pesan dihasilkan di Producer, sedangkan Span untuk menerima pesan dihasilkan di Consumer. Jika suatu aplikasi tidak dipantau dengan benar, Span yang sesuai akan hilang.
Jika Anda tidak dapat melihat Span untuk mengirim pesan, periksa apakah versi agen aplikasi Producer Anda adalah 4.x atau yang lebih baru. Pada versi agen sebelum 4.x, pengiriman pesan tidak menghasilkan Span terpisah, melainkan direkam dalam stack metode dari Span induk. Anda dapat mengklik ikon
di sebelah kanan Span induk untuk melihat stack metode panggilan aktual.
Jika Anda tidak dapat melihat Span untuk menerima pesan, periksa apakah Invalid Interface Filter diaktifkan di bagian Interface Call Configurations pada tab Custom Configuration. Opsi ini menyaring Span yang tidak Anda perlukan.
Mengapa terdapat perbedaan besar dalam waktu respons Kafka antara versi agen 4.x dan sebelumnya?
Masalah: Waktu respons berubah dari beberapa detik menjadi 0,x milidetik.
Penyebab:
Pada versi agen 3.x dan sebelumnya, saat memproses BatchMessageListener, satu batch pesan dianggap sebagai satu panggilan tunggal, dan semua durasi diagregasi bersama.
Pada versi agen 4.x dan seterusnya, operasi-operasi ini dipisahkan, dengan setiap pesan dihitung sebagai panggilan individual. Oleh karena itu, saat meningkatkan dari versi agen 3.x ke 4.x, durasi satu panggilan akan berkurang secara signifikan sementara jumlah panggilan akan meningkat secara signifikan.
Metode statistik pada versi 3.x tidak masuk akal, dan telah dioptimalkan pada versi 4.x.