1 问题除了像 监控从大的层面来说有两种,一种是监控用来拦截的,即有依赖的,一种只是用来报警和分析的。 由于依赖接入源较多,以下问题常有发生: 1.1数据延时产出,数据产出空分区,数据质量可能有问题(条数,时间戳不对)一般处理过程:花费时间30m+ 处理-延时问题→ 去易创上找依赖图,确认是哪个上游产出表没有产出->复制表名->去数据地图里面找负责人->一般会拉群跟进-->等处理完-->同步或者不同步/关注方→同步产出好了 1.2使用方无意识使用到错误数据,花费时间60m + 处理-空分区问题处理过程: 需要对最终的产出标签的分布等进行质量监控,暂时没有->如果发现以后->复制表名->去数据地图里面找负责人->一般会拉群跟进-->等处理完-->同步或者不同步/关注方→回溯数据->通知使用方数据问题 1.3使用方先意识使用到错误数据花费时间60m +数据质量问题 (条数,时间戳)→ 一般只有等标签使用方发现才能意识到->问题复现->复制表名->去数据地图里面找负责人->一般会拉群跟进-->等处理完→同步或者不同步/关注方→同步产出好了 1.4 数据延时产出问题有一些例行的,必须在每天xx点产出的数据,如果没有生成好,就要人为去挨个找上游负责人去找问题,与1.1.3中的问题类似,都是要手动找上游。 2解决思路基于以上问题,我们发现这些问题,都是监控不完善,完善的监控应该是怎么样的呢? 在已知问题内,只要给表或者数据的标签分布加了监控,那么当出现问题时候,可以自动通知到数据使用方,数据发布方,当问题抛出来给某人以后,他可以选择,将此次报警置为处理中,后续在xx时间内处理好,如果处理不好继续报警,但是报警范围可能更大,比如给负责人经理电话,邮件,短信,拉群艾特等。这样有另外一个好处是数据的sla在一定程度上保证了,可以过后来查问题,或者在未来的“某些特殊场合”使用到。 需求如上,那么设计 监控独立于调度系统,与调度系统唯一的交互是done文件,调度在done文件产出后才继续执行。 1.2.0 为什么基于done文件呢? 任务依赖,对于任务依赖来说,为了对数据源的质量检测,就要对每个任务进行配置任务检测依赖,会有两个问题,其一是任务检测脚本会更分散,其二,检测逻辑很多是类似的,也会造成脚本冗余 表依赖,检测位置是表的分区,那么当数据质量检测通过后,生成一个表的分区,最终就是类似 dt=xxxx/rule=check_t1_count.done 类似这样 通过add partition 来添加 文件依赖,跟表依赖类似之处就是生成一个done文件,区别之处在于可以直接通过服务来调用生成done,较方便所以选文件依赖 1.2.1 done文件由一个唯一的表名+任务id.done组成 1.2.2 单点报警 + 多层处理报警,如果A表怎么样,B表怎么样,就报警给谁,具体有产出延时,失败报警 3设计开发1.任务信息 2.报警信息 3.表信息 4.监控逻辑表 5.监控与报警关联表 6.监控与表信息与任务信息的关联表 基于 主要开发,等后续再分享, |
|