共计 6083 个字符，预计需要花费 16 分钟才能阅读完成。
什么是 Redis
Redis 是一种风行的内存键 / 值数据存储。Redis 以其杰出的性能和简略的入门而闻名，已在各个行业中找到了用处，包含：
- 数据库：只管能够应用异步磁盘持久性，但 Redis 能够用持久性来换取速度，而不是传统的基于磁盘的数据库。Redis 提供了丰盛的数据原语集和异样丰盛的命令列表。
- 邮件队列：Redis 的阻止列表命令和低提早使其成为邮件代理服务的良好后端。
- 内存缓存：可配置的密钥发出策略，包含风行的“最近起码应用”策略以及从 Redis 4.0 开始的“起码常常应用”策略，使 Redis 成为缓存服务器的绝佳抉择。与传统的缓存不同，Redis 还容许长久化磁盘以进步可靠性。
Redis 是收费的凋谢源代码产品。提供商业反对，以及齐全托管的 Redis 即服务。
Redis 被许多高流量的网站和应用程序所采纳，例如 Twitter，GitHub，Docker，Pinterest，Datadog 和 Stack Overflow。
要害 Redis 指标
监督 Redis 能够帮忙您在两个方面发现问题：Redis 自身的资源问题以及反对基础架构中其余中央呈现的问题。
在本文中，咱们具体介绍了以下每个类别中最重要的 Redis 指标：
- 性能指标
- 内存指标
- 根本流动指标
- 持续性指标
- 谬误指标
性能指标
除低错误率外，良好的性能是零碎运行状况的最佳顶级指标之一。如内存局部中所述，性能不佳通常是由内存问题引起的。
告警指标：latency
提早是对客户端申请和理论服务器响应之间的工夫的度量。跟踪提早是检测 Redis 性能变动的最间接办法。因为 Redis 具备单线程个性，因而提早散布中的异样值可能会导致重大的瓶颈。一个申请的响应工夫过长会减少所有后续申请的等待时间。一旦确定提早是一个问题，就能够采取多种措施来诊断和解决性能问题。
观测指标：Instantaneous_ops_per_sec
跟踪已解决命令的吞吐量对于诊断 Redis 实例中高提早的起因至关重要。高提早可能是由许多问题引起的，从积压的命令队列到速度慢的命令，再到网络链路适度应用。您能够通过测量每秒解决的命令数来进行考察 - 如果该命令简直放弃不变，则起因不是计算密集型命令。如果一个或多个慢速命令引起提早问题，您将看到每秒的命令数量降落或齐全进行。与历史标准相比，每秒解决的命令数量降落可能是低命令量或阻塞零碎的慢命令的迹象。低命令量可能是失常景象，或者可能表明上游呈现问题。
指标：hit rate
将 Redis 用作缓存时，监督缓存命中率能够告诉您缓存是否失去无效应用。命中率低意味着客户端正在寻找不再存在的密钥。Redis 不间接提供命中率指标。咱们依然能够这样计算：
hit rate = keyspace_hits / (keyspace_hits + keyspace_misses)高速缓存命中率低可能是由多种因素引起的，包含数据到期和调配给 Redis 的内存不足（这可能会导致键退出）。低命中率可能会导致应用程序提早减少，因为它们必须从较慢的备用资源中获取数据。
内存指标
观测指标：used_memory
内存使用率是 Redis 性能的要害组成部分。如果 used_memory 超出了可用的零碎总内存，则操作系统将开始替换内存的旧 / 未应用局部。每个替换的局部都写入磁盘，从而重大影响性能。从磁盘写入或读取比从内存写入或读取要慢 5 个数量级（100,000x！）（内存为 0.1 µs，磁盘为 10 ms）。
您能够将 Redis 配置为限度在指定的内存量内。在 redis.conf 文件中设置 maxmemory 指令能够间接管制 Redis 的内存应用状况。启用 maxmemory 要求您为 Redis 配置驱赶策略，以确定开释内存的形式。在 evicted_keys 局部中理解无关配置 maxmemory-policy 指令的更多信息。
警报指标：mem_fragmentation_ratio
mem_fragmentation_ratio 度量规范提供了操作系统（used_memory_rss）所应用的内存与 Redis 调配的内存（used_memory）的比率。
mem_fragmentation_ratio = used_memory_rss / used_memory操作系统负责为每个过程调配物理内存。操作系统的虚拟内存管理器解决由内存分配器介导的理论映射。
这是什么意思？如果您的 Redis 实例的内存占用为 1GB，则内存分配器将首先尝试查找间断的内存段来存储数据。如果找不到间断的段，则分配器必须将过程的数据划分为多个段，从而减少内存开销。
跟踪碎片率对于理解 Redis 实例的性能十分重要。碎片率大于 1 示意正在产生碎片。比率超过 1.5 示意碎片过多，您的 Redis 实例耗费了其申请的物理内存的 150%。小于 1 的碎片率告诉您 Redis 须要的内存多于零碎上可用的内存，这导致替换。替换到磁盘将导致提早显着减少（请参阅已用内存）。现实状况下，操作系统将在物理内存中调配一个间断的段，其碎片率等于 1 或更大。
如果服务器的碎片率超过 1.5，重新启动 Redis 实例将容许操作系统复原以前因为碎片而无奈应用的内存。在这种状况下，将警报作为告诉可能就足够了。
然而，如果您的 Redis 服务器的碎片率低于 1，则可能须要作为页面收回警报，以便您能够疾速减少可用内存或缩小内存使用量。
从 Redis 4 开始，将 Redis 配置为应用随附的 jemalloc 正本时，能够应用新的被动碎片整顿性能。能够将该工具配置为在碎片达到肯定级别时启动，并开始将值复制到间断的内存区域中并开释旧正本，从而缩小服务器运行时的碎片。
警报指标：evicted_keys（仅高速缓存）
如果您将 Redis 用作缓存，则可能须要将其配置为在达到最大内存限度时主动革除密钥。如果您将 Redis 用作数据库或队列，则最好将其替换为逐出，在这种状况下，您能够跳过此指标。
跟踪密钥移出很重要，因为 Redis 会程序解决每个操作，这意味着逐出大量密钥会导致较低的命中率，从而导致更长的延迟时间。如果您应用的是 TTL，则可能不会心愿退出按键。在这种状况下，如果该指标始终大于零，则您的实例中的提早可能会减少。其余大多数不应用 TTL 的配置最终都会耗尽内存，并开始逐出密钥。只有您的响应工夫是能够承受的，稳固的驱赶率是能够承受的。
您能够应用以下命令配置密钥到期策略：
redis-cli CONFIG SET maxmemory-policy <policy>其中 policy 是下列之一：
- noeviction：当达到内存限度并且用户尝试增加其余键时，返回一个谬误
- volatile-lru：删除具备到期集的密钥中最近起码应用的密钥
- volatile-ttl：从具备到期集的密钥中删除残余生存工夫最短的密钥
- volatile-random：从具备到期集的密钥中删除一个随机密钥
- allkeys-lru：从所有密钥集中删除最近起码应用的密钥
- allkeys-random：从所有密钥集中删除一个随机密钥
- volatile-lfu：在 Redis 4 中增加、删除具备到期集的密钥中最不罕用的密钥
- allkeys-lfu：在 Redis 4 中增加、从所有密钥集中删除最不罕用的密钥
留神：因为性能起因，在应用 LRU，TTL 或 Redis 4（从 LUF 开始）策略时，Redis 实际上不会从整个键空间中进行采样。Redis 首先对密钥空间的一个随机子集进行采样，而后将逐出策略利用于该样本。通常，较新的（> = 3）版本的 Redis 采纳 LRU 采样策略，该策略更靠近于实在 LRU。LFU 策略能够通过设置例如以下内容来调整：设置我的项目必须通过多少工夫能力拜访级别升高的我的项目。无关更多详细信息，请参见 Redis 的文档。
观测指标：blocked_clients
Redis 提供了许多对列表进行操作的阻止命令。BLPOP，BRPOP 和 BRPOPLPUSH 别离是命令 LPOP，RPOP 和 RPOPLPUSH 的阻塞变体。当源列表为非空时，命令将按预期执行。然而，当源列表为空时，阻止命令将期待，直到源被填充或达到超时为止。
期待数据的被阻止客户端的数量减少可能是问题的征兆。提早或其余问题可能会阻止源列表的填写。只管阻止的客户端自身并不会引起警报，然而，如果您看到此指标始终为非零值，则应进行考察。
根本流动指标
留神：本节包含应用术语“主”和“从”的度量。除了援用特定的度量规范名称外，本文将其替换为“primary”和“replica”。
告警指标：connected_clients
因为对 Redis 的拜访通常是由应用程序介导的（用户通常不间接拜访数据库），因而在大多数状况下，所连贯客户端的数量会有正当的下限和上限。如果数字超出失常范畴，则可能表明存在问题。如果它太低，则上游连贯可能已失落；如果它太高，则大量并发客户端连贯可能会使服务器解决申请的能力不堪重负。
无论如何，客户端连贯的最大数量始终是无限的资源 - 无论是受操作系统，Redis 的配置还是网络限度。监督客户端连贯可帮忙您确保有足够的可用资源可用于新客户端或治理会话。
告警指标：connected_slaves
如果您的数据库是读取型数据库，则可能是在应用 Redis 中可用的主正本数据库复制性能。在这种状况下，监督连贯正本的数量是要害。如果连贯的正本数量意外更改，则可能表明主机已敞开或正本实例呈现问题。
留神：在上图中，Redis 主数据库将显示其具备两个连贯的正本，并且第一个子节点将各自报告它们也具备两个连贯的正本。因为辅助副本未间接连贯到 Redis 主正本，因而它们不包含在连贯到主正本的正本计数中。
告警指标：master_last_io_seconds_ago
应用 Redis 的复制性能时，正本实例会定期应用其主实例进行检入。长时间没有通信可能表明您的主 Redis 服务器，正本服务器或两者之间存在问题。您还冒着正本提供自上次同步以来可能已更改的旧数据的危险。因为 Redis 执行同步的形式，因而最小化主正本通信的中断至关重要。当正本在中断后从新连贯到主数据库时，它将发送 PSYNC 命令以尝试仅对中断期间失落的命令进行局部同步。如果无奈做到这一点，则正本将申请残缺的 SYNC，这将导致主正本立刻开始将数据库后盾保留到磁盘，同时缓冲收到的所有将批改数据集的新命令。后盾保留实现后，数据将与缓冲的命令一起发送到客户端。正本每次执行一次 SYNC 时，都会导致主实例的提早显着减少。
值得关注的指标：keyspace
跟踪数据库中键的数量通常是一个好主见。作为内存数据存储，键空间越大，Redis 须要更多的物理内存来确保最佳性能。Redis 将持续增加密钥，直到达到最大内存限度为止，此时，Redis 开始以新密钥以雷同的速率逐出密钥。
如果您将 Redis 用作缓存，并且看到键空间饱和（如上图所示）以及较低的命中率，则您的客户端可能会申请旧数据或发出的数据。随着工夫的推移跟踪您的 keyspace_misses 数量将有助于您查明起因。
另外，如果您将 Redis 用作数据库或队列，则可能不倡议应用易失性键。随着键空间的增长，如果可能的话，您可能须要思考在框内增加内存或在主机之间拆分数据集。增加更多的内存是一种简略无效的解决方案。当须要的资源超过一个框所能提供的资源时，能够通过对数据进行分区或分片来组合多台计算机的资源。有了分区打算，Redis 能够存储更多密钥而无需逐出或替换。然而，利用分区打算比在几个记忆棒中替换更具挑战性。
持续性指标
启用持久性可能是必要的，尤其是在应用 Redis 的复制性能的状况下。因为正本会自觉复制对主实例所做的任何更改，因而，如果要重新启动主实例（无持久性），则与其连贯的所有正本都将复制其当初为空的数据集。
如果您将 Redis 用作缓存或在用例中数据失落将不那么重要，则可能不须要持久性。
重要监督的指标：rdb_last_save_time 和 rdb_changes_since_last_save
通常，最好留神数据集的波动性。如果服务器产生故障，两次写入磁盘之间的工夫距离过长可能会导致数据失落。在上次保留工夫和故障工夫之间对数据集所做的任何更改都将失落。
监督 rdb_changes_since_last_save 可让您更深刻地理解数据的波动性。如果您的数据集在该距离内没有太大变动，则两次写入之间的长时间距离不成问题。跟踪两个指标能够使您很好地理解如果在给定的工夫点产生故障，您将失落多少数据。
谬误指标
留神：本节包含应用术语“主”和“从”的指标。除了援用特定的度量规范名称外，本文将其替换为“primary”和“replica”。
Redis 谬误指标能够提醒您异常情况。以下指标跟踪常见谬误：
主服务器和正本服务器之间的链接断开的工夫（以秒为单位）
Resource: Errors
告警指标：rejected_connections
Redis 可能解决许多流动连贯，默认状况下有 10,000 个客户端连贯可用。通过更改 redis.conf 中的 maxclient 指令，能够将最大连接数设置为其余值。如果您的 Redis 实例以后处于最大连接数，则任何新的连贯尝试都将断开。
请留神，您的零碎可能不反对您应用 maxclient 指令申请的连接数。Redis 与内核核查以确定可用文件描述符的数量。如果可用文件描述符的数量小于 maxclient + 32（Redis 保留 32 个文件描述符供本人应用），则将疏忽 maxclient 指令，并应用可用文件描述符的数量。
告警指标：keyspace_misses
每次 Redis 查找密钥时，只有两种可能的后果：密钥存在，或者密钥不存在。查找不存在的键会导致 keyspace_misses 计数器减少。此度量规范始终为非零值示意客户端正在尝试在数据库中查找不存在的键。如果未将 Redis 用作缓存，则 keyspace_misses 应该为零或靠近零。请留神，对空键调用的任何阻止操作（BLPOP，BRPOP 和 BRPOPLPUSH）都将导致 keyspace_misses 递增。
告警指标：master_link_down_since_seconds
仅当主节点及其正本之间的连贯失落时，此指标才可用。现实状况下，该值应永远不超过零 - 主数据库和正本数据库应放弃继续通信，以确保正本数据库不提供过期的数据。连贯之间的较大工夫距离应失去解决。请记住，从新连贯后，您的次要 Redis 实例将须要投入资源来更新正本上的数据，这可能会导致提早减少。
论断
在本文中，咱们提到了一些最有用的指标，您能够对其进行监控以在 Redis 服务器上保留标签。如果您刚开始应用 Redis，那么监督上面的列表中的指标将使您能够很好地理解数据库基础架构的运行状况和性能：
- Number of commands processed per second
- Latency
- Memory fragmentation ratio
- Evictions
- Rejected clients
最终，您将意识到与您本人的根底构造和用例特地相干的其余指标。当然，您要监督的内容将取决于您领有的工具和可用的指标。
