随着字节跳动业务的快速发展，大数据开发场景下需要运维管理的任务越来越多，然而普通的监控系统只支持配置相应任务的监控规则，已经不能完全满足当前需求，在日常运维中开发者经常会面临以下几个问题：

1. 任务多，依赖关系复杂：很难查找到重要任务的所有上游任务并进行监控。如果监控所有任务，又会产生很多无用报警，导致有用报警被忽略；

2. 配置运维成本高：每个任务的运行情况不一样，承诺完成时间不一样，如果单独对每个任务设置监控，分析及人工对齐任务 SLA 成本非常高；

3. 报警形式多样性：对于小时级的任务，不同时段的报警及时性要求不同，普通监控无法很好得满足不同时段多样的报警需求。

为了有效运维日常任务，保障数据质量，字节跳动数据平台开发套件数据开发团队自研了基于依赖关系的全链路智能监控报警——基线监控，能根据任务运行情况，智能决策是否报警、何时报警、如何报警以及给谁报警，保障任务的整体产出链路。基线监控已在字节跳动内部得到广泛使用，覆盖抖音、电商、广告等 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 任务按时产出。

通过上面的实际案例，你应该对基线有了一个大概的理解。下篇文章，就让我们一起了解下基线监控的相关概念和系统架构，并详细了解下基线监控的核心实现逻辑吧。