共计 5984 个字符，预计需要花费 15 分钟才能阅读完成。
更多技术交换、求职机会、试用福利，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
字节跳动数据平台开发套件数据开发团队自研了基于依赖关系的全链路智能监控报警——基线监控，目前已在字节跳动外部失去宽泛应用，笼罩抖音、电商、广告等 100+ 个我的项目，SLA 工作的基线监控覆盖率超过 80%。
随着字节跳动业务的疾速倒退，大数据开发场景下须要运维治理的工作越来越多，然而一般的监控零碎只反对配置相应工作的监控规定，曾经不能齐全满足以后需要，在日常运维中开发者常常会面临以下几个问题：
工作多，依赖关系简单：很难查找到重要工作的所有上游工作并进行监控。如果监控所有工作，又会产生很多无用报警，导致有用报警被疏忽；
配置运维老本高：每个工作的运行状况不一样，承诺实现工夫不一样，如果独自对每个工作设置监控，剖析及人工对齐工作 SLA 老本十分高；
报警模式多样性：对于小时级的工作，不同时段的报警及时性要求不同，一般监控无奈很好得满足不同时段多样的报警需要。
为了无效运维日常工作，保障数据品质，字节跳动数据平台开发套件数据开发团队自研了基于依赖关系的全链路智能监控报警——基线监控，能依据工作运行状况，智能决策是否报警、何时报警、如何报警以及给谁报警，保障工作的整体产出链路。
基线监控已在字节跳动外部失去宽泛应用，笼罩抖音、电商、广告等 100+ 个我的项目，SLA 工作的基线监控覆盖率超过 80%。
理论案例
本节将从一个理论案例登程，介绍基线监控相较于一般监控的外围劣势。
用户小明有一个对外承诺了的 SLA 工作，10 点前必须要产出。其上下游关系如下图所示，其中 SLA 工作和工作 4、5 属于我的项目 B，其余我的项目属于我的项目 A。小明仅具备我的项目 B 的运维权限。
在没有基线监控前，为了保障 SLA 工作产出合乎预期，小明会在 SLA 工作及其雷同我的项目 B 内的上游工作上配置一系列告警规定，来预防上游工作提早导致的 SLA 破线。比方在 SLA 工作和工作 4、5 上都配置了 3 条根底告警，以保障 SLA 工作提早的危险及时感知和裸露，如下图所示。
但这种形式的问题也是不言而喻的：
利用根底监控规定，至多须要配置 9 条规定，能力根本实现对 SLA 工作的监控；监控规定的配置形式大多来自于专家教训，但仍有脱漏的危险；根底监控规定只能监控到有运维权限的我的项目，不属于本我的项目的上游工作是无奈监控到，因而小明也就无奈提前感知到提早危险。
有了基线监控，小明就只须要将 SLA 工作作为“保障工作”退出到基线监控中，保障工作的所有上游节点默认会被基线监控笼罩，小明再也不必配置多条根底告警规定，极大升高了告警规定配置的难度；一旦基线监控配置好之后，任意上游工作提早，对小明来说都能够疾速感知到，可无效保障 SLA 工作按时产出。
通过下面的理论案例，你应该对基线有了一个大略的了解。上面，就让咱们一起理解下基线监控的相干概念和零碎架构，并具体理解下基线监控的外围实现逻辑吧。
概念解读
基线监控
依据监控规定和工作运行状况，基线监控可能决策是否报警、何时报警、如何报警以及给谁报警。基线监控保障的是工作整体产出链路。基线监控的外围指标包含：
笼罩链路中的所有工作；
升高工作监控配置老本；
防止有效报警。
保障工作
个别抉择有 SLA 要求的工作作为保障工作退出基线，基线通过保障工作的依赖拓扑图主动监控上游工作，造成须要监控的工作链路。
工夫定义
承诺工夫：最晚实现工夫，即 SLA。
预警余量：基线 SLA Buffer，耗费预警余量即触发基线预警。
预警工夫：工作承诺工夫 – 预警余量，即工作预期最晚实现工夫。
预测运行时长：基于工作历史的执行状况预测当前任务执行的运行时长。
承诺最晚开始工夫：承诺工夫 - 工作预测运行时长。
预警最晚开始工夫：预警工夫 - 工作预测运行时长。
各工夫的关系如下图所示：
监控范畴
基线默认监控的范畴包含：基线保障工作及保障工作上游的所有工作。
如下图所示，保障工作 D，E 及它们所有的上游节点都会纳入基线监控范畴，而工作 C，F 不受基线监控。值得阐明的是，基线监控容许用户配置基线监控只笼罩“指定我的项目”下的工作，此时基线监控的范畴就只蕴含了保障工作及这些我的项目下的上游工作。
基线实例
和工作相似，基线也有业务工夫的概念。对工作来说，一个业务工夫会生成一个工作实例；而对基线来说，一个业务工夫会生成一个基线实例，负责监控同一业务工夫下保障工作的实例及其依赖的所有上游工作实例的运行状态。天基线和小时基线每天生成实例的规定如下：
天基线：每天生成一个基线实例，其业务工夫与该基线保障工作的业务工夫雷同；
小时基线：承诺工夫有两种设置形式：对立承诺和分时承诺。如果是对立承诺，则生成基线实例的个数为 24 个，每个基线实例的承诺工夫统一；如果是分时承诺，则每天生成 N 个基线实例，其中 N 为用户配置的监控业务工夫范畴蕴含的业务工夫数量，N 的范畴是[1,24]。
基线实例状态
- 平安：工作在预警工夫之前实现。
- 预警：工作在预警工夫未开始运行，但还未达到承诺工夫。
- 破线：工作在承诺工夫仍未运行实现。
- 其余：基线实例敞开或者基线没有关联工作时，基线实例所处的状态。
报警类型
基线监控反对十分丰盛的报警类型：
- 基线预警：基线监控的链路上，首个没有在基线预警工夫节点开始运行的节点。
- 基线破线：“基线破线”报警需满足以下两个条件：
工作节点的上游 (蕴含间接和间接上游) 没有呈现过破线；
该工作没有在破线工夫节点开始运行。 - 破线加剧：“执行变慢导致破线加剧”报警触发需满足以下两个条件：
工作所在链路已发送首次“基线破线”报警
工作运行耗时相较于预测运行耗时有所增加，具体来说：
a. 当工作理论开始工夫早于基线破线开始工夫时，将“破线开始工夫 + (预测运行耗时 * (1 + N%))”作为检测时间点，如果工作达到检测时间点时还没有运行实现，则触发告警；
b. 当工作理论开始工夫晚于破线开始工夫时，将“工作理论开始工夫 + (预测运行耗时 * (1 + N%))”作为检测时间点，如果工作达到检测时间点时还没有运行实现，则触发告警。 - 保障工作预警工夫未实现：基线预警工夫达到(承诺工夫 - 预警余量)，查看基线所有保障工作是否实现运行，若有保障工作未运行实现，且基线之前无预警、破线报警，则触发报警。
- 保障工作承诺工夫未实现：基线承诺工夫达到，查看基线所有保障工作是否实现运行，若有保障工作未运行实现，则触发报警。
- 工作失败事件：基线监控链路上，任意工作，重试完结仍失败，则触发失败事件。监控链路上的工作，产生失败事件则触发该报警。
基线事件
基线监控工作（保障工作及其上游工作），在执行过程中，若呈现失败、变慢等状况，将被当作基线的异样事件，进行记录。
- 变慢事件: 辨认基线监控工作（保障工作及其上游）运行变慢的状况。辨认条件为：工作运行时长较该工作的预测运行时长上涨了 X%，则视为一个变慢事件。
- 失败事件: 辨认基线监控工作（保障工作及其上游）运行失败的状况，辨认条件为：工作运行过程中呈现过失败，则视为一个失败事件。
基线事件的状态蕴含“新发现”和“已复原”两种。当基线监控的工作产生变慢或者失败事件时，基线事件状态更新为“新发现”；但如果工作最终实现了的话，基线事件的状态会被更新为“已复原”。
零碎实现
整体架构
- 基线治理模块：负责基线创立、更新、删除等操作，治理基线元信息，包含保障工作，承诺工夫，余量及报警配置等；
- 基线实例生成：零碎每天定时触发生成基线实例，生成实例的同时依据保障工作，由下而上逐层遍历 (BFS)所有上游工作并生成基线监控埋点。
生成基线监控埋点的过程中，会计算每个工作节点的预测运行时长，承诺工夫，预警工夫，预警最晚开始工夫，承诺最晚开始工夫。
此外，零碎会给基线监控工作增加基线出错 / 变慢报警规定，当工作执行触发规定后，通过根底报警服务发送基线报警事件； - 监控埋点校验：系统维护一个提早队列，依据校验工夫点（预警最晚开始工夫，承诺最晚开始工夫以及破线加剧工夫校验点)，定时触发监控埋点校验工作实例运行状态，如果在工夫点实例未运行胜利，产生基线预警 / 破线报警事件，发送给根底报警服务发送报警。
因为基线实例生成和基线埋点检测是基线监控的外围模块，因而本文只着重介绍下这两个模块。
基线实例生成
每天固定工夫点(如 22:00)，依据基线类型及业务日期生成对应的基线实例。
针对每一个基线实例，零碎依据该基线实例对应的监控链路 (工作 DAG)，由保障工作为终点，自下而上逐层(BFS) 计算各工作对应的监控埋点实例的校验工夫节点，包含预测运行时长、预警工夫、承诺工夫、预警最晚开始工夫，承诺最晚开始工夫。
如下图所示，上游工作 (B) 的预警工夫为其子工作实例埋点的预警最晚开始工夫，
工作节点中的数字示意工作的预测运行时长，如节点 A(1.5h)，示意 A 的预测运行时长是 1.5 小时。
如图所示，基线保障工作为 A，承诺工夫为 9:00，用户设置的预警余量为 0.5h，联合零碎推算出该工作本次的预测运行时长为 1.5h。因而，工作 A 监控埋点的预警工夫为 8:30(9:00-0.5h)，预警最晚开始工夫为 7:00(8:30-1.5h)，承诺最晚开始工夫为 7:30(7:00+0.5h)。
上下游工作之间监控埋点的各工夫节点办法如上图所示，满足：上游工作的承诺 (预警) 工夫 = 上游工作的承诺 (预警) 最晚开始工夫。
上图示例只是现实状况，但实际上工作链路会非常复杂，如跨层依赖、循环依赖十分常见。此外，工作链路也是有可能动态变化的，上游依赖新增或者缩小也是个普遍现象。
因而，基线实例生成时，须要针对上述情况进行解决，以保障基线监控的有效性和合理性。上面，咱们针对每种场景介绍基线监控算法的解决办法。
基线监控的工作链变动了怎么办？
目前，基线监控算法是通过基线实例生成时刻该基线监控的工作链路“快照”来生成监控埋点实例的，暂未针对监控埋点生成完结后，基线笼罩的工作链路发生变化的状况进行解决。即，用户操作工作并不扭转曾经生成的基线监控埋点实例的信息（计算得来的各种工夫及工作与基线的映射关系等），而是等到下一次生成基线实例的时候从新去计算。具体实现时，零碎会将工作 DAG 进行缓存(1h)，以进步埋点实例生成的效率。
基线笼罩的工作链路存在跨层依赖怎么办？
因为在计算监控埋点实例的时候是由下至上逐层计算的，能够了解为是个部分计算，无奈获取整个工作链路的全貌。因而，如果基线笼罩的工作链路中存在跨层依赖，那么同一业务工作实例上的监控埋点的工夫点须要不断更新至最早值。
如下图所示，工作 A 依赖工作 C 和 E，工作 C 依赖于工作 E，而工作 A 又间接依赖于工作 E。保障工作 A 的埋点实例计算完结之后，能够计算工作 B、C、D、E 的埋点实例信息；而当计算工作 C 的埋点实例信息时，工作 E 的埋点实例须要依据工作 C 的埋点实例信息进行更新。这样能力保障整个工作链路监控的合理性。
基线笼罩的工作链路存在循环依赖怎么办？
基线笼罩的工作链路中存在循环依赖，个别是因为某两个工作之间在业务工夫存在 offset 导致的。如下图所示，比方工作 B 业务工夫 23:00 的实例依赖工作 C 业务工夫 23:00 的实例，而工作 C 业务工夫 23:00 的实例又依赖于工作 A 业务工夫 22:00 的实例。
对于这种状况，解决准则为：只保留工作最新业务工夫 (latest_task_time) 对应的埋点实例，早于 latest_task_time 的业务工夫对应的埋点实例间接抛弃。这是思考到对更早工夫点的实例进行监控的意义不大，因为前一天的基线监控曾经发现出问题并触发告警了。
基线埋点校验
基线实例生成完结后，将生成的监控埋点实例保护到一个提早队列 BaselineTimeQueue 里，Delay 工夫节点、监控埋点实例校验阶段及对应阶段触发的报警类型三者之间的关系如下图所示：
- 基线监控埋点实例的初始阶段为基线预警校验阶段(CHECK_START_WARNING_TIME)，其 Delay 工夫点为预警最晚开始工夫(earliest_start_time_for_warning)。当达到 earliest_start_time_for_warning 工夫节点时，监控埋点对应的工作仍未开始运行，且该工作是该基线监控链路上的首个满足条件的工作，则基线实例的状态由安全更新为基线预警，并发送基线预警报警。无论是否触发报警，监控埋点实例的状态都会从 CHECK_START_WARNING_TIME 流转至基线破线校验阶段(CHECK_START_COMMIT_TIME)，并且从新放至提早队列中，期待基线破线的校验。
- 当达到承诺最晚开始工夫 (earliest_start_time_for_commit) 工夫节点时，监控埋点对应的工作仍未开始执行，且该工作是该基线监控链路上的首个满足条件的工作，则基线实例的状态由平安 / 基线预警更新为基线破线，并发送基线破线报警。
- 在基线破线校验完结之后，须要判断是否须要进入基线破线加剧校验阶段：
如果当前任务或其上游存在破线工作，且当前任务曾经开始执行，则基线实例状态更新为基线破线加剧查看阶段(CHECK_OVERTIME_INTENSIFY)，Delay 工夫为基线破线加剧校验工夫节点(overtime_intensify_time)，即工作理论开始工夫 + (预测运行耗时 * (1 + N%))；
如果当前任务尚未开始执行，则基线实例状态更新为期待基线破线加剧查看阶段(CHECK_WAIT_OVERTIME_INTENSIFY)，此时 Delay 工夫为期待基线破线校验工夫节点(wait_overtime_intensify_time)，即破线开始工夫 + (预测运行耗时 * (1 + N%))。
当达到 wait_overtime_intensify_time 工夫节点进行校验时，若工作仍未开始执行，则查看阶段放弃不变，wait_overtime_intensify_time 减少 30 秒，从新入队期待下次查看。
当达到 overtime_intensify_time 工夫节点进行校验时，若工作仍未运行胜利，则触发基线破线加剧报警，并将基线实例的状态更新为 FINISH_WITH_UNSAFE，埋点监控完结；若工作已运行胜利，则不触发报警，并将基线实例的状态更新为 FINISH_WITH_SAFE，监控完结。
将来
目前，基线监控这一能力也曾经通过火山引擎大数据研发治理套件 DataLeap 向企业凋谢。企业能够通过火山引擎 DataLeap 基线监控，无效升高监控配置老本、防止有效报警及报警泛滥。
将来，咱们将持续针对基线监控进行优化，如基线要害路径分析、基线实例生成效率优化等，一直进步基线监控算法性能，欠缺基线链路剖析能力，一直晋升用户体验，致力于向火山引擎 DataLeap 用户提供更弱小的全链路监控运维能力。
立刻跳转火山引擎大数据研发治理套件 DataLeap 官网理解详情！
