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

使用 Redis Enterprise 进行监控和可观测性

简介

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

下面的截图显示了一个节点的相关统计信息仪表盘：

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

核心集群资源包括

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

关键数据库性能指标包括

• 延迟
• 缓存命中率
• 键逐出率
• 代理性能

显示集群指标概览的仪表盘：

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

核心集群资源监控

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

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

如果您已经在使用现有的抓取端点进行集成，请按照本指南进行过渡并试用新引擎。您可以同时抓取现有和新的端点，这使您能够创建高级仪表盘并顺利过渡。

内存

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

显示高级集群指标的仪表盘 - 集群仪表盘

阈值

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

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

缓存工作负载

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

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

虽然您的 Redis 数据库在缓存场景中使用了 100% 的可用内存，但监控性能仍然很重要。关键性能指标包括

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

读延迟

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

• 在 Redis 本身的环境中，延迟是 Redis 响应请求所需的时间。下面的延迟部分对此指标进行了更广泛的讨论。

• 在您的应用程序环境中，延迟是 应用程序处理请求所需的时间。这包括执行 Redis 读写以及调用其他数据库和服务所需的时间。请注意，即使 Redis 报告低延迟，应用程序也可能遇到高延迟。这可能表明缓存命中率低，最终原因是内存不足。

您需要同时监控应用程序级别和 Redis 级别的延迟，以诊断生产环境中的缓存性能问题。

缓存命中率和逐出

缓存命中率是 Redis 成功服务的读取请求的百分比。逐出率是 Redis 从缓存中逐出键的速度。这些指标有时呈负相关：如果逐出了太多常用键，高逐出率可能会导致低缓存命中率。

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

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

当工作集无法适应内存时，逐出策略将开始逐出键。重要的是选择一个通常逐出很少使用的键的策略，以使缓存命中率尽可能高。

在这两种情况下，键都可能被应用程序手动失效，或通过使用 TTL（生存时间）和逐出策略进行逐出。

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

这意味着当您的 Redis 数据库使用了 100% 的可用内存时，您需要衡量键逐出的速度。

可接受的键逐出率取决于数据库中的键总数和应用程序级延迟的衡量。如果应用程序延迟较高，请检查键逐出是否没有增加。

逐出策略

逐出策略指南

• 当您期望请求的流行度呈幂律分布时，请使用 allkeys-lru 策略。也就是说，您期望一小部分元素将被访问的频率远高于其余元素。如果您不确定，这是一个很好的选择策略。

• 如果您有循环访问（其中所有键都被连续扫描）或当您期望分布均匀时，请使用 allkeys-random 策略。

• 如果您希望通过在创建缓存对象时使用不同的 TTL 值来向 Redis 提供关于哪些键是过期好候选者的提示，请使用 volatile-ttl 策略。

volatile-lru 和 volatile-random 策略主要适用于您希望使用单个实例进行缓存并拥有一组持久化键的情况。但是，通常更好的做法是运行两个 Redis 实例来解决此类问题。

注意：为键设置 expire 值会消耗内存，因此使用 allkeys-lru 等策略更省内存，因为在内存压力下逐出键时无需配置 expire。

非缓存工作负载

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

故障排除

CPU

Redis Enterprise 提供几个 CPU 指标

为了理解 CPU 指标，回顾一下 Redis Enterprise 集群是如何组织的很有帮助。集群由一个或多个节点组成。每个节点是一个虚拟机（或云计算实例）或物理服务器。

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

在仪表盘中，分片 CPU 是组成数据库的进程的 CPU 利用率。诊断性能问题时，请首先查看分片 CPU。

显示 CPU 使用情况的仪表盘 - 数据库仪表盘

阈值

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

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

显示代理 CPU 使用情况 - 代理仪表盘

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

显示节点 CPU 使用数据集合的仪表盘 - 节点仪表盘

节点 CPU 也应保持在总容量的 80% 以下。与代理一样，节点 CPU 根据节点的 CPU 容量而变化。您需要根据节点中的核心数校准警报。

故障排除

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

连接

Redis Enterprise 数据库仪表盘显示了数据库的总连接数。

监控此连接数指标时，应考虑最小和最大连接数。根据连接到 Redis 的应用程序实例数量（以及应用程序是否使用连接池），您应该大致了解给定数据库的预期最小和最大连接数。此数字应随时间保持相对稳定。

故障排除

显示连接数的仪表盘 - 数据库仪表盘

网络入流量/出流量

网络入流量/出流量面板显示发送到数据库和从数据库接收的数据量。网络流量的大幅峰值可能表明集群配置不足，或者应用程序正在读取和/或写入异常大键。高网络流量与高 CPU 利用率之间的关联可能表明存在大键场景。

数据库端点不平衡

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

一种解决方案是使用最优的分片放置和代理策略，确保端点与主分片所在的节点位于同一位置。如果需要恢复平衡（例如，节点故障后），可以使用 rladmin 命令行工具手动执行分片故障转移。

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

同步

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

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

为了实现参与集群之间的一致性，Redis Active-Active 同步使用一个称为 syncer 的进程。

syncer 维护一个复制积压日志，其中存储 syncer 发送给其他参与集群的数据集更改。syncer 使用部分同步使副本与更改保持同步，或者在副本或主节点丢失时执行完全同步。

显示区域间连接指标的仪表盘 - 同步仪表盘

与其他的地理分布式解决方案相比，CRDT 提供了三个基本优势

• 它在读写操作上提供本地延迟，而无论地理复制区域的数量及其相互之间的距离如何。
• 它实现了对简单和复杂数据类型（如 Redis 核心数据类型）的无缝冲突解决（“无冲突”）。
• 即使 CRDT 数据库中的大多数地理复制区域（例如，5 个中的 3 个）发生故障，剩余的地理复制区域也能不受干扰地继续处理读写操作，确保业务连续性。

数据库性能指标

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

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

延迟

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

配置充足、运行高效 Redis 操作的 Redis 数据库平均延迟将低于 1 毫秒。实际上，通常以微秒为单位测量延迟。企业经常实现，有时也要求达到 400-600 微秒的平均延迟。

显示延迟指标的仪表盘 - 数据库仪表盘

这些指标区分了读延迟和写延迟。了解高延迟是由读还是写引起的可以帮助您隔离底层问题。

请注意，这些延迟指标不包括网络往返时间或应用程序级序列化，因此在应用程序端也测量请求延迟至关重要。

显示延迟明显峰值

故障排除

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

缓存命中率

缓存命中率是所有返回响应的读操作的百分比。注意：缓存命中率是一个复合统计量，通过将读取命中的次数除以总读取操作次数来计算。当应用程序尝试读取一个存在的键时，这称为缓存命中。反之，当应用程序尝试读取一个不存在的键时，这称为缓存未命中。

对于缓存工作负载，缓存命中率通常应高于 50%，尽管具体的理想缓存命中率会根据应用程序以及缓存是否已填充而差异很大。

显示缓存命中率以及读/写未命中的仪表盘 - 数据库仪表盘

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

故障排除

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

高或不断增加的逐出率将对数据库延迟产生负面影响，特别是如果必要键逐出的速度超过了新键插入的速度。

有关缓存命中率故障排除的提示，请参阅缓存命中率和逐出部分。

键逐出率

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

显示对象驱逐的仪表盘 - 数据库仪表盘

代理性能

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 命令几乎不应在生产系统上运行，因为在大型 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 的操作来识别热键。您可以通过对高 CPU 分片运行 MONITOR 命令来完成此操作。由于这可能是一个影响很大的操作，您应仅将其作为备选方案。对于任务关键型数据库，请考虑联系 Redis 支持寻求帮助。

解决方案

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

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

大键

大键是指数百千字节或更大的键。高网络流量和高 CPU 利用率可能由大键引起。

故障排除

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

对您的数据库运行 redis-cli --memkeys，以实时采样键空间并可能识别数据库中的最大键。

解决方案

解决大键问题需要首先了解应用程序创建大键的原因。因此，很难为此问题提供通用建议。解决通常需要更改应用程序的数据模型或其与 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. 经典仪表盘提供有关集群、节点和单个数据库的详细信息。
2. 基本仪表盘提供各种集群组件的高级概述。
3. 扩展仪表盘。这些需要第三方库来执行 ReST 调用。

还有两个 Redis Enterprise software 的工作流仪表盘，提供钻取功能。

软件

• 基本
• 扩展
• 经典

工作流

• 数据库
• 节点

云

• 基本
• 扩展

注意： - “工作流”仪表盘旨在作为一个软件包使用。因此应全部安装，因为它们包含指向组中其他仪表盘的链接，以便在概览视图和钻取视图之间快速导航。