Lihat dependensi aplikasi - Application Real-Time Monitoring Service

Setelah Anda menginstal agen untuk aplikasi, ARMS akan mulai memantaunya. Di halaman Dependencies, Anda dapat melihat dependensi aplikasi, termasuk panggilan eksternal, panggilan database, dan antrian pesan.

Prasyarat

Penting

Pemantauan Aplikasi ARMS menyediakan halaman detail pemantauan baru bagi pengguna yang telah mengaktifkan model penagihan baru. Untuk informasi selengkapnya tentang model penagihan tersebut, lihat Penagihan Produk (Baru).

Jika Anda belum mengaktifkan model penagihan baru tetapi ingin mengakses halaman detail pemantauan baru, klik Switch to New Version pada halaman Application List.

Anda telah menginstal probe untuk aplikasi Anda. Untuk petunjuknya, lihat Ikhtisar Integrasi Pemantauan Aplikasi.

Dependensi aplikasi

Masuk ke Konsol ARMS. Di panel navigasi kiri, pilih Application Monitoring > Application List.
Di halaman Application List, pilih wilayah di bilah navigasi atas, lalu klik nama aplikasi tersebut.
Catatan
Ikon pada kolom Language memiliki arti sebagai berikut:
- : aplikasi Java yang terhubung ke Pemantauan Aplikasi.
- : aplikasi Golang yang terhubung ke Pemantauan Aplikasi.
- : aplikasi Python yang terhubung ke Pemantauan Aplikasi.
- -: aplikasi yang terhubung ke Managed Service for OpenTelemetry.
Di bilah navigasi atas, klik Dependencies.
- Di area filter cepat, Anda dapat memfilter grafik dan daftar layanan berdasarkan Request Type, Interface Name, dan Host.
- Area grafik tren menampilkan kurva deret waktu untuk jumlah total permintaan, jumlah error, dan waktu respons rata-rata terhadap panggilan ke dependensi aplikasi dalam rentang waktu yang dipilih.
  
  Klik ikon untuk melihat statistik metrik periode tertentu atau membandingkan statistik antar tanggal berbeda. Klik ikon untuk beralih antara grafik batang dan grafik tren.
- Di area daftar layanan, Anda dapat melihat informasi seperti nama antarmuka, tipe, dan metrik RED (jumlah permintaan, jumlah error, dan waktu respons rata-rata).
  
  Di daftar layanan, Anda dapat melakukan operasi berikut:
  - Klik nama antarmuka, atau klik Details, SQL Analysis atau Exception Analysis di kolom Actions untuk melihat detail layanan terkait. Untuk informasi lebih lanjut, lihat Detail dependensi.
  - Klik Trace di kolom Actions untuk melihat jejak terkait. Untuk informasi lebih lanjut, lihat Trace Explorer.

Kerangka kerja yang didukung

Detail dependensi

Panggilan eksternal

Ikhtisar

Di tab Overview, Anda dapat melihat statistik jumlah permintaan, jumlah error, dan waktu respons rata-rata untuk alamat tujuan atau layanan tersebut, serta kurva deret waktu untuk panggilan lambat.

Trace Explorer

Fitur Trace Explorer menganalisis data jejak yang tersimpan secara real time, memungkinkan Anda menggabungkan kondisi filter dan dimensi agregasi untuk memenuhi berbagai kebutuhan diagnostik kustom. Untuk informasi lebih lanjut, lihat Trace Explorer.

Penerbitan pesan

Catatan

Menampilkan data penerbitan pesan tidak didukung untuk aplikasi Python.

Ikhtisar

Di tab Overview, Anda dapat melihat statistik jumlah permintaan, jumlah error, dan waktu respons rata-rata untuk pesan target, serta kurva deret waktu untuk panggilan lambat.

Statistik pengiriman

Tab Sending Statistics mencantumkan statistik pengiriman topik dari perspektif pengirim, termasuk jumlah permintaan, jumlah error, dan waktu respons.

Trace Explorer

Panggilan database

Catatan

Menampilkan data panggilan database tidak didukung untuk aplikasi Python.

Ikhtisar

Di tab Overview, Anda dapat melihat statistik, grafik deret waktu, dan distribusi untuk jumlah permintaan, jumlah error, dan waktu respons rata-rata dari panggilan ke instans database target, serta distribusi jumlah panggilan lambat.

SQL Analysis

Di tab SQL Analysis, Anda dapat melihat tren permintaan (jumlah permintaan, jumlah SQL lambat, dan waktu respons rata-rata) untuk instans database yang dipilih, serta metrik statistik pada tingkat panggilan SQL. Informasi ini membantu Anda mengidentifikasi pernyataan SQL mana yang menyebabkan respons layanan menjadi lambat.

Catatan

Metrik Return Size hanya didukung untuk versi MySQL 5.x dan memerlukan agen Pemantauan Aplikasi versi 2.7.1.3 atau lebih baru.

Klik Trace di sebelah kanan pernyataan SQL untuk melihat jejak lengkap yang mencakup eksekusi SQL tersebut. Untuk informasi lebih lanjut, lihat Trace Explorer.

Exception Analysis

Di tab Exception Analysis, Anda dapat melihat frekuensi kemunculan setiap exception selama panggilan ke database target dalam rentang waktu tertentu, serta detail exception tersebut. Untuk informasi lebih lanjut, lihat Exception Analysis.

Call source

Di tab Call Source, Anda dapat melihat kurva deret waktu untuk waktu respons, jumlah permintaan, dan jumlah error dari antarmuka sumber yang memanggil database target.

Trace Explorer

FAQ

Database

Tidak ada data untuk panggilan database

Kemungkinan penyebab:

Database tersebut tidak termasuk dalam daftar database yang didukung oleh ARMS. Untuk daftar database yang didukung, lihat Komponen dan kerangka kerja Java yang didukung untuk Pemantauan Aplikasi ARMS.
Versi agen sebelum 4.x tidak mendukung database yang dipanggil secara asinkron atau tanpa titik masuk.

Ketidaksesuaian pada panggilan database lambat

ARMS melakukan pemantauan dari perspektif sisi klien, artinya pengukurannya mencakup seluruh proses: aplikasi menginisiasi permintaan, permintaan dikirim melalui jaringan, server memprosesnya, dan respons dikembalikan ke klien. Oleh karena itu, metrik database yang dikumpulkan oleh ARMS dipengaruhi oleh faktor-faktor seperti garbage collection (GC) dan latensi jaringan, yang dapat menghasilkan nilai lebih tinggi dibandingkan dengan yang dilaporkan langsung oleh server. Selain itu, ARMS mengidentifikasi panggilan lambat berdasarkan Slow SQL Threshold yang dikonfigurasi pada halaman Custom Configuration. Ambang batas ini secara default bernilai 500 ms dan mungkin berbeda dari konfigurasi pada server database.

Ketidaksesuaian volume panggilan database

Sebuah database tunggal dapat diakses oleh beberapa aplikasi. Konsol ARMS hanya menampilkan volume panggilan dari aplikasi saat ini.

Panggilan eksternal tidak terekam

Untuk agen versi 3.x, kemungkinan penyebabnya meliputi:

Panggilan eksternal tanpa titik masuk.

Secara default, agen versi 3.x hanya mengumpulkan panggilan eksternal yang terjadi dalam alur pemrosesan antarmuka HTTP, antarmuka RPC, tugas terjadwal, dan konsumsi pesan. Panggilan eksternal, seperti akses database atau permintaan HTTP, yang diinisiasi oleh kolam thread latar belakang tidak dikumpulkan.
Panggilan eksternal dengan titik masuk tetapi terjadi pergantian thread selama eksekusi.

Agen versi 3.x tidak mendukung propagasi konteks asinkron secara otomatis. Jika terjadi pergantian thread, konteks jejak hilang, dan panggilan tersebut tidak dikumpulkan.

Kedua masalah ini dapat diselesaikan dengan meningkatkan versi agen ke 4.x.

Data tidak terdefinisi dalam panggilan eksternal

Versi agen 3.1.x dan sebelumnya memiliki cacat pada instrumentasi Dubbo yang mencegah agen memperoleh alamat IP peer. Masalah ini telah diperbaiki pada versi 3.2.x.

Kunci kacau pada panggilan Redis

Masalah instrumentasi pada kerangka kerja Lettuce menyebabkan pengambilan kunci yang salah. Anda dapat mengabaikan bagian kunci yang acak tersebut; sisanya merupakan kunci yang valid.

Tidak ada data jejak dari pernyataan SQL

Penyebab: Untuk menghindari biaya dan overhead performa akibat pelaporan data dalam jumlah besar pada skenario ekstrem, agen ARMS secara default mengaktifkan kompresi span. Ketika beberapa child span di bawah satu parent span memiliki nama yang sama, span-span tersebut dikompresi menjadi satu span representatif. Atributnya kemudian menyimpan jumlah, durasi total, durasi maksimum, dan durasi minimum dari semua child span identik tersebut. Namun, kompresi ini menghilangkan detail individual dari span yang diagregasi. Akibatnya, pernyataan SQL dalam span yang dikompresi tersebut tidak dapat langsung diquery pada halaman Trace Explorer.

Solusi: Nonaktifkan kompresi jejak.

Catatan

Setelah Anda menonaktifkan kompresi, jika antarmuka aplikasi sering mengakses komponen seperti database atau Redis, jumlah data yang dilaporkan akan meningkat, dan logika sampling ARMS untuk error dan panggilan lambat akan menjadi kurang efektif.

Penerbitan pesan

Perbedaan data antara tampilan klien dan server

Halaman Message Subscription dan Message Publishing menampilkan metrik performa sisi klien untuk aplikasi yang dipilih yang bertindak sebagai konsumen atau produsen, sedangkan dasbor pemantauan untuk instans MQ menampilkan metrik performa sisi server yang terkait topik.

Format nama span untuk pesan

Tipe pesan	Versi agen sebelum 4.x	Agen 4.x dan seterusnya
Pengiriman pesan RocketMQ/Ons	Tidak ada span yang dibuat. Hanya tumpukan metode yang direkam.	`${topic} + publish`
Penerimaan pesan RocketMQ/Ons	`Recv Topic@${topic}`	`Recv Topic@${topic}`
Pengiriman pesan Kafka	Tidak ada span yang dibuat. Hanya tumpukan metode yang direkam.	`${topic} + publish`
Penerimaan pesan Kafka	`Kafka/topic=${topic}`	`Kafka/topic=${topic}`
Pengiriman pesan RabbitMQ	Tidak ada span yang dibuat. Hanya tumpukan metode yang direkam.	`${exchange} + publish`
Penerimaan pesan RabbitMQ	`Recv Exchange@${exchange}`	`Recv Exchange@${exchange}`

Dukungan untuk Spring Cloud Alibaba RocketMQ

Kerangka kerja ini didukung pada versi agen 4.x dan seterusnya. Jika versi agen Anda sebelum 4.x, tingkatkan agen ARMS.

Metrik Message Delay

Message delay mengacu pada total waktu dari produksi hingga konsumsi pesan. Satuan untuk metrik ini adalah milidetik (ms). Metrik ini saat ini hanya dikumpulkan untuk RocketMQ Client dan Ons Client.

Jejak atau metrik konsumen tidak muncul

Hal ini dapat terjadi jika versi agen sebelum 4.x dan Anda menggunakan ekspresi lambda untuk mendefinisikan logika konsumsi dalam pendengar pesan.

Karena peningkatan kelas untuk ekspresi lambda gagal pada versi agen 2.x dan 3.x, Anda dapat meningkatkan versi agen ke 4.x untuk mengatasi masalah ini.

Error header Kafka 'Magic v1'

Agen Java menggunakan bidang Header pada pesan Kafka untuk menyebarkan konteks jejak. Pada versi Kafka sebelum 0.11.0.0 (baik untuk klien maupun broker), format pesan tidak mendukung header. Jika Anda menggunakan versi Kafka lama untuk broker atau klien Anda, migrasikan ke versi 0.11.0.0 atau lebih baru. Jika Anda tidak dapat segera melakukan migrasi, untuk versi agen Java sebelum 4.x, Anda dapat menonaktifkan peningkatan komponen Kafka (sakelar kafka-plugin) pada bagian Agent Switch Settings di halaman Custom Configurations aplikasi. Untuk versi agen Java 4.x dan seterusnya, tambahkan parameter JVM -Dotel.instrumentation.kafka.producer-propagation.enabled=false saat memulai layanan sebagai solusi sementara.

Span pesan tidak muncul dalam jejak

Periksa apakah SDK klien message queue yang digunakan oleh aplikasi produsen dan konsumen Anda didukung oleh ARMS. Untuk komponen yang didukung, lihat Komponen dan kerangka kerja Java yang didukung untuk Pemantauan Aplikasi ARMS.
Periksa apakah aplikasi produsen dan konsumen Anda terhubung ke Pemantauan Aplikasi atau Managed Service for OpenTelemetry, memiliki sakelar agen dan plugin yang diaktifkan, serta melaporkan ke wilayah yang sama. Span untuk pengiriman pesan dihasilkan di sisi produsen, dan span untuk penerimaan pesan dihasilkan di sisi konsumen. Jika salah satu aplikasi tidak dikonfigurasi dengan benar, span-nya akan hilang.
Jika Anda tidak dapat melihat span untuk pengiriman pesan, periksa apakah versi agen aplikasi produsen Anda 4.x atau lebih baru. Pada versi agen sebelum 4.x, pengiriman pesan tidak direkam sebagai span terpisah, melainkan disertakan dalam tumpukan metode span induk. Anda dapat mengklik ikon di sebelah span induk untuk melihat tumpukan panggilan metode.
Jika Anda tidak dapat melihat span untuk penerimaan pesan, periksa apakah Anda telah mengonfigurasi Invalid API Filter di bagian Interface Call Configuration pada halaman Custom Configurations aplikasi konsumen. Filter ini digunakan untuk mengecualikan span yang tidak diinginkan agar tidak dikumpulkan.

Perbedaan waktu respons Kafka antar versi agen

Gejala: Waktu respons turun dari beberapa detik menjadi 0,x milidetik.

Penyebab:

Pada versi agen 3.x dan sebelumnya, saat memproses BatchMessageListener, satu batch pesan diperlakukan sebagai satu panggilan tunggal, dan durasinya diagregasi menjadi satu nilai.

Versi agen 4.x dan seterusnya memisahkan logika ini, menghitung setiap pesan sebagai panggilan individual. Oleh karena itu, setelah peningkatan dari agen versi 3.x ke 4.x, waktu respons per panggilan akan menurun signifikan sementara jumlah panggilan akan meningkat signifikan.

Metode statistik yang digunakan pada versi 3.x kurang tepat dan telah diperbaiki pada versi 4.x.