[原创] 体感监控,体感报警体系

如何从用户来看监控系统?

1. 用户视角法. 梳理用户的每个业务操作步骤,想想这一步有可能出哪些错误.怎么监控. 每个状态机切换的action都会出错.

2. 接口体感监控法. 用户失败了会连续重试.

体感监控解决什么核心问题?

    1. 灰度小流量下的错误监控(服务器级,功能级). 其他小流量场景同样适用.

    2. 每次上线回归遗漏掉的核心流程.[量少] (回归自动化测试不是想象中的那么容易实现)

老的监控体系有什么缺点?

     1. 面对服务器粒度小流量,或者服务器粒度灰度流量需要专门设计报警阈值,比较麻烦,也容易遗漏. 

     2. 功能小流量要观察灰度流和非灰度流的大小,也要专门设置报警阈值.补充设置.

       传统报警1. 需要专门进行配置较低的阈值,2.较低的阈值容易误报 3.功能小流量容易遗忘配置. 

为什么要体感监控,体感报警体系?

       有没有什么方法可以解决上述问题.那就是体感监控,体感报警体系.

两者的关系?

   1. 体感是一种有效补充,而不是替代. 每次发布,功能小流量,整体小流量的新增error,线程池检查都是非常必要的.

还需要什么补充?

    值班观察体系是极佳的补充,特别是上线灰度后的值班观察:

        1. 预发环境,灰度机器上的增量error日志查看,有一个就需要专门分析. ( 整合到发布系统上去. 发布会的error 对比发布前的error 相似度对比. )

        2. 对应流量接口耗时增加对比.

  

体感报警分几个阶段.

 

   1.0  服务端throw异常感知,filterException sysError

   2.0  服务端业务异常感知,通过BO Bean中字段返回.bizError

   3.0  异步异常感知.

   4.0  服务端弱依赖异常感知,新的 weekError. 

   5.0 串联端上的场景进行告警.

   6.0  端上的体感报警. 例如h5渲染,例如蓝牙连接失败,例如wifi获取失败. 通过端上的性能监控体系. 阿里的话就是魔点.

   7.0  五级粒度报警体系, 异步化,稍微延后. orgId粒度(公司网络整体不行,投屏卡顿,提示用户进行网络检测.注意不能直接告知用户网络不行), 区域粒度(某个区域4G用户网络不佳,代驾时期的监控)