Redis Enterprise Software 可观测性和监控指南

在 Redis Enterprise 中使用监控和可观测性

介绍

本文档为运行应用程序的开发人员提供了可观测性和监控指导 连接到 Redis Enterprise。本指南特别侧重于系统 以及最有可能影响应用程序性能的资源。

下面的屏幕截图显示了一个控制面板，其中包含节点的相关统计数据：

要有效地监控 Redis Enterprise 集群，您需要观察 核心集群资源和关键数据库性能指标，如本指南的以下部分所述。

核心集群资源包括：

• 内存利用率
• CPU 利用率
• 数据库连接
• 网络流量
• 同步

关键数据库性能指标包括：

• 延迟
• 缓存命中率
• 密钥驱逐率
• 代理性能

显示集群指标概览的控制面板：

除了手动监控这些资源和指标外，最佳实践是设置警报。

核心集群资源监控

Redis Enterprise 版本 7.8.2 引入了新指标流引擎的预览版，该引擎在https://<IP>:8070/v2.这个新引擎使用 Prometheus 将所有时间序列指标导出到外部监控工具，例如 Grafana、DataDog、NewRelic 和 Dynatrace。

新引擎支持实时监控，包括维护作期间的全面监控，从而在分片故障转移和扩展作等事件期间提供对性能的全面可见性。有关更多详细信息，请参阅使用指标和警报进行监控。

如果您已经在使用现有的抓取终端节点进行集成，请按照本指南进行过渡并尝试新引擎。您可以同时抓取现有终端节点和新终端节点，从而创建高级控制面板并顺利过渡。

记忆

每个 Redis Enterprise 数据库都有一个最大配置的内存限制，以确保隔离 在多数据库集群中。

显示高级集群指标的控制面板 - Cluster Dashboard

阈 值

适当的内存阈值取决于应用程序使用 Redis 的方式。

• 允许 Redis 逐出键的缓存工作负载可以安全地使用 100% 的可用内存。
• 非缓存工作负载不允许键逐出，一旦内存使用率达到 80%，就应立即密切监控。

缓存工作负载

对于仅将 Redis 用作缓存的应用程序，您可以安全地让内存使用 只要您制定了驱逐政策，就可以达到 100%。这将确保 Redis 可以在继续接受新写入的同时驱逐键。

注意：驱逐将增加写入命令延迟，因为 Redis 必须在接受新的写入之前清理内存/对象，以防止在内存使用率为 100% 时出现 OOM。

当您的 Redis 数据库在缓存上下文中使用 100% 的可用内存时， 监控性能仍然很重要。关键绩效指标包括：

• 延迟
• 缓存命中率
• 逐出的键

读取延迟

延迟有两个重要的定义，具体取决于上下文：

• 在 Redis 本身的上下文中，延迟是 Redis 所需的时间 以响应请求。下面的 Latency （延迟） 部分提供了对此指标的更广泛讨论。

• 在应用程序的上下文中，Latency 是应用程序所花费的时间 以处理请求。这将包括执行读取和写入所花费的时间 到 Redis，以及调用其他数据库和服务。请注意，它可能适用于 Redis 报告低延迟，而应用程序遇到高延迟。 这可能表示缓存命中率低，最终是由内存不足引起的。

您需要监控应用程序级和 Redis 级延迟以进行诊断 在生产环境中缓存性能问题。

缓存命中率和驱逐

缓存命中率是 Redis 成功提供的读取请求的百分比。Eviction rate （驱逐率） 是 Redis 从缓存中驱逐键的速率。这些指标 有时是负相关的：如果驱逐太多常用的 key，高驱逐率可能会导致低缓存命中率。

如果 Redis 服务器为空，则命中率为 0%。当应用程序运行并填充缓存时， 命中率将增加。

当整个缓存的工作集适合内存时，缓存命中率将接近 100% 而已用内存的百分比将保持在 100% 以下。

当 working set 无法放入内存时，驱逐策略将开始驱逐 key。 选择一个通常驱逐很少使用的 key 的策略以尽可能保持较高的缓存命中率非常重要。

在这两种情况下，密钥都可能由应用程序手动失效或通过 TTL （生存时间） 和驱逐策略的使用。

理想的缓存命中率取决于应用程序，但通常，该比率应大于 50%。 低命中率加上大量对象驱逐可能表明您的缓存太小。 这可能会导致应用程序端出现抖动，即缓存不断失效的情况。

这意味着，当您的 Redis 数据库使用 100% 的可用内存时，您需要 来衡量密钥驱逐的比率。

可接受的键驱逐率取决于数据库中的键总数 以及应用程序级延迟的度量。如果应用程序延迟较高， 检查键逐出是否未增加。

驱逐策略

驱逐策略准则

• 当您期望请求的受欢迎程度出现幂律分布时，请使用 allkeys-lru 策略。也就是说，您预计元素子集的访问频率远高于其余元素子集。如果您不确定，这是一个很好的选择策略。

• 如果您具有连续扫描所有键的循环访问，或者您希望分布是均匀的，请使用 allkeys-random。

• 如果您希望在创建缓存对象时能够使用不同的 TTL 值向 Redis 提供有关哪些是适合过期的候选对象的提示，请使用 volatile-ttl。

volatile-lru 和 volatile-random 策略主要在您希望将单个实例用于缓存并拥有一组持久密钥时有用。但是，运行两个 Redis 实例来解决此类问题通常是一个更好的主意。

注意：将过期值设置为密钥会消耗内存，因此使用像 allkeys-lru 这样的策略内存效率更高，因为在内存压力下不需要过期配置来驱逐密钥。

非缓存工作负载

如果未启用驱逐策略，则当内存使用率达到 100% 时，Redis 将停止接受写入。 因此，对于非缓存工作负载，最佳实践是将警报配置为内存使用率为 80%。 在数据库达到此 80% 阈值后，您应该仔细检查内存使用增长率。

故障 排除

中央处理器

Redis Enterprise 提供了几个 CPU 指标：

要了解 CPU 指标，有必要回顾一下 Redis Enterprise 集群的组织方式。 集群由一个或多个节点组成。每个节点都是一个 VM（或云计算实例）或 裸机服务器。

数据库是跨集群节点部署的一组进程，称为分片。

在控制面板中，分片 CPU 是组成数据库的进程的 CPU 利用率。 在诊断性能问题时，请先查看分片 CPU。

显示 CPU 使用率的控制面板 - Database Dashboard

阈 值

通常，我们将高 CPU 定义为超过总容量 80% 的任何 CPU 利用率。

分片 CPU 应保持在 80% 以下。分片是单线程的，因此分片 CPU 为 100% 意味着分片已充分利用。

显示代理 CPU 使用率 - 代理控制面板

代理 CPU 应保持在总容量的 80% 以下。 代理是一个多线程进程，用于处理客户端连接并将请求转发到相应的分片。 由于代理线程的总数是可配置的，因此代理 CPU 可能会超过 100%。 配置了 6 个线程的代理可以达到 600% 的 CPU 利用率，因此在这种情况下， 将利用率保持在 80% 以下意味着将代理 CPU 总使用率保持在 480% 以下。

显示 Node CPU 使用率数据集合的仪表板 - Node Dashboard

节点 CPU 还应保持在总容量的 80% 以下。与代理一样，节点 CPU 是可变的，具体取决于 在节点的 CPU 容量上。您需要根据节点中的内核数量校准警报。

故障 排除

CPU 使用率高有多种可能的原因。常见原因包括集群预置不足、 过多的低效 Redis作和热主分片。

连接

Redis Enterprise 数据库控制面板指示与数据库的连接总数。

您应该在监控此连接计数指标时同时考虑最小和最大连接数。 根据连接到 Redis 的应用程序实例的数量（以及您的应用程序是否使用连接池）， 您应该大致了解您希望为任何给定数据库看到的最小和最大连接数。 随着时间的推移，这个数字应该保持相对恒定。

故障 排除

显示连接的控制面板 - 数据库控制面板

网络入口/出口

网络入口/出口面板显示发送到数据库和从数据库接收的数据量。 网络流量的大幅峰值可能表明集群预置不足，或者 应用程序正在读取和/或写入异常大的密钥。高网络流量之间的相关性 CPU 使用率高可能表示 key 方案较大。

不平衡的数据库终端节点

网络流量峰值的一个可能原因是数据库终端节点与主分片不位于同一节点上。除了增加网络延迟之外，如果启用了数据平面节点间加密，CPU 消耗也会增加。

一种解决方案是使用最佳分片放置和代理策略来确保终端节点并置在托管主分片的节点上。如果您需要恢复平衡（例如，在节点发生故障后），您可以使用rladminCLI 工具。

极端的网络流量利用率可能接近底层网络基础设施的限制。 在这种情况下，唯一的补救措施是向集群添加更多节点，并在这些节点之间扩展数据库的分片。

同步

在 Redis Enterprise 中，地理分布式同步基于无冲突复制数据类型 （CRDT） 技术。 CRDT 的 Redis Enterprise 实现称为主动-主动数据库（以前称为 CRDB）。 使用主动-主动数据库，应用程序可以从不同的地理位置无缝、低延迟地读取和写入同一数据集，而无需更改应用程序连接到数据库的方式。

主动-主动架构是一种数据弹性架构，它使用独立且地理位置分散的集群和节点将数据库信息分布在多个数据中心。 它是一个由独立处理节点组成的网络，每个节点都可以访问一个通用的复制数据库，以便所有节点都可以参与一个通用的应用程序，确保本地低延迟，每个区域都能够独立运行。

为了实现参与集群之间的一致性，Redis 主动-主动同步使用称为同步器的过程。

同步器保留一个复制积压，该积压存储对 syncer 发送到其他参与集群的数据集的更改。 同步器使用部分同步来使副本与更改保持同步，或者在副本或主副本丢失时进行完全同步。

显示区域之间的连接指标的控制面板 - 同步控制面板

与其他异地分布式解决方案相比，CRDT 具有三个基本优势：

• 它在读取和写入作时提供本地延迟，而不管异地复制区域的数量及其彼此之间的距离如何。
• 它支持简单和复杂数据类型（如 Redis 核心）的无缝冲突解决（“无冲突”）。
• 即使 CRDT 数据库中的大多数异地复制区域（例如，5 个中的 3 个）已关闭，其余的异地复制区域也不会中断，并且可以继续处理读取和写入作，从而确保业务连续性。

数据库性能指标

有几个关键性能指标可以针对应用程序的工作负载报告数据库的性能：

• 延迟
• 缓存命中率
• 密钥驱逐率

延迟

延迟是 Redis 响应请求所需的时间。 Redis Enterprise 测量从代理接收的第一个字节到命令响应中发送的最后一个字节的延迟。

运行高效 Redis作的充分预置的 Redis 数据库将报告低于 1 毫秒的平均延迟。事实上，衡量 以微秒为单位的延迟。企业经常达到（有时需要）400-600 的平均延迟 微秒。

延迟指标的控制面板显示 - Database Dashboard

这些指标区分读取延迟和写入延迟。了解是否由于高延迟 读取或写入可以帮助您隔离潜在问题。

请注意，这些延迟指标不包括网络往返时间或应用程序级序列化。 这就是为什么在应用程序中测量请求延迟也很重要的原因。

显示屏显示延迟明显激增

故障 排除

以下是导致数据库延迟较高的一些可能原因。请注意，高数据库延迟只是原因之一 为什么应用程序延迟可能很高。应用程序延迟可能由多种因素引起，包括 缓存命中率低。

缓存命中率

缓存命中率是返回响应的所有读取作的百分比。注意：缓存命中率是一个复合统计数据，计算方法是将读取命中数除以读取作总数。 当应用程序尝试读取存在的键时，这称为缓存命中。 或者，当应用程序尝试读取不存在的键时，这称为缓存未命中。

对于缓存工作负载，缓存命中率通常应高于 50%，但 确切的理想缓存命中率可能会因应用程序以及缓存是否 已填充。

显示缓存命中率以及读/写未命中数的控制面板 - Database Dashboard

注意：Redis Enterprise 实际上报告了四种不同的缓存命中/未命中指标。 这些定义如下：

故障 排除

缓存命中率通常仅与缓存工作负载相关。在数据库接近其最大内存容量后，将开始逐出。

高驱逐率或不断增加的驱逐率将对数据库延迟产生负面影响，尤其是 如果必要的密钥驱逐的速率超过新密钥插入的速率。

请参阅 缓存命中率和驱逐 部分，了解有关缓存命中率问题排查的提示。

密钥驱逐率

键驱逐率是从数据库中驱逐对象的速率。 有关键驱逐及其与内存使用情况的关系的讨论，请参阅驱逐策略。

显示对象逐出的仪表板 - Database Dashboard

代理性能

Redis Enterprise Software 通过代理进程提供高性能数据访问，该进程管理和优化对集群内分片的访问。每个节点都包含一个代理进程。每个代理可以是主动代理并接收传入流量，也可以是被动代理并等待故障转移。

代理策略

显示代理线程活动的仪表板 - 代理线程仪表板

如果需要，可以使用rladmin tune proxy命令使代理使用更多的 CPU 核。 代理使用的核心将不可用于 Redis，因此我们需要考虑主机上的 Redis 节点数和可用核心的总数。

该命令包含一些参数，您可以使用这些参数来设置新的代理核心数：

• id|all- 您可以按 ID 或所有代理调整特定代理。

• mode- 确定代理是否可以根据负载自动调整线程数。

• threads和max_threads- 确定启动时创建的初始线程数以及允许的最大线程数。

• scale_threshold- 确定触发生成新线程的 CPU 利用率阈值。在执行自动扩展之前，此 CPU 利用率水平需要保持至少 scale_duration 秒。

下表显示了指定环境的理想代理线程计数。

数据访问反模式

有三种数据访问模式可能会限制 Redis 数据库的性能：

• 运行缓慢
• 热键
• 大键

本节定义了这些模式中的每一种，并介绍了如何诊断和缓解它们。

运行缓慢

慢速作是指完成时间超过几毫秒的作。

并非所有 Redis作都具有相同的效率。 最有效的 Redis作是 O（1）作;也就是说，它们具有恒定的时间复杂度。 此类作的示例包括 GET、SET、SADD、 和 HSET。

这些恒定时间作不太可能导致高 CPU 利用率。注意：虽然如此 高速率的恒定时间作仍有可能使预置不足的数据库不堪重负。

其他 Redis作表现出更高的时间复杂度。 O（n） （线性时间）作更可能导致高 CPU 利用率。 示例包括 HGETALL、SMEMBERS 和 LREM。 这些作不一定有问题，但如果针对持有 大量元素（例如，包含 100 万个元素的列表）。

但是，KEYS 命令几乎永远不应该针对 production 系统，因为返回大型 Redis 数据库中所有键的列表可能会导致速度明显变慢 并阻止其他作。如果您需要扫描密钥空间，尤其是在生产集群中，请始终改用 SCAN 命令。

故障 排除

发现慢速作的最佳方法是查看慢速日志。 Redis Enterprise 和 Redis Cloud 控制台中提供了慢日志：

• Redis Enterprise 慢日志文档
• Redis Cloud 慢日志文档

Redis Cloud 控制面板显示数据库作缓慢

热键

热键是访问频率极高的键（例如，每秒数千次或更多次）。

Redis 中的每个键都属于一个分片，且仅属于一个分片。 因此，热键可能会导致该分片上的高 CPU 利用率。 这可能会增加所有其他作的延迟。

故障 排除

如果您在单个分片上看到 CPU 利用率较高，您可能会怀疑您有热键。 识别热键有两种主要方法：使用 Redis CLI 和针对 Redis 对作进行采样。

要使用 Redis CLI 识别热键，请执行以下作：

1. 首先确认您有足够的可用内存来启用驱逐策略。
2. 接下来，在数据库上启用 LFU（最不常用）逐出策略。
3. 最后，运行redis-cli --hotkeys

您还可以通过对 Redis 的作进行采样来识别热键。 您可以通过运行 MONITOR 命令来执行此作 针对高 CPU 分片。由于这是一项可能影响较大的作，因此您只应 将此技术用作辅助选项。对于任务关键型数据库，请考虑 联系 Redis 支持寻求帮助。

修复

发现热键后，您需要找到一种方法来减少针对它的作数量。 这意味着要了解应用程序的访问模式以及如此频繁访问的原因。

如果热键作是只读的，请考虑实现应用程序本地缓存，以便 发送到 Redis 的读取请求更少。例如，即使是每 5 秒过期一次的本地缓存 可以完全消除热键问题。

大键

大密钥是数百 KB 或更大的密钥。 高网络流量和高 CPU 利用率可能是由大 key 引起的。

故障 排除

要识别大键，您可以使用 Redis CLI 对键空间进行采样。

跑redis-cli --memkeys针对您的数据库对 KeySpace 进行实时采样 并可能识别数据库中最大的键。

修复

解决大密钥问题需要了解应用程序首先创建大密钥的原因。 因此，很难提供解决此问题的一般性建议。解决方法通常需要更改 到应用程序的数据模型或它与 Redis 的交互方式。

提醒

Redis Enterprise 可观测性软件包包括一套用于 Prometheus 的警报及其相关测试。注意：并非所有警报都适合所有环境;例如，不使用持久性的安装不需要存储警报。

警报与一系列测试打包在一起，用于验证各个触发器。您可以使用这些测试来验证针对特定环境和使用案例对这些警报的修改。

要使用这些警报，请安装 Prometheus Alertmanager。 有关使用 Prometheus 和 Grafana 发出警报的综合指南， 请参阅有关该主题的 Grafana 博客文章。

配置 Prometheus

要配置 Prometheus 进行警报，请打开prometheus.yml配置文件。

取消注释Alertmanager部分。 以下配置启动 Alertmanager 并指示它监听其默认端口 9093。

# Alertmanager configuration
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093

配置文件的 Rule file 部分指示 Alertmanager 读取特定的规则文件。 如果您将alerts.yml文件转换为/etc/prometheus那么需要以下配置。

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  - "error_rules.yml"
  - "alerts.yml"

完成此作后，重新启动 Prometheus。

内置配置error_rules.yml，只有一个警报：Critical Connection Exception。 如果您打开 Prometheus 控制台（默认位于端口 9090），然后选择 Alert 选项卡， 您将看到此警报，以及您作为规则文件包含的任何其他文件中的警报。

以下是alerts.yml文件。有几点需要考虑：

• 并非所有 Redis Enterprise 部署都会导出所有指标
• 大多数指标仅在指定的触发器持续给定持续时间时发出警报

警报列表

附录 A：Grafana 仪表板

Grafana 控制面板可用于 Redis Enterprise Software 和 Redis Cloud 部署。

这些仪表板有三种样式，可以一起使用以提供 部署的完整图片。

1. Classic 控制面板提供有关集群、节点和单个数据库的详细信息。
2. 基本仪表板提供了各种集群组件的高级概述。
3. 扩展仪表板。这些需要第三方库来执行 ReST 调用。

Redis Enterprise 软件还有两个工作流控制面板，它们提供向下钻取功能。

软件

• 基本
• 扩展
• 经典

工作流

• 数据库
• 节点

云

• 基本
• 扩展

注意： - “工作流”仪表板旨在用作包。因此，它们都应该安装，因为它们包含指向组中其他仪表板的链接，允许在概览和向下钻取视图之间快速导航。