这两天在对一个项目的接口加case监控，中间也有了自己的理解，特来分享给大家：
一、监控的目的
1、检验核心逻辑的正确性
2、能够实时监控接口状态，防止发生异常无法及时发现，从而不能够及时处理，导致线上事故
二、哪些case需要加监控
首先，case分为四类：
全case：测试过程中编写的所有case
checklist：覆盖全部需求的case
主路径：覆盖核心功能逻辑的case
冒烟：核心case，一般这条case不通过，基本能确定接口已经崩了
加监控时，一般是加冒烟类别的case，最多加到主路径类别的case
三、什么情况下配置什么样的监控报警条件
监控的报警条件有，一次出错即报警，连续三次出错后报警、1h出错5次报警等，大多情况下，是连续三次出错会报警。
一次出错即报警：
1、不允许出任何错误，比如牵扯到利益的红包、优惠券、积分、金币等逻辑
2、一次出错能确定程序已经崩了
连续三次出错报警：
1、一次出错可能会误判，比如执行这条case时，实现报警机制的逻辑出错
2、允许出现偶然性错误
四、监控的频率是多长时间一次，由什么决定
监控的频率时长通常有1分钟一次，5分钟一次，10分钟一次、30分钟一次等
1、报警条件是一次还是三次。如果是三次，频率时长相对要设置短一点，因为报警时间=报警条件（3）*频率时长
2、线上QPS。如果线上QPS较高，频率时长要短，减少损失
3、监控的检查点是新功能，还是已上过线的旧版本。新功能的稳定性不好保证，所以监控要密集一点；已经上线的旧版本，基本说明已经能稳定运行了，所以不用加太密集的监控耗费资源
五、要与开发确认的事项
1、报警后怎么保证能够及时收到通知
2、收到通知后怎么保证能够及时处理
3、业务是否有容灾能力，即服务端异常无结果时，客户端怎么处理，能让用户发觉不到出现了bug
4、业务是否有回滚能力，即新功能上线后，出现bug，能够及时回滚，再去花时间排查
5、如果出现bug，目标多长时间能够解决