Application Real-Time Monitoring Service:Pemantauan instans untuk aplikasi Java

Metrik berdasarkan lingkungan

Metrik yang tersedia berbeda tergantung pada apakah aplikasi Anda berjalan di ECS atau di kontainer, serta apakah lingkungan kontainer terintegrasi dengan Managed Service for Prometheus.

Metrik grafik tren

Untuk lingkungan ECS, gunakan daftar drop-down di samping judul setiap grafik infrastruktur untuk beralih antara nilai rata-rata dan maksimum.

Untuk grafik GC, beralihlah antara jumlah GC dan durasi rata-rata GC. Untuk grafik memori JVM, beralihlah antara tampilan memori heap dan non-heap.

Kolom daftar instans

Di lingkungan Kontainer (Prometheus), utilisasi CPU, memori, dan disk menampilkan - ketika tidak ada limit yang ditetapkan untuk resource tersebut.

Persyaratan lingkungan kontainer

• Dengan Managed Service for Prometheus: Metrik kontainer berasal dari Managed Service for Prometheus. Untuk menyiapkan integrasi, lihat Container Observability.

• Tanpa Managed Service for Prometheus: Tingkatkan probe Pemantauan Aplikasi ke versi 4.1.0 atau lebih baru. Versi probe sebelumnya tidak melaporkan metrik dasar kontainer. Untuk detail versi probe, lihat Panduan versi Probe (Java Agent).

Interaksi grafik

Setiap grafik tren mendukung dua aksi:

• Klik untuk melihat statistik metrik dalam rentang waktu tertentu atau membandingkan rentang waktu yang sama di tanggal berbeda.

• Klik untuk beralih antara grafik kolom dan grafik tren.

Aksi daftar instans

• Klik IP instans (atau Details di kolom Actions untuk lingkungan kontainer) untuk membuka detail instans.

• Klik Trace di kolom Actions untuk melihat detail jejak. Untuk informasi lebih lanjut, lihat Analisis jejak.

Ikhtisar

Tab Overview menampilkan jumlah permintaan, jumlah error, waktu respons rata-rata, dan informasi panggilan lambat untuk antarmuka yang dipilih.

Host List di sisi kiri memungkinkan Anda beralih antar host untuk melihat data pemantauan. Kartu ringkasan menunjukkan perubahan persentase hari-ke-hari. Di bawah kartu, grafik tren deret waktu menampilkan Requests/1m, Errors/1m, dan Response Time/1m dengan granularitas per menit. Halaman ini juga mencakup tab JVM Monitoring, Host Monitoring, dan Trace Analysis.

Pemantauan JVM

Tab JVM Monitoring menampilkan metrik GC, memori, thread, dan deskriptor file untuk instans yang dipilih.

Bagian GC berisi grafik Full GC Count/1m, Young GC Count/1m, Full GC Trigger Reason/1m, dan Young GC Trigger Reason/1m. Bagian memori berisi grafik Memory Usage Distribution/1m, Heap Memory/1m, Heap Memory (used)/1m, dan lainnya. Panel kiri memungkinkan Anda memilih instans aplikasi tertentu untuk melihat data pemantauannya.

Pemantauan kolam thread

Pemantauan kolam thread melacak konfigurasi thread inti, status thread aktif, dan metrik eksekusi tugas. Filter kolam thread berdasarkan jenis dan nama di bagian atas tab.

Pemantauan kolam koneksi

Pemantauan kolam koneksi melacak konfigurasi inisialisasi dan status koneksi waktu proses. Filter kolam koneksi berdasarkan jenis di bagian atas tab.

Pemantauan host

Tab Host Monitoring menampilkan metrik CPU, memori, disk, load, traffic jaringan, dan paket jaringan.

Pemantauan kontainer

Tab Container Monitoring menampilkan metrik resource tingkat kontainer. Metrik yang tersedia bergantung pada metode integrasi Anda:

Tab Container Monitoring menampilkan area Ikhtisar dengan metrik ringkasan Namespace, Kluster, serta CPU (core) dan Memori avg/max/last/Limit. Di bawahnya, area Resource berisi empat grafik garis berikut:

• Memory/Limit(%)

• Memory Usage

• CPU Usage(%)

• CPU Usage By Cores (dengan kurva user/system/total)

Analisis jejak

Analisis jejak melakukan kueri data jejak yang tersimpan secara real-time. Gabungkan filter dan dimensi agregasi untuk mendiagnosis masalah performa di berbagai skenario. Untuk detailnya, lihat Analisis jejak.

Di konsol Tracing, masukkan kriteria pencarian seperti serviceName: "mall-gateway" untuk melakukan kueri data jejak. Halaman ini berisi:

• Panel filter cepat di sisi kiri: filter berdasarkan Status, Durasi (rentang slider 0 ns–5 s), Nama Antarmuka, dan Alamat Host.

• Grafik statistik atas: histogram Jumlah Panggilan, histogram Error/Error HTTP, grafik garis Durasi Rata-Rata.

• Tabel data Span bawah: kolom mencakup TraceId, Nama Antarmuka, Nama Aplikasi, Durasi, Status, Waktu Mulai, Alamat Host. Klik Details atau Logs untuk melihat detail jejak.

• Panel Slow Trace Analysis di sisi kanan: menampilkan spanNames teratas berdasarkan kontribusi durasi.

Mengapa traffic tidak merata di seluruh instans?

Pada versi probe 3.x, mengaktifkan optimasi memori dapat menyebabkan beberapa metrik terlewat. Tingkatkan ke versi probe 4.x.

Mengapa satu permintaan Undertow dihitung dua kali?

Pada versi probe sebelum 3.2.x, instrumentasi DeferredResult menyebabkan satu panggilan direkam dua kali. Tingkatkan ke versi probe 3.2.x atau lebih baru.

Mengapa kuota CPU atau memori di Pemantauan Kontainer tidak sesuai dengan pengaturan Pod?

Periksa apakah Pod mendefinisikan beberapa kontainer. Metrik ini merupakan jumlah kuota dari semua kontainer dalam Pod tersebut.

Mengapa beberapa metrik sistem hilang, tidak akurat, atau menunjukkan penggunaan CPU 100%?

Versi probe sebelum 4.x tidak mengumpulkan metrik sistem di Windows. Tingkatkan ke versi probe 4.x atau lebih baru.

Mengapa Full GC terjadi tepat setelah startup aplikasi?

Ukuran metaspace default sekitar 20 MB. Selama startup, ekspansi metaspace memicu Full GC. Tetapkan ukuran awal dan maksimum metaspace menggunakan parameter -XX:MetaspaceSize dan -XX:MaxMetaspaceSize.

Bagaimana VM Stack dihitung?

VM Stack dihitung sebagai jumlah thread aktif dikalikan 1 MB (ukuran stack thread default). Jika Anda menetapkan ukuran stack berbeda dengan -Xss, metrik ini mungkin tidak sesuai dengan nilai aktual.

Bagaimana metrik JVM dikumpulkan?

ARMS mengambil metrik JVM menggunakan antarmuka JDK standar.

Metrik memori:

• ManagementFactory.getMemoryPoolMXBeans

• java.lang.management.MemoryPoolMXBean#getUsage

Metrik GC (probe sebelum 4.4.0):

• ManagementFactory.getGarbageCollectorMXBeans

• GarbageCollectorMXBean#getCollectionCount

• GarbageCollectorMXBean#getCollectionTime

Metrik GC (probe 4.4.0 atau lebih baru):

Diambil dengan berlangganan event GarbageCollectionNotificationInfo dari GarbageCollectorMXBean.

Mengapa nilai maksimum memori heap JVM adalah -1?

Nilai -1 berarti ukuran maksimum heap tidak dikonfigurasi. Tetapkan menggunakan parameter -Xmx.

Mengapa penggunaan memori heap JVM tidak sama dengan ukuran maksimum memori heap?

Parameter -Xms menetapkan ukuran heap awal. JVM memperluas heap sesuai kebutuhan, hingga batas maksimum yang ditetapkan oleh -Xmx. Ketidaksesuaian berarti heap belum sepenuhnya diperluas.

Mengapa frekuensi GC JVM meningkat secara bertahap?

Hal ini biasanya terjadi dengan ParallelGC, algoritma GC default di JDK 8. ParallelGC mengaktifkan -XX:+UseAdaptiveSizePolicy secara default, yang secara dinamis menyesuaikan ukuran heap. Saat Young GC berjalan sering, ruang survivor mungkin menyusut, menyebabkan objek dipromosikan ke generasi lama lebih cepat. Ini mempercepat pertumbuhan generasi lama dan memicu Full GC lebih sering. Untuk detailnya, lihat dokumentasi Java GC Ergonomics.

Mengapa tidak ada data untuk pemantauan kolam thread atau kolam koneksi?

1. Di halaman Custom Configuration, di bawah Advanced Settings, pastikan pemantauan kolam thread dan kolam koneksi diaktifkan.

2. Verifikasi bahwa framework-nya didukung. Lihat Pemantauan kolam thread dan kolam koneksi.

Mengapa jumlah koneksi maksimum HikariCP tidak sesuai ekspektasi?

Versi probe sebelum 3.2.x salah mengambil jumlah koneksi maksimum. Tingkatkan ke versi probe 3.2.x atau lebih baru.

Mengapa metrik pemantauan pooling ditampilkan sebagai nilai desimal?

Probe mengumpulkan data setiap 15 detik. Konsol menampilkan rata-rata dalam rentang waktu yang dipilih. Misalnya, jika empat titik data dalam satu menit adalah 0, 0, 1, dan 0, nilai yang ditampilkan adalah 0,25.

Mengapa kolam thread atau kolam koneksi penuh, tetapi pemantauan tidak menunjukkan perubahan?

ARMS mengumpulkan metrik kolam thread dan kolam koneksi setiap 15 detik. Lonjakan singkat dalam interval ini mungkin tidak tertangkap.

Mengapa jumlah maksimum thread kolam thread tidak sesuai ekspektasi atau menunjukkan angka 2,1 miliar?

ARMS membaca jumlah maksimum thread langsung dari objek kolam thread. Nilai 2,1 miliar biasanya menunjukkan kolam thread terjadwal, yang secara default menggunakan Integer.MAX_VALUE.

/**
 * Creates a new ScheduledThreadPoolExecutor with the given core pool size.
 * @param corePoolSize the number of threads to keep in the pool, even if they are idle,
 *        unless allowCoreThreadTimeOut is set
 * @throws IllegalArgumentException if corePoolSize < 0
 */
public ScheduledThreadPoolExecutor(int corePoolSize) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
            new DelayedWorkQueue());
}

/**
 * Creates a new ScheduledThreadPoolExecutor with the given initial parameters.
 * @param corePoolSize the number of threads to keep in the pool, even if they are idle,
 *        unless allowCoreThreadTimeOut is set
 * @param threadFactory the factory to use when the executor creates a new thread
 * @throws IllegalArgumentException if corePoolSize < 0
 * @throws NullPointerException if threadFactory is null
 */
public ScheduledThreadPoolExecutor(int corePoolSize,
                        ThreadFactory threadFactory) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
            new DelayedWorkQueue(), threadFactory);
}

Mengapa metrik kolam thread Tomcat tidak sesuai ekspektasi?

Jika beberapa metrik (jumlah maksimum thread, jumlah thread aktif, jumlah thread inti) semuanya berbeda dari nilai yang diharapkan, periksa apakah aplikasi mengekspos layanan Tomcat di beberapa port. Misalnya, Spring Actuator membuka port tambahan untuk metrik. Dalam kasus ini, ARMS mungkin menggabungkan metrik dari beberapa kolam thread karena konvergensi dimensi.

Untuk memperbaikinya, tingkatkan ke versi probe 4.1.10 atau lebih baru. Lalu buka Application Configuration > Custom Configuration > Pooling Monitoring Configuration, dan atur Thread Pool Thread Name Pattern Extraction Strategy menjadi Replace trailing digits with *.

Mengapa tidak ada data untuk kolam thread atau kolam koneksi sebelum waktu tertentu?

Hal ini terjadi ketika tugas terjadwal membuat kolam tersebut. Data muncul hanya setelah tugas menginisialisasi kolam. Metrik berbasis traffic, seperti jumlah permintaan API, bersifat serupa.

Mengapa tidak ada data untuk kolam koneksi HttpClient?

Mulai dari versi probe ARMS 4.x, pemantauan kolam koneksi untuk OkHttp3 dan Apache HttpClient tidak lagi didukung. Framework ini membuat kolam koneksi terpisah untuk setiap domain eksternal. Ketika banyak domain terlibat, hal ini menyebabkan overhead berlebihan dan risiko stabilitas.

Mengapa tidak ada data pemantauan kontainer setelah mengintegrasikan aplikasi ACK?

ARMS hanya menampilkan data pemantauan kontainer untuk resource yang berada di bawah Akun Alibaba Cloud yang sama. Verifikasi bahwa akun yang digunakan untuk membuat kluster ACK sesuai dengan akun yang digunakan untuk integrasi ARMS.

Mengapa laju buka file handle tidak nol, tetapi jumlah file handle nol?

Hal ini terjadi pada JDK 9 atau lebih baru saat menggunakan versi probe ARMS 3.x. Tingkatkan ke versi probe 4.2.2 atau lebih baru. Lihat Tingkatkan agen ARMS.

Mengapa penggunaan memori fisik proses JVM berbeda signifikan dari penggunaan memori heap pemantauan JVM?

Proses JVM kemungkinan besar menggunakan banyak memori off-heap, yang tidak sepenuhnya dipantau oleh ARMS. Untuk detail area memori JVM yang dicakup ARMS, lihat Detail memori pemantauan JVM.

Mengapa Druid menunjukkan lebih banyak koneksi idle daripada pengaturan koneksi idle maksimum?

Parameter MaxIdle di Druid hanya ada untuk kompatibilitas migrasi DBCP. Parameter ini tidak memiliki efek fungsional.

Mengapa tidak ada data setelah meningkatkan beberapa instans ke versi probe terbaru?

Saat meningkatkan dari versi probe sebelum 4.1.x, semua instans harus ditingkatkan. Halaman akan menyesuaikan diri secara otomatis setelah semua instans menjalankan versi yang sama.