数据之道 | SLA/SLE监控与告警

供稿 | eBay DSS Team

作者 | 冯奕彬

编辑 | 顾欣怡本文2622字，预计阅读时间8分钟更多干货请关注“eBay技术荟”公众号

导言

eBay 现在处理的数据量达数百PB，每天执行的数据作业量超过100,000，这对 eBay 大数据系统有着很高的要求。高质量、高可靠、准时到达的数据不仅仅是AI、数据建模的基础，更是eBay业务部门做业务决策的重要基石。

iDO（Intelligent Data Operation）是eBay大数据部门的数据运维智能化平台， 其重要功能之一就是监控数据作业流中的异常。本文一方面是展示iDO平台在2019上线的数据作业的监控策略，即如何从大量的job中发现可能导致delay的隐患，一方面也是对目前策略的总结和探讨，以期更智能更精确的数据监控。

Q1:我们在做什么？

简单的说，就是在发现目标数据预计生成时间晚于设置的deadline时，发出告警提醒我们的工程师，从而让数据作业可以满足向用户承诺的SLA（Service Level Agreement），避免可能发生的delay。

为了实现这个目标：

1. 需要监控job的实时运行情况从而获得数据流的状态；

2. 需要从数据流的状态中估算出目标done file是否可能晚于deadline生成。

这里面有两个很重要的指标：

1. Precision/Recall，准确度和召回率，即不多告警也不漏告警，这是告警策略能被依赖的基础；

2. 时效性，告警发出后留给工程师解决问题的时间，这是告警能够帮助工程师避免数据miss的基础。

当然，这两者存在某种程度的互斥，在后面会进行阐述。

理想的结果是，我们的工程师仅需在收到告警的时候去关注告警所指向的异常位置，即可避免绝大多数的miss，同时这些告警也不会造成过多的打扰。

Q2:为什么替换原告警策略？

原先的策略是，我们在目标数据的上游选取关键节点，监控这些关键节点的完成时间，如果完成时间晚于平均完成时间很多，就在这个节点上发出告警。类似于项目管理中里程碑的概念。例如下图中绿色节点所示：

这种策略从整个流程中取样出关键节点，并用关键节点的状态代替整体的状态。实现简单，同时告警内容易于说明。将一个整体目标拆成了多个里程碑，所有的里程碑都应该按时完成。这其实是一种非常严格的监控策略，优点很明显，几乎不会发生漏报。但缺点是会产生大量的误报，据以往的统计数据来看，误报率在30%左右。同时也不利于异常的检查，因为告警的内容是某个节点晚于平时完成了，收到告警的工程师需要相关的经验才能知道造成异常的原因。为了使这个策略在上述的指标上表现良好，需要工程师合理地选取关键节点，并设置关键节点的超时阈值，这非常依赖于经验。我们认为单纯依赖经验不够完善，无法与实时的数据作业运行状态相结合；另外误报率太高，工程师被打扰的次数太多，因此希望改善这个策略，更多地通过数据来说话。

Q3:新告警策略是什么？

新策略的想法来自于项目管理的关键路径。关键路径是指设计中从输入到输出经过的延时最长的逻辑路径。而在数据作业监控的实际场景下，关键路径指的就是在一个含有多条并行或串行的工作节点连接起来的拓扑图中，完成时间最长的一条路径。下图中紫色节点组成的路径就是关键路径，这里假设每个节点的工作时间期望都是相同的。

从里程碑监控变为关键路径监控，就能让数据具备自己决定关键节点的能力，并且这些关键节点是动态变化的，产生的告警就会聚焦于决定目标完成时间的那部分job节点。这样就会大量减少误报率，因为原策略中根据经验选择的关键节点不在关键路径上的监控就会撤销，不再因此而产生误报。在关键路径策略上线的第一个月，我们并行使用了原有的策略，在相同条件下分别统计告警指标：

Q4:如何处理每天的冷启动？

获取每日job流程图的结构，有两部分数据来源，一部分是job的动态指标，即每天实际运行的job的开始时间、执行状态、run id等等；另一部分是job的静态信息，包含了工作流的关系，比如前驱、后继、包含等，可在job实际运行之前获得。将两部分结合起来，当实际运行的job没完全启动的时候，用静态的job信息，填入能获取的部分动态指标；若实际运行job已完全或基本启动，则仅使用动态信息，因为用动态指标可以更准确地表示当天的实际运行情况。

Q5:如何处理节点大小分布不均衡的问题，是否需要人为设置关键节点？

我们关注的是关键路径，实际上就是将自动计算出来的关键路径中的job节点作为重点关注的节点。而在这些节点中，计算运行进度是考虑节点的已用时间的，用已用时间和预计完成时间计算其预估完成进度，部分job还可获取实际完成进度。换句话说，我们是将有向图转换成了进度条，检查其中是否发生了卡顿或是进展过于缓慢，如下图所示：

所以节点大小不均衡就不会成为问题，同时也是无需设定关键节点的，只需设定最终目标。

Q6:在可视化流程图时，如何处理节点数量过多的问题？

在实践中发现，被监控的一个流程图会有超过1,000的节点，很难进行展示。

（点击可查看大图）

当然在具体实现中会有一些预处理，像是去除运行时间基本为0的节点（不对最终完成时间产生影响的节点），例如start/end，但并不能使节点数量在数量级上有所下降。此外也有一些UI上的设计，但都不能从根本上解决这个问题，依旧很难同时将所有节点清楚地展示在一个网页中。所以我们在可视化的时候实现了一个临时的解决方案，只同时展示当前运行节点以及这些节点的上下游，并限定上下游的深度。只有在job全部完成且不再存在当前运行节点时，我们才给出完整视图。在完整视图中也会提供筛选功能，例如查看critical path，查看特定job或是table的上下游。

Q7:如何处理告警准确度和时效性的矛盾？

越是接近deadline的告警当然越准，但这样的告警对避免数据miss并没有作用；而过早的告警则会产生很多的误报。我们在实践中尝试过很多方式去减少误报或是减少漏报，最终保留下来的几个方式就形成了现在的分级告警：

1. 预计完成时间超过deadline。

2. 执行过于缓慢或是发生了卡顿。
3. job执行状态异常，或是发生了重启。

在准确度上，1>2>3; 在时效性上3>2>1。1的准确度很高，一旦发生这种级别的告警，设定的目标就很难在deadline之前完成了，所以建议设定的deadline比实际的deadline早1小时左右。2的时效性会很好，异常的卡顿是造成最终miss的真正原因，但也会造成一定程度的误报。3是对1和2的补充，准确度偏低。

我们在策略的运行速度上也做了很多优化，比如大量的缓存以及多线程计算等等，将原本最高30分钟的反应时间降低到2分钟以内，尽可能提高时效性。

Q8:有什么改进方向？

我们在实际运行中发现，目前的关键路径策略存在两个问题，一个是从关系型数据库中读取信息组成有向图的过程较为费时：目前流程图中各个job节点的属性以及相互依赖关系都是从关系型数据库中读取出来组成有向图的数据格式放在内存中，不断更新其中各个节点的状态；一个是在实际运行中会不断发现之前未被覆盖的特殊情况，在把所有情况都纳入计算之后，算法逻辑也就变得特别复杂，导致测试验证变成了一件很困难的事情。

所以一个改进思路是图数据库，如果一开始将数据存在图数据库中，可能会赋予告警算法更为高效灵活的特性。将告警算法与图数据库结合也是某种程度的抽象，或许可以回馈开源社区。另一个改进思路是机器学习，将策略向更为智能的方向改进。既然关键路径策略的细节特别复杂，步骤很多，不如考虑使用ML端到端地给出一个告警，比如70%的概率将发生miss；或是用ML进行异常检测，将发现异常的位置作为告警的内容。

您可能还感兴趣：

👇点击阅读原文，一键投递 

    eBay大量优质职位，等的就是你