后台的系统模块非常多,链条非常长,有时为了避免麻烦,只在前端加了监控,如果出问题则报警
这个报警还是比较有用的,能发现很多问题;
但到现在发现只在前端加监控明显不够,前端的监控是比较简单,他不需要管系统内部模块的组成,
相当于把系统内部当成黑盒测试,产生的问题其实和测试一样,黑盒测试能发现问题,但经常解决不了问题,
或者说解决的问题的成本过高,一般来说,测试需要单元测试+模块单点测试+前端黑盒测试,这样才能尽可
能的发现问题,解决问题;
监控也应该像测试一样,既需要监控接口,比如:最终系统响应速度,最终成功率,失败率之类;
接口处的监控最接近用户,最能反应用户的问题;同时,监控也需要白盒监控,即对系统涉及的所有模块进
行监控,这时候,指标就和各个模块的功能相关了,比如:cache 模块一般需要监控cache命中率,db模块
最需要监控db响应速度,失败率之类,业务模块需要监控业务status;
最理想的情况是系统的监控能形成一个又一个的实时图表,每个图表都能直观的简洁的反应各个模块
的运行状况,运行指标;
最坏的情况是系统基本没有监控,系统在干什么,干的怎么样,完全一无所知,曾经经常出现过多次
的情况是:系统是分布式的,有时用户抱怨他的账户或者数据有问题,然后我们就拿他的帐号去测试,经常发
现是成功的,正常的;然后就回复用户说:系统应该正常,再多试几次,然后的然后,然后用户体验迟迟不能
提高,用户就走了。。。
“系统应该正常”这完全是猜测的语气,系统要么正常,要么不正常,要拿效果拿数据说话,而不是
靠臆度靠揣测;分布式的系统有时会产生这种某批用户是正常的,然后某小批用户不正常,这时候,如果没有
完善的监控,是很难发现这个问题的;
以前发现问题,解决问题非常依赖日志,但log确实是远远不够的,他太不直观,太难以发现规律,
发现问题,太难以衡量整个系统的运行状况。仅仅依靠 WARN 和 ERROR 的出现是非常不够的。。。
现在对 mysql 的慢查询加了监控,对dbp cache命中率加了监控,对系统出口处加了监控,只有这样
完善完整的一系列监控才能更好的发现问题,而且当问题出现的时候,迅速的定位到问题,然后解决之!!
阅读(3542) | 评论(0) | 转发(1) |