本文重点介绍了Redis需要监控哪些指标（篇幅有限，无法涵盖所有??），以及我们如何获取这些指标数据。为了保证对我们应用至关重要的Redis的健康运行，并在出现问题时及时通知我们。吞吐量吞吐量包括Redis实例历史总吞吐量和每秒吞吐量。我们要监控的吞吐量可以通过几个commandinfostats获得：#ThetotalnumberofcommandsprocessedsinceRdislaststartedtotal_commands_processed:2255#OPSinstantaneous_ops_per_secofcurrentRedisinstance:12#Totalnetworkinputtotal_net_input_bytes:34312#Network总输出total_net_output_bytes:78215#每秒输入，单位为kb/sinstantaneous_input_kbps:1.20#每秒输出，单位为kb/sinstantaneous_output_kbps:2.62内存利用率Redis高性能保证的一个重要资源是充足的内存。Usedmemory表示Redis已经分配的总内存大小。我们可以通过infomemory命令获取所有内存利用了相关数据，其结果如下：127.0.0.1:6379>infomemory#Memoryused_memory:1007888used_memory_human:984.27Kused_memory_rss:581632used_memory_rss_human:568.00Kused_memory_peak:1026064used_memory_peak_human:1002.02Ktotal_system_memory:8589934592total_system_memory_human:8.00Gused_memory_lua:37888used_memory_lua_human:37.00Kmaxmemory:0maxmemory_human:0Bmaxmemory_policy:noevictionmem_fragmentation_ratio:0.58mem_allocator:libc需要注意的是，如果我们不配置maxmemory（可以通过configget/setmaxmemory查询并设置，无需重启Redis实例），那么Redis可能会被耗尽服务器的所有可用内存都可能导致交换甚至被系统杀死。所以推荐的方案是配置maxmemory和配置maxmemory-policy（不是默认的noviction）。即使这样还不够，因为如果并发比较大，缓存驱逐策略可能会忙不过来，所以还是会出现无法操作Redis的错误。所以强烈建议在配置maxmemory-policy和maxmemory双重策略的前提下监控used_memory。推荐值为maxmemory的90%。比如maxmemory为10G，那么当used_memory达到9G时，会给出相关警告，为扩容做准备。缓存命中率缓存命中率表示缓存的效率。显然，它是通过公式计算的：HitRate=keyspace_hits/(keyspace_hits+keyspace_misses)。infostats中正好有这些数据：keyspace_hits:17keyspace_misses:1建议缓存命中率不需要低于90%，越高越好。命中率越低，越多不在缓存中的KEY被访问。可能是这些KEY已经过期，被删除，被逐出，或者被根本不存在的KEY非法访问。缓存命中率越低，或者穿透Redis从MySQL（或其他比Redis慢得多的存储服务）获取数据的请求越多，导致请求越多延迟越大，导致API耗时增加，影响用户体验。如果内存不足，则需要扩展。比如infostats中的evicted_keys不为0，或者used_memory已经达到内存限制。如果是使用问题，则需要优化代码。客户端连接数的值可以通过infoclients中的connected_clients字段获取，会受到操作系统ulimit和redis的maxclients配置的限制。如果Rdis客户端报错无法获取连接数（异常信息：ERRmaxnumberofclientsreached），需要查看这两个地方是否限制了客户端连接数。当然也有可能是其他原因，比如客户端bug导致连接没有释放。慢日志Redis和其他关系型数据库一样，也有一个用于命令执行的慢日志。慢日志采集的阈值可以通过configsetslowlog-log-slower-than配置，单位为微秒。默认为10000微秒，即10ms。笔者认为默认值偏大。建议调整为1ms。因为这个慢日志统计的时间只是命令的执行时间，不包括客户端到服务器的时间和命令在服务器队列中的等待时间。Rdis的性能方面，正常执行时间一般在10微秒级别（单实例OPS可达10W）。因此，设置slowlog-log-slower-than为1000，即1毫秒绰绰有余：redis>slowlogget1)1)(integer)21#UniqueID2)(integer)1439419285#Unixtimestamp3)(integer)19125#Executiontimeinmicroseconds4)1)"keys"#Command...另外，可以通过命令slowlogreset清除所有保存的慢日志。注意：Redis4.0或更高版本有两个附加字段：客户端IP端口和客户端名称。客户端名称可以通过命令自定义：clientsetname。延迟监控任何环境都会有延迟，关键看延迟是否在我们可以接受的范围内。一些高延迟会造成比较大影响的原因可能有很多，比如：网络原因、计算量大的命令、时间复杂度为O(n)的命令、系统内存不足和SWAP等。Redis提供了很多用于定位这些延迟问题的工具。slowlog就是慢日志，上面已经详细介绍过了，是一个很重要的监控项。Redis在单线程中处理命令，所以如果有命令执行时间长，其他命令就会被阻塞。latencymonitor延迟监控是Redis2.8.13引入的新特性，用于帮助群定位延迟问题。它可以记录Redis延迟问题的可能原因。您需要通过以下命令启用此功能。当然你也可以在redis.conf中配置：configsetlatency-monitor-thresholdms接下来可以通过以下命令查看是否开启成功：redis>latencylatest1)1)"command"#Eventname2)(integer)1539479413#Unixtimestamp3)(integer)381#Latencyoflatestevent4)(integer)6802#Alltimemaximumlatency#也可以查看导致延迟的历史命令：redis>latencyhistorycommand#Latencydiagnosisredis>latencydoctorintrinsiclatencyRedis服务内部延迟。通过执行命令：src/redis-cli--intrinsic-latencysec得到延迟统计，结果可以用来衡量Redis服务的内部延迟。该命令的总运行时间由最后一个参数sec决定。通过这条命令，我们可以判断构建的Redis服务的性能是否正常。命令使用参考：afeideMBP:redis-3.2.11litian$src/redis-cli--intrinsic-latency5Maxlatencysofar:1microseconds.Maxlatencysofar:4microseconds.Maxlatencysofar:11microseconds.Maxlatencysofar:17microseconds.Maxlatencysofar:115microseconds.Maxlatencysofar:648microseconds.99087235totalruns(avglatency:0.0505微秒/每次运行50.46纳秒）。Worstruntook12842xlongerthantheaveragelatency.networklatency可以使用--intrinsic-latency查看Redis的内部延迟，但是由于Redis是远程缓存服务，执行命令时不计算客户端到服务器的时间延迟。而且，与内部延迟相比，Redis客户端到服务端的网络延迟影响更大，不确定因素更多，比如网络抖动。Redis也提供了相关的命令来统计网络延迟。该命令的本质是通过ping您的Redis服务器来测量响应时间。使用方法如下：afeideMBP:redis-3.2.11litian$src/redis-cli--latency-h127.0.1.168-p6379min:0,max:1,avg:0.18(174samples)注：该命令将继续运行，除非你主动终止它。cachecloud从上面我们可以看出，大部分的metrics都可以通过info命令获取。毫不夸张地说，info命令是窥探Redis的最佳方式。因此，我们要监控Redis，必须熟悉info结果中各个字段的含义，然后结合自身业务，针对性定制最适合自身业务的监控方案。但是info命令只是一个独立的命令，一般我们的生产环境都是redis集群。那么我们就需要一个专业的监控服务来汇总整个redis集群的指标，供我们查看。笔者这里强烈推荐cachecloud。GIthub地址为：https://github.com/sohutv/cachecloud，用过的都说可以，呵呵~
