监控Redis其实就是盯着它运行，确保不出问题，避免服务崩溃啥的保障稳定啦

监控Redis其实就是盯着它运行,确保不出问题，避免服务崩溃啥的，保障稳定啦，这事儿说起来简单，但真要做细了，方方面面都得照顾到，咱就把它想象成照顾一个特别能干但也挺娇气的小伙子，你得时刻关心他“吃饱没”、“累着没”、“身体有没有哪里不舒服”，这样才能让他一直生龙活虎地给你干活。

最最基础的就是看他是不是“活着”。 这是底线，人没了就啥也别谈了，监控系统第一个要做的就是定时去“戳一戳”这个Redis服务，看看它有没有反应，专业点叫“心跳检测”或者“Ping检查”，如果每次戳它，它都能马上回一句“在呢在呢”，那说明服务基本是正常的，至少是“活着”的，要是戳了半天没反应，或者反应特别慢，那坏事了，肯定是出问题了，可能服务挂掉了，或者网络不通了，这时候就得赶紧拉响警报，找人去处理，这是最紧急的情况，属于一级警报。

光活着还不够，还得看他“精神状态”好不好，也就是性能咋样。 这个小伙子虽然活着，但如果发着高烧，或者浑身没劲，那也干不了活啊，接下来就得看一些关键指标。

第一个关键指标是“忙不忙”，也就是CPU使用率。 Redis是个单线程的家伙，大部分活都靠一个核心CPU来干，你可以想象他只有一个大脑，如果这个大脑一直满负荷运转，利用率动不动就跑到90%甚至100%，那就跟人一直不睡觉连续思考一样，迟早要累垮，这时候服务虽然没挂，但会变得非常卡顿，处理请求的速度慢得像蜗牛，盯着CPU使用率，一旦发现它持续很高，就得找原因了：是不是有特别复杂耗时的命令在执行？是不是请求量突然暴增了？得赶紧给他“减负”。

第二个关键是“记性怎么样”，也就是内存使用情况。 Redis的所有数据都放在内存里，内存就是他的办公桌，桌子就那么大，东西堆满了就没法再放新东西了，所以必须时刻关注内存使用了多少，还剩多少，如果内存快用完了，Redis就会根据你设定的规则（比如删掉最近最少用的数据）开始“扔东西”来腾地方，这就会导致一些本来能查到的数据突然不见了，更严重的是，如果内存彻底耗尽，Redis可能就直接崩溃了，服务就挂了，内存使用率是个非常重要的预警指标，一般到了80%就得高度警惕，开始想办法了，比如清理没用的数据，或者干脆给服务器加内存。

第三个关键是“手脚利索不利索”，也就是延迟和QPS。 延迟就是说，你让Redis办个事（比如查个数据），它需要花多长时间才能给你结果，这个时间当然是越短越好，如果平时都是零点几毫秒就能响应，突然有一天变成了几十毫秒甚至几百毫秒，那肯定是哪里不对劲了，可能是网络问题，也可能是Redis本身“卡壳”了，QPS呢，就是每秒能处理多少个请求，这个数能告诉你当前的业务压力有多大，把QPS和延迟、CPU使用率结合起来看，就能比较全面地了解Redis的“工作状态”：是游刃有余，还是已经不堪重负了。

除了这些，还得看看他有没有“不良习惯”或者“异常行为”。 有没有很多客户端连接着但长时间不干活（闲置连接），这相当于占着茅坑不拉屎，浪费资源，再比如，Redis为了持久化数据，会创建子进程来干活（比如RDB快照或AOF重写），如果子进程出问题了，也会影响主进程的稳定，还有，得盯着日志看，看有没有输出一些错误信息，比如连接失败、命令执行错误之类的，这些就像是小伙子在抱怨或者喊“疼”，是发现问题的重要线索。

还得关心一下“周边环境”，也就是服务器本身。 Redis是跑在服务器上的，如果服务器本身的磁盘快满了（虽然Redis主要用内存，但持久化文件还是存在磁盘上的），或者网络带宽被其他程序占满了，那Redis也会跟着受影响，表现得不正常，服务器的整体资源监控也是不能忽视的一环。

监控Redis就是个细致活,不能等它真挂了才后知后觉，得通过上面说的这些方法，像关心人一样，7x24小时地“望闻问切”，提前发现亚健康状态，把小毛病及时解决掉，这样才能保证它一直稳定可靠地为我们服务，避免关键时刻掉链子，导致整个网站或应用崩溃的悲剧发生，说白了，就是花点心思防患于未然，总比出了问题手忙脚乱、损失惨重要强得多。