Setelah menginstal agen Application Real-Time Monitoring Service (ARMS) untuk aplikasi Java, ARMS mulai memantau aplikasi tersebut. Anda dapat melihat informasi tentang instansi aplikasi seperti metrik dasar, pengumpulan sampah (GC), dan memori mesin virtual Java (VM) pada tab Pemantauan Instansi halaman detail aplikasi.
Prasyarat
Agen ARMS telah diinstal untuk aplikasi tersebut.
Pemantauan Aplikasi menyediakan halaman detail aplikasi baru bagi pengguna yang telah mengaktifkan mode penagihan baru.
Jika belum mengaktifkan mode penagihan baru, klik Beralih ke Versi Baru di halaman Daftar Aplikasi untuk melihat halaman detail aplikasi baru.
Prosedur
Masuk ke Konsol ARMS. Di panel navigasi kiri, pilih .
Pilih wilayah di bilah navigasi atas dan klik aplikasi tersebut.
CatatanIkon di kolom Language menunjukkan bahasa pemrograman aplikasi:
: Java
: Go
: Python- (Tanda hubung): aplikasi yang dipantau dalam Managed Service for OpenTelemetry
Di bilah navigasi atas, klik tab Pemantauan Instansi.
Pemantauan Instansi
Tab Instance Monitoring menyediakan data dashboard berdasarkan apakah aplikasi diterapkan di Instance ECS atau kluster kontainer, serta apakah lingkungan dipantau dalam Managed Service for Prometheus.
Jika aplikasi diterapkan di kluster kontainer yang dipantau dalam Managed Service for Prometheus, data dari Managed Service for Prometheus ditampilkan di dashboard. Untuk informasi tentang cara menggunakan Managed Service for Prometheus untuk memantau kluster kontainer, lihat Pemantauan Kluster ACK.
Jika kluster kontainer tidak dipantau dalam Managed Service for Prometheus, pastikan bahwa versi agen ARMS adalah 4.1.0 atau lebih baru. Kemudian, data Pemantauan Aplikasi akan ditampilkan. Untuk informasi tentang agen ARMS untuk Java, lihat Catatan Rilis Agen ARMS untuk Java.
Instance ECS
Di bagian Quick Filter (ikon 1), Anda dapat mencari grafik dan instansi berdasarkan alamat IP host.
Di bagian grafik tren (ikon 2), Anda dapat melihat deret waktu dari metrik dasar, GC, dan memori JVM.
Pemantauan Dasar Instansi: menampilkan grafik tren dari utilisasi CPU, penggunaan memori, dan penggunaan disk dalam periode waktu tertentu. Beralih antara nilai rata-rata dan maksimum dari daftar drop-down.
Instansi GC: menampilkan grafik tren dari full GC dan young GC dalam periode waktu tertentu. Beralih antara jumlah GC dan durasi rata-rata.
Memori JVM: menampilkan grafik tren dari heap memori yang digunakan dan maksimum dalam periode waktu tertentu dari daftar drop-down. Beralih antara memori heap dan non-heap.
CatatanData yang dikumpulkan oleh Pemantauan Aplikasi berasal dari JMX, tidak termasuk beberapa area memori non-heap dari proses Java. Oleh karena itu, jumlah total heap dan non-heap yang ditampilkan dalam Pemantauan Aplikasi sangat berbeda dengan RES yang diperoleh dengan menjalankan perintah
top. Untuk informasi lebih lanjut, lihat Detail Memori JVM.
Klik ikon
. Dalam kotak dialog yang muncul, Anda dapat melihat data metrik dalam periode waktu tertentu atau membandingkan data metrik dalam periode waktu yang sama pada tanggal yang berbeda. Anda dapat mengklik ikon 
untuk menampilkan data dalam grafik kolom atau grafik tren.Di bagian daftar instansi (ikon 3), Anda dapat melihat informasi instansi seperti alamat IP, utilisasi CPU, penggunaan memori, penggunaan disk, beban, jumlah full GC, jumlah young GC, penggunaan memori heap, penggunaan memori non-heap, dan metrik utama dari setiap instansi yang didefinisikan oleh Metode RED, termasuk laju, kesalahan, dan durasi.
Di daftar instansi, Anda dapat melakukan operasi berikut:
Klik alamat IP instansi untuk melihat detail instansi. Untuk informasi lebih lanjut, lihat bagian Detail Instansi.
Klik Jejak di kolom Tindakan untuk melihat detail jejak dari sebuah instansi. Untuk informasi lebih lanjut, lihat Penjelajah Jejak.
Kluster kontainer yang dipantau dalam Managed Service for Prometheus
Di bagian Quick Filter (ikon 1), Anda dapat mencari grafik dan instansi berdasarkan ID kluster atau alamat IP host.
Di bagian grafik tren (ikon 2), Anda dapat melihat deret waktu dari metrik dasar, GC, dan memori JVM.
Pemantauan Dasar Instansi: menampilkan grafik tren dari utilisasi CPU dan penggunaan memori dalam periode waktu tertentu.
Instansi GC: menampilkan grafik tren dari full GC dan young GC dalam periode waktu tertentu. Beralih antara jumlah GC dan durasi rata-rata.
Memori JVM: menampilkan grafik tren dari heap memori yang digunakan dan maksimum dalam periode waktu tertentu dari daftar drop-down. Beralih antara memori heap dan non-heap.
CatatanData yang dikumpulkan oleh Pemantauan Aplikasi berasal dari JMX, tidak termasuk beberapa area memori non-heap dari proses Java. Oleh karena itu, jumlah total heap dan non-heap yang ditampilkan dalam Pemantauan Aplikasi sangat berbeda dengan RES yang diperoleh dengan menjalankan perintah
top. Untuk informasi lebih lanjut, lihat Detail Memori JVM.
Klik ikon
. Dalam kotak dialog yang muncul, Anda dapat melihat data metrik dalam periode waktu tertentu atau membandingkan data metrik dalam periode waktu yang sama pada tanggal yang berbeda. Anda dapat mengklik ikon untuk menampilkan data dalam grafik kolom atau grafik tren.Di bagian daftar instansi (ikon 3), Anda dapat melihat informasi instansi seperti alamat IP, CPU terpakai, CPU diminta, CPU maksimum, utilisasi CPU (%), memori terpakai, memori diminta, memori maksimum, penggunaan memori (%), ukuran disk terpakai, ukuran disk maksimum, penggunaan disk (%), beban, jumlah full GC, jumlah young GC, penggunaan memori heap, penggunaan memori non-heap, dan metrik utama dari setiap instansi yang didefinisikan oleh Metode RED, termasuk laju, kesalahan, dan durasi. Perhatikan bahwa jika CPU maksimum, memori, atau ukuran disk tidak dikonfigurasi, - akan ditampilkan sebagai pengganti utilisasi CPU, penggunaan memori, atau penggunaan disk.
Di daftar instansi, Anda dapat melakukan operasi berikut:
Klik alamat IP instansi atau klik Detail di kolom Tindakan untuk melihat detail instansi. Untuk informasi lebih lanjut, lihat bagian Detail Instansi.
Klik Jejak di kolom Tindakan untuk melihat detail jejak dari sebuah instansi. Untuk informasi lebih lanjut, lihat Penjelajah Jejak.
Kluster kontainer (pengumpulan data kustom)
Di bagian Quick Filter (ikon 1), Anda dapat mencari grafik dan instansi berdasarkan alamat IP host.
Di bagian grafik tren (ikon 2), Anda dapat melihat deret waktu dari metrik dasar, GC, dan memori JVM.
Pemantauan Dasar Instansi: menampilkan grafik tren dari utilisasi CPU dan penggunaan memori dalam periode waktu tertentu.
Instansi GC: menampilkan grafik tren dari full GC dan young GC dalam periode waktu tertentu. Beralih antara jumlah GC dan durasi rata-rata.
Memori JVM: menampilkan grafik tren dari heap memori yang digunakan dan maksimum dalam periode waktu tertentu dari daftar drop-down. Beralih antara memori heap dan non-heap.
CatatanData yang dikumpulkan oleh Pemantauan Aplikasi berasal dari JMX, tidak termasuk beberapa area memori non-heap dari proses Java. Oleh karena itu, jumlah total heap dan non-heap yang ditampilkan dalam Pemantauan Aplikasi sangat berbeda dengan RES yang diperoleh dengan menjalankan perintah
top. Untuk informasi lebih lanjut, lihat Detail Memori JVM.
Klik ikon
. Dalam kotak dialog yang muncul, Anda dapat melihat data metrik dalam periode waktu tertentu atau membandingkan data metrik dalam periode waktu yang sama pada tanggal yang berbeda. Anda dapat mengklik ikon untuk menampilkan data dalam grafik kolom atau grafik tren.Di bagian daftar instansi (ikon 3), Anda dapat melihat informasi instansi seperti alamat IP, utilisasi CPU, penggunaan memori, beban, jumlah full GC, jumlah young GC, penggunaan memori heap, penggunaan memori non-heap, dan metrik utama dari setiap instansi yang didefinisikan oleh Metode RED, termasuk laju, kesalahan, dan durasi.
Di daftar instansi, Anda dapat melakukan operasi berikut:
Klik alamat IP instansi atau klik Detail di kolom Tindakan untuk melihat detail instansi. Untuk informasi lebih lanjut, lihat bagian Detail Instansi.
Klik Jejak di kolom Tindakan untuk melihat detail jejak dari sebuah instansi. Untuk informasi lebih lanjut, lihat Penjelajah Jejak.
Detail Instansi
Ikhtisar
Klik Jejak di kolom Tindakan untuk melihat detail jejak dari sebuah instansi. Untuk informasi lebih lanjut, lihat Penjelajah Jejak.
Pemantauan JVM
Di tab Pemantauan JVM, Anda dapat melihat GC, memori, thread, dan file dari instansi tersebut.
Pemantauan Pool Thread
Agen V4.1.x dan yang lebih baru
Tab Pemantauan Pool Thread memungkinkan Anda melihat berbagai metrik dari pool thread yang digunakan oleh aplikasi, termasuk konfigurasi thread inisialisasi, status thread runtime, dan status eksekusi tugas.
Di bagian atas tab, Anda dapat memfilter pool thread yang ingin Anda kueri berdasarkan jenis dan nama pool thread.
Agen sebelum V4.1.x
Tab Pemantauan Pool Thread memungkinkan Anda melihat metrik seperti jumlah thread inti, jumlah thread saat ini, jumlah thread maksimum, jumlah thread aktif, dan kapasitas antrian tugas dari pool thread yang digunakan oleh aplikasi.
Pemantauan Pool Koneksi
Agen V4.1.x dan yang lebih baru
Tab Pemantauan Pool Koneksi memungkinkan Anda melihat berbagai metrik dari pool koneksi yang digunakan oleh aplikasi, termasuk konfigurasi thread inisialisasi dan status thread runtime.
Di bagian atas tab, Anda dapat memfilter pool koneksi yang ingin Anda kueri berdasarkan jenis pool koneksi.
Agen sebelum V4.1.x
Tab Pemantauan Pool Koneksi memungkinkan Anda melihat jumlah koneksi maksimum dan jumlah koneksi aktif dari pool koneksi yang digunakan oleh aplikasi.
Pemantauan Host
Di tab Pemantauan Host, Anda dapat melihat metrik terkait utilisasi CPU, penggunaan memori, penggunaan disk, beban sistem, lalu lintas jaringan, dan paket.
Pemantauan Kontainer
Kluster kontainer yang dipantau dalam Managed Service for Prometheus
Untuk informasi tentang cara menghubungkan kluster kontainer Anda ke Managed Service for Prometheus, lihat Buat instansi Prometheus untuk memantau kluster ACK.
Di tab Pemantauan Kontainer, Anda dapat melihat metrik terkait utilisasi CPU, penggunaan memori, penggunaan disk, beban, lalu lintas, dan paket.
Lingkungan kontainer (pengumpulan data kustom ARMS)
Jika kluster kontainer tidak dipantau dalam Managed Service for Prometheus, pastikan bahwa versi agen ARMS adalah 4.1.0 atau lebih baru. Untuk informasi tentang agen ARMS untuk Java, lihat Catatan Rilis Agen ARMS untuk Java.
Di tab Pemantauan Kontainer, Anda dapat melihat deret waktu dari CPU, memori, dan lalu lintas jaringan.
Penjelajah Jejak
Penjelajah Jejak memungkinkan Anda menggabungkan kondisi filter dan dimensi agregasi untuk analisis real-time berdasarkan data jejak penuh yang tersimpan. Alat ini dapat memenuhi kebutuhan diagnostik kustom dalam berbagai skenario. Untuk informasi lebih lanjut, lihat Penjelajah Jejak.
Referensi
Untuk informasi lebih lanjut mengenai metrik Pemantauan Aplikasi, lihat Metrik Pemantauan Aplikasi.
FAQ
Apa hubungan antara metrik tingkat aplikasi dan metrik tingkat mesin tunggal?
Metrik RED (rate, errors, dan duration):
Jumlah permintaan, jumlah panggilan lambat, dan frekuensi kode status HTTP: Metrik tingkat aplikasi merupakan jumlah agregat dari metrik tingkat mesin tunggal yang sesuai.
Waktu respons: Metrik tingkat aplikasi mewakili waktu respons rata-rata di semua mesin.
Metrik JVM:
Frekuensi dan durasi GC: Metrik tingkat aplikasi adalah jumlah dari metrik tingkat mesin tunggal.
Penggunaan memori heap dan jumlah thread: Metrik tingkat aplikasi mengambil nilai maksimum yang diamati di antara mesin-mesin tunggal.
Metrik pool thread dan pool koneksi:
Untuk semua metrik dalam kategori ini, data tingkat aplikasi adalah rata-rata dari metrik tingkat mesin tunggal.
Metrik sistem:
Untuk semua metrik sistem, data tingkat aplikasi mengambil nilai maksimum yang diamati di antara mesin-mesin tunggal.
Panggilan SQL dan NoSQL: Mirip dengan metrik RED, metrik Frekuensi adalah jumlah agregat dari metrik tingkat mesin tunggal. Metrik lainnya mewakili nilai rata-rata di semua mesin.
Metrik pengecualian: Semua metrik terkait pengecualian di tingkat aplikasi adalah jumlah agregat dari metrik tingkat mesin tunggal.
Mengapa lalu lintas antar instansi tidak merata?
Agen ARMS V3.x mungkin melewatkan beberapa data metrik jika optimasi memori diaktifkan. Agen V4.x telah memperbaiki masalah ini.
Mengapa permintaan Undertow dihitung dua kali?
Agen ARMS sebelum v3.2.x mengeksekusi metode implementasi dua kali saat menggunakan DeferredResult. Agen v3.2.x dan yang lebih baru telah memperbaiki masalah ini.
Mengapa kuota CPU/memori kontainer tidak sesuai dengan pengaturan aktual pod?
Periksa apakah pod Anda mendefinisikan beberapa kontainer. Kuota CPU/memori menggabungkan total kuota dari semua kontainer dalam pod.
Mengapa beberapa metrik sistem hilang atau tidak akurat? Mengapa utilisasi CPU 100%?
Agen ARMS sebelum V4.x tidak mendukung pengumpulan metrik sistem dalam lingkungan Windows. Agen ARMS V4.x dan yang lebih baru telah memperbaiki masalah ini.
Mengapa Full GC dipicu saat aplikasi dimulai?
Ini mungkin karena Anda belum mengonfigurasi ukuran metaspace. Ukuran metaspace default adalah 20 MB. Saat aplikasi dimulai, metaspace mungkin diperluas untuk memicu Full GC. Anda dapat mengatur ukuran awal dan maksimum metaspace melalui parameter -XX:MetaspaceSize dan -XX:MaxMetaspaceSize.
Bagaimana cara menghitung total ukuran stack VM?
Metrik ini dihitung dengan mengalikan jumlah thread hidup (status: live, blocked, new, runnable, timed-wait, wait) dengan ukuran stack default 1 MB. Ini menjadi tidak akurat jika ukuran stack diubah melalui -Xss.
Bagaimana metrik JVM diambil?
ARMS mengambil metrik JVM menggunakan antarmuka JDK standar berikut:
Metrik memori:
ManagementFactory.getMemoryPoolMXBeans
java.lang.management.MemoryPoolMXBean#getUsage
Metrik GC:
Agen sebelum V4.4.0
ManagementFactory.getGarbageCollectorMXBeans
java.lang.management.GarbageCollectorMXBean#getCollectionCount
java.lang.management.GarbageCollectorMXBean#getCollectionTime
Agen V4.4.0 dan yang lebih baru
Metrik diambil dengan berlangganan ke event GarbageCollectionNotificationInfo dari GarbageCollectorMXBean.
Mengapa memori heap JVM maksimum -1?
-1 menunjukkan bahwa ukuran memori heap maksimum tidak diatur.
Mengapa penggunaan memori heap JVM tidak sama dengan memori heap maksimum?
Dalam konteks mekanisme alokasi memori JVM, parameter -Xms mengatur ukuran awal memori heap. Saat aplikasi berjalan dan memori heap tersisa menjadi tidak mencukupi, JVM akan meningkatkan ukuran heap secara bertahap hingga mencapai ukuran heap maksimum yang ditentukan oleh parameter -Xmx. Jika total memori yang dialokasikan kurang dari nilai maksimum, ini menunjukkan bahwa heap belum berkembang sepenuhnya. Memori yang digunakan mewakili jumlah aktual memori heap yang saat ini digunakan oleh aplikasi.
Mengapa frekuensi GC JVM meningkat?
Peningkatan frekuensi GC JVM mungkin disebabkan oleh penggunaan algoritma GC default di JDK 8, Parallel GC. Algoritma ini mengaktifkan -XX:+UseAdaptiveSizePolicy secara default, yang secara otomatis menyesuaikan parameter ukuran heap, termasuk ukuran generasi muda dan SurvivorRatio, untuk memenuhi target waktu jeda GC. Saat Young GC terjadi sering, itu dapat secara dinamis mengurangi ukuran ruang Survivor. Akibatnya, objek di ruang Survivor dapat dengan mudah dipromosikan ke generasi tua, menyebabkan pertumbuhan cepat di ruang generasi tua dan, akhirnya, peningkatan frekuensi Full GC. Untuk informasi lebih lanjut, lihat Dokumentasi Java.
Mengapa pemantauan pool thread atau pool koneksi kehilangan data?
Di bagian Pengaturan Lanjutan tab Konfigurasi Kustom, periksa apakah pemantauan pool thread atau pool koneksi diaktifkan.
Periksa apakah kerangka kerja aplikasi didukung. Untuk informasi lebih lanjut, lihat Pemantauan pool thread dan pool koneksi.
Mengapa jumlah maksimum koneksi yang diperoleh dari pool koneksi HikariCP tidak benar?
Ini disebabkan oleh masalah pengkodean agen ARMS sebelum v3.2.x. Agen v3.2.x dan yang lebih baru telah memperbaiki masalah ini.
Mengapa nilai dalam metrik pemantauan pool ditampilkan sebagai desimal?
Karena agen ARMS mengumpulkan data setiap 15 detik, ia mengumpulkan empat titik data per menit. Konsol ARMS menampilkan nilai rata-rata selama periode waktu tertentu berdasarkan data yang dikumpulkan. Misalkan empat titik data yang dikumpulkan dalam satu menit adalah 0, 0, 1, dan 0. Rata-rata teoritisnya adalah 0,25.
Mengapa metrik pool thread atau pool koneksi tidak meningkat ketika pool thread atau pool koneksi sepenuhnya digunakan seperti yang ditunjukkan dalam log atau catatan lainnya?
Ini mungkin karena ketidaksesuaian antara waktu sampling metrik dan waktu ketika pool sepenuhnya digunakan. Karena ARMS secara otomatis mengumpulkan status metrik pool thread dan pool koneksi setiap 15 detik, lonjakan sesaat yang terjadi dalam interval ini mungkin tidak tertangkap.
Mengapa jumlah maksimum thread dari pool thread tidak sesuai harapan? Mengapa jumlah maksimum thread 2,1 miliar?
Ukuran maksimum pool thread diperoleh dengan langsung memanggil metode untuk mendapatkan jumlah maksimum thread dari objek pool thread, yang umumnya benar. Jika tidak sesuai dengan harapan Anda, mungkin karena jumlah maksimum thread yang ditentukan pengguna belum berlaku.
Jika jumlah maksimum thread adalah 2,1 miliar, ini biasanya menunjukkan pool thread terjadwal. Di pool thread terjadwal, jumlah maksimum thread default diatur ke Integer.MAX_VALUE, seperti yang ditunjukkan pada gambar berikut.
Apa yang harus saya lakukan jika metrik pool thread Tomcat tidak sesuai harapan?
Metrik pool thread ARMS diperoleh langsung dengan memanggil metode yang sesuai dari objek pool thread, yang umumnya tidak menghasilkan kesalahan. Jika beberapa dimensi tidak sesuai (seperti jumlah maksimum thread, jumlah thread aktif, atau jumlah thread inti), pertama-tama konfirmasikan apakah aplikasi Anda menyediakan layanan Tomcat melalui beberapa port (misalnya, komponen seperti spring-actuator juga membuka port untuk mengekspos metrik). Dalam kasus seperti itu, karena mekanisme konvergensi dimensi, agen ARMS mungkin menggabungkan data dari beberapa pool thread selama statistik. Jika data digabungkan, Anda dapat meningkatkan versi agen ke 4.1.10 atau lebih baru dan mengubah parameter Kebijakan Ekstraksi Pola Nama Thread Pool menjadi Ganti karakter numerik akhir * di bagian Pooled Monitoring Configuration tab Custom Configurations.
Mengapa pool thread atau pool koneksi tertentu tidak memiliki data sebelum titik waktu tertentu?
Bisnis memulai tugas terjadwal, yang menghasilkan data untuk pool thread atau pool koneksi saat inisialisasi. Hingga tugas tersebut dipicu, tidak ada data untuk pool thread atau pool koneksi yang sesuai. Ini sering terjadi dengan data tipe lalu lintas, seperti jumlah permintaan untuk antarmuka tertentu.
Mengapa pool koneksi HTTPClient tidak memiliki data?
Agen ARMS V4.x dan yang lebih baru tidak lagi mendukung pemantauan pool koneksi untuk kerangka kerja seperti okHttp3 dan Apache HTTPClient. Keputusan ini diambil dengan mempertimbangkan bahwa kerangka kerja ini membuat objek pool koneksi untuk setiap nama domain eksternal yang diakses oleh aplikasi saat ini. Saat mengakses banyak nama domain eksternal, ini dapat menyebabkan overhead yang signifikan dan menimbulkan risiko stabilitas. Oleh karena itu, dukungan untuk pemantauan pool koneksi ini telah dihentikan.
Mengapa data pemantauan kontainer tidak dapat dilihat setelah mengintegrasikan aplikasi dalam lingkungan ACK?
Ini mungkin karena akun Alibaba Cloud yang digunakan untuk membuat kluster ACK dan akun Alibaba Cloud yang digunakan untuk mengintegrasikan ARMS berbeda. Saat ini, ARMS hanya mendukung menampilkan data pemantauan kontainer dalam akun Alibaba Cloud yang sama.
Apa yang harus saya lakukan jika tingkat pembukaan handle tidak 0, tetapi jumlah handle file adalah 0?
Konfirmasikan apakah lingkungan aplikasi Anda adalah JDK 9+ dan versi agen ARMS adalah 3.x. Jika ya, masalah ini muncul karena masalah kompatibilitas dengan logika pengumpulan metrik dalam lingkungan ini. Masalah ini telah diperbaiki di agen V4.2.2 dan yang lebih baru. Kami sarankan Anda memperbarui agen.
Mengapa penggunaan memori fisik aktual proses JVM dan penggunaan memori heap yang ditampilkan dalam pemantauan JVM sangat berbeda?
Ini mungkin karena proses JVM memiliki penggunaan memori off-heap yang besar. Saat ini, ARMS hanya dapat memantau memori in-heap dari proses JVM dan sebagian dari penggunaan memori off-heap. Untuk informasi tentang bagian mana dari penggunaan memori JVM yang dapat dipantau oleh ARMS dan mana yang tidak, lihat Detail memori JVM. Jika penggunaan memori off-heap tinggi, Anda dapat merujuk ke bagian "Memori non-heap" untuk melakukan analisis sendiri.
Mengapa jumlah koneksi idle real-time dari pool koneksi Druid melebihi jumlah maksimum koneksi idle yang ditetapkan?
Parameter MaxIdle diperkenalkan oleh Druid untuk memfasilitasi migrasi pengguna DBCP, tetapi parameter ini sebenarnya tidak berlaku.
Mengapa ada data yang hilang setelah memperbarui beberapa agen instansi ke versi terbaru?
Jika agen-agen ini diperbarui dari versi sebelum 4.1.x, Anda perlu memperbarui semua agen instansi ke versi terbaru untuk memastikan halaman secara otomatis menyesuaikan dan menampilkan data.
state=live mencakup status berikut: live, blocked, new, runnable, timed-wait, dan wait.