共计 1134 个字符，预计需要花费 3 分钟才能阅读完成。
随着字节跳动业务的疾速倒退，大数据开发场景下须要运维治理的工作越来越多，然而一般的监控零碎只反对配置相应工作的监控规定，曾经不能齐全满足以后需要，在日常运维中开发者常常会面临以下几个问题：
- 工作多，依赖关系简单：很难查找到重要工作的所有上游工作并进行监控。如果监控所有工作，又会产生很多无用报警，导致有用报警被疏忽；
- 配置运维老本高：每个工作的运行状况不一样，承诺实现工夫不一样，如果独自对每个工作设置监控，剖析及人工对齐工作 SLA 老本十分高；
- 报警模式多样性：对于小时级的工作，不同时段的报警及时性要求不同，一般监控无奈很好得满足不同时段多样的报警需要。
为了无效运维日常工作，保障数据品质，字节跳动数据平台开发套件数据开发团队自研了基于依赖关系的全链路智能监控报警——基线监控，能依据工作运行状况，智能决策是否报警、何时报警、如何报警以及给谁报警，保障工作的整体产出链路。基线监控已在字节跳动外部失去宽泛应用，笼罩抖音、电商、广告等 100+ 个我的项目，SLA 工作的基线监控覆盖率超过 80%。
目前，这一能力也曾经通过火山引擎 DataLeap 向企业凋谢。企业能够通过火山引擎 DataLeap 基线监控，无效升高监控配置老本、防止有效报警及报警泛滥。
理论案例
本节将从一个理论案例登程，介绍基线监控相较于一般监控的外围劣势。
用户小明有一个对外承诺了的 SLA 工作，10 点前必须要产出。其上下游关系如下图所示，其中 SLA 工作和工作 4、5 属于我的项目 B，其余我的项目属于我的项目 A。小明仅具备我的项目 B 的运维权限。
在没有基线监控前，为了保障 SLA 工作产出合乎预期，小明会在 SLA 工作及其雷同我的项目 B 内的上游工作上配置一系列告警规定，来预防上游工作提早导致的 SLA 破线。比方在 SLA 工作和工作 4、5 上都配置了 3 条根底告警，以保障 SLA 工作提早的危险及时感知和裸露，如下图所示。
但这种形式的问题也是不言而喻的：利用根底监控规定，至多须要配置 9 条规定，能力根本实现对 SLA 工作的监控；而且监控规定的配置形式大多来自于专家教训，但仍有脱漏的危险；根底监控规定只能监控到有运维权限的我的项目，不属于本我的项目的上游工作是无奈监控到，因而小明也就无奈提前感知到提早危险。有了基线监控，小明就只须要将 SLA 工作作为“保障工作”退出到基线监控中，保障工作的所有上游节点默认会被基线监控笼罩，小明再也不必配置多条根底告警规定，极大升高了告警规定配置的难度；一旦基线监控配置好之后，任意上游工作提早，对小明来说都能够疾速感知到，可无效保障 SLA 工作按时产出。
通过下面的理论案例，你应该对基线有了一个大略的了解。下篇文章，就让咱们一起理解下基线监控的相干概念和零碎架构，并具体理解下基线监控的外围实现逻辑吧。
