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

投屏问题如何监控.

边界

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监控是细粒度,提供更精准的定位和分析,且有一个报警和定位都具备. 可操作性.

 

   

 

 

 

 

发布了369 篇原创文章 · 获赞 69 · 访问量 86万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览