Redis监控小技巧

Posted 2021-04-07 白鳝的洞穴

Redis是现在使用最为广泛的开源内存数据库之一，对于DBA来说，刚刚接触REDIS的运维会有些蒙圈。虽然Redis也提供了十分友好的界面，可以随时检查Redis的运行情况，但是如何才能有效的监控Redis数据库呢？和传统的关系型数据库不同，和Timesten等关系型内存数据库也不同，Redis是一种KV的非关系型内存数据库，随着使用Redis的应用的不同，Redis的监控指标体现出来的特征差异也十分大。采用传统的关系型数据库的监控方式来监控Redis是行不通的。

一般的企业对Redis的监控大多数基于应用，通过上层应用的总体情况来判断Redis实例是否正常，如果不正常，大多数采取的措施也只能重启，较难定位Redis内部出现问题的原因。

对Redis像传统数据库一样建立健康模型并通过健康模型来监控Redis数据库是老白团队近期在做的一件事情。

在做的过程中，也总结出了一些Redis监控的小技巧，今天分享出来，和大家共享，同时也希望Redis运维监控方面的专家对此提出一些建议。

首先是操作系统的重要指标监控，Redis是一种内存数据库，对操作系统的健康度依赖很高，操作系统出现瓶颈或者不健康对Redis影响很大。首先是CPU的使用情况，监控时不仅要关注CPU使用率，还要关注SYS CPU的使用情况，r队列的情况，以及interrupt、context switch的情况，这些情况出现异常，都可能导致redis的访问性能出现问题。另外一个值得关注的是内存使用情况，Redis是一个内存数据库，因此需要使用大量的物理内存，不过无论如何，我们都不希望Redis去使用虚拟内存。因此对内存空闲大小以及SWAP使用率的监控十分重要。正常情况下SWAP使用率都应该是0，如果出现了SWAP使用率超过10%的情况，我们就要十分关注了。第三个方面要关注的是网络的情况，一般的监控软件只关心网络的进出流量，Redis的监控指标里也提供了这方面的数据，不过通过网络进出流量作为监控指标使用，其算法十分复杂，一般的监控场景很难掌握其要点，需要和应用的负载等进行联合分析，才能发现其中的异常。另外一个重要的网络指标Redis监控数据并未提供，需要我们从操作系统层面去采集，就是网络丢包错包数，网络问题将对REDIS的健康造成极大的影响，如果每秒平均的丢包错包数超过5个，那么就要十分关注网络的健康了。最后一个操作系统层面的监控项目是IO延时，作为一个十分简单的内存数据库，持久化和复制是对数据库影响较大的因素，因为在做数据复制的时候，REDIS的访问是受到很大限制的。如果系统IO的延时很高，你那么对Redis的性能影响也是很大的。

针对Redis数据库实例层面，我们关注active_defrag_hits（活动碎片整理进程每分钟执行的值重新分配数） 、used_memory、keyspace_hits/keyspace命中率、当前连接数、最近新增连接数、可用内存的百分比、 DBO 的 avg_ttl、Redis 引擎线程的 CPU 使用率、由于 maxmemory 限制而被驱逐的KEY的数量、memory_frag_ratio（引擎的内存分配的效率）、 expired_keys （key过期数）等，要注意的是，对于部分指标，我们不能仅仅关注总量，而是要关注一个特定监控周期（比如5分钟)内的增量或者平均每秒钟的增量。

Redis的健康状态和应用关系较大，因此分析应用的情况也十分关键。使用commandstats获得应用的状态，并进行分析对于发现Redis运行状态的深层次问题十分关键。


commandstats命令可以把系统中各类命令的调用次数与平均调用时间都显示出来。不过不同的应用命令的种类会有较大的不同，命令的种类也比较多，为了更好、更直观的进行分析，建议根据命令操作数据类型的不同，对这些命令进行一些归并，形成一个数量更少，更为聚焦的监控指标集。比如我们可以把geo类的命令进行归并，把 geoadd 、 geodist 、 geohash 、 geopos 、 georadius 、 georadiusbymember这些命令的统计和作为一个指标来进行监控，如果这个指标发现明显的异常，那么我们就认为geo类的应用有问题了。