Analisis laporan diagnostik untuk mengidentifikasi anomali kinerja dan query lambat - Tair (Redis® OSS-Compatible) - Alibaba Cloud - Tair (Redis® OSS-Compatible)

Laporan diagnostik mengevaluasi kesehatan instans ApsaraDB for Redis dengan menganalisis metrik performa, distribusi permintaan, dan data kueri lambat. Gunakan laporan ini untuk mengidentifikasi anomali dan mengambil tindakan sebelum memengaruhi bisnis Anda.

Prasyarat

Sebelum memulai, pastikan Anda telah:

Menjalankan diagnostik pada instans tersebut. Untuk petunjuknya, lihat Perform diagnostics on an instance.

Bagian laporan

Laporan diagnostik terdiri dari empat bagian:

Informasi dasar instans: ID instans, tipe instans, versi engine, dan zona tempat instans ditempatkan.
Rangkuman: skor kesehatan instans dan rincian pengurangan nilai.
Tingkat performa: kondisi saat ini dari metrik performa utama.
TOP 10 node yang menerima jumlah kueri lambat terbanyak: 10 node data teratas berdasarkan jumlah kueri lambat, disertai detail mengenai kueri tersebut.

Informasi dasar instans

Bagian ini menampilkan ID instans, tipe instans, versi engine, dan wilayah tempat instans ditempatkan.

Rangkuman

Bagian ini menunjukkan skor kesehatan keseluruhan instans. Skor maksimum adalah 100. Skor di bawah 100 mencantumkan item diagnostik yang menyebabkan pengurangan nilai dan menjelaskan alasannya.

Tingkat performa

Bagian ini menunjukkan kondisi saat ini dari metrik performa utama. Perhatikan secara seksama metrik apa pun yang berada dalam status Hazard—pembacaan yang terus-menerus melebihi ambang batas dapat menurunkan throughput dan meningkatkan latensi.

Untuk instans yang berjalan dalam arsitektur kluster atau arsitektur Pemisahan baca/tulis, periksa apakah metrik tersebar tidak merata di seluruh node data. Tinjau grafik kurva Top 5 Nodes untuk setiap metrik guna mengidentifikasi node mana yang mengalami beban tertinggi. Untuk detail arsitektur, lihat Cluster master-replica instances dan Read/write splitting instances.

Tabel berikut menjelaskan setiap metrik performa, ambang batasnya, dampak bisnis jika ambang batas dilampaui, serta cara troubleshooting-nya.

Metric	Threshold	Applies to	Impact	Possible causes and next steps
CPU utilization	60%	All architectures	Penggunaan CPU tinggi mengurangi throughput dan meningkatkan waktu respons. Klien mungkin menjadi tidak responsif.	Penyebab: perintah kompleksitas tinggi, hotkeys, atau pembuatan koneksi yang terlalu sering. Lihat Troubleshoot high CPU utilization on an instance.
Memory usage	80%	All architectures	Penggunaan memori tinggi yang berkelanjutan meningkatkan waktu respons, mengganggu stabilitas queries per second (QPS), dan memicu eviksi kunci secara sering.	Penyebab: kehabisan memori atau jumlah besar kunci berukuran besar. Lihat Troubleshoot high memory usage on an instance.
Connections usage of data nodes	80%	Cluster instances in direct connection mode only. When clients connect through proxy nodes, monitor connections at the proxy node level instead. See Enable the direct connection mode and View performance monitoring data.	Saat koneksi mencapai batas, permintaan koneksi baru akan timeout atau gagal.	Penyebab: lonjakan traffic atau koneksi idle yang tidak dilepas. Lihat Instance sessions.
Inbound traffic	80%	All architectures	Saat traffic melebihi bandwidth yang disediakan oleh tipe instans, performa klien menurun.	Penyebab: lonjakan workload atau kunci besar yang sering dibaca/ditulis. Lihat Troubleshoot high traffic usage on an instance.
Outbound traffic	80%	All architectures	Dampaknya sama seperti inbound traffic.	Penyebab dan langkah troubleshooting-nya sama seperti inbound traffic.

Distribusi permintaan tidak merata

Untuk instans yang berjalan dalam cluster architecture atau read/write splitting architecture, laporan juga memeriksa apakah permintaan tersebar merata di seluruh node data. Jika terdeteksi distribusi permintaan tidak merata untuk suatu metrik, identifikasi node mana yang menerima beban tidak seimbang tersebut.

Laporan menandai distribusi permintaan tidak merata ketika kedua kondisi berikut terpenuhi:

Nilai puncak di seluruh node data melebihi ambang batas minimum berikut:
- CPU utilization: 10%
- Memory usage: 20%
- Inbound and outbound traffic: 5 Mbit/s
- Connection usage: 5%
Skor keseimbangan melebihi 1,3. Skor keseimbangan dihitung sebagai: max{nilai performa rata-rata semua node data} / nilai median performa semua node data. Misalnya, sebuah instans memiliki empat node data dengan rata-rata CPU utilization sebesar 10%, 30%, 50%, dan 60%. Nilai mediannya adalah 40%, sehingga skor keseimbangannya adalah 60% / 40% = 1,5. Karena 1,5 > 1,3, laporan menganggap distribusi CPU utilization tidak merata.

Possible cause	Troubleshooting method
Node data memiliki kunci yang ukurannya terlalu besar.	Gunakan offline key analysis feature atau top key statistics feature untuk mengidentifikasi dan mendistribusikannya ulang.
Sebuah node data memiliki hotkeys.	Gunakan top key statistics feature untuk mengidentifikasi hotkeys.
Hash tags dikonfigurasi secara tidak tepat. Kunci dengan hash tag yang sama selalu ditempatkan pada node data yang sama. Jika banyak kunci menggunakan hash tag yang sama, node tersebut menjadi kelebihan beban.	Tinjau dan sesuaikan konfigurasi hash tag Anda agar kunci tersebar merata di seluruh node.

TOP 10 node yang menerima jumlah kueri lambat terbanyak

Bagian ini mencantumkan 10 node data teratas berdasarkan jumlah kueri lambat dan memberikan detail mengenai kueri tersebut. Laporan ini mengambil data log lambat dari dua sumber:

System audit logs: log lambat yang disimpan selama 4 hari.
Data node logs: 1.024 entri log terbaru, disimpan langsung di setiap node data. Hubungkan ke instans menggunakan redis-cli dan jalankan perintah SLOWLOG GET untuk mengambilnya.

Gunakan data kueri lambat ini untuk mengidentifikasi perintah yang menyebabkan masalah performa.

Cause	Solution
Perintah dengan kompleksitas waktu O(N) atau biaya CPU tinggi, seperti `KEYS *`	Evaluasi dan nonaktifkan perintah berisiko tinggi seperti `FLUSHALL`, `KEYS`, dan `HGETALL`. Lihat Disable high-risk commands.
Large keys yang sering dibaca/ditulis ke node data.	Analisis large keys tersebut menggunakan offline key analysis feature, lalu pecah berdasarkan kebutuhan bisnis Anda.