如何监控Redis性能指标（译）

Redis给人的印象是简单、很快，可是不表明它不须要关注它的性能指标，此文简单地介绍了一部分Redis性能指标.
翻译过程当中加入了本身延伸的一些疑问信息，仍然还有一些东西没有彻底弄明白。
原文中Metric to watch *** 和 Metric to alert on ***这里翻译为须要观察的指标和须要告警的指标，不知道合不合适。

原文出处：https://www.datadoghq.com/blog/how-to-monitor-redis-performance-metrics/

 

如下为部分译文：

监控Redis能够帮助解决两个方面的问题：Redis自己的资源问题，以及基础架构中其余方面出现的问题。 在本文中，咱们将介绍如下每一个类别中最重要的Redis指标：

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

1．性能指标：Performance metrics

除错误率低外，良好的性能是系统健康情况的最佳顶级指标之一。性能不佳一般是由内存问题引发的，如内存部分所述。

Name	Description	Type
latency	Redis响应一个请求的时间 Average time for the Redis server to respond to a request	Performance
instantaneous_ops_per_sec	平均每秒处理请求总数 Total number of commands processed per second	Throughput
hit rate (calculated)	缓存命中率（计算出来的） keyspace_hits / (keyspace_hits + keyspace_misses)	Success

1.1须要告警的指标: latency（延迟） 

延迟是客户端请求与实际服务器响应之间的时间的度量。跟踪延迟是检测Redis性能变化的最直接方法。
因为Redis的单线程特性，异常状况下的延迟可能会致使严重的瓶颈。一个请求的长响应时间会增长全部后续请求的延迟。
一旦肯定延迟是一个问题，您能够采起一些措施来诊断和解决性能问题。请参阅白皮书“了解前5个Redis性能指标”中的第14页的“使用延迟命令提升性能”一节。

 

译者注：哪些因素会引发延迟？

1，slowlog 慢查询引发的延迟

slowlog-log-slower-than： 慢查询时间阈值，超过这个阈值的查询将会被记录，默认值10000，可是微妙，也即10毫秒。

slowlog-max-len：慢查询日志最大条数，默认值128，先进先出的队列的形式记录在内存中。

slowlog-get n：获取前n条慢查询日志

2，网络延迟

redis-cli --latency 命令用来检测网络延迟，输出的时间单位为毫秒，它经过Redis PING命令测量Redis服务器响应的时间(以毫秒为单位)来实现这一点。
redis-cli --latency -h 127.0.0.1 -p

对于以上返回信息的含义，参考：https://stackoverflow.com/questions/27735411/understanding-latency-using-redis-cli
在此上下文中，延迟是客户机发出命令到客户机接收到对命令的响应之间的最大延迟。一般Redis处理时间很是低，在亚微秒范围内，可是有一些条件会致使更高的延迟数字。
What's (1815samples)? 这是redis-cli记录发出PING命令并接收响应的次数。换句话说，这是采样数据。在当前示例中，记录了1815个请求和响应。
What's min: 0? 最小值表示CLI发出PING的时间到收到回复的时间之间的最小延迟。换句话说，这是来自采样数据的最佳响应时间。
What's max: 15? 最大值表示CLI发出PING信号到收到命令的响应之间的最大延迟。这是来自采样数据的最长响应时间。在咱们1815个示例中，最长的事务花费了1ms。
What's avg: 0.12? avg值是全部采样数据的平均响应时间(以毫秒为单位)。平均而言，个个样本的响应时间是0.12毫秒。
redis-cli --latency-history，以分段的形式展示Redis延迟

redis-cli --latency-dist，以图表的形式展示Redis延迟，这个图表的结果看不怎么懂

3，Intrinsic latency 固有延迟
顾名思义，任何请求响应都要通过代码的处理，必然有延迟，Intrinsic latency是Redis自身处理指令须要消耗的时间，这部分时间耗费没法避免。
固然Intrinsic latency的延迟很是低，在微妙级别

　　如何检测延迟？
　　参考：https://blog.csdn.net/dc_726/article/details/47699739，http://www.redis.cn/topics/latency-monitor.html
　　 CONFIG SET latency-monitor-threshold 100
　　延迟检测模式是关闭的，能够经过配置打开延迟监控

　　打开延迟监控后，人为制造一个产生高延迟的save操做指令，经过latency latest观测延迟信息
　　latency latest：四列分别表示事件名、最近延迟的Unix时间戳、最近的延迟（毫秒）、最大延迟（毫秒）。

　　

latency 能够经过如下参数检测延迟信息
LATEST：四列分别表示事件名、最近延迟的Unix时间戳、最近的延迟、最大延迟。
HISTORY：延迟的时间序列。可用来产生图形化显示或报表。
GRAPH：以图形化的方式显示。最下面以竖行显示的是指延迟在多久之前发生。
RESET：清除延迟记录。

1.2须要观察的指标：instantaneous_ops_per_sec

跟踪处理的命令吞吐量对于诊断Redis实例中的高延迟缘由相当重要。
高延迟多是由许多问题引发的，从积压命令队列到慢速命令，再到网络过分使用。
能够经过测量每秒处理的命令数来进行诊断 - 若是它相对比较平稳，则缘由不是计算密集型命令（Redis自己引发的）。
若是一个或多个慢速命令致使延迟问题，您将看到每秒的命令数量彻底降低或中止。
与历史基线相比，每秒处理的命令数量的降低多是低命令量或阻塞系统的慢命令的标志。
1．OPS较低多是正常的，或者它可能表示上游存在问题（译者注：表示Redis自己被负载量较低）。
2．有关慢速命令的详细信息，请参阅第2部分，了解有关收集Redis指标的信息。

译者注：如何获取Redis的OPS

1.3Metric to watch: hit rate

使用Redis做为缓存时，监视缓存命中率能够告诉您缓存是否被有效使用。命中率低意味着客户端正在寻找再也不存在（Redis内存中）的Key值。
Redis不直接提供命中率指标。咱们仍然能够像这样计算：
HitRate=keyspace_hits/(keyspace_hits+keyspace_misses)
低缓存命中率可能由许多因素引发，包括数据到期和分配给Redis的内存不足（这可能致使key值被清除）。
低命中率可能会致使应用程序延迟增长，由于它们必须从较慢的备用资源中获取数据。

译者注：如何获取Redis的keyspace_hits+keyspace_misses，一样是info stats

2.Memory metrics

Name	Description	Type
used_memory	已使用内存 Amount of memory (in bytes) used by Redis	Utilization
mem_fragmentation_ratio	内存碎片率 Ratio of memory allocated by the operating system to memory requested by Redis	Saturation
evicted_keys	因为最大内存限制被移除的key的数量 Number of keys removed due to reaching the maxmemory limit	Saturation
blocked_clients	因为BLPOP, BRPOP, or BRPOPLPUSH而备阻塞的客户端 Number of keys removed due to reaching the maxmemory limit	Other

2.1须要注意的指标: used_memory

内存使用是Redis性能的关键组成部分。
若是实例超过可用内存(used_memory > total available memory)，操做系统将开始交换老的/未使用的部份内存(pages)，将该部分pages写入磁盘，为较新/活动页腾出内存空间。
每一个交换的部分都写入磁盘，严重影响性能。从磁盘写入或读取速度比写入或从存储器读取速度慢5个数量级（100,000）（内存为0.1μs，磁盘为10 ms）。
能够将Redis配置为仅限于指定的内存量。在redis.conf文件中设置maxmemory指令能够直接控制Redis的内存使用状况。
启用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分配的内存，参考https://stackoverflow.com/questions/44385820/redis-used-memory-is-largger-than-used-memory-rss
　　used_memory being < used_memory_rss意味着内存碎片的存在。
　　used_memory > used_memory_rss 意味着物理内存不足，发生了内存swap。

2.2 须要告警的指标: mem_fragmentation_ratio

mem_fragmentation_ratio度量标准给出了操做系统看到的内存与Redis分配的内存的比率。
MemoryFragmentationRatio =Used_Memory_RSS（Used_Memory）
操做系统负责为每一个进程分配物理内存。操做系统的虚拟内存管理器处理由内存分配器调解的实际映射。
若是Redis实例的内存占用为1GB，内存分配器将首先尝试找到一个连续内存段来存储数据。若是没有找到连续的段，分配器必须将进程的数据划分为多个段，从而致使内存开销的增长。
跟踪碎片比率对于了解Redis实例的性能很是重要。
碎裂率大于1表示发生碎片。比率超过1.5表示碎片过多，Redis实例占用了所请求的物理内存的150％。
碎片率低于1会告诉您Redis须要的内存比系统上可用的内存多，这会致使交换。交换到磁盘将致使延迟显着增长（请参阅已用内存）。
理想状况下，操做系统会在物理内存中分配一个连续的段，碎片比率等于1或稍大一些。
1，若是您的服务器的碎片率高于1.5，则从新启动Redis实例将容许操做系统恢复之前因碎片而没法使用的内存。在这种状况下，做为通知的警报可能就足够了。
2，若是Redis服务器的碎片比率低于1，则可能须要以发出告警，以便快速增长可用内存或减小内存使用量。
从Redis 4开始，当Redis配置为使用包含的jemalloc副本时，可使用新的活动碎片整理功能。
能够将此工具配置为在碎片达到特定级别时启动，并开始将值复制到连续的内存区域并释放旧副本，从而减小服务器运行时的碎片。

译者注，info memory能够查看内存碎片信息

配置文件中增长activedefrag yes选项，不用重启的方式自动重整内存碎片。

2.3须要告警的指标：evicted_keys（仅限缓存）

若是您使用Redis做为缓存，可能将其配置为在达到maxmemory限制时（按照某种方式）自动清除key值。
若是您使用Redis做为数据库或队列，可能须要交换而不是清除key值，在这种状况下，所以能够跳过此指标。
跟踪key值清理指标很是重要，由于Redis按顺序处理每一个操做，这意味着驱逐大量key能够下降命中率，从而增长延迟时间。
若是您使用TTL，您可能不会指望清理key值。在这种状况下，若是此指标始终高于零，您可能会看到实例中的延迟增长。
大多数不使用TTL的其余配置最终会耗尽内存并开始清理key值。只要您的响应时间能够接受，就能够接受稳定的清除率。
您可使用如下命令配置key值过时策略：
config set maxmemory-policy = ***

其中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值集的随机子集进行采样，而后对样本应用清理策略。
一般，Redis的较新（> = 3）版本采用LRU采样策略，该策略更接近真实LRU。
例如，能够经过设置必须通过多少时间而无需访问项目在排名中向下移动来调整LFU策略。有关更多详细信息，请参阅Redis的文档。

译者注：
关于LRU和LFU，分别是最近最少使用和最近最不频繁使用，LFU理论上是比LRU更加合理的算法，清理key的时候，LFU认为“最近最不频繁”使用要比“最近最少”使用更加合理。
LRU和LFU的区别：
LRU是最近最少使用页面置换算法(Least Recently Used),也就是首先淘汰最长时间未被使用的页面!
LFU是最近最不经常使用页面置换算法(Least Frequently Used),也就是淘汰必定时期内被访问次数最少的页!

2.4 须要注意的指标: blocked_clients 

Redis提供了许多在List上运行的阻塞命令。
BLPOP，BRPOP和BRPOPLPUSH分别是命令LPOP，RPOP和RPOPLPUSH的阻塞变体。
当List非空时，命令按预期执行。可是，当List为空时，阻塞命令将一直等到源被填充或达到超时。
等待数据的被阻止客户端数量的增长多是一个麻烦的迹象。
延迟或其余问题可能会阻止源列表被填充。虽然被阻止的客户端自己不会引发警报，但若是您看到此指标的值始终为非零值，则应该引发注意。

3. 基本活动指标

Name	Description	Type
connected_clients	客户端链接数 Number of clients connected to Redis	Utilization
connected_slaves	Slave数量 Number of slaves connected to current master instance	Other
master_last_io_seconds_ago	最近一次主从交互以后的秒数 Number of slaves connected to current master instance	Other
keyspace	数据库中的key值总数 Total number of keys in your database	Utilization

 3.1 须要告警的指标: connected_clients

因为对Redis的访问一般由应用程序发起（用户一般不直接访问数据库），所以对于大多数场景，链接客户端的数量将有合理的上限和下限。
若是数字偏离正常范围，这表示可能存在问题。
若是它过低，表示客户端链接可能已经丢失，若是它过高，大量的并发客户端链接可能会打垮服务器处理请求的能力。
不管如何，客户端链接始终是有限的资源 - 不管是经过操做系统，Redis的配置仍是网络限制。
监视客户端链接可帮助您确保有足够的可用资源用于新客户端或管理会话。

译者注：查看Redis的最大链接数，这个配置至关于MySQL的变量（show variables ***），是一个不随Redis服务负载改变的值，所以不在info中查看。

 

3.2须要告警的指标: connected_slaves

若是您的数据库是大量读取的，那么您可能正在使用Redis中提供的主从数据库复制功能。
在这种状况下，监控链接的从站数量是关键。若是链接的从站数量意外更改，则可能表示主机已关闭或从站实例出现问题。

注意：在上图中，Redis Master将显示它有两个链接的slave，而且每一个slave都有两个slave。
因为slave的slave不直接链接到Redis Master，所以它们不包含在Redis Master的connected_slaves中。

3.3须要告警的指标: master_last_io_seconds_ago

使用Redis的复制功能时，slave会按期检查其主服务器。主从长时间没有通讯的可能表示主从Redis实例之间存在问题。而且冒着slave中数据在master中已经发生了变化危险。
因为Redis执行同步的方式，最大限度地减小主从通讯的中断相当重要。当从设备在中断后从新链接到master时，它会发送PSYNC命令以尝试仅同步中断期间丢失的命令。
若是没法作到这一点，则从站将请求完整的SYNC，这会迫使master当即开始执行background save命令，同时新增长的命令会被缓冲起来。
当background save命令执行完成时，数据与缓冲的命令一块儿发送到客户端。每次从机执行SYNC时，都会致使主实例上的延迟显着增长。

3.4须要注意的指标: keyspace

跟踪数据库中的键数一般是个好主意。做为内存数据存储，key值集合空间越大，为了确保性能，Redis须要的物理内存越多。
Redis将继续添加key值，直到它达到maxmemory limit，而后它开始以相同的速率清理key值。这会产生一个“扁平线”图，如上图所示。
若是您使用Redis做为缓存并查看key值空间饱和度 - 如上图所示 - 加上命中率较低，您可能会让客户端请求旧的或已逐出的数据。随着时间的推移跟踪keyspace_misses数量将帮助您查明缘由。
或者，若是使用Redis做为数据库或队列，则可能不选择volatile策略。
随着key值空间的增加，若是可能的话，您可能须要考虑在添加物理内存或在主机之间拆分数据集。
添加更多内存是一种简单有效的解决方案。若是单机资源有限，则对数据进行分区或分片能够合并许多计算机的资源。
有了分区计划，Redis能够存储更多key值集合而无需清理或swap。可是，分片比增长内存要困可贵多。
值得庆幸的是，Redis文档中有一个关于使用Redis实例实现分区方案的重要部分，请在此处阅读更多内容。

 　　译者注：Redis的keyspace信息

 

4.持久化指标

Redis须要启用持久性配置，尤为是在使用Redis的复制功能时。
若是您使用Redis做为缓存，或者在数据丢失可有可无的用例中，则可能不须要持久性。

Name	description	Type
rdb_last_save_time	最后一次持久化保存到磁盘的Unix时间戳 Unix timestamp of last save to disk	other
rdb_changes_since_last_save	自最后一次持久化以来数据库的更改数	other

 4.1 须要注意的指标: rdb_last_save_time and rdb_changes_since_last_save

一般，关注数据集的波动性是个好主意。写入磁盘之间的时间间隔过长可能会在服务器发生故障时致使数据丢失。
在上次保存时间和故障时间之间对数据集所作的任何更改都将丢失。
监控rdb_changes_since_last_save可以让您更深刻地了解数据的波动性。若是您的数据集在该间隔内没有太大变化，则写入之间的长时间间隔不是问题。
跟踪这两个指标可让您清楚地了解在给定时间点发生故障时您将丢失多少数据。

译者注：如何查看Redis的rdb_last_save_time and rdb_changes_since_last_save

info Persistence

5．Error metrics

Redis错误指标能够提醒您注意异常状况。如下指标可跟踪常见错误：

Name	Description	Type
rejected_connections	因为达到maxclient限制而被拒绝的链接数 number of connections rejected due to hitting maxclient limit	Saturation
keyspace_misses	Key值查找失败（没有命中）次数 number of failed lookups of keys	Errors / Other
master_link_down_since_seconds	主从断开的持续时间（以秒为单位） time in seconds of the link between master and slave being down	Errors

5.1须要告警的指标: rejected_connections

Redis可以处理许多活动链接，默认状况下可使用10,000个客户端链接。
能够经过更改redis.conf中的maxclient指令将最大链接数设置为不一样的值。
若是您的Redis实例当前处于其最大链接数，则将断开任何新的链接尝试。

请注意，Redis可能不支持使用maxclient指令请求的链接数。
Redis检查内核以肯定可用文件描述符的数量。若是可用文件描述符的数量小于maxclient + 32（Redis为其本身使用保留32个文件描述符），则忽略maxclient指令并使用可用文件描述符的数量。
有关Redis如何处理客户端链接的更多信息，请参阅有关redis.io的文档。

译者注：rejected_connections能够经过查看Info stat

5.2须要告警的指标: keyspace_misses

每次Redis查找key时，只有两种可能的结果：key存在，或key不存在。
查找不存在的键会致使keyspace_misses计数器递增，所以keyspace_misses意味着客户端尝试在数据库中查找不存在的密key。
若是您不使用Redis做为缓存，则keyspace_misses应该为零或接近零。请注意，调用阻塞的任何阻塞操做（BLPOP，BRPOP和BRPOPLPUSH）都将致使keyspace_misses递增。

译者注：keyspace_misses能够经过查看Info stat

5.3须要告警的指标: master_link_down_since_seconds

该指标仅在主从之间的链接丢失时可用。
理想状况下，此值不该超过零-主从之间保持持续通讯，以确保slave不提供过期数据。
应该解决链接之间的大的时间间隔。请记住，从新链接后，您的主Redis实例将须要投入资源来更新从站上的数据，这可能会致使延迟增长。

总结

在这篇文章中，咱们提到了一些最有用的指标，您能够监控这些指标以密切关注您的Redis服务器。若是您刚刚开始使用Redis，那么监控下面列表中的指标将提供对数据库基础结构的运行情况和性能的良好可见性：Number of commands processed per secondLatencyMemory fragmentation ratioEvictionsRejected clients最终，您将认识到与您本身的设备和用例特其余指标。固然，您监控的内容取决于您拥有的工具和可用的指标。有关收集Redis指标的分步说明，请参阅随附文章。