对于任何应用服务和组件，都需要一套完善可靠谱监控方案。
尤其redis这类敏感的纯内存、高并发和低延时的服务，一套完善的监控告警方案，是精细化运营的前提。
本文分几节，细说Redis的监控和告警：
1.Redis监控告警的价值
2.Redis监控的数据采集
3.Redis告警策略
4.基于Open Falcon的Redis监控告警方案
Redis监控告警的价值Redis监控告警的价值对每个角色都不同，重要的几个方面：
redis故障快速通知，定位故障点；对于DBA，redis的可用性和性能故障需快速发现和定位解决。 分析redis故障的Root cause redis容量规划和性能管理 redis硬件资源利用率和成本 redis故障快速发现，定位故障点和解决故障当redis出现故障时，DBA应在尽可能短时间内发现告警；如果故障对服务是有损的(如大面积网络故障或程序BUG)，需立即通知SRE和RD启用故障预案(如切换机房或启用emergency switch）止损。
如果没完善监控告警;假设由RD发现服务故障，再排查整体服务调用链去定位；甚于用户发现用问题，通过客服投诉，再排查到redis故障的问题；整个redis故障的发现、定位和解决时间被拉长，把一个原本的小故障被”无限”放大。
分析redis故障的Root cause任何一个故障和性能问题，其根本“诱因”往往只有一个，称为这个故障的Root cause。
一个故障从DBA发现、止损、分析定位、解决和以后规避措施；最重要一环就是DBA通过各种问题表象，层层分析到Root cause；找到问题的根据原因，才能根治这类问题，避免再次发生。
完善的redis监控数据，是我们分析root cause的基础和证据。
备注：Troubleshtooing定位Root cause，就像医生通过病人的病历和检查报告找到“真正的病灶”，让病人康复和少受苦，一样有意思和复杂；或像刑警通过案件的证据分析和推理，寻找那个唯一的真相，一样惊心动魄。(快看DBA又在吹牛了），其实在大型商业系统中，一次故障轻松就达直接损失数十万（间接损失更大），那“抓住元凶”，避免它再次“作案”，同样是“破案”。
问题表现是综合情的，一般可能性较复杂，这里举2个例子：
服务调用Redis响应时间变大的性能总是；可能网络问题，redis慢查询，redis QPS增高达到性能瓶颈，redis fork阻塞和请求排队，redis使用swap, cpu达到饱和(单核idle过低),aof fsync阻塞，网络进出口资源饱和等等 redis使用内存突然增长，快达到maxmemory; 可能其个大键写入，键个数增长，某类键平均长度突增，fork COW, 客户端输入/输出缓冲区,lua程序占用等等Root cause是要直观的监控数据和证据，而非有技术支撑的推理分析。
redis响应抖动，分析定位root casue是bgsave时fork导致阻塞200ms的例子。而不是分析推理：redis进程rss达30gb,响应抖动时应该有同步，fork子进程时，页表拷贝时要阻塞父进程，估计页表大小xx，再根据内存copy连续1m数据要xx 纳秒，分析出可能fork阻塞导致的。（要的不是这种分析）说明：粮厂有个习惯，在分析root cause尽量能拿到直观证据。因为一旦引入推理步骤，每一步的推理结果都可能出现偏差，最终可能给出错误root cause. “元凶”又逃过一劫，它下次作案估计就会更大。所以建议任何小的故障或抖动，至少从个人或小组内部，深入分析找到root cause；这样个人或组织都会成长快； 形成良好的氛围。
Redis容量规划和性能管理通过分析redis资源使用和性能指标的监控历史趋势数据；对集群进行合理扩容(Scale-out)、缩容(Scale-back)；对性能瓶颈优化处理等。
Redis资源使用饱和度监控，设置合理阀值；
一些常用容量指标：redis内存使用比例，swap使用，cpu单核的饱和度等；当资源使用容量预警时，能及时扩容，避免因资源使用过载，导致故障。
另一方面，如果资源利用率持续过低，及时通知业务，并进行redis集群缩容处理，避免资源浪费。
进一步，容器化管理redis后，根据监控数据，系统能自动地弹性扩容和缩容。
Redis性能监控管理，及时发现性能瓶颈，进行优化或扩容，把问题扼杀在”萌芽期“，避免它”进化“成故障。
Redis硬件资源利用率和成本从老板角度来看，最关心的是成本和资源利用率是否达标。
如果资源不达标，就得推进资源优化整合；提高硬件利用率，减少资源浪费。砍预算，减成本。
资源利用率是否达标的数据，都是通过监控系统采集的数据。
这一小节，扯了这么多； 只是强调redis不是只有一个端口存活监控就可以了。
下面进入主题，怎么采集redsis监控数。
老板曾说：监控告警和数据备份，是对DBA和SRE最基础也是最高的要求；
当服务和存储达到产品规模后，可认为“无监控，不服务；无备份，不存储”。
Redis监控数据采集redis监控的数据采集，数据采集1分钟一次，分为下面几个方面：
服务器系统数据采集 Redis Server数据采集 Redis响应时间数据采集 Redis监控Screen 服务器系统监控数据采集服务器系统的数据采集，这部分包含数百个指标. 采集方式现在监控平台自带的agent都会支持
如Zabbix和Open Falcon等，这里就不介绍采集方法。
我们从redis使用资源的特性，分析各个子系统的重要监控指标。
服务器存活监控 ping监控告警 CPU 平均负载 (Load Average): 综合负载指标(暂且归类cpu子系统)，当系统的子系统出现过度使用时，平均负载会升高。可说明redis的处理性能下降(平均响应时间变长、吞吐量降低)。 CPU整体利用率或饱和度 (cpu.busy): redis在高并发或时间复杂度高的指令，cpu整体资源饱和，导致redis性能下降，请求堆积。 CPU单核饱和度 (cpu.core.idle/core=0): redis是单进程模式，常规情况只使用一个cpu core, 单某个实例出现cpu性能瓶颈，导致性能故障，但系统一般24线程的cpu饱和度却很低。所以监控cpu单核心利用率也同样重样。 CPU上下文切换数 (cpu.switches)：context swith过高xxxxxx 内存和swap 系统内存余量大小 (mem.memfree)：redis是纯内存系统，系统内存必须保有足够余量，避免出现OOM，导致redis进程被杀，或使用swap导致redis性能骤降。 系统swap使用量大小 (mem.swapused)：redis的”热数据“只要进入swap,redis处理性能就会骤降； 不管swap分区的是否是SSD介质。OS对swap的使用材质还是disk store. 这也是作者早期redis实现VM,后来又放弃的原因。说明：系统内存余量合理，给各种缓冲区，fork cow足够的内存空间。
另一个问题：我的系统使用Redis缓存集群，”不怕挂，就怕慢“，或redis集群高可用做得厉害；这样redis的服务器是否能关闭swap呢？
磁盘 磁盘分区的使用率 （df.bytes.used.percent)：磁盘空间使用率监控告警，确保有足磁盘空间用AOF/RDB, 日志文件存储。不过 redis服务器一般很少出现磁盘容量问题 磁盘IOPS的饱和度(disk.io.util)：如果有AOF持久化时，要注意这类情况。如果AOF持久化，每秒sync有堆积，可能导致写入stall的情况。 另外磁盘顺序吞吐量还是很重要，太低会导致复制同步RDB时，拉长同步RDB时间。（期待diskless replication） 网络 网络吞吐量饱和度(net.if.out.bytes/net.if.in.bytes)：如果服务器是千兆网卡（Speed: 1000Mb/s），单机多实例情况，有异常的大key容量导致网卡流量打n