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

# 使用 CloudWatch 指标监控使用情况
<a name="CacheMetrics"></a>

ElastiCache 提供了使您能够监控集群的指标。您可以通过访问这些指标 CloudWatch。有关的更多信息 CloudWatch，请参阅[CloudWatch 文档。](https://aws.amazon.com/documentation/cloudwatch/)

ElastiCache 提供主机级指标（例如 CPU 使用率）和特定于缓存引擎软件的指标（例如，缓存获取和缓存未命中）。这些指标每隔 60 秒对每个缓存节点进行测量并发布结果。

**重要**  
您应该考虑对某些关键指标设置 CloudWatch 警报，以便在集群性能开始下降时收到通知。有关更多信息，请参阅本指南中的[应监控哪些指标？](CacheMetrics.WhichShouldIMonitor.md)。

**Topics**
+ [主机级指标](CacheMetrics.HostLevel.md)
+ [Valkey 和 Redis OSS 的指标](CacheMetrics.Redis.md)
+ [Memcached 的指标](CacheMetrics.Memcached.md)
+ [应监控哪些指标？](CacheMetrics.WhichShouldIMonitor.md)
+ [选择指标统计数据和周期](CacheMetrics.ChoosingStatisticsAndPeriods.md)
+ [监控 CloudWatch 集群和节点指标](CloudWatchMetrics.md)

# 主机级指标
<a name="CacheMetrics.HostLevel"></a>

`AWS/ElastiCache` 命名空间包含各个缓存节点的以下主机级指标。这些指标每隔 60 秒对每个缓存节点进行测量并发布结果。

**另请参阅**
+ [Valkey 和 Redis OSS 的指标](CacheMetrics.Redis.md)


| 指标 | 描述 | 单位 | 
| --- | --- | --- | 
| CPUUtilization |  整个主机的 CPU 使用率百分比。由于 Valkey 和 Redis OSS 是单线程的，所以我们建议您监控有 4 个或更多 vCPU 的节点的 EngineCPUUtilization 指标。 |  百分比  | 
| CPUCreditBalance | 实例自启动后已累积获得的 CPU 积分数。对于 T2 标准，CPUCreditBalance 还包含已累积的启动积分数。 在获得积分后，积分将在积分余额中累积；在花费积分后，将从积分余额中扣除积分。积分余额具有最大值限制，这是由实例大小决定的。在达到限制后，将丢弃获得的任何新积分。对于 T2 标准，启动积分不计入限制。 实例可以花费 CPUCreditBalance 中的积分，以便突增到基准 CPU 使用率以上。 CPU 信用指标仅每 5 分钟提供一次。 这些指标对 T2 可突增性能实例不可用。  | 积分（vCPU 分钟）  | 
| CPUCreditUsage | 实例为保持 CPU 使用率而花费的 CPU 积分数。一个 CPU 积分等于一个 vCPU 按 100% 利用率运行一分钟，或者 vCPU、利用率和时间的等效组合（例如， 一个 vCPU 按 50% 利用率运行两分钟，或者两个 vCPU 按 25% 利用率运行两分钟）。 CPU 信用指标仅每 5 分钟提供一次。如果您指定一个大于五分钟的时间段，请使用“Sum（总和）”统计数据，而非“Average（平均值）”统计数据。 这些指标对 T2 可突增性能实例不可用。  | 积分（vCPU 分钟）  | 
| FreeableMemory  |  主机上可用的闲置内存量。这是从操作系统报告为空闲的 RAM、缓冲区和缓存中派生出来的。 |  字节  | 
| NetworkBytesIn |  主机已从网络读取的字节数。 |  字节  | 
| NetworkBytesOut | 实例在所有网络接口上发送的字节数。 |  字节  | 
| NetworkPacketsIn | 实例在所有网络接口上收到的数据包的数量。此指标依据单个实例上的数据包数量来标识传入流量的量。 | 计数  | 
| NetworkPacketsOut |  实例在所有网络接口上发送的数据包的数量。此指标依据单个实例上的数据包数量标识传出流量的量。 | 计数  | 
| NetworkBandwidthInAllowanceExceeded | 因入站聚合带宽超过实例的最大值而排队或丢弃的数据包的数量。 | 计数  | 
| NetworkConntrackAllowanceExceeded | 由于连接跟踪超过实例的最大值且无法建立新连接而丢弃的数据包的数量。这可能会导致进出实例的流量丢失数据包。 | 计数  | 
| NetworkBandwidthOutAllowanceExceeded | 因出站聚合带宽超过实例的最大值而排队或丢弃的数据包的数量。 | 计数  | 
| NetworkPacketsPerSecondAllowanceExceeded | 因每秒双向数据包数量超过实例的最大值而排队或丢弃的数据包数量。 | 计数  | 
| NetworkMaxBytesIn | 每分钟内接收字节的最大每秒突增量。 | 字节 | 
| NetworkMaxBytesOut  | 每分钟内传输字节的最大每秒突增量。 | 字节 | 
| NetworkMaxPacketsIn | 每分钟内接收数据包的最大每秒突增量。 | 计数  | 
| NetworkMaxPacketsOut | 每分钟内传输数据包的最大每秒突增量。 | 计数  | 
| SwapUsage |  主机上的交换区使用量。 |  字节  | 

# Valkey 和 Redis OSS 的指标
<a name="CacheMetrics.Redis"></a>

`Amazon ElastiCache` 命名空间包括以下 Valkey 和 Redis OSS 指标。使用 Valkey 引擎时，这些指标是相同的。

除 `ReplicationLag`、`EngineCPUUtilization`、`SuccessfulWriteRequestLatency` 和 `SuccessfulReadRequestLatency` 之外，这些指标均源自 **info** 命令。每项指标均是按照缓存节点级计算的。

有关该**info**命令的完整文档，请参阅 [http://valkey。 io/commands/info](https://valkey.io/commands/info)。

**另请参阅**
+ [主机级指标](CacheMetrics.HostLevel.md)

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonElastiCache/latest/dg/CacheMetrics.Redis.html)

**发动机CPUUtilization 可用性**  
AWS以下列出的区域适用于所有支持的节点类型。


| Region |  区域名称 | 
| --- | --- | 
| us-east-2 | 美国东部（俄亥俄州） | 
| us-east-1 | 美国东部（弗吉尼亚州北部） | 
| us-west-1 | 美国西部（加利福尼亚北部） | 
| us-west-2 | 美国西部（俄勒冈） | 
| ap-northeast-1 | 亚太地区（东京） | 
| ap-northeast-2 | 亚太地区（首尔） | 
| ap-northeast-3 | 亚太地区（大阪） | 
| ap-east-1 | 亚太地区（香港） | 
| ap-south-1 | Asia Pacific (Mumbai) | 
| ap-southeast-1 | 亚太地区（新加坡） | 
| ap-southeast-2 | 亚太地区（悉尼） | 
| ap-southeast-3 | 亚太地区（雅加达） | 
| ca-central-1 | 加拿大（中部） | 
| cn-north-1 | 中国（北京） | 
| cn-northwest-2 | 中国（宁夏） | 
| me-south-1 | 中东（巴林） | 
| eu-central-1 | 欧洲地区（法兰克福） | 
| eu-west-1 | 欧洲地区（爱尔兰） | 
| eu-west-2 | 欧洲地区（伦敦） | 
| eu-west-3 | 欧洲地区（巴黎） | 
| eu-south-1 | 欧洲地区（米兰） | 
| af-south-1 | 非洲（开普敦） | 
| eu-north-1 | 欧洲地区（斯德哥尔摩） | 
| sa-east-1 | 南美洲（圣保罗） | 
| us-gov-west-1 | AWS GovCloud （美国西部） | 
| us-gov-east-1 | AWS GovCloud （美国东部） | 

以下是一些类型的命令的集合，派生自 **info commandstats**。commandstats 部分提供基于命令类型的统计数据，包括调用次数、这些命令消耗的总 CPU 时间以及每个命令执行所消耗的平均 CPU 时间。对于每种命令类型，都会添加以下行：`cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX`。

下面列出的延迟指标是使用 [INFO](https://valkey.io/commands/info) 中的 commandstats 统计数据计算得出的。计算方式如下：`delta(usec)/delta(calls)`。`delta` 计算为一分钟内的差异。延迟定义为处理命令所花费 ElastiCache 的 CPU 时间。请注意，对于使用数据分层的集群，这些测量值并未包含从 SSD 提取项目所需的时间。

有关可用命令的完整列表，请参阅 Valkey 文档中的[命令](https://valkey.io/commands)。


| 指标  | 说明  | 单位  | 
| --- | --- | --- | 
| ClusterBasedCmds | 基于集群的命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于集群（cluster info、cluster slot 等）的命令的总和。 | 计数 | 
| ClusterBasedCmdsLatency | 基于集群的命令的延迟。 | 微秒 | 
| EvalBasedCmds | 基于 eval 的命令的命令总数。这是根据 commandstats 统计数据得出的，方法是计算 eval、evalsha 的总和。 | 计数 | 
| EvalBasedCmdsLatency | 基于 Eval 的命令的延迟。 | 微秒 | 
| GeoSpatialBasedCmds | 基于地理空间的命令的命令总数。这是根据 commandstats 统计数据得出的。它是通过汇总所有地理类型的命令的总和得出的：geoadd、geodist、geohash、geopos、georadius 和 georadiusbymember。 | 计数 | 
| GeoSpatialBasedCmdsLatency | 基于地理空间的命令的延迟。 | 微秒 | 
| GetTypeCmds | read-only 类型命令的总数。这是根据 commandstats 统计数据得出的，方法是计算所有 read-only 类型命令（get、hget、scard、lrange 等）的总和。 | 计数 | 
|  GetTypeCmdsLatency |  读取命令的延迟。 | 微秒 | 
| HashBasedCmds | 基于哈希的命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于一个或多个哈希的命令（hget、hkeys、hvals、hdel 等）的总和。 | 计数 | 
|  HashBasedCmdsLatency |  基于哈希的命令的延迟。 | 微秒 | 
| HyperLogLogBasedCmds | 基于 HyperLogLog 的命令的总数。这是根据 commandstats 统计数据得出的，方法是计算所有 pf 类型的命令（pfadd、pfcount、pfmerge 等）的总和。 | 计数 | 
|  HyperLogLogBasedCmdsLatency |  HyperLogLog基于命令的延迟。 | 微秒 | 
| JsonBasedCmds | JSON 命令的总数，包括读取和写入命令。这是根据 commandstats 统计数据得出的，方法是计算所有作用于 JSON 键的 JSON 命令的总和。 | 计数 | 
| JsonBasedCmdsLatency | 所有 JSON 命令的延迟，包括读取和写入命令。 | 微秒 | 
| JsonBasedGetCmds | JSON 只读命令的总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于 JSON 键的 JSON 读取命令的总和。 | 计数 | 
| JsonBasedGetCmdsLatency | JSON 只读命令的延迟。 | 微秒 | 
| JsonBasedSetCmds | JSON 写入命令的总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于 JSON 键的 JSON 写入命令的总和。 | 计数 | 
| JsonBasedSetCmdsLatency | JSON 写入命令的延迟。 | 微秒 | 
| KeyBasedCmds | 基于密钥的命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于多个数据结构中的一个或多个键的命令（del、expire、rename 等）的总和。 | 计数 | 
|  KeyBasedCmdsLatency |  基于键的命令的延迟。 | 微秒 | 
| ListBasedCmds | 基于列表的命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于一个或多个列表的命令（lindex、lrange、lpush、ltrim 等）的总和。 | 计数 | 
|  ListBasedCmdsLatency |  基于列表的命令的延迟。 | 微秒 | 
| NonKeyTypeCmds | 不基于键的命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有不作用于某个键的命令（例如 acl、dbsize 或 info 等）的总和。 | 计数 | 
| NonKeyTypeCmdsLatency |  non-key-based命令延迟。 | 微秒 | 
| PubSubBasedCmds |  pub/sub 功能命令总数。这是从commandstats统计数据中得出的，方法是将所有用于 pub/sub 功能的命令相加：psubscribepublish、pubsub、punsubscribe、ssubscribe、、sunsubscribe、spublishsubscribe、和unsubscribe。 | 计数 | 
| PubSubBasedCmdsLatency | PubSub-based 命令的延迟。 | 微秒 | 
| SetBasedCmds | 基于设置的命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于一个或多个集合的命令（scard、sdiff、sadd、sunion 等）的总和。 | 计数 | 
|  SetBasedCmdsLatency |  基于集合的命令的延迟。 | 微秒 | 
| SetTypeCmds | write 类型命令的总数。这是根据 commandstats 统计数据得出的，方法是计算对数据执行操作的所有 mutative 类型的命令（set、hset、sadd、lpop 等）的总和。 | 计数 | 
|  SetTypeCmdsLatency |  写入命令的延迟。 | 微秒 | 
| SortedSetBasedCmds | 基于设置的已排序命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于一个或多个已排序集合的命令（zcount、zrange、zrank、zadd 等）的总和。 | 计数 | 
|  SortedSetBasedCmdsLatency |  基于排序的命令的延迟。 | 微秒 | 
| StringBasedCmds | 基于字符串的命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于一个或多个字符串的命令（strlen、setex、setrange 等）的总和。 | 计数 | 
|  StringBasedCmdsLatency |  基于字符串的命令的延迟。 | 微秒 | 
| StreamBasedCmds | 基于流的命令总数。这是根据 commandstats 统计数据得出的，方法是计算所有作用于一个或多个流数据类型的命令（xrange、xlen、xadd、xdel 等）的总和。 | 计数 | 
|  StreamBasedCmdsLatency |  基于流的命令的延迟。 | 微秒 | 
| SearchBasedCmds | Search 命令的总数，包括读取和写入命令。这是从 commandstats 统计数据通过汇总所有 Search 命令得出的。 | 计数 | 
| SearchBasedCmdsLatency | 所有 Search 命令的延迟，包括读取和写入命令。 | 微秒 | 
| SearchBasedGetCmds | Search 只读命令的总数。这是从 commandstats 统计数据通过汇总所有 Search 读取命令得出的。 | 计数 | 
| SearchBasedGetCmdsLatency | Search 只读命令的延迟。 | 微秒 | 
| SearchBasedSetCmds | Search 写入命令的总数。这是从 commandstats 统计数据通过汇总所有 Search 写入命令得出的。 | 计数 | 
| SearchBasedSetCmdsLatency | Search 写入命令的延迟。 | 微秒 | 

# Memcached 的指标
<a name="CacheMetrics.Memcached"></a>

`AWS/ElastiCache` 命名空间包括以下 Memcached 指标。

AWS/ElastiCache 命名空间包括源自 Memcached stats 命令的以下指标。每项指标均是按照缓存节点级计算的。

**另请参阅**。
+ [主机级指标](CacheMetrics.HostLevel.md)


| 指标  | 描述  | 单位  | 
| --- | --- | --- | 
| BytesReadIntoMemcached | 缓存节点已从网络读取的字节数。 | 字节 | 
| BytesUsedForCacheItems | 用来存储缓存项的字节数。 | 字节 | 
| BytesWrittenOutFromMemcached | 缓存节点已写入网络的字节数。 | 字节 | 
| CasBadval | Cas（检查和设置）值不匹配已存储 Cas 值的情况下，缓存已收到的 Cas 请求数。 | 计数 | 
| CasHits | 找到了请求的密钥并且 Cas 值匹配的情况下，缓存已收到的 Cas 请求数。 | 计数 | 
| CasMisses | 未找到所请求密钥的情况下，缓存已收到的 Cas 请求数。  | 计数 | 
| CmdFlush | 缓存已收到的 flush 命令数。 | 计数 | 
| CmdGet |  缓存已收到的 get 命令数。 | 计数 | 
| CmdSet | 缓存已收到的 set 命令数。 | 计数 | 
| CurrConnections | 在某个瞬间连接到缓存的连接计数。ElastiCache 使用 2 到 3 个连接来监控集群。 除了上述内容之外，Memcached 还创建了一些相当于用于节点类型所用线程两倍的内部连接。各种节点类型的线程计数可以在适用参数组的 `Nodetype Specific Parameters` 中查看。 总连接是客户端连接、用于监控的连接和上述内部连接的总和。  | 计数 | 
| CurrItems | 当前存储在缓存中的项目的计数。 | 计数 | 
| DecrHits | 找到了所请求密钥的情况下，缓存已收到的减量请求数。 | 计数 | 
| DecrMisses | 未找到所请求密钥的情况下，缓存已收到的减量请求数。 | 计数 | 
| DeleteHits | 找到了所请求密钥的情况下，缓存已收到的删除请求数。 | 计数 | 
| DeleteMisses | 未找到所请求密钥的情况下，缓存已收到的删除请求数。 | 计数 | 
| Evictions | 缓存为给新的写入留出空间而移除的未过期项目数。 | 计数 | 
| GetHits | 找到了所请求密钥的情况下，缓存收到的 get 请求数。 | 计数 | 
| GetMisses | 未找到所请求密钥的情况下，缓存收到的 get 请求数。 | 计数 | 
| IncrHits | 找到了所请求密钥的情况下，缓存收到的增量请求数。 | 计数 | 
| IncrMisses | 未找到所请求密钥的情况下，缓存收到的增量请求数。 | 计数 | 
| Reclaimed | 缓存为给新的写入留出空间而移除的过期项目数。 | 计数 | 

对于 Memcached 1.4.14，还提供下列额外指标。


| 指标  | 描述  | 单位  | 
| --- | --- | --- | 
| BytesUsedForHash |  散列表当前使用的字节数。 | 字节 | 
| CmdConfigGet | config get 请求的累计数量。 | 计数 | 
| CmdConfigSet | config set 请求的累计数量。 | 计数 | 
| CmdTouch | touch 请求的累计数量。 | 计数 | 
| CurrConfig | 当前存储的配置数。 | 计数 | 
| EvictedUnfetched | 从最近最少使用的缓存 (LRU) 移出、设置后从未被触动的有效项目数。 | 计数 | 
| ExpiredUnfetched | 从 LRU 移出、设置后从未被触动的过期项目数。 | 计数 | 
| SlabsMoved | 已移动的 Slab 页面总数。 | 计数 | 
| TouchHits | 已被触动并赋予新的过期时间的密钥数。 | 计数 | 
| TouchMisses | 已被触动但未找到的项目数。 | 计数 | 

AWS/ElastiCache 命名空间包括以下计算出的缓存层面指标。


| 指标  | 描述  | 单位  | 
| --- | --- | --- | 
| NewConnections | 缓存已收到的新连接数。这一数字通过记录一段时间内 total\$1connections 的变化，从 Memcached total\$1connections 统计数据得出。由于一项为 ElastiCache 预留的连接，这一数字始终至少为 1。 | 计数 | 
| NewItems | 缓存存储的新项目数。这一数字通过记录一段时间内 total\$1items 的变化，从 Memcached total\$1items 统计数据得出。 | 计数 | 
| UnusedMemory | 数据未使用的内存的数量。这一数量通过从 limit\$1maxbytes 扣减字节数，从 Memcached 统计数据 limit\$1maxbytes 和字节数得出。 由于除了数据使用的内存之外 Memcached 开销还会使用一些内存，因此不应将 UnusedMemory 视为可供额外数据使用的内存量。即使您仍然拥有一些未使用的内存，也可能会出现移出情况。 有关更多详细信息，请参阅 [Memcached 项目内存使用](https://web.archive.org/web/20190422040715/https://www.deplication.net/2016/02/memcached-item-memory-usage/)。  | 字节 | 

# 应监控哪些指标？
<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://aws.amazon.com/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://aws.amazon.com/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://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)” 中的 “**内存**” 部分。 CloudWatch

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

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

有关更多信息，请参阅 “[使用亚马逊监控亚马逊 ElastiCache 适用于 Redis OSS 的最佳实践” 中的 “](https://aws.amazon.com/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://aws.amazon.com/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://aws.amazon.com/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` 指标。

# 选择指标统计数据和周期
<a name="CacheMetrics.ChoosingStatisticsAndPeriods"></a>

虽然 CloudWatch 将允许您为每个指标选择统计数据和周期，但并非所有的组合都有用。例如，CPU 利用率的平均、最小和最大统计数据均有用，但求和统计数据却无用。

对于每个单独缓存节点，发布所有 ElastiCache 示例的持续时间均为 60 秒。对于任何 60 秒期间，缓存节点的度量标准将只包含一个单一示例。

有关如何检索您的缓存节点的度量标准之更多信息，请参阅 [监控 CloudWatch 集群和节点指标](CloudWatchMetrics.md)。

# 监控 CloudWatch 集群和节点指标
<a name="CloudWatchMetrics"></a>

ElastiCache 并 CloudWatch 已集成，因此您可以收集各种指标。您可以使用监控这些指标 CloudWatch。

**注意**  
以下示例需要 CloudWatch 命令行工具。有关开发者工具的更多信息 CloudWatch 以及要下载开发者工具，请参阅[ CloudWatch 产品页面](https://aws.amazon.com/cloudwatch)。

以下过程向您展示 CloudWatch 如何使用收集集群过去一小时的存储空间统计信息。

**注意**  
下述示例中提供的 `StartTime` 和 `EndTime` 值均供说明之用。您必须针对您的缓存节点使用适当的开始和结束时间值替代示例中的相应值。

有关 ElastiCache 限制的信息，请参阅的[AWS服务限制](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_elasticache) ElastiCache。

## 监控 CloudWatch 集群和节点指标（控制台）
<a name="CloudWatchMetrics.CON"></a>

 **收集缓存集群的 CPU 利用率统计数据** 

1. 登录AWS 管理控制台并打开 ElastiCache 控制台，网址为[ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)。

1. 选择您希望查看其度量标准的缓存节点。
**注意**  
若选择 20 个以上的节点，则将禁用在控制台上查看指标。

   1. 在AWS管理控制台的**缓存集群**页面上，单击一个或多个集群的名称。

      显示集群的详情页面。

   1. 单击位于窗口顶部的 **Nodes** 选项卡。

   1. 在详情窗口的 **Nodes** 选项卡上，选择您希望查看其度量标准的缓存节点。

      可用 CloudWatch 指标列表显示在控制台窗口的底部。

   1. 单击 **CPU 利用率** 度量标准。

       CloudWatch 控制台将打开，显示您选择的指标。您可以使用**统计数据**和**周期**下拉列表框以及**时间范围** 选项卡来更改所显示的指标。

## 使用 CloudWatch CLI 监控 CloudWatch 集群和节点指标
<a name="CloudWatchMetrics.CLI"></a>

 **收集缓存集群的 CPU 利用率统计数据** 
+ 对于 Linux、macOS 或 Unix：

  ```
  aws cloudwatch get-metric-statistics \
      --namespace AWS/ElastiCache \
      --metric-name CPUUtilization \
      --dimensions='[{"Name":"CacheClusterId","Value":"test"},{"Name":"CacheNodeId","Value":"0001"}]' \					
      --statistics=Average \
      --start-time 2018-07-05T00:00:00 \
      --end-time 2018-07-06T00:00:00 \
      --period=3600
  ```

  对于 Windows：

  ```
  aws cloudwatch get-metric-statistics ^
      --namespace AWS/ElastiCache ^
      --metric-name CPUUtilization ^
      --dimensions='[{"Name":"CacheClusterId","Value":"test"},{"Name":"CacheNodeId","Value":"0001"}]' ^
      --statistics=Average ^
      --start-time 2018-07-05T00:00:00 ^
      --end-time 2018-07-06T00:00:00 ^
      --period=3600
  ```

## 使用 CloudWatch API 监控 CloudWatch 集群和节点指标
<a name="CloudWatchMetrics.API"></a>

 **收集缓存集群的 CPU 利用率统计数据** 
+ `GetMetricStatistics`使用以下参数调用 CloudWatch API（请注意，开始和结束时间仅作为示例显示；您需要用自己的适当开始和结束时间代替）：
  + `Statistics.member.1``=Average`
  + `Namespace``=AWS/ElastiCache`
  + `StartTime``=2013-07-05T00:00:00`
  + `EndTime``=2013-07-06T00:00:00`
  + `Period``=60`
  + `MeasureName``=CPUUtilization`
  + `Dimensions``=CacheClusterId=mycachecluster,CacheNodeId=0002`  
**Example**  

  ```
   1. http://monitoring.amazonaws.com/
   2.     ?Action=GetMetricStatistics
   3.     &SignatureVersion=4
   4.     &Version=2014-12-01
   5.     &StartTime=2018-07-05T00:00:00
   6.     &EndTime=2018-07-06T23:59:00
   7.     &Period=3600
   8.     &Statistics.member.1=Average
   9.     &Dimensions.member.1="CacheClusterId=mycachecluster"
  10.     &Dimensions.member.2="CacheNodeId=0002"
  11.     &Namespace=&AWS;/ElastiCache
  12.     &MeasureName=CPUUtilization						
  13.     &Timestamp=2018-07-07T17%3A48%3A21.746Z
  14.     &AWS;AccessKeyId=<&AWS; Access Key ID>
  15.     &Signature=<Signature>
  ```