Survival所有指标中最重要的是检查Redis是否还活着，可以通过命令PING的响应是否为PONG来判断。连接数连接的客户端数可以通过命令src/redis-cliinfoClients|获取grepconnected_clients。该值与使用redis的服务的连接池配置密切相关，因此在监控该字段的值时需要注意。另外，这个值不宜过大。建议不要超过5000，如果太大，可能是redis处理太慢，需要排查问题，找出原因。此外，还有一些拒绝连接（rejected_connections）也需要注意。这个值最好是0，如果大于0，说明创建的连接数超过了maxclients，需要排查原因。是redis连接池配置不合理还是这个redis实例连接的服务太多。阻塞客户端数blocked_clients一般是执行list数据类型的BLPOP或BRPOP命令引起的。可以通过命令src/redis-cliinfoClients|获取grepblocked_clients。显然，这个值最多应该为0。使用内存峰值监控redis内存使用峰值。我们都知道Redis可以使用命令configsetmaxmemory10737418240来设置允许的最大内存（强烈建议不要超过20G）。如果内存超过限制，它会被系统杀死。建议used_memory_peak的值和maxmemory的值之间有一个安全区间，比如1G，那么used_memory_peak的值不能超过9663676416（9G）。此外，我们还可以监控maxmemory不能小于多少G，比如5G。因为之前我们在生产环境中出现过这样的问题，运维不小心配置了10G到1G，导致服务器内存够用却无法使用的悲剧。内存碎片率mem_fragmentation_ratio=used_memory_rss/used_memory，这也是一个很重要的指标。如果是redis4.0之前的版本，这个问题除了重启没有什么好的优化办法。redis4.0的一大特色就是优化了内存碎片率（Memoryde-fragmentation）。在redis.conf配置文件中引入，即ACTIVEDEFRAGMENTATION：碎片整理可以让Redis压缩内存空间，从而回收内存。这个特性默认是禁用的，你可以使用命令CONFIGSETactivedefragyes热启动这个特性。当这个值大于1时，表示分配的内存超过了实际使用的内存。值越大，碎片率越严重。当这个值小于1时，说明发生了swap，即可用内存不够。另外需要注意的是，当内存使用量（used_memory）较小时，这个值参考价值不大。所以建议used_memory至少1G再考虑监控内存碎片率。缓存攻击率keyspace_misses/keyspace_hits这两个指标用来统计缓存的命令率，keyspace_misses是指未命中数，keyspace_hits是指攻击数。keyspace_hits/(keyspace_hits+keyspace_misses)是缓存命中率。视情况而定，建议在0.9以上，即缓存穿透率要超过90%。如果缓存穿透率太低，那就检查一下是不是缓存的使用有问题！OPSinstantaneous_ops_per_sec指标表示缓存的OPS。如果业务比较稳定，那么这个值不会有太大的波动，但是国内的业务比较有特点，如果不是全球产品，晚上基本没有流量，所以这个字段的监控要结合自己的具体情况业务，不同时间段波动幅度可能不同。持久化rdb_last_bgsave_status/aof_last_bgrewrite_status，即最后一次或最后一次RDB/AOF持久化是否有问题，两个值都应该是“ok”。另外，由于redis在持久化的时候会fork子进程，fork是一个完全阻塞的进程，所以可以监控fork的耗时，即latest_fork_usec，单位是微妙的。如果这个值比较大，会影响业务，甚至会出现超时。InvalidKEY如果使用Redis作为缓存，建议所有key都设置expire属性，通过命令src/redis获取每个db中key的个数和设置expire属性的key的属性-cliinfoKeyspace,andexpiresrequiresEqualtokeys:#Keyspacedb0:keys=30,expires=30,avg_ttl=0db0:keys=23,expires=22,avg_ttl=0slowlog通过命令slowlog获取Redis执行的slowlog集合得到。理想情况下，慢日志集合应该是Empty，即没有慢日志。但是，有时由于网络波动等原因，执行setkeyvalue命令需要几毫秒的时间。监控的时候需要注意，看不到slowlog，想优化一下。简单的set/get也可能出现在slowlog中。
