本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 应监控哪些指标？
<a name="CacheMetrics.WhichShouldIMonitor"></a>

以下 CloudWatch 指标可以很好地了解 ElastiCache 性能。在大多数情况下，我们建议您为这些指标设置 CloudWatch 警报，以便在出现性能问题之前采取纠正措施。

**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [发动机 CPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage （Valkey 和 Redis OSS）](#metrics-swap-usage)
+ [移出](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [内存（Valkey 和 Redis OSS）](#metrics-memory)
+ [Network](#metrics-network)
+ [延迟](#metrics-latency)
+ [复制](#metrics-replication)
+ [流量管理（Valkey 和 Redis OSS）](#traffic-management)

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

这是以百分比形式报告的主机级指标。有关更多信息，请参阅 [主机级指标](CacheMetrics.HostLevel.md)。

**Valkey 和 Redis OSS**

 对于 2v CPUs 或更低的较小节点类型，请使用该`CPUUtilization `指标来监控您的工作负载。

一般来说，我们建议您将阈值设置为可用 CPU 的 90%。因为 Valkey 和 Redis OSS 都是单线程的，实际阈值应计算为节点总容量的一小部分。例如，假设您使用具有两个核心的节点类型。在这种情况下，的阈值 CPUUtilization 将为 90/2，即 45%。

您需要根据所使用的缓存节点中的核心数，来确定自己的阈值。如果超过此阈值，并且主要工作负载来自读取请求，则请通过添加只读副本来扩展集群。如果主要工作负载来自写入请求，我们的建议取决于您的集群配置：
+ **Redis（已禁用集群模式）集群**：使用更大的缓存实例类型进行纵向扩展。
+ **Redis（已启用集群模式）集群**：添加更多分片，将写入工作负载分配给更多主节点。

**提示**  
Valkey 和 Redis OSS 用户可能无法使用主机级指标 `CPUUtilization`，而可以使用指标 `EngineCPUUtilization`，该指标可以报告 Valkey 或 Redis OSS 引擎核心的使用百分比。要了解此指标在您的节点上是否可用并了解更多信息，请参阅 [Valkey 和 Redis OSS 的指标](CacheMetrics.Redis.md)。

对于具有 4v CPUs 或更高版本的大型节点类型，您可能需要使用该`EngineCPUUtilization`指标，该指标报告 Valkey 或 Redis OSS 引擎核心的使用百分比。要了解此指标在您的节点上是否可用并了解更多信息，请参阅 [Redis OSS 的指标](CacheMetrics.Redis.md)。

**Memcached**

因为 Memcached 是多线程的，所以此指标可能高达 90%。如果超过此阈值，请使用更大的缓存节点类型来纵向扩展集群，或通过添加更多缓存节点进行横向扩展。

## 发动机 CPUUtilization
<a name="metrics-engine-cpu-utilization"></a>

对于具有 4v CPUs 或更高版本的大型节点类型，您可能需要使用该`EngineCPUUtilization`指标，该指标报告 Redis OSS 引擎核心的使用百分比。要了解此指标在您的节点上是否可用并了解更多信息，请参阅 [Valkey 和 Redis OSS 的指标](CacheMetrics.Redis.md)。

有关更多信息，请参阅 “[使用亚马逊监控亚马逊 ElastiCache 适用于 Redis OSS 的最佳实践](https://www.amazonaws.cn/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)” **CPUs**部分。 CloudWatch

## 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*可能表明您的应用程序存在问题；您需要调查应用程序行为才能解决此问题。

有关更多信息，请参阅 “[使用亚马逊监控亚马逊 ElastiCache 适用于 Redis OSS 的最佳实践” 中的 “](https://www.amazonaws.cn/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)**连接**” 部分。 CloudWatch

## 内存（Valkey 和 Redis OSS）
<a name="metrics-memory"></a>

内存是 Valkey 和 Redis OSS 的核心指标。了解集群的内存利用率对于避免数据丢失和适应数据集的未来增长是必要的。有关节点内存利用率的统计信息可在 [INFO](https://valkey.io/commands/info) 命令的内存部分中找到。

有关更多信息，请参阅 “[使用亚马逊监控亚马逊 ElastiCache 适用于 Redis OSS 的最佳实践](https://www.amazonaws.cn/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)” 中的 “**内存**” 部分。 CloudWatch

## Network
<a name="metrics-network"></a>

集群网络带宽容量的决定因素之一是您选择的节点类型。有关您的节点网络容量的更多信息，请参阅 [Amazon ElastiCache 定价](https://www.amazonaws.cn/elasticache/pricing/)。

有关更多信息，请参阅 “[使用亚马逊监控亚马逊 ElastiCache 适用于 Redis OSS 的最佳实践” 中的 “](https://www.amazonaws.cn/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)**网络**” 部分。 CloudWatch

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

根据所需的粒度级别，可以通过多种方式测量 for Valkey 实例的响应时间。 ElastiCache 影响 Valkey 整体服务器端响应 ElastiCache 时间的关键阶段是命令预处理、命令执行和命令后处理。

 源自 Valkey [INFO](https://valkey.io/commands/info) 命令的特定于命令的延迟指标，例如 GetTypeCmdsLatency 该 SetTypeCmdsLatency 指标专门针对执行 Valkey 命令的核心命令逻辑。如果您的使用案例是确定命令执行时间或每个数据结构的聚合延迟，则这些指标将很有帮助。

延迟指标`SuccessfulWriteRequestLatency`和`SuccessfulReadRequestLatency`衡量 for Valkey 引擎响应请求所 ElastiCache 花费的总时间。

**注意**  
当使用 Valkey 管道传输且在 Valkey 客户端上启用 CLIENT REPLY 时，`SuccessfulWriteRequestLatency` 和 `SuccessfulReadRequestLatency` 指标的值可能会虚高。Valkey 管道传输是一种通过同时发出多个命令来提高性能的技术，无需等待每个命令的响应。为避免值虚高，我们建议您将 Valkey 客户端配置为在关闭 [CLIENT REPLY](https://valkey.io/commands/client-reply/) 的情况下通过管道传输命令。

有关更多信息，请参阅 “[ ElastiCache 使用亚马逊监控亚马逊最佳实践](https://www.amazonaws.cn/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)” 中的 “**延迟**” 部分 CloudWatch。

## 复制
<a name="metrics-replication"></a>

可通过 `ReplicationBytes` 指标了解被复制的数据量。尽管此指标表示复制组上的写入负载，但它不提供有关复制运行状况的信息。要了解此信息，您可以使用 `ReplicationLag` 指标。

有关更多信息，请参阅 “[使用亚马逊监控亚马逊 ElastiCache 适用于 Redis OSS 的最佳实践](https://www.amazonaws.cn/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)” 中的 “**复制**” 部分。 CloudWatch

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

 ElastiCache for Redis 当向节点发送的传入命令多于 Valkey 或 Redis OSS 处理的命令时，OSS 会自动管理针对该节点的流量。这样做是为了保持引擎的最佳运行和稳定性。

 在节点上主动管理流量时，指标 `TrafficManagementActive` 将发出为 1 的数据点。这表示节点对于所提供的工作负载而言可能规模过小。如果此指标在很长一段时间内保持为 1，请评估集群以确定是否需要纵向扩展或横向扩展。

 有关更多信息，请参阅[指标](CacheMetrics.Redis.md)页面上的 `TrafficManagementActive` 指标。