随着字节跳动业务的快速发展,大数据开发场景下需要运维管理的任务越来越多,然而普通的监控系统只支持配置相应任务的监控规则,已经不能完全满足当前需求,在日常运维中开发者经常会面临以下几个问题:
- 任务多,依赖关系复杂:很难查找到重要任务的所有上游任务并进行监控。如果监控所有任务,又会产生很多无用报警,导致有用报警被忽略;
- 配置运维成本高:每个任务的运行情况不一样,承诺完成时间不一样,如果单独对每个任务设置监控,分析及人工对齐任务SLA成本非常高;
- 报警形式多样性:对于小时级的任务,不同时段的报警及时性要求不同,普通监控无法很好得满足不同时段多样的报警需求。
实际案例
本节将从一个实际案例出发,介绍基线监控相较于普通监控的核心优势。 用户小明有一个对外承诺了的SLA任务,10点前必须要产出。其上下游关系如下图所示,其中SLA任务和任务4、5属于项目B,其他项目属于项目A。小明仅具有项目B的运维权限。![](/i/l/?n=23&i=blog/2691015/202306/2691015-20230606150305906-1462680928.jpg)
在没有基线监控前,为了保障SLA任务产出符合预期,小明会在SLA任务及其相同项目B内的上游任务上配置一系列告警规则,来预防上游任务延迟导致的SLA破线。比如在SLA任务和任务4、5上都配置了3条基础告警,以保证SLA任务延迟的风险及时感知和暴露,如下图所示。
![](/i/l/?n=23&i=blog/2691015/202306/2691015-20230606150322022-1694823169.jpg)
但这种方式的问题也是显而易见的:利用基础监控规则,至少需要配置9条规则,才能基本完成对SLA任务的监控;而且监控规则的配置方式大多来自于专家经验,但仍有遗漏的风险;基础监控规则只能监控到有运维权限的项目,不属于本项目的上游任务是无法监控到,因此小明也就无法提前感知到延迟风险。有了基线监控,小明就只需要将SLA任务作为“保障任务”加入到基线监控中,保障任务的所有上游节点默认会被基线监控覆盖,小明再也不用配置多条基础告警规则,极大降低了告警规则配置的难度;一旦基线监控配置好之后,任意上游任务延迟,对小明来说都可以快速感知到,可有效保障SLA任务按时产出。 通过上面的实际案例,你应该对基线有了一个大概的理解。下篇文章,就让我们一起了解下基线监控的相关概念和系统架构,并详细了解下基线监控的核心实现逻辑吧。 标签:常见问题,DataLeap,运维,报警,任务,基线,监控,链路,SLA From: https://www.cnblogs.com/bytedata/p/17460595.html