本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 應監控哪些指標？
<a name="CacheMetrics.WhichShouldIMonitor"></a>

以下 CloudWatch 指標可提供 ElastiCache 效能的深入分析。在大多數的案例中，我們建議您為這些指標設定 CloudWatch 警示，讓您可以在發生效能問題前先採取修正動作。

**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [EngineCPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage (Valkey 和 Redis OSS)](#metrics-swap-usage)
+ [移出](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [記憶體 (Valkey 和 Redis OSS)](#metrics-memory)
+ [網路](#metrics-network)
+ [延遲](#metrics-latency)
+ [複寫](#metrics-replication)
+ [流量管理 (Valkey 和 Redis OSS)](#traffic-management)

## CPUUtilization
<a name="metrics-cpu-utilization"></a>

此為主機層級指標，以百分比報告。如需詳細資訊，請參閱[主機層級指標](CacheMetrics.HostLevel.md)。

**Valkey 和 Redis OSS**

 對於具有 2 個或以下 vCPU 的小型節點類型，請使用 `CPUUtilization ` 指標來監控工作負載。

一般而言，我們建議您將閾值設為您可用 CPU 的 90%。由於 Valkey 和 Redis OSS 都是單執行緒，因此實際閾值應該計算為節點總容量的一小部分。例如，假設您使用擁有二核心的節點類型。在此情況下，CPUUtilization 的閾值將為 90/2 或 45%。

您將需要根據您所使用快取節點中的核心數，來判斷您自己的閾值。如果您超過此閾值，且主要工作負載來自讀取請求，請新增僅供讀取複本來擴展叢集。若主要工作負載是來自寫入請求，取決於您的叢集組態，我們建議您：
+ **Valkey 或 Redis OSS （停用叢集模式） 叢集：**使用較大的快取執行個體類型擴展。
+ **Valkey 或 Redis OSS （啟用叢集模式） 叢集：**新增更多碎片，將寫入工作負載分散到更多主節點。

**提示**  
與其使用主機層級指標 `CPUUtilization`，Valkey 和 Redis OSS 使用者可以使用指標 `EngineCPUUtilization`，這會報告 Valkey 或 Redis OSS 引擎核心上的用量百分比。若要查看此指標是否在您的節點上可用，以及詳細資訊，請參閱 [Valkey 和 Redis OSS 的指標](CacheMetrics.Redis.md)。

對於具有 4vCPUs或更多的較大節點類型，您可能需要使用 `EngineCPUUtilization` 指標，該指標會報告 Valkey 或 Redis OSS 引擎核心上的用量百分比。若要查看此指標是否可在您的節點上使用，以及如需詳細資訊，請參閱 [Redis OSS 的指標](CacheMetrics.Redis.md)。

**Memcached**

因為 Memcached 為多執行緒，此指標可高達 90%。如果您超過此閾值，請使用較大的快取節點類型來擴展叢集，或新增更多快取節點來擴展叢集。

## EngineCPUUtilization
<a name="metrics-engine-cpu-utilization"></a>

對於具有 4vCPUs或更多的較大節點類型，您可能需要使用 `EngineCPUUtilization` 指標，該指標會報告 Redis OSS 引擎核心上的用量百分比。若要查看此指標是否可在您的節點上使用，以及如需詳細資訊，請參閱 [Valkey 和 Redis OSS 的指標](CacheMetrics.Redis.md)。

如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon ElastiCache for Redis OSS 最佳實務 Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)的 **CPUs** 一節。

## SwapUsage (Valkey 和 Redis OSS)
<a name="metrics-swap-usage"></a>

此為主機層級指標，以位元組報告。如需詳細資訊，請參閱[主機層級指標](CacheMetrics.HostLevel.md)。

`FreeableMemory` CloudWatch 指標接近 0 (亦即低於 100MB) 或 `SwapUsage` 指標大於 `FreeableMemory` 指標表示節點處於記憶體壓力之下。如果發生此情況，請見下列主題：
+ [確保您有足夠的記憶體來建立 Valkey 或 Redis OSS 快照](BestPractices.BGSAVE.md)
+ [管理 Valkey 和 Redis OSS 的預留記憶體](redis-memory-management.md)

## 移出
<a name="metrics-evictions"></a>

此為快取引擎指標。建議您根據應用程式需求，親自判斷此指標的警示閾值。

如果您使用 Memcached 並超過您選擇的閾值，請使用較大的節點類型來擴展叢集，或新增更多節點來擴展叢集。

## CurrConnections
<a name="metrics-curr-connections"></a>

此為快取引擎指標。建議您根據應用程式需求，親自判斷此指標的警示閾值。

*CurrConnections* 的數字增加，可能表示您的應用程式發生問題。您需要調查應用程式行為才能處理此問題。

如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon ElastiCache for Redis OSS 最佳實務 Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)的**連線**一節。

## 記憶體 (Valkey 和 Redis OSS)
<a name="metrics-memory"></a>

記憶體是 Valkey 和 Redis OSS 的核心層面。為避免資料遺失以及因應資料集的未來成長而調整，了解叢集的記憶體使用率是必要的。有關節點記憶體使用率的統計資料，請參閱 [INFO](https://valkey.io/commands/info) 命令的記憶體區段。

如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon ElastiCache for Redis OSS 最佳實務 Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)的**記憶體**一節。

## 網路
<a name="metrics-network"></a>

叢集網路頻寬容量的決定因素之一，是您選取的節點類型。如需節點網路容量的詳細資訊，請參閱 [Amazon ElastiCache 定價](https://aws.amazon.com/elasticache/pricing/)。

如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon ElastiCache for Redis OSS 最佳實務 Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)**的網路**一節。

## 延遲
<a name="metrics-latency"></a>

可根據所需的精細程度，以各種方式接近 ElastiCache for Valkey 執行個體的回應時間。造成 ElastiCache for Valkey 整體伺服器端回應時間的關鍵階段是命令預處理、命令執行和命令後處理。

 衍生自 Valkey [INFO](https://valkey.io/commands/info) 命令的命令特定延遲指標，例如 GetTypeCmdsLatency 和 SetTypeCmdsLatency 指標，特別著重於執行 Valkey 命令的核心命令邏輯。如果您的使用案例是判斷命令執行時間或每個資料結構的彙總延遲，這些指標會很有幫助。

ElastiCache for Valkey 引擎回應請求所需的延遲指標`SuccessfulWriteRequestLatency`和`SuccessfulReadRequestLatency`測量總時間。

**注意**  
在 Valkey 用戶端上啟用 CLIENT REPLY 的情況下使用 Valkey 管道時，可能會發生 `SuccessfulWriteRequestLatency`和 `SuccessfulReadRequestLatency`指標的膨脹值。Valkey pipeline 是一種透過一次發出多個命令來改善效能的技術，無需等待對每個個別命令的回應。為了避免膨脹值，建議您使用 [CLIENT REPLY OFF](https://valkey.io/commands/client-reply/) 將 Valkey 用戶端設定為管道命令。

如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon ElastiCache 最佳實務 Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)的**延遲**一節。

## 複寫
<a name="metrics-replication"></a>

遭複寫的資料量可透過 `ReplicationBytes` 指標顯示。雖然此指標代表複寫群組上的寫入負載，但並沒有提供複寫運作狀態的深入分析。針對這個用途，您可以使用 `ReplicationLag` 指標。

如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 Amazon ElastiCache for Redis OSS 最佳實務 Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)的**複寫**一節。

## 流量管理 (Valkey 和 Redis OSS)
<a name="traffic-management"></a>

 當傳送給節點的傳入命令超過 Valkey 或 Redis OSS 可處理的數目時，ElastiCache for Redis OSS 會自動管理節點的流量。這樣做是為了讓引擎保持最佳運作狀態和穩定性。

 若在節點上主動管理流量，則指標 `TrafficManagementActive` 會發出資料點 1。這表示節點的規模可能不足以因應所提供的工作負載。如果此指標長時間維持 1，請評估叢集，以決定是否需要縱向擴展或橫向擴展。

 如需詳細資訊，請參閱[指標](CacheMetrics.Redis.md)頁面上的 `TrafficManagementActive` 指標。