共计 8452 个字符，预计需要花费 22 分钟才能阅读完成。
在维持 Amazon ElastiCache 资源的可靠性、可用性与性能方面，监控始终是最为重要的伎俩之一。在本文中，咱们将独特理解如何应用 Amazon CloudWatch 及其他内部工具维持衰弱运作的 Redis 集群，并避免其意外中断。咱们还将具体探讨对扩大需要进行预测及筹备的几种可行办法。
将 Amazon CloudWatch 与 Amazon ElastiCache 配合应用的劣势
Amazon ElastiCache 与 Amazon CloudWatch 相结合，可能极大晋升资源相干外围性能指标的可见性。此外，Amazon CloudWatch 警报还可能帮忙您设置指标阈值并触发告诉，确保在须要采取预防措施时及时做出揭示。
随工夫对趋势加以监控，还能够帮忙您检测工作负载的持续增长。您能够为数据点设置最长达 455 天（15 个月）的工夫周期，在此窗口内察看 Amazon CloudWatch 指标的扩大状况，据此预测资源的后续利用率与应用状况。
监控资源
Amazon ElastiCache Redis 集群的运行状况由要害组件（例如 CPU、内存以及网络）的利用率决定。这些组件的适度应用可能导致系统等待时间缩短以及整体性能降落。另一方面，适度配置则可能导致资源得不到充分利用，重大影响老本的优化成果。
Amazon ElastiCache 提供的指标使您可能监控集群；截至本文撰稿时，亚马逊云科技曾经公布 18 项新的 Amazon CloudWatch 指标。
面向 Amazon ElastiCache 的 Amazon CloudWatch 指标次要分为两类：引擎级指标（由 Redis INFO 命令生成）以及主机级指标（来自 ElastiCache 节点的操作系统）。这些指标以 60 秒为距离对每个缓存节点进行测量并进行公布。只管 Amazon CloudWatch 容许您为每项指标任意指定统计信息与检测周期，但只有通过精心设计、相干组合能力真正服务于零碎运行。例如，CPU 使用率中的“均匀”、“最小”以及“最大”等统计信息十分重要，但“总和”信息则根本没有任何理论价值。
CPU
Redis 能够应用不同的 CPU 执行快照保留或者 UNLINK 等辅助操作，但只能通过繁多线程运行命令。换句话说，Redis 每次只能解决一条命令。
思考到 Redis 的单线程属性，Amazon ElastiCache 提供 EngineCPUUtilization 指标，用以提供对 Redis 过程自身负载状况的准确可见性，从而更好地帮忙您理解 Redis 工作负载运行状态。
不同的用例对于高 EngineCPUUtilization 的容忍度都有所区别，其中不存在通用性质的阈值。但作为最佳实际，本文倡议大家确保您的 EngineCPUUtilization 始终低于 90%。
应用应用程序及预期工作负载对集群进行基准测试，能够帮忙您将 EngineCPUUtilization 与零碎理论性能关联起来。咱们建议您针对 EngineCPUUtilization 在不同层级上设置多项 Amazon CloudWatch 警报，以便在达到每项阈值（例如 WARN 为 65%，HIGH 为 90%）时，抢在集群性能遭逢理论影响前向您发出通知。
如果您集群的 EngineCPUUtilization 较高，则能够思考以下补救措施：
- 较高的 EngineCPUUtilization 指标很可能源自特定的 Redis 操作。Redis 命令会应用 Big O 表示法对工夫复杂度进行定义。您能够应用 Redis SLOWLOG 帮忙您确定实现命令所须要的工夫。一大常见问题在于适度应用 Redis KEY 命令，请在生产环境中对这条命令放弃高度关注。
- 在 Redis 命令的工夫复杂性方面，非最优数据模型也有可能给 EngineCPUUtilization 指标带来不必要的压力。例如，汇合的基数可能为一项性能因素，而 SMEMBERS、SDIFF、SUNION 以及其余集命令的工夫复杂度则由集内元素的数量所定义。哈希的大小（字段数）与运行的操作类型，也会给 EngineCPUUtilization 造成影响。
- 如果您在蕴含多个节点的节点组中运行 Redis，则建议您应用副原本创立快照。在从正本创立快照时，主节点不会受到快照保留工作的影响，因而能够持续解决申请而不会升高速度。请验证该节点是否在应用 SaveInProgress 创立快照。在齐全同步的状况下，快照应始终位于主节点之上。
- 大量操作同样可能带来较高的 EngineCPUUtilization。请明确操作所对应的具体负载类型。如果高 EngineCPUUtilization 次要源自大量读取操作，您能够在 Redis 客户端库中应用 Amazon ElastiCache 读取器端点将其配置为禁用集群模式，或者应用 Redis READONLY 命令将其配置为集群模式。如果您只从读取正本处进行读取，则能够在正本组或者各个分片中增加其余节点（最多五个读取正本）。如果写入操作带来较高的 EngineCPUUtilization，则须要为主节点提供更弱小的计算容量。您能够降级至最新一代 m5 与 r5 节点类型，应用更强的处理器疾速执行工作。如果您曾经在应用最新一代节点，则应思考将禁用集群模式切换至启用集群模式。要实现切换，您能够为现有集群创立一套备份，并将另一套曾经启用集群模式的新集群内还原这些数据。在启用集群模式之后，解决方案可能增加更多分片并进行横向扩大。分片数量越多，您可能增加的主节点数量就越多，计算容量天然就越强。
除了应用 EngineCPUUtilization 指标监控 Redis 过程负载之外，您还该当留神其余 CPU 内核的资源应用状况。通过 EngineCPUUtilization，您能够监控整个主机的 CPU 利用率百分比。例如，因为建设连贯会带来局部解决负载，因而大量新连贯的涌入同样有可能拉高 EngineCPUUtilization 指标。
对于 CPU 内核数量小于等于 2 个的小型节点，您还须要关注 CPUUtilization 指标。因为除了快照及托管保护事件等操作之外，您还须要保留一部分计算容量并与 Redis 共享节点 CPU 外围，因而在 EngineCPUUtilization 发生变化之前，您的 CPUUtilization 很可能先一步达到 100%。
最初，Amazon ElastiCache 还反对 T2 与 T3 缓存节点。这些缓存节点提供基准程度的 CPU 性能，并可随时突发峰值 CPU 容量，直到您的收费配额耗尽为止。如果您应用的正是 T2 或 T3 缓存节点，则应监控 CPUCreditUsage 与 CPUCreditBalance，这是因为在配额耗尽之后，其性能会逐步升高至基准程度。
内存
内存是 Redis 中的一大外围因素。理解集群的内存利用率，有助于防止数据失落并继续适应数据集规模的一直增长。
Redis INFO 命令中的 memory 局部，提供对于以后节点内存利用率的统计信息。
其中最重要的指标之一为 used_memory，即 Redis 应用分配器所调配的内存容量。Amazon CloudWatch 提供名为 BytesUsedForCache 的指标，其衍生自 used_memory，您能够应用这项指标确定以后集群的内存利用率。
随着 18 项全新 Amazon CloudWatch 指标的公布，当初您能够应用 DatabaseMemoryUsagePercentage 并依据以后内存利用率（BytesUsedForCache）以及 maxmemory 查看内存利用率百分比。Maxmemory 将设置指标数据集的最大可用内存量。您能够应用 Redis INFO 命令以及 Redis 节点类型特定参数中的 memory 局部调车集群的内存下限。其默认取值由须要保留的内存容量决定。因而在设定之后，您的集群 maxmemory 将有所降落。例如，cache.r5.large 节点类型默认最大内存为 14037181030 字节，但如果您心愿默认保留 25% 的内存，则可用最大内存容量将为 10527885772.5 字节（14037181030 x 0.75）。
当您的 DatabaseMemoryUsagePercentage 达到 100% 时，Redis maxmemory 策略将被触发，且依据所选策略（例如 volatile lru）决定是否进行数据逐出。如果高速缓存内没有任何对外贸易能够进行逐出（依据逐出策略），则写入操作将失败，Redis 主节点随后返回以下音讯：(error) OOM command not allowed when used memory > ‘maxmemory’
逐出并不代表必然产生了问题或性能降落。某些工作负载在设计上就思考到了利用逐出机制。要监控集群内的逐出量，您能够应用 Evictions 指标。此指标同样可通过 Redis INFO 命令应用。但请留神，大量逐出同样会拉高 EngineCPUUtilization 指标。
如果您的工作负载在设计中并未思考应用逐出，则建议您设置 Amazon CloudWatch 警报以在须要执行扩大操作时，被动依据 DatabaseMemoryUsagePercentage 指标的变动状况收回警报并扩大内存容量。对于禁用集群模式的场景，您能够扩大至更大的节点类型以获取更高内存容量。而对于启用集群模式的场景，横向扩大以逐渐减少内存容量才是最正当的解决方案。
控制数据集增长的另一种办法，是在密钥当中应用 TTL（生存工夫）。当生存工夫到期之后，如果客户端（以被动形式）尝试拜访或 Redis（以被动形式）定期测试随机密钥，则该密钥将不再提供起效并将被删除。您能够应用 Redis SCAN 命令来剖析数据集内的某些局部，并放大被动办法以删除过期密钥。在 Amazon ElastiCache 当中，密钥到期可通过 Reclaimed AmazonCloudWatch 指标进行监控。
在执行备份或故障转移的过程中，当将集群数据写入至 .rdb 文件时，Redis 会应用额定的内存来记录对集群的写入操作。如果此额定的内存使用量超过了节点中的可用内存容量，则适度分页及 SwapUsage 会导致处理速度变慢。因而，咱们建议您预留一部分内存容量。预留内存属于专为包容某些操作（例如备份或故障转移）所预留的内存资源。
最初，本文建议您为 SwapUsage 建设 Amazon CloudWatch 警报。此指标不应超过 50 MB。如果集群正在耗费 swap 空间，请在集群的参数组中验证是否配置了短缺的预留内存。
网络
决定集群网络带宽容量的一大决定性因素，在于您所应用的理论节点类型。
咱们强烈建议您在理论生产应用之前对集群进行基准测试，借此评估其性能体现并在监控当中设置正确的阈值。您应以数小时为周期运行基准测试，借此反映临时性网络突发容量的呈现频率与潜在需要。
Amazon ElastiCache 与 Amazon CloudWatch 提供多项主机层级的指标以监控网络利用率，相似于 Amazon Elastic Compute Cloud (Amazon EC2) 实例。NetworkBytesIn 与 NetworkBytesOut 别离代表主机曾经从网络处读取、以及发送至网络处的字节数。NetworkPacketsIn 与 NetworkPacketsOut 则别离代表在网络上接管及发送的数据包数。
在定义集群的网络容量之后，您能够借此映射并建设最高网络利用率预期峰值。此峰值不应高于所选节点类型的网络容量。每种节点类型都提供肯定的突发容量，但咱们建议您预留这部分额定容量以应答流量的意外减少。
依据您所定义的最高利用率，您能够创立 Amazon CloudWatch 警报，确保在网络利用率高于预期或靠近此限度时发送电子邮件告诉。
如果您的网络利用率继续减少并触发了网络警报，则应采取必要措施以增加更多网络容量。要确保调整正确，您须要确定导致网络利用率进步的因素。您能够应用 Amazon CloudWatch 指标来检测操作强度的变动，并在读取或写入操作类别中对这种稳定进行分类。
如果网络利用率的进步源自读取操作，请首先确保应用所有现有读取正本解决读取操作。您能够在配置禁用集群模式下对 Redis 客户端库中应用 ElastiCache 读取器端点，也能够在启用集群模式下应用 Redis READONLY 命令。如果您曾经在读取正本中执行读取操作，则能够在正本组或分片当增加更多节点（最多反对五个读取正本）。
如果网络利用率进步源自写入操作，则须要为主节点增加更多容量。在禁用集群模式的场景下，您能够间接将主节点扩大为更大的节点类型。在启用集群模式时，同样能够执行这一纵向扩大操作。
另外，启用集群模式时，您还能够应用另外一种读取及写入用例扩容办法。此办法将增加更多分片并执行横向扩大，确保每个节点只负责数据集中的局部较小子集，由此保障每个节点的网络利用率放弃在较低水平。
只管横向扩大可能解决大部分网络相干问题，但这里还是要探讨几种对于高热度键的极其状况。所谓高热度键，是指拜访特地频率、远超失常比例的特定键或键子集，因而导致繁多分片可能须要接受高于其余分片的流量规模。如果这些键保留在同一分片上，则会带来很高的网络利用率。在这类常见示例中，如果不变更现有数据集，则向上扩大办法往往比拟实用。当然，您也能够重构数据模型以从新平衡网络利用率。例如，您能够复制字符串并拆分存储有多个元素的对象。
连贯
Amazon CloudWatch 为构建集群连贯提供两项指标：
- CurrConnections – Redis 引擎所注册的并发连贯及流动连接数。此指标派生自 Redis INFO 命令中的 connected_clients 属性。
- NewConnections – 在特定时段内，Redis 已承受的连贯总数，包含所有处于活动状态及敞开状态的连贯。此指标同样源自 Redis INFO 命令。
要监控连贯，咱们次要须要关注 Redis 中的 maxclients 限度指标。Amazon ElastiCache 为该指标设定的默认值为 65000。换句话说，每个节点最多能够应用 65000 个并发连贯。
CurrConnections 与 NewConnections 指标均可帮忙检测并预防性能问题。例如，CurrConnections 的一直减少可能疾速耗尽 65000 个可用连贯。这类指标减少可能示意应用程序端呈现了问题，且连贯未能正确敞开，因而最终还是在服务器端占用了连贯。除了考察应用程序的行为以解决问题之外，您也能够在集群中应用 tcp-keepalive 以检测并终止潜在的死对等连贯。在 Redis 3.2.4 及更高版本中，默认的 tcp-keepalive 计时器时长为 300 秒。对于旧版本，默认状况下禁用 tcp-keepalive。您能够在集群的参数组中调整 tcp-keepalive 计时器。
对 NewConnections 的监控同样十分重要。请留神，最大客户端限度 65000 不适用于此指标，因为其掂量的是指定工夫内创立的连贯总数，而各项连贯之间并不一定同时产生。在 1 分钟的数据采样期间，一个节点可能会收到 10 万个 NewConnections，但从未达到 2000 个 CurrConnections（同时连贯）。在此特定示例中，工作负载并未达到 Redhis 须要染指的连贯限度危险。然而期间产生的大量连贯疾速开启及敞开同样可能会影响到节点性能。创立 TCP 连贯须要消耗几毫秒工夫，这也属于应用程序在运行 Redis 操作时经常出现的额定有效载荷。
依据最佳实际的要求，应用程序应尽可能复用现有连贯，以防止创立新连贯并造成额定老本。您能够通过 Redis 客户端库（如果反对）应用适宜以后应用程序环境的框架以建设连接池，也能够亲手入手从零开始创立连接池。
更重要的是，因为 TLS 握手会带来额定的工夫与 CPU 使用率，因而在集群内应用 Amazon ElastiCache 传输加密性能时，请关注对新连贯数量的管制。
复制
如果存在至多一个读取正本，则主节点须要向读取节点发送复制命令流。通过 ReplicationBytes 指标，您能够看到须要复制的数据量。只管此指标代表正本组上的写入负载，但无奈帮忙咱们理解正本运行状况的具体见解。为此，您能够应用 ReplicationLag 指标。此指标提供一项十分便捷的示意模式，用以体现正本与主节点之间的提早。从 Redis 5.0.6 版本开始，此指标数据将以毫秒为单位进行捕获。只管比拟常见，但您能够通过监控 ReplicationLag 指标以检测潜在的问题，其中复制滞后的峰值将表明主节点或正本无奈及时处理复制操作。一旦产生这类状况，您可能须要对正本执行齐全同步。齐全同步代表更为简单的过程，须要在主节点上创立快照，并可能导致性能降落。您能够将 ReplicationLag 指标与 SaveInProgress 指标确定齐全同步尝试。
重大的复制滞后趋势，往往源自写入操作过多、网络容量耗尽或者根底服务降级等问题。
对于禁用集群模式的繁多主节点，如果您的写入流动强度过高，则须要思考启用集群模式，借此将写入操作扩散到多个分片及其关联的主节点之上。如果复制滞后源自网络容量耗尽，则请参考本文“网络”局部的步骤进行操作。
提早
您能够应用一组 Amazon CloudWatch 指标来掂量命令的提早，通过这些指标为每种数据结构计算总提早。您能够应用 Redis INFO 命令中的 commandstats 统计信息计算出这项后果。
在以下图表中，咱们能够看到 StringBasedCmdsLatency 指标，代表的是特定工夫范畴之内运行的、基于字符串的命令的均匀提早（以微秒为单位）。
此提早不蕴含网络与 I/O 工夫，这些属于 Redis 解决操作时消耗的工夫。
如果 Amazon CloudWatc h 指标批示出特定数据结构的提早有所增加，则能够应用 Redis SLOWLOG 来确定哪些具体命令的运行工夫较长。
如果您的应用程序遇到高提早，但 Amazon CloudWatch 指标批示 Redis 引擎级提早很低，则应次要关注网络提早。Redis CLI 提供一款提早监控工具，实用于以隔离形式考察网络或应用程序问题（min , max 以及 avg 皆以毫秒为单位）：
$ redis-cli –latency-history -h mycluster.6advcy.ng.0001.euw1.cache.amazonaws.commin: 0, max: 8, avg: 0.46 (1429 samples) — 15.01 seconds rangemin: 0, max: 1, avg: 0.43 (1429 samples) — 15.01 seconds rangemin: 0, max: 10, avg: 0.43 (1427 samples) — 15.00 seconds rangemin: 0, max: 1, avg: 0.46 (1428 samples) — 15.00 seconds range
min: 0, max: 9, avg: 0.44 (1428 samples) — 15.01 seconds range
最初，您还能够监控客户端当中是否存在可能影响应用程序性能、或者导致解决工夫减少的流动。
Amazon ElastiCache 事件与 Amazon SNS
与您资源相干的各类 Amazon ElastiCache 日志事件（包含故障转移、扩大操作、打算内保护等），皆蕴含日期与工夫、源名称、源类型以及形容。您能够在 Amazon ElastiCache 管制台上、应用 Amazon 命令行界面（Amazon CLI）的 describe-events 命令以及 Amazon ElastiCache API 轻松拜访这类事件。
监控事件能够帮忙您随时理解集群的以后状态，并依据事件采取必要的措施。只管 Amazon ElastiCache 事件能够通过多种形式获取，但咱们强烈建议您在 Amazon ElastiCache 配置中应用 Amazon Simple Notification Service (Amazon SNS) 发送重要的事件告诉。
在将 Amazon SNS 主题增加至 Amazon ElastiCache 集群中时，与此集群相干的所有重要事件都将被公布至 Amazon SNS 主题当中，并可通过电子邮件进行发送。
在配合集群应用 Amazon SNS 时，您还能够通过编程形式对 ElastiCache 事件采取措施。例如，Amazon Lambda 函数能够订阅 Amazon SNS 主题并在检测到特定事件时主动运行。
总结
在本文中，咱们探讨了 Amazon ElastiCache Redis 资源监控方面的常见挑战与相干最佳实际。借助本文中提到的常识，您当初能够轻松检测、诊断并保护 Amazon ElastiCache Redis 资源。
本篇作者
Yann Richard
Amazon ElastiCache 解决方案架构师
他的集体指标是在次毫秒级内实现数据传输，并在 4 小时之内实现马拉松。