Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Metrik Apa yang Harus Saya Pantau?
CloudWatch Metrik berikut menawarkan wawasan yang baik tentang kinerja MemoryDB. Dalam kebanyakan kasus, kami menyarankan Anda menyetel CloudWatch alarm untuk metrik ini sehingga Anda dapat mengambil tindakan korektif sebelum masalah kinerja terjadi.
**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [Mesin CPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Memori](#metrics-memory)
+ [Jaringan](#metrics-network)
+ [Latensi](#metrics-latency)
+ [Replikasi](#metrics-replication)
## CPUUtilization
Ini adalah metrik tingkat host yang dilaporkan sebagai persentase. Untuk informasi selengkapnya, lihat [Metrik Tingkat Host](metrics.HostLevel.md).
Untuk tipe node yang lebih kecil dengan 2v CPUs atau kurang, gunakan `CPUUtilization ` metrik untuk memantau beban kerja Anda.
Secara umum, sebaiknya atur ambang batas Anda sebesar 90% dari CPU yang tersedia. Karena Valkey dan Redis OSS adalah single-threaded, nilai ambang sebenarnya harus dihitung sebagai sebagian kecil dari total kapasitas node. Sebagai contoh, misalkan Anda menggunakan jenis simpul yang memiliki dua inti. Dalam hal ini, ambang batas untuk CPUUtilization adalah 90/2, atau 45%. Untuk menemukan jumlah core (vCPUs) yang dimiliki tipe node Anda, lihat [MemoryDB](https://aws.amazon.com/memorydb/pricing/?p=ps) Pricing.
Anda perlu menentukan ambang batas Anda sendiri, berdasarkan jumlah core di node yang Anda gunakan. Jika Anda melebihi ambang batas ini, dan beban kerja utama Anda berasal dari permintaan baca, skala klaster Anda dengan menambahkan replika baca. Jika beban kerja utama berasal dari permintaan tulis, kami sarankan Anda menambahkan lebih banyak pecahan untuk mendistribusikan beban kerja tulis di lebih banyak node utama.
**Tip**
Alih-alih menggunakan metrik Host-Level`CPUUtilization`, Anda mungkin dapat menggunakan metrik`EngineCPUUtilization`, yang melaporkan persentase penggunaan pada inti mesin Valkey atau Redis OSS. Untuk melihat apakah metrik ini tersedia di node Anda dan untuk informasi selengkapnya, lihat [Metrik untuk MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
Untuk tipe node yang lebih besar dengan 4v CPUs atau lebih, Anda mungkin ingin menggunakan `EngineCPUUtilization` metrik, yang melaporkan persentase penggunaan pada inti mesin Valkey atau Redis OSS. Untuk melihat apakah metrik ini tersedia di node Anda dan untuk informasi selengkapnya, lihat [Metrik untuk MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## Mesin CPUUtilization
Untuk tipe node yang lebih besar dengan 4v CPUs atau lebih, Anda mungkin ingin menggunakan `EngineCPUUtilization` metrik, yang melaporkan persentase penggunaan pada inti mesin Valkey atau Redis OSS. Untuk melihat apakah metrik ini tersedia di node Anda dan untuk informasi selengkapnya, lihat [Metrik untuk MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## SwapUsage
Ini adalah metrik tingkat host yang dilaporkan dalam byte. Untuk informasi selengkapnya, lihat [Metrik Tingkat Host](metrics.HostLevel.md).
Jika salah satu `FreeableMemory` CloudWatch metrik mendekati 0 (yaitu, di bawah 100MB), atau `SwapUsage` metrik lebih besar dari `FreeableMemory` metrik, maka node bisa berada di bawah tekanan memori.
## Evictions
Ini adalah metrik mesin. Sebaiknya tentukan ambang batas alarm Anda sendiri untuk metrik ini berdasarkan kebutuhan aplikasi Anda.
## CurrConnections
Ini adalah metrik mesin. Sebaiknya tentukan ambang batas alarm Anda sendiri untuk metrik ini berdasarkan kebutuhan aplikasi Anda.
Peningkatan jumlah *CurrConnections*mungkin menunjukkan masalah dengan aplikasi Anda; Anda perlu menyelidiki perilaku aplikasi untuk mengatasi masalah ini.
## Memori
Memori adalah aspek inti dari Valkey dan Redis OSS. Memahami pemanfaatan memori dari klaster Anda diperlukan untuk menghindari kehilangan data dan mengakomodasi pertumbuhan set data Anda pada masa mendatang. Statistik tentang pemanfaatan memori node tersedia di bagian memori dari perintah [INFO](https://valkey.io/commands/info).
## Jaringan
Salah satu faktor penentu untuk kapasitas bandwidth jaringan dari klaster Anda adalah jenis simpul yang telah Anda pilih. Untuk informasi selengkapnya tentang kapasitas jaringan node Anda, lihat [harga Amazon MemoryDB](https://aws.amazon.com/memorydb/pricing/).
## Latensi
Metrik latensi `SuccessfulWriteRequestLatency` dan `SuccessfulReadRequestLatency` ukur total waktu yang dibutuhkan MemoryDB untuk mesin Valkey untuk menanggapi permintaan.
**catatan**
Nilai yang meningkat untuk `SuccessfulWriteRequestLatency` dan `SuccessfulReadRequestLatency` metrik dapat terjadi saat menggunakan pipelining Valkey dengan CLIENT REPLY diaktifkan pada klien Valkey. Valkey pipelining adalah teknik untuk meningkatkan kinerja dengan mengeluarkan beberapa perintah sekaligus, tanpa menunggu respons terhadap setiap perintah individu. [Untuk menghindari nilai yang meningkat, kami sarankan untuk mengonfigurasi klien Redis Anda ke perintah pipeline dengan CLIENT REPLY OFF.](https://valkey.io/commands/client-reply/)
## Replikasi
Volume data yang direplikasi akan terlihat melalui metrik `ReplicationBytes`. Anda dapat memantau `MaxReplicationThroughput` terhadap throughput kapasitas replikasi. Disarankan untuk menambahkan lebih banyak pecahan saat mencapai throughput kapasitas replikasi maksimum.
`ReplicationDelayedWriteCommands`juga dapat menunjukkan apakah beban kerja melebihi throughput kapasitas replikasi maksimum. [Untuk informasi lebih lanjut tentang replikasi di MemoryDB, lihat Memahami replikasi MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html)