系统监控之重要性

后台的系统模块非常多，链条非常长，有时为了避免麻烦，只在前端加了监控，如果出问题则报警

这个报警还是比较有用的，能发现很多问题；

但到现在发现只在前端加监控明显不够，前端的监控是比较简单，他不需要管系统内部模块的组成，

相当于把系统内部当成黑盒测试，产生的问题其实和测试一样，黑盒测试能发现问题，但经常解决不了问题，

或者说解决的问题的成本过高，一般来说，测试需要单元测试+模块单点测试+前端黑盒测试，这样才能尽可

能的发现问题，解决问题；

监控也应该像测试一样，既需要监控接口，比如：最终系统响应速度，最终成功率，失败率之类；

接口处的监控最接近用户，最能反应用户的问题；同时，监控也需要白盒监控，即对系统涉及的所有模块进

行监控，这时候，指标就和各个模块的功能相关了，比如：cache 模块一般需要监控cache命中率，db模块

最需要监控db响应速度，失败率之类，业务模块需要监控业务status；

最理想的情况是系统的监控能形成一个又一个的实时图表，每个图表都能直观的简洁的反应各个模块

的运行状况，运行指标；

最坏的情况是系统基本没有监控，系统在干什么，干的怎么样，完全一无所知，曾经经常出现过多次

的情况是：系统是分布式的，有时用户抱怨他的账户或者数据有问题，然后我们就拿他的帐号去测试，经常发

现是成功的，正常的；然后就回复用户说：系统应该正常，再多试几次，然后的然后，然后用户体验迟迟不能

提高，用户就走了。。。

“系统应该正常”这完全是猜测的语气，系统要么正常，要么不正常，要拿效果拿数据说话，而不是

靠臆度靠揣测；分布式的系统有时会产生这种某批用户是正常的，然后某小批用户不正常，这时候，如果没有

完善的监控，是很难发现这个问题的；

以前发现问题，解决问题非常依赖日志，但log确实是远远不够的，他太不直观，太难以发现规律，

发现问题，太难以衡量整个系统的运行状况。仅仅依靠 WARN 和 ERROR 的出现是非常不够的。。。

现在对 mysql 的慢查询加了监控，对dbp cache命中率加了监控，对系统出口处加了监控，只有这样

完善完整的一系列监控才能更好的发现问题，而且当问题出现的时候，迅速的定位到问题，然后解决之！！