Lindorm:Pemantauan dan Peringatan

CPU dan beban

Modul ini memantau pemanfaatan CPU dan beban sistem, termasuk metrik seperti pemanfaatan CPU, pemanfaatan CPU WIO, tingkat idle CPU, dan beban rata-rata. Pemanfaatan CPU mencakup CPU utilization User dan CPU utilization System(%).

Saat mengonfigurasi aturan peringatan, disarankan menetapkan ambang batas untuk CPU idle rate(%) berdasarkan karakteristik bisnis dan sensitivitas terhadap latensi. Umumnya, peningkatan pemanfaatan CPU menyebabkan waktu respons (RT) lebih lama, tetapi dampaknya bervariasi tergantung jenis bisnis. Misalnya, ketika pemanfaatan CPU melebihi 40%, bisnis online mungkin mengalami latensi, sedangkan bisnis offline mungkin tetap stabil hingga pemanfaatan CPU mencapai 100%. Oleh karena itu, tetapkan ambang batas sesuai situasi bisnis Anda. Jika pemanfaatan CPU terlalu tinggi, pertimbangkan untuk meningkatkan kapasitas atau meng-upgrade instance. Untuk informasi lebih lanjut, lihat Kelola penyimpanan instance dan Ubah konfigurasi sebuah instance.

CPU WIO usage(%) menunjukkan proporsi waktu yang dihabiskan CPU menunggu operasi I/O. Nilai tinggi menunjukkan adanya hambatan dalam operasi baca/tulis disk. Analisis CPU WIO usage(%) bersama dengan Average load per minute(load1) (metrik beban) untuk menilai kesehatan mesin. Metrik beban mencerminkan pemanfaatan CPU dan penggunaan disk.

Beban yang dapat diterima bergantung pada konfigurasi CPU. Misalnya, jika mesin memiliki 8 core CPU, nilai beban lebih besar dari 8 menunjukkan bahwa pemrosesan CPU mulai antre dan mesin berada dalam kondisi suboptimal. Jika pemanfaatan CPU rendah tetapi nilai beban tinggi, itu menunjukkan penggunaan disk yang berlebihan. Saat beban CPU atau pemanfaatan WIO terlalu tinggi, disarankan meningkatkan kapasitas atau meng-upgrade instance untuk menghindari dampak pada bisnis.

Jaringan dan disk

Modul ini memantau kinerja jaringan dan disk mesin. Pantau metrik utama seperti lalu lintas jaringan, operasi baca/tulis disk, dan IOPS, serta pastikan nilai-nilai tersebut tetap di bawah ambang batas throttling dari instance Elastic Compute Service (ECS) dan cloud disk.

Jenis ECS instance berbeda memiliki lebar pita jaringan yang berbeda. Untuk ambang batas throttling jaringan, lihat Ikhtisar keluarga instance. Untuk ambang batas throttling disk, lihat Kinerja penyimpanan blok. Jika ada pertanyaan tentang batasan jaringan dan disk, hubungi dukungan teknis Lindorm (ID DingTalk: s0s3eg3).

Disk ECS non-lokal memiliki batas bandwidth total. Jika gabungan lalu lintas baca dan tulis melebihi batas bandwidth disk ECS, throttling mungkin terjadi dan memengaruhi operasi bisnis. Selama penggunaan, pantau penggunaan disk dan jaringan secara dekat untuk mencegah melebihi batas jaringan dan disk mesin dasar.

Beban kluster

Modul ini mencakup metrik-metrik berikut:

• LindormTable compute node memory usage ratio(%): Rasio memori heap yang digunakan oleh LindormTable. Jika rasio penggunaan heap tetap tinggi untuk waktu lama, LindormTable mungkin mengalami kehabisan memori (OOM) atau garbage collection (GC) penuh, yang memengaruhi operasi bisnis. Ukuran memori heap berfluktuasi. Jika penggunaan memori heap berlebihan sementara, sistem akan mengurangi ukuran heap melalui GC. Jika ukuran memori heap terus melebihi ambang tertentu, pertimbangkan untuk meng-upgrade spesifikasi node LindormTable. Saat membuat aturan peringatan, disarankan menentukan kondisi peringatan ketika rasio ini lebih besar dari 85%-90% selama 30-60 menit. Untuk informasi lebih lanjut, lihat Ubah spesifikasi engine sebuah instance.

• Number of regions of RS (unit): Jumlah shard data (Regions) pada setiap node LindormTable. LindormTable membagi tabel menjadi shard berdasarkan rentang dan mendistribusikannya di seluruh mesin, dengan alokasi terpusat yang dikelola oleh node master. Setiap shard menempati ruang memori metadata, sehingga jumlah shard berlebihan dapat menyebabkan memori mesin tidak mencukupi. Kontrol jumlah shard dengan mengurangi jumlah tabel atau pre-partisi saat membuat tabel.

  Tabel berikut menjelaskan jumlah shard yang direkomendasikan per mesin untuk konfigurasi berbeda.

  Konfigurasi mesin (ukuran memori)	Jumlah shard yang direkomendasikan per mesin
  8 GB	Kurang dari 500
  16 GB	Kurang dari 1000
  32 GB	Kurang dari 2000
  64 GB	Kurang dari 3000
  128 GB	Kurang dari 5000

  Nilai-nilai di atas hanya referensi. Dalam penggunaan aktual, tentukan apakah instance memiliki memori tidak mencukupi menggunakan rumus: Memori terpakai node komputasi LindormTable/Total memori node komputasi LindormTable.

• HandlerQueue Length (unit): Situasi antrian permintaan di server. Jika panjang HandlerQueue lebih besar dari 0, permintaan perlu mengantri di server, menunjukkan bahwa sumber daya server tidak cukup untuk menangani permintaan saat ini secara tepat waktu. Disarankan meng-upgrade konfigurasi instance untuk meningkatkan sumber daya CPU.

• Compaction Queue Length (units): Situasi antrian tugas compaction di server. Saat operasi tulis meningkat, lebih banyak operasi compaction perlu dieksekusi, yang dapat menyebabkan skenario antrian.

  Catatan

  • Nilai Compaction Queue Length lebih besar dari 0 tidak selalu menunjukkan bahwa instance berada dalam keadaan tidak sehat. Jika bisnis memiliki pola tulis periodik, misalnya puncak siang hari dan lembah malam hari, tugas compaction mungkin menumpuk selama puncak tulis siang hari, menyebabkan nilai Compaction Queue Length melebihi 0. Namun, sistem secara otomatis memproses tugas-tugas yang menumpuk ini di malam hari, sehingga nilai Compaction Queue Length akan berkurang menjadi 0. Dalam hal ini, instance sehat. Selain itu, jika panjang antrian compaction tetap stabil pada nilai tertentu untuk waktu lama, itu menunjukkan bahwa instance berada dalam keadaan stabil dan tidak memerlukan perhatian.

  • Jika nilai Compaction Queue Length terus meningkat tanpa tren penurunan, itu menunjukkan bahwa sumber daya instance tidak mencukupi. Tambahkan node atau upgrade konfigurasi untuk meningkatkan sumber daya CPU agar sistem dapat memproses tugas compaction secara tepat waktu. Meskipun akumulasi jangka pendek tugas compaction tidak akan memengaruhi bisnis, akumulasi jangka panjang dapat menyebabkan jumlah file berlebihan di dalam shard, yang dapat meningkatkan RT baca. Jika jumlah file terus bertambah, tekanan balik tulis akan terjadi, mengakibatkan peningkatan RT tulis atau bahkan timeout.

• Average number of files in Region: Jumlah rata-rata file dalam sebuah shard. Nilai yang lebih tinggi menunjukkan peningkatan RT baca. Metadata file menempati ruang memori dan jumlah file berlebihan dapat memicu Full GC atau OOM.

• Maximum number of files in Region: Jumlah maksimum file dalam sebuah shard tunggal. Jika batas ini dilampaui, tekanan balik tulis akan terjadi, mengakibatkan timeout tulis. Untuk informasi lebih lanjut, lihat Batas pada permintaan data.

Permintaan baca

Modul ini mencakup metrik-metrik berikut:

• Metrik operasi Get: Get requests (pieces/second), Get Average RT (ms), dan Get P99 RT (ms). Panggilan query titik dieksekusi pada server Lindorm menggunakan informasi kunci utama lengkap untuk mendapatkan metrik pemantauan relevan termasuk QPS, RT rata-rata, dan P99 RT. Jika menggunakan operasi BatchGet, terlepas dari berapa banyak baris yang termasuk dalam operasi BatchGet, itu dianggap sebagai satu panggilan query titik karena operasi BatchGet dieksekusi secara serial pada server tunggal. Jika hanya menggunakan operasi BatchGet atau menggunakan kedua operasi BatchGet dan Get baris tunggal, RT rata-rata akan lebih tinggi daripada RT operasi Get baris tunggal.

• Metrik operasi Scan: Scan requests (pieces/second), Scan Average RT (ms), dan Scan P99 RT (ms). Metrik ini digunakan untuk memantau permintaan scan rentang. Server Lindorm membagi permintaan scan rentang besar dan mengembalikan data secara streaming. Scan requests (pieces/second) menunjukkan jumlah permintaan sub-scan yang dikirim ke server per detik setelah permintaan scan rentang besar dibagi dan Scan Average RT (ms) menunjukkan waktu rata-rata yang digunakan oleh setiap operasi scan. Oleh karena itu, nilai Scan requests (pieces/second) mungkin lebih dari jumlah sebenarnya dari permintaan sub-scan yang dimulai. Waktu yang digunakan oleh permintaan scan lengkap adalah jumlah waktu yang digunakan oleh beberapa permintaan sub-scan.

• Metrik operasi baca: Read Requests (s/sec), Read Average RT (ms), dan Read traffic. Metrik ini digunakan untuk memantau permintaan Get dan permintaan scan serta mengumpulkan informasi seperti jumlah baris yang dikembalikan oleh instance per detik dan RT rata-rata yang digunakan untuk mengembalikan setiap baris data. Beberapa baris mungkin dikembalikan dalam satu permintaan Get atau scan, sehingga metrik ini dapat lebih akurat mencerminkan throughput baca instance.

Permintaan tulis

• Write traffic: Metrik ini digunakan untuk memantau throughput (satuan: KB/s) operasi tulis ke LindormTable. Saat LindormTable menulis data ke penyimpanan dasar, kolom tabel lebar diubah menjadi pasangan key-value, sehingga kolom yang disimpan memiliki volume data lebih besar daripada kolom yang sebenarnya ditulis. Disarankan menggunakan metrik ini untuk menentukan throughput tulis LindormTable.

  Throughput tulis yang tinggi dapat menyebabkan tugas compaction menumpuk, yang dapat memengaruhi stabilitas instance. Disarankan mengonfigurasi CPU secara tepat berdasarkan kebutuhan bisnis Anda.

  Tabel berikut menjelaskan throughput tulis yang direkomendasikan untuk konfigurasi berbeda.

  Konfigurasi CPU	Throughput tulis yang direkomendasikan
  4 core	Kurang dari 5 MB/s
  8 core	Kurang dari 10 MB/s
  16 core	Kurang dari 30 MB/s
  32 core	Kurang dari 60 MB/s

  Nilai-nilai di atas hanya referensi. Dalam penggunaan aktual, pertimbangkan kombinasinya dengan metrik seperti Compaction Queue Length, Average number of files in Region, dan Maximum number of files in Region.

• Number of times exceeding the upper limit of Memstore (times): LindormTable pertama kali menulis data ke Memstore shard yang sesuai. Saat penggunaan Memstore terlalu tinggi, sistem memicu operasi Flush untuk menulis data ke disk. Jika permintaan tulis terkonsentrasi pada beberapa shard, penggunaan Memstore dari shard-shard tersebut menjadi terlalu tinggi, menghasilkan tekanan balik tulis yang memengaruhi throughput. Oleh karena itu, ketika nilai metrik ini lebih besar dari 0, pertimbangkan apakah hotspot tulis ada atau apakah transaksi per detik (TPS) telah melebihi batas yang dapat ditangani oleh instance, yang dapat menyebabkan data tidak ditulis ke disk secara tepat waktu. Dalam hal ini, gunakan algoritma Hash untuk mendistribusikan kunci utama secara lebih merata untuk menghindari hotspot. Untuk informasi lebih lanjut, lihat Desain kunci utama untuk tabel lebar Lindorm.