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 ElastiCache kinerja. 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 (Valkey dan Redis OSS)](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Memori (Valkey dan Redis OSS)](#metrics-memory)
+ [Jaringan](#metrics-network)
+ [Latensi](#metrics-latency)
+ [Replikasi](#metrics-replication)
+ [Manajemen Lalu Lintas (Valkey dan Redis OSS)](#traffic-management)
## CPUUtilization
Ini adalah metrik tingkat host yang dilaporkan sebagai persentase. Untuk informasi selengkapnya, lihat [Metrik Tingkat Host](CacheMetrics.HostLevel.md).
**Valkey dan Redis OSS**
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 keduanya 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%.
Anda akan perlu menentukan ambang batas Anda sendiri, berdasarkan jumlah inti pada simpul cache 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 dari permintaan tulis, bergantung pada konfigurasi klaster Anda, sebaiknya Anda:
+ Cluster **Valkey atau Redis OSS (mode cluster dinonaktifkan):** tingkatkan dengan menggunakan jenis instance cache yang lebih besar.
+ Cluster **Valkey atau Redis OSS (mode cluster enabled):** tambahkan lebih banyak pecahan untuk mendistribusikan beban kerja tulis di lebih banyak node primer.
**Tip**
Alih-alih menggunakan metrik Host-Level`CPUUtilization`, pengguna Valkey dan Redis OSS 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 Valkey dan Redis](CacheMetrics.Redis.md) OSS.
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 Redis](CacheMetrics.Redis.md) OSS.
**Memcache**
Karena Memcached bersifat multi-thread, metrik ini dapat mencapai 90%. Jika Anda melebihi ambang batas ini, tingkatkan klaster Anda dengan menggunakan jenis node cache yang lebih besar atau skala dengan menambahkan lebih banyak node cache.
## 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 Redis OSS. Untuk melihat apakah metrik ini tersedia di node Anda dan untuk informasi selengkapnya, lihat [Metrik untuk Valkey dan Redis](CacheMetrics.Redis.md) OSS.
Untuk informasi selengkapnya, lihat **CPUs**bagian di [Memantau praktik terbaik dengan Amazon ElastiCache untuk Redis OSS menggunakan Amazon](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). CloudWatch
## SwapUsage (Valkey dan Redis OSS)
Ini adalah metrik tingkat host yang dilaporkan dalam byte. Untuk informasi selengkapnya, lihat [Metrik Tingkat Host](CacheMetrics.HostLevel.md).
`FreeableMemory` CloudWatch Metrik yang mendekati 0 (yaitu, di bawah 100MB) atau `SwapUsage` metrik lebih besar dari `FreeableMemory` metrik menunjukkan node berada di bawah tekanan memori. Jika tidak, lihat topik berikut:
+ [Memastikan Anda memiliki cukup memori untuk membuat snapshot Valkey atau Redis OSS](BestPractices.BGSAVE.md)
+ [Mengelola memori cadangan untuk Valkey dan Redis OSS](redis-memory-management.md)
## Evictions
Ini adalah metrik mesin cache. Sebaiknya tentukan ambang batas alarm Anda sendiri untuk metrik ini berdasarkan kebutuhan aplikasi Anda.
Jika Anda menggunakan Memcached dan melebihi ambang batas yang Anda pilih, tingkatkan skala cluster Anda dengan menggunakan tipe node yang lebih besar atau skala dengan menambahkan lebih banyak node.
## CurrConnections
Ini adalah metrik mesin cache. 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.
Untuk informasi selengkapnya, lihat bagian **Koneksi** di [Memantau praktik terbaik dengan Amazon ElastiCache untuk Redis OSS menggunakan Amazon](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). CloudWatch
## Memori (Valkey dan Redis OSS)
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).
Untuk informasi selengkapnya, lihat bagian **Memori** di [Memantau praktik terbaik dengan Amazon ElastiCache untuk Redis OSS menggunakan Amazon](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). CloudWatch
## 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 [ ElastiCache harga Amazon](https://aws.amazon.com/elasticache/pricing/).
Untuk informasi selengkapnya, lihat bagian **Jaringan** di [Memantau praktik terbaik dengan Amazon ElastiCache untuk Redis OSS menggunakan Amazon](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/). CloudWatch
## Latensi
Mengukur waktu respons untuk instance ElastiCache for Valkey dapat didekati dengan berbagai cara tergantung pada tingkat granularitas yang diperlukan. Tahapan kunci yang berkontribusi pada keseluruhan waktu respons sisi server ElastiCache untuk Valkey adalah pra-pemrosesan perintah, eksekusi perintah, dan pasca-pemrosesan perintah.
Metrik latensi khusus perintah yang berasal dari perintah Valkey [INFO](https://valkey.io/commands/info) seperti GetTypeCmdsLatency dan fokus SetTypeCmdsLatency metrik secara khusus pada mengeksekusi logika perintah inti untuk perintah Valkey. Metrik ini akan sangat membantu jika kasus penggunaan Anda adalah untuk menentukan waktu eksekusi perintah atau latensi agregat per struktur data.
Metrik latensi `SuccessfulWriteRequestLatency` dan `SuccessfulReadRequestLatency` ukur total waktu yang ElastiCache dibutuhkan 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 Valkey Anda ke perintah pipeline dengan CLIENT REPLY OFF.](https://valkey.io/commands/client-reply/)
Untuk informasi selengkapnya, lihat bagian **Latensi** di [Memantau praktik terbaik dengan Amazon ElastiCache menggunakan Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/).
## Replikasi
Volume data yang direplikasi akan terlihat melalui metrik `ReplicationBytes`. Metrik ini tidak memberikan wawasan tentang kondisi replikasi, meskipun merepresentasikan beban tulis pada grup replikasi. Untuk tujuan ini, Anda dapat menggunakan metrik `ReplicationLag`.
Untuk informasi selengkapnya, lihat bagian **Replikasi** di [Memantau praktik terbaik dengan Amazon ElastiCache untuk Redis OSS menggunakan](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/) Amazon. CloudWatch
## Manajemen Lalu Lintas (Valkey dan Redis OSS)
ElastiCache untuk Redis OSS secara otomatis mengelola lalu lintas terhadap node ketika lebih banyak perintah yang masuk dikirim ke node daripada yang dapat diproses oleh Valkey atau Redis OSS. Hal ini dilakukan untuk menjaga operasi dan stabilitas mesin yang optimal.
Ketika lalu lintas dikelola secara aktif pada simpul, metrik `TrafficManagementActive` akan memancarkan titik data 1. Hal ini menunjukkan bahwa simpul mungkin kurang diskalakan untuk beban kerja yang disediakan. Jika metrik ini tetap 1 untuk jangka waktu yang lama, evaluasi klaster untuk memutuskan apakah penaikan skala atau penskalaan ke luar diperlukan.
Untuk informasi selengkapnya, lihat metrik `TrafficManagementActive` di halaman [Metrik](CacheMetrics.Redis.md).