Redis可观测最佳实践，5⼤关键指标最全解析！
什么是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指标：
性能指标
内存指标
基本活动指标
持续性指标
错误指标
性能指标
除低错误率外，良好的性能是系统运⾏状况的最佳顶级指标之⼀。如内存部分中所述，性能不佳通常是由内存问题引起的。
名称描述Metric Type
latency Redis服务器平均响应请求的时间Work: Performance
Instantaneous_ops_per_sec每秒处理的命令总数Work: Throughput
hit rate (calculated）keyspace_hits /（keyspace_hits + keyspace_misses）Work: Success
告警指标：latency
延迟是对客户端请求和实际服务器响应之间的时间的度量。跟踪延迟是检测Redis性能变化的最直接⽅法。由于Redis具有单线程特性，因此延迟分布中的异常值可能会导致严重的瓶颈。⼀个请求的响应时间过长会增加所有后续请求的等待时间。⼀旦确定延迟是⼀个问题，就可以采取多种措施来诊断和解决性能问题。
观测指标：Instantaneous_ops_per_sec
跟踪已处理命令的吞吐量对于诊断Redis实例中⾼延迟的原因⾄关重要。⾼延迟可能是由许多问题引起的，从积压的命令队列到速度慢的命令，再到⽹络链路过度使⽤。您可以通过测量每秒处理的命令数来进⾏调查-如果该命令⼏乎保持不变，则原因不是计算密集型命令。如果⼀个或多个慢速命令引起延迟问题，您将看到每秒的命令数量下降或完全停⽌。与历史规范相⽐，每秒处理的命令数量下降可能是低命令量或阻塞系统的慢命令的迹象。低命令量可能是正常现象，或者可能表明上游出现问题。
指标：hit rate
将Redis⽤作缓存时，监视缓存命中率可以告诉您缓存是否得到有效使⽤。命中率低意味着客户端正在寻不再存在的密钥。Redis不直接提供命中率指标。我们仍然可以这样计算：
hit rate = keyspace_hits / (keyspace_hits + keyspace_misses)
⾼速缓存命中率低可能是由多种因素引起的，包括数据到期和分配给Redis的内存不⾜（这可能会导致键退出）。低命中率可能会导致应⽤程序延迟增加，因为它们必须从较慢的备⽤资源中获取数据。
内存指标
名称描述Metric Type
used_memory Redis使⽤的内存量（以字节为单位）Resource: Utilization
mem_fragmentation_ratio操作系统分配的内存与Redis请求的内存的⽐率Resource: Saturation
evicted_keys由于达到最⼤内存限制⽽删除的键数Resource: Saturation
blocked_clients客户端在等待BLPOP，BRPOP或BRPOPLPUSH时被阻⽌Other
观测指标：used_memory
内存使⽤率是Redis性能的关键组成部分。如果used_memory超出了可⽤的系统总内存，则操作系统将开始交换内存的旧/未使⽤部分。每个交换的部分都写⼊磁盘，从⽽严重影响性能。从磁盘写⼊或读取⽐从内存写⼊或读取要慢5个数量级（100,000x！）（内存为0.1 µs，磁盘为10 ms）。
您可以将Redis配置为限制在指定的内存量内。在f⽂件中设置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"。
名称描述Metric Type
connected_clients连接到Redis的客户端数量Resource: Utilization
connected_slaves连接到当前主实例的副本数Other
master_last_io_seconds_ago⾃副本和主实例之间最后⼀次交互以来的时间（以秒为单位）Other
keyspace数据库中的键总数Resource: Utilization
告警指标：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 可以存储更多密钥⽽⽆需逐出或交换。但是，应⽤分区计划⽐在⼏个记忆棒中交换更具挑战性。
持续性指标
名称描述Metric Type
名称描述Metric Type
rdb_last_save_time上次保存到磁盘的Unix时间戳Other
rdb_changes_since_last_save⾃上次转储以来对数据库所做的更改数Other
启⽤持久性可能是必要的，尤其是在使⽤Redis的复制功能的情况下。由于副本会盲⽬复制对主实例所做的任何更改，因此，如果要重新启动主实例（⽆持久性），则与其连接的所有副本都将复制其现在为空的数据集。
如果您将Redis⽤作缓存或在⽤例中数据丢失将不那么重要，则可能不需要持久性。
重要监视的指标：rdb_last_save_time和rdb_changes_since_last_save
通常，最好注意数据集的波动性。如果服务器发⽣故障，两次写⼊磁盘之间的时间间隔过长可能会导致数据丢失。在上次保存时间和故障时间之间对数据集所做的任何更改都将丢失。
监视rdb_changes_since_last_save可让您更深⼊地了解数据的波动性。如果您的数据集在该间隔内没有太⼤变化，则两次写⼊之间的长时间间隔不成问题。跟踪两个指标可以使您很好地了解如果在给定的时间点发⽣故障，您将丢失多少数据。
错误指标
注意：本节包括使⽤术语“主”和“从”的指标。除了引⽤特定的度量标准名称外，本⽂将其替换为“primary” 和 “replica"。
Redis错误指标可以提醒您异常情况。以下指标跟踪常见错误：
名称描述Metric Type
rejected_connections由于达到maxclient限制⽽被拒绝的连接数Resource: Saturation
keyspace_misses失败的键查次数Resource: Errors / Other
master_link_down_since_seconds主服务器和副本服务器之间的链接断开的时间（以秒为单位）Resource: Errors
告警指标：rejected_connections
redis支持的五种数据类型
Redis能够处理许多活动连接，默认情况下有10,000个客户端连接可⽤。通过更改f中的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
最终，您将认识到与您⾃⼰的基础结构和⽤例特别相关的其他指标。当然，您要监视的内容将取决于您拥有的⼯具和可⽤的指标。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。