关于数据挖掘:DataLeap的全链路智能监控报警实践一常见问题

随着字节跳动业务的疾速倒退,大数据开发场景下须要运维治理的工作越来越多,然而一般的监控零碎只反对配置相应工作的监控规定,曾经不能齐全满足以后需要,在日常运维中开发者常常会面临以下几个问题:

  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工作按时产出。

通过下面的理论案例,你应该对基线有了一个大略的了解。下篇文章,就让咱们一起理解下基线监控的相干概念和零碎架构,并具体理解下基线监控的外围实现逻辑吧。

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理