redis监控指标

性能指标：　　　　Performance metrics
内存指标：　　　　Memory metrics
基本活动指标：　　Basic activity metrics
持久性指标：　　　Persistence metrics
错误指标：　　　　Error metrics

1．性能指标：Performance metrics

latency：Redis响应一个请求的时间
instantaneous_ops_per_sec：平均每秒处理请求总数
hit rate (calculated)：缓存命中率（keyspace_hits / (keyspace_hits + keyspace_misses)）

1.1 latency（延迟）

客户端请求与实际服务器响应之间的时间的度量。跟踪延迟是检测Redis性能变化的最直接方法。

检测方法：

redis-cli --latency（redis-cli --latency -c -h 127.0.0.1 -p 8001） redis-cli --latency-history，以分段的形式展现Redis延迟 redis-cli --latency-dist，以图表的形式展现Redis延迟

输出的时间单位为毫秒，它通过Redis PING命令测量Redis服务器响应的时间(以毫秒为单位)来实现这一点

min: 0, max: 1, avg: 0.33 (1467 samples)

结果解析：

min: 0。redis-cli发出PING的时间到收到回复的时间之间的最小延迟。
max: 1。redis-cli发出PING信号到收到命令的响应之间的最大延迟
avg: 0.33。所有采样数据的平均响应时间(以毫秒为单位)
1467 samples。redis-cli记录发出PING命令并接收响应的次数。

1.2 instantaneous_ops_per_sec

跟踪处理的命令吞吐量对于诊断Redis实例中的高延迟原因至关重要。

高延迟可能是由许多问题引起的，从积压命令队列到慢速命令，再到网络过度使用。

可以通过测量每秒处理的命令数来进行诊断 - 如果它相对比较平稳，则原因不是计算密集型命令（Redis本身引起的）。

如果一个或多个慢速命令导致延迟问题，您将看到每秒的命令数量完全下降或停止。与历史基线相比，每秒处理的命令数量的下降可能是低命令量或阻塞系统的慢命令的标志。

1．OPS较低可能是正常的，或者它可能表示上游存在问题（表示Redis本身被负载量较低）。

2．有关慢速命令的详细信息，请参阅第2部分，了解有关收集Redis指标的信息。

1.3 hit rate

使用Redis作为缓存时，监视缓存命中率可以告诉您缓存是否被有效使用。命中率低意味着客户端正在寻找不再存在（Redis内存中）的Key值。

Redis不直接提供命中率指标。我们仍然可以像这样计算：

低缓存命中率可能由许多因素引起，包括数据到期和分配给Redis的内存不足（这可能导致key值被清除）。注意，需要设置maxmemory，比如90%，达到90%告警扩容redis。否则严重时会发生swap被kill掉进程。

低命中率可能会导致应用程序延迟增加，因为它们必须从较慢的备用资源中获取数据。

2 内存指标Memory metrics

used_memory：已使用内存
mem_fragmentation_ratio：内存碎片率
evicted_keys：由于最大内存限制被移除的key的数量
blocked_clients：由于BLPOP, BRPOP, or BRPOPLPUSH而备阻塞的客户端

内存使用是Redis性能的关键组成部分。

如果实例超过可用内存(used_memory > total available memory)，操作系统将开始swap老的/未使用的部分内存(pages)，将该部分pages写入磁盘，为较新/活动页腾出内存空间。

每个交换的部分都写入磁盘，严重影响性能。从磁盘写入或读取速度比写入或从存储器读取速度慢5个数量级（100,000）（内存为0.1μs，磁盘为10 ms）。

可以将Redis配置为仅限于指定的内存量。在redis.conf文件中设置maxmemory指令可以直接控制Redis的内存使用情况。比如90%，达到90%告警扩容redis。否则严重时会发生swap被kill掉进程。

启用maxmemory需要您为Redis配置驱逐（过期）策略以确定它应如何释放内存。

当Redis用作缓存时，这种“扁平线”模式很常见;消耗掉所有可用内存，并以与插入新数据相同的速率清理旧数据。

Redis的内存参数命令：info memory

used_memory和used_memory_human都是Redis使用到的内存，used_memory_human是以更加可读性的方式展示Redis的内存使用。

used_memory_rss和used_memory_rss_human 表示操作系统为Redis进程分配的内存总量。

为什么会出现Redis使用的内存大于操作系统给Redis分配的内存，参考。

used_memory being < used_memory_rss：内存碎片的存在。

used_memory > used_memory_rss ：物理内存不足，发生了内存swap。

2.2 mem_fragmentation_ratio

内存碎片率。操作系统看到的内存与Redis分配的内存的比率。配置文件中增加activedefrag yes选项，不用重启的方式自动重整内存碎片。

操作系统会为每个进程分配内存，并且是通过虚拟内存管理来处理分配内存的。例如操作系统为redis分配1G的内存，内存分配器会尝试寻找一块连续的1G内存段给redis进程，如果找不到，就会查找总大小超过1G的多段内存分配给redis，从而导致内存没有完全的利用，造成了内存碎片化了。

碎片率>1：表示发生碎片。
碎片率>1.5：表示碎片过多，Redis实例占用了所请求的物理内存的150％。
碎片率<1会：表示Redis需要的内存比系统上可用的内存多，这会导致交换swap。交换到磁盘将导致延迟显着增加。

理想情况下，操作系统会在物理内存中分配一个连续的段，碎片率等于1或稍大一些。

如果redis服务器的碎片率高于1.5，重新启动Redis实例将允许操作系统恢复以前因碎片而无法使用的内存。在这种情况下，作为通知的警报可能就足够了。
如果redis服务器的碎片率低于1，则可能需要以发出告警，以便快速增加可用内存或减少内存使用量。从Redis 4开始，当Redis配置为使用jemalloc内存管理时，内存管理更加优秀。

2.3 evicted_keys（仅限缓存）

由于最大内存限制被移除的key的数量。

使用Redis作为缓存，可将其配置为在达到maxmemory限制时（按照某种内存淘汰方式）自动清除key值。

使用Redis作为数据库或队列，可能需要交换而不是清除key值，在这种情况下，因此可以跳过此指标。

跟踪key值清理指标非常重要，因为Redis按顺序处理每个操作，这意味着驱逐大量key可以降低命中率，从而增加延迟时间。

对于TTL的key，不希望被淘汰掉，如果此指标始终高于零，会看到实例中的延迟增加。对于非TTL的key，会不常用或者不重要的key，逐渐会耗尽所有内存，此时会发生内存key淘汰。只要响应时间可以接受，就可以接受稳定的清除率。

内存管理方面要配置maxmemory和maxmemory-policy。

noeviction：当达到内存限制并且用户尝试添加其他键时，将返回错误（也就是说达到内存限制之后不允许写入）
volatile-lru：在已过期的key值中，删除最近最少使用的key值
volatile-ttl：在已过期的key值中，删除最短过期时间的key值
volatile-random：在已过期的key值中，随机删除key值
allkeys-lru：从所有key值中删除最近最少使用的key
allkeys-random：从所有key值中随机删除
volatile-lfu：在Redis 4中新增选项，在已过期的key值中，“最近最不常用”的key值
allkeys-lfu：在Redis 4中新增选项，从所有key值中，删除“最近最不常用”的key值

出于性能原因，当使用LRU，TTL或Redis 4的LFU策略时，Redis实际上不会从整个key值集进行采样。Redis首先对key值集的随机子集进行采样，然后对样本应用清理策略。贪心算法的LRU

关于LRU和LFU，分别是最近最少使用和最近最不频繁使用，LFU理论上是比LRU更加合理的算法，清理key的时候，LFU认为“最近最不频繁”使用要比“最近最少”使用更加合理。

LRU和LFU的区别：

LRU是最近最少使用页面置换算法(Least Recently Used)，首先淘汰最长时间未被使用的页面
LFU是最近最不常用页面置换算法(Least Frequently Used)，淘汰一定时期内被访问次数最少的页

2.4 blocked_clients

由于BLPOP, BRPOP, or BRPOPLPUSH而备阻塞的客户端。

这类命令产生的请求会在list中阻塞，直到源被填充或者超时。延迟或其他问题可能会阻止源列表被填充。虽然被阻止的客户端本身不会引起警报，但如果您看到此指标的值始终为非零值，则应该引起注意。

3 基本活动指标

connected_clients：客户端连接数
connected_slavesSlave：数量
master_last_io_seconds_ago：最近一次主从交互之后的秒数
keyspace：数据库中的key值总数

3.1 connected_clients

大多数场景，连接客户端的数量将有合理的上限和下限。监视客户端连接可帮助您确保有足够的可用资源用于新客户端或管理会话。

connected_clients太低，表示客户端连接可能已经丢失
connected_clients太高，大量的并发客户端连接可能会打垮服务器处理请求的能力。

3.2 connected_slaves

对于读多写少的场景，一般是多从架构。使用Redis中提供的主从数据库复制功能。

监控这个值是必要的，因为一般这个值是稳定的，若果发生变化，证明主从间的连接断开，网络问题了。

3.3 master_last_io_seconds_ago

最近一次主从交互之后的秒数。

使用Redis的主从复制功能时，slave会定期检查其主服务器。主从长时间没有通信表示主从Redis实例之间存在问题。会有slave和master间的数据不同步的风险。

主从断开重连后，slave会发送PSYNC命令以尝试仅同步中断期间丢失的命令。如果不行，会发送SYNC命令，请求一次全量同步。

这时会使master立即开始执行background save命令，同时新增加的命令会被缓冲起来。

当background save命令执行完成时，数据与缓冲的命令一起发送到客户端。每次从机执行SYNC时，都会导致主实例上的延迟显着增加。

因此，监控这个指标是必须的，假如主从真的是网络断开了，越快启动slave重连master，将会越大可能执行PSYNC命令以尝试仅同步中断期间丢失的命令。避免全量同步。

3.4 keyspace

数据库中的key值总数。

作为内存数据存储，key值集合空间越大，为了确保性能，Redis需要的物理内存越多。

redis使用的内存超过maxmemory，会发生内存淘汰，以相同的速率清理key值。这会产生一个“扁平线”

使用Redis作为缓存，查看key值空间饱和度，加上命中率较低，会让客户端请求旧的或已逐出的数据。随着时间的推移跟踪keyspace_misses数量会帮助查明原因。

使用Redis作为数据库或队列，则可能不选择volatile策略。

随着key值空间的增长，如果可能的话，需要考虑在添加物理内存或在主机之间拆分数据集(使用Redis实例实现分区方案)。

4 持久化指标

rdb_last_save_time：最后一次持久化保存到磁盘的Unix时间戳
rdb_changes_since_last_save：自最后一次持久化以来数据库的更改数

4.1 rdb_last_save_time 和 rdb_changes_since_last_save

关注数据集的波动性。

写入磁盘之间的时间间隔过长可能会在服务器发生故障时导致数据丢失。在上次保存时间和故障时间之间对数据集所做的任何更改都将丢失。

监控 rdb_changes_since_last_save 可更深入地了解数据的波动性。如果数据集在该间隔内没有太大变化，则写入之间的长时间间隔不是问题。

跟踪这两个指标可以清楚地了解在给定时间点发生故障时您将丢失多少数据。

5 错误指标Error metrics

rejected_connections：由于达到maxclient限制而被拒绝的连接数
keyspace_missesKey：值查找失败（没有命中）次数
master_link_down_since_seconds：主从断开的持续时间（以秒为单位）

5.1 rejected_connections

Redis能够处理许多活动连接，默认情况下可以使用10,000个客户端连接。 rejected_connections可以通过查看Info stat

修改redis.conf中的maxclient将最大连接数设置为不同的值。超过这个值，新的客户端连接会被拒绝连接。

Redis检查内核以确定可用文件描述符的数量。如果可用文件描述符的数量小于maxclient + 32（Redis为其自己使用保留32个文件描述符），则忽略maxclient指令并使用可用文件描述符的数量。

5.2 keyspace_misses

查找不存在的键会导致keyspace_misses计数器递增，因此keyspace_misses意味着客户端尝试在数据库中查找不存在的密key。

不使用Redis作为缓存，则keyspace_misses应该为零或接近零。注意，调用阻塞的任何阻塞操作（BLPOP，BRPOP和BRPOPLPUSH）都将导致keyspace_misses递增。

5.3 master_link_down_since_seconds

主从断开的持续时间（以秒为单位）。该指标仅在主从之间的连接丢失时可用。

理想情况下，此值不应超过零-主从之间保持持续通信，以确保slave不提供过时数据。

发现这个值突然增大，最好马上查看主从连接，因为越长时间，主从重连后发生SYNC全量同步的可能性越大，对整个服务的性能影响较大。

redis

监控指标