对于任何应用服务和组件,都需要一套完善可靠谱监控方案。
尤其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性能监控管理,及时发现性能瓶颈,进行优化或扩容,把问题扼杀在”萌芽期“,避免它”进化“成故障。