泛化监控系统_通过埋点和机器学习

父文章 稳定性之 监控,报警,定位 架构师该做什么. 偏数据分析视角,智能定位. 2/5/15 of 安全生产_个人渣记录仅为自己搜索用的博客-CSDN博客

投屏问题如何监控.

边界

1.用户行为是边界 2.代码作为两个边界之间的执行体,就是监控的对象.

埋点图

任何埋点都整理成图,对应的比例关系在统计层面都是差不多不变的.

基于埋点图的统计监控:

 如果某个埋点数低了,那么就要从哪些没有了下游埋点的埋点中去找对应的问题,假设A埋点后肯定是B埋点. A,B埋点之间只有代码. 那么逻辑上A埋点和B埋点的数量应该是一致的. 或者说除去某些业务异常外,A,B埋点数量是一致的. 故存在A成功-B和A失败-X埋点. 需要对A打标. 

异常case定位

怎么找case,这个时候就需要一个唯一标识了. 一般这个就是uid加单位分钟. 通过01分钟的A,01-02分钟内都没有出现过B.这些A筛选出来就是可用于case分析的例子.

Q: 如果有正常情况就是没有B,那么定位就会非常难.

A: 不会除非是有用户的行为没有埋点, 不然肯定是完备的

跨用户的埋点串联

如果类似投屏垮了用户和智能设备,需要把用户uid和设备uid关联起来,也就是需要一个sessionId. 不然无法找到那些缺失了B埋点的A埋点,进行case分析.

 其实埋点的时候,也会有一个sessionId,一般是软件激活时更新. 对于监控报警来说一般不需要,

进一步地缩小到某个具体业务:

  例如投屏,几个行为串联起来. 作为业务状态监控,避免出现那种大流量接口少了一些发现不了.

后来想了想上诉还是不够通用:

归本溯源,还是要模拟服务端接口. 对每次代码进行try Catch 或者 对result码进行监控. 成功数监控,失败数监控,耗时监控.

外加可通过灰度id监控+体感报警监控.来解决大流量少了一部分发现不了的问题.

最终还是监控好每段独立的代码即可,异步的单独添加,弱依赖的单独添加..丢失问题不是很大.

端上的是异步回调,无非是将服务端的一个监控变成了三个(主动调用一个,失败回调一个,成功回调一个; 主动调用,除了自己代码,基本不会出现异常,重点监控, 失败回调属于依赖监控,需要知道,需要做好降级,做好推进解决.,失败回调里的代码需要重点监控, 成功回调需要重点监控. )

关键是端上如果没有好的框架,统一监控比较难. 埋点还是有用的.

综上所诉:

   埋点是粗粒度,且要求一个行为后续所有行为埋点都完备,不然可报警但不好定位. 类似状态机. 不可操作性

   代码段tryCatch监控是细粒度,提供更精准的定位和分析,且有一个报警和定位都具备. 可操作性.