中国开源软件网

当前位置: 首页 > 生活服务 >

光大银行统一监控平台,第二个选型

时间:2020-06-03 22:27来源:互联网 作者:小狐

光大银行统一监控平台,第二个选型(图1)

本文根据胖亚鹏老师在〖deeplus直播第222期〗线上演讲内容整理而成。文末有获取本期PPT&回放的途径,不要错过

光大银行统一监控平台,第二个选型(图2)

大家好,我今天的主题是光大银行统一监控平台建设实践。

光大银行统一监控平台,定位是服务全行科技条线的IT监控,是运维之眼。该平台体系比较庞大,今天主要介绍偏向于监控和报警的相关功能。这部分功能是我行根据多年的经验自主研发实现的,里面蕴含着监控方面的理念和思路,希望此次能给大家带来一些参考和启发。

一、监控发展现状分析

1、发展背景

金融科技是一个炙手可热的话题,通过互联网、大数据、云计算、人工智能、区块连等新技术的应用,支持和引领着业务的快速发展。

这个过程中,对银行科技运维和都带来了很大的,主要表现在:

业务对服务的稳定性、可靠性要求越来越高。

业务对IT支撑能力的依赖性越来越强。

IT架构本身的复杂度越来越高。

为了提升整体的IT和运维能力,银行业的数据中心较早引入了ITIL理念,建立流程的模式,形成运维工作的流程化和标准化模式。

随着云计算、大数据和人工智能的发展,在原有的ITIL的基础上引入了DevOps和AIOps理念的相关技术,逐步转向为数据和业务价值驱动,向着IT和数字化的目标转型。

光大银行统一监控平台,第二个选型(图3)

从我们光大银行的角度,科技部运维中心提出了BCDT的理念,作为运维相关工作的总体指导思想和理念。从监控建设的角度,主要的内容就是:

底线思维:不漏报、不误报、全覆盖,监控自身高可用,安全可靠。

闭环思维:监控能力建设要向、前移,监控策略的部署、故障处置、定位和后分析,要形成闭环持续优化。

发展思维:是研究和引入新的监控手段和方法,适应和满足新的要求。

技术思维:强调技术是核心驱动力,通过技术带动监控能力的提升。

2、建设历程

光大银行监控体系经过了多年的建设,历经了几个主要阶段,通过分析可以看到主要的趋势是朝着集中化、平台化和数字化的发展方向。

光大银行统一监控平台,第二个选型(图4)

12005年开始配置独立的监控工具。

22011年开始进入平台化建设,报警统一。

32014年开始全面监控,实现应用交易监控,搭建了大数据平台的框架。

42018年新一代的监控平台上线运行,这是我行自主研发的平台,在报警、标准化和自动化能力上的提升明显。

52019年科技数据平台投产,这个通过产学研合作的方式落地 AI分析处理能力,监控向着数字化转型。

3、思考总结

在我行监控持续演进的过程中,我们也在思考和总结,哪些是不变的,哪些是频繁变化的。

相对稳定不变的内容包括:

平台职能目标:保障IT稳定运行,不变。运维中心对监控设定的主动发现率这个KPI指标,一直没有变。

报警的目标:事前预警、事中发现和定位、事后分析,这个工作方法没有变。

监控的模型: 监控作为业务去分析,它包含的监控对象、监控指标、监控策略,这个模型没有变。

变化的内容就比较多了,比如:

监控对象更复杂。

监控技术和工具日新月异。

监控范围涵盖指标、日志、Tracing等。

更加认识到数据的价值。

引入很多智能算法。

运维和更加紧密合作等等。

二、光大银行监控体系总体介绍

1、总体架构

在重点介绍监控平台之前,有必要让大家对光大银行监控体系的总体架构和功能有个了解。

光大银行统一监控平台,第二个选型(图5)

光大银行监控的定位是面向全行科技部门的IT监控。从功能层面分为3层,分别是监控工具层、平台层和统一展示层。

1监控工具层,包含各类开源或者商业的专业领域的监控工具,他们实现对各类监控工具的实时的数据采集。常见的比如Zabbix、Nagios、Prometheus、BPC、Tivoli等等,都定位在监控工具层。监控工具会把报警数据、性能数据、日志数据,上送到平台层。

2平台层,包含两大部分功能:一是由监控报警处理、监控标准化和自服务等功能模块组成的平台;二是基于大数据架构的科技数据平台,包括大数据处理、存储、AI分析以及数据服务接口等子。在平台层,还实现了和行内其他运维的对接。

总的来说,平台层的建设思路是开源+自研,是整个体系的核心;工具层的建设思路是专业+敏捷+统一。

通过多年的建设,监控的指标覆盖从底层的机房设施到最上层的应用交易,实现了指标全覆盖。借助多种监控工具的部署,对监控指标的实现,一般都具备多种监控手段。

我们内部有个原则:对于关键指标,要有两种的工具能够覆盖。这样做有两个好处:一是能够确保监控策略有冗余,二是确保当我们识别出一个新的指标要纳入监控时,我们一定有工具能快速实现监控部署。

2、交易监控

交易监控,一直是所有监控建设的重点功能。我们通过多种手段,实现端到端的交易全方位监控:

光大银行统一监控平台,第二个选型(图6)

1采用了网络旁路抓包、流水表镜像和交易日志分析等多种方式监控交易成功率、响应率、响应时间等指标,实现了对应用无侵入的、实时的监控。

2TCP网络层监控,通过旁路方式对应用的全链路“通讯对”进行监控和分析,能够快速发现网络的异常,也能从网络层面对应用故障进行协助定位和分析。

3模拟监控,从互联网以及内网探点模拟访问应用,主动获取可用性和性能数据,并接入到监控平台进行集中处理和分析。

3、大数据和智能化

大数据和智能算法,是我们现在的工作重心。2019年我们的科技数据平台完成上线投产,这个平台综合运用了多种算法,实现了指标异常检测、检测、批处理异常检测等多种功能。

光大银行统一监控平台,第二个选型(图7)

一个场景是交易监控,综合节假日、促销等各种因素实现动态的异常交易检测和告警,可以细化到每一只交易单独进行监控,相比于传统的固定阈值监控能提前3-5分钟进行提示。

第二个场景,是对批量任务时长的智能分析,相比于传统的固定批量执行时长的监控,智能分析的结果能够做到提前预警,为夜间故障处置赢得了时间。

在数据展示方面,我们建设了统一视图。支持移动端、大屏端、PC端实时数据展示。根据业务场景,定制了日常运维视图、 应急保障视图、和重保视图。

按照用户角色的使用需求,对各类视图进行分类,如一线偏重于故障发现、和按照预案处置以及事后的验证;二线偏重于故障的解决以及趋势分析和隐患排查。

4、技术栈

对于监控的建设,我们的原则是以开源为主,自主可控。

光大银行统一监控平台,第二个选型(图8)

在数据采集层面,我们使用了zabbix、nagios、prometheus 等常见的开源软件。另外也有国产的网络流量采集和分析的产品。对于存量的国外商业套件,我们已经制定了替换的计划,预计会逐步下线。

需要特别提到的是,我们正在实施部署的统一采控Agent子,采用自研方式建设,目标是能够成为一个采集脚本编写和的基础平台,通用的Agent驱动能力,独立实现上所有数据的实时采集,成为大数据平台最稳定可靠的数据。

在数据处理、数据存储、前端展示以及部署各个层面,也就是平台层的产品则基本都是开源的产品和技术。

上面是对我行监控整体的功能和架构进行了简要介绍。

三、监控平台建设实践

前面介绍了光大银行总体监控体系,在本章节我来介绍一下监控体系中的监控子。

1、平台功能架构

光大银行统一监控平台,第二个选型(图9)

主要是两大部分,第一个是左半部分,从下到上包括报警采集、预处理和处理,构成了报警处理引擎子,其中还包括了报警和维护期的功能。

第二是右半部分从上到下,监控标准化子,包含监控对象、策略、指标和规则等标准化功能,以及监控配置自动化、监控评价等功能。

通俗的说,左面部分解决的是报警来了怎么处理的问题, 右面部分解决的是报警如何配置,怎么产生的问题。

2、监控报警引擎

下面分别介绍一下报警处理引擎和监控标准化两大部分功能。报警处理引擎,是光大银行自主研发实现的核心组件,所以这个部分是本次的重点内容。

首先,我们先来分析报警的技术和业务特点:

在事件采集层,数据源丰富、报文格式多种多样,并且期望的采集延迟在毫秒级。

在报警处理层,特点包括报警量大、可能存在报警风暴、报警之间相关性高、处理逻辑复杂,要考虑扩展性并且还要合理继承原有的规则,处理延迟要求在秒级完成。

在展示和处置层,要求的是展现形式多种多样,前端页面能够高频刷新或主动的接收推送的报警,保证时效性。

光大银行统一监控平台,第二个选型(图10)

基于上述报警的特点,我们制定了报警处理引擎的选型和的目标:

1事件采集和处理要解耦,这样能够保证采集器的采集时效性。

2事件处理集中化,规则、外部对象资源都要加载,通过集中处理可以更加充分的利用资源,一次加载重复使用。

3事件处理分布式,处理集中之后就要有分布式处理可水平扩展的能力。

4分布式内存数据库,针对报警反复读写数据库的情况,这是从性能角度考虑。

5对SQL的支持好,数据库的访问就能非常灵活和简洁,监控报警规则就更容易实现。

6去商业化,自主构建。基于开源软件构建,能够最大程度满足要求。

上述几点是我们最初选择报警处理引擎的一些考量或者是目标。这和我们之前用的产品也有一定关系,我们之前采用的是IBM Omnibus产品,到现在也有很多金融机构在使用该产品,它是一个基于内存的支持SQL的报警处理引擎,它的最大问题就是单节点、单进程运行,所以对于大数据量的处理存在瓶颈。

所以我们的新报警引擎一方面要解决处理能力的瓶颈,另一方面要能够完全兼容原平台的处理逻辑和规则。这是我们在技术选型前的另外一个约束。

在产品选型的过程中,我们主要考虑的是两部分,一是数据库,二是分布式的框架。

在数据库选型中,我们选择了Apache Ignite作为分布式数据库。和其他数据库的对比,比如Oracle、MySQL、Eedis、Geode、ES,主要考量几个特征是内存关系数据库、支持SQL、支持持久化等。

第二个选型,是分布式框架,因为框架主要用于引擎内各个组件的高性能交互,所以我们选择了Dubbo框架,相对更轻量和小巧。

下面是报警处理引擎的功能架构图,包括接入层、处理层、APP层、数据层和接口层。

光大银行统一监控平台,第二个选型(图11)

其中的重点是处理层,分为两大类的处理功能,下层是报警流处理,上层是报警的批处理。这些处理功能模块是动态加载和可扩展的,是在App层采用应用商店的模式,进行发布和编排的App。在我们的报警引擎中,将每个处理功能都作为一个App来。通过这样的灵活和部署的架构,满足报警处理的各种需求。

光大银行统一监控平台,第二个选型(图12)

一个事件处理节点内部的逻辑架构和数据的流向图如下:

光大银行统一监控平台,第二个选型(图13)

主要内容包括:

1数据处理流程是报警从采集器来,送到流处理模块后通过ignite客户端节点入库。批处理模块负责把报警取出来进行二次分析,增删改的动作还会送到流处理模块进行处理后入库。

2在ignite库中分为实时库和历史库,保存所有的报警信息。引擎通过报警跟踪的模块,把所有的报警变化记录同步到kafka,供第三方消费。批处理分配模块则实现了批任务的分布式处理调度的工作。

3控制台用户交互接口,流处理和批处理中运行的处理功能App。节点间信息的同步则通过RMI通讯模块完成。

报警处理功能,是处理引擎的核心功能。什么是处理功能?比如一个报警发生了,要不要进维护期,那这就是一个报警处理功能。那维护期的判断,一定是在报警之前执行。那这就是功能间的编排。

我们的报警处理引擎,是以应用商店App的模式对报警处理功能进行封装和编排,定义了多种App类型,支持处理功能的定制。也就是说报警功能可以不断的扩充的。

App的类型,包括:

最普通的流App和批量App。

广播型的App本质是为分布式批量。

Restful App 可以动态的生成访问App内部数据的接口,可以对App运行情况进行监控。

在我行报警处理引擎正在运行的处理功能,包括一些基本的处理功能,比如报警丰富、报警压缩 、恢复关联、自动升降级、维护期等。在智能化报警方面,主要的处理功能用于报警的根因和影响分析,实现了根因升级和受影响报警的自动降级,场景包括如宕机、应用服务拥堵、DWDM中断等异常场景。我们正在做的优化工作,包括基于算法的报警和基于cmdb规则的排障树等功能。

总结一下报警处理引擎的特性:

光大银行统一监控平台,第二个选型(图14)

特性包括:分布式处理、高可用;完全兼容之前IBM omnibus的处理规则,可以平滑过渡;支持App热部署热插拔;App可编排、调度和协作;扩展性强,支持自定义App和部署以及SQL函数扩展;高并发、高性能;支持告警链路追踪和处理性能统计;支持全备+增量的备份方式;支持多数据中心主备模式部署。

3、监控标准化

前面讲了监控平台的报警引擎,下面要再来标准化的内容。

在前面介绍监控演进过程时我们讲到过,监控的模型到目前为止还是依然适用的:

光大银行统一监控平台,第二个选型(图15)

其中涉及监控对象、监控工具、监控策略、监控指标 ,比较核心的几个概念和关系:

监控指标是针对每一类对象要监控什么,是对象的一组动态属性,比如CPU使用率就是一个指标。

监控策略是如何进行度量指标,比如 CPU使用率大于80%,持续3分钟,报一个警告。

关系是:监控对象关联了监控指标,监控策略实现了监控指标,并且在特定的监控工具上运行,完成对监控对象的监控。

监控标准,就是哪些对象用哪些策略覆盖哪些指标。把这些规则汇总和发布出来,就是我们企业级的监控标准。

在实际运行中,监控对象、指标、策略和工具自身的内容,都在发生变化,比如我们引入了交易量动态基线的监控,实际上就是用一种新的工具和策略,去检查我们原有的监控对象和指标。

在我行监控实现时的一些要点总结如下:

光大银行统一监控平台,第二个选型(图16)

1在监控对象的方面,支持对象全覆盖、对象类别和属性扩充、对象关联关系。录入对象时,物理的属性是自动发现和采集;属性优先是从外部的cmdb进行同步。支持批量导入。这部分的功能可以套用cmdb的。

2指标方面,需要支持虚拟指标和工具指标的定义和关联。

4、监控自动化和自服务

前面标准化模型的内容都准备好之后,就具备了监控自动化和自服务部署策略的前提。

自动化分为两个层次:

自动化,就是监控的实施人员进行的自动化部署。

自服务,这个是面向专业团队运维人员的操作。自服务是自动化的更高阶的阶段,需要面向业务场景的、更加易用的交互界面。

实现过程中的技术要点,就是通过监控工具驱动程序的,实现平台对底层监控工具的变更操作,而且能够屏蔽工具的差异性,快速接入各类工具。根据工具接口的完备度,有全驱动和半驱动之分,全驱动就是所有的操作都能在平台层完成,半驱动就是常见的标准化策略部署,在平台完成,一些特殊策略部署还需要到工具手工完成。

正是有了驱动能力的不同,所以对于半驱动来说,我们还需要一个策略采集器,确保平台有完整的工具策略。

光大银行统一监控平台,第二个选型(图17)

对于监控自的执行,那我们有一个原则:专业团队的员的自助式的配置,是在监控标准下的自服务。

典型场景是操作人员录入设备信息,自动发现或者同步资源的信息,补充必要的对象信息,预览自动匹配到的监控策略,进行确认后,下发生效。

在这个流程中,策略的匹配和绑定是基于监控规则的,监控规则是企业级定义和发布的监控标准,所以大家在进行自服务的时候,还是要以规则为准。

对于个性化策略的部署,技术上是可以支持的。目前在我们的实际使用中是要走ITSM流程审批过后,由监控员去执行非标策略或个性化策略部署的。而且这种非标的策略部署过后,我们是有评价机制来跟踪的。

5、监控评价

监控评价模块,用于事后量化评价每个应用的监控情况。

光大银行统一监控平台,第二个选型(图18)

评价主要是3个指标,监控覆盖率、监控标准化率、超额布控率,这三个指标在设计的时候,从上要求是逐级升高的:

1监控覆盖率,是说需要有监控,这是最基本的要求。计算公式是基于监控指标进行的。

2监控标准化率,是说除了有监控,还应该按照行里的标准策略进行监控,比如标准的阈值是90%,如果某个需要改为80%的阈值,那这就是不遵从标准了。所以监控标准化率指标是基于监控策略进行计算的。

3超额布控率,就是说前面的标准动作都做完了,如果员责任心强,又提了额外的监控策略,那就是超额布控率,也是基于指标计算的。

通过这样三个指标,可以对我们的应用的监控完备度进行一个量化的评价和排名。有了这个排名后,那我们的机制就能够发挥作用了。

监控评价的目标是以评促改。基于评价的结果,我们或者进一步去完善监控标准,或者对于一些非标的特例就要促进相应的应用进行整改,进一步符合监控的规范。这样一个持续改进的闭环就形成了。

6、监控自动化和自服务

平台还有一个比较重要的功能,维护期。这和报警以及标准化都有一些关系。这个是个常用的功能,技术上并不复杂,但也非常容易出问题。它直接影响了报警的有效性,的不好很容易出现漏报警或者误报警。

光大银行统一监控平台,第二个选型(图19)

关于维护期使用,我们在多年的监控运行中,吃了一些亏得到一些教训,这会促进我们不断优化相关的功能。以下经验和大家:

1维护期最多设置30天,单次超过24小时,就要进行二次确认,避免出现误操作。

2非周期的维护期内发生的高级别报警,也要到员,避免把维护期报警和故障报警进行混淆。

3出维护期前,员要去检查维护期内报警的状态,避免出现误报警。

4出维护期后,如果报警还没有恢复,那就要重新进入处置流程,避免遗漏报警。

此外,我们还定期导出报表,进行维护期的重检,确认维护期的有效性。

7、监控的整体评价

作为监控平台,如何对我们整个监控体系的运行效果进行评价,最直接的指标,是发现率和有效率。

光大银行统一监控平台,第二个选型(图20)

目前运维中心设定的KPI指标是监控发现率,就是监控发现的故障占总体故障的百分比。我们的监控主动发现率基本能保持在98%以上,对于监控未主动发现的故障,有相当例会引起业务影响,这也从侧面也证明了监控的重要性。

前面讲的偏向于工具功能以及技术实现,在这我还想强调一系的作用,体系包括人员的参与和流程:

1人员各司其职很重要,一线人员、二线人员、专家、运维质量人员、监控的人员还有监控建设的人员,都参与到运行中,而且通过二线应用人员,项目组的人员也间接参与到整个监控体系运转中,尽职尽责。

2我们做了很多基础的工作和数据分析工作,通过监控报表、事件报表,每天、每周、每月、每年的事件会,对报警相关的事件进行分析,持续的反馈和优化监控标准、补充策略。过去10年间,运维中心的领导能够亲身参与到这些工作中。坚持,所以才能让我们的监控持续优化。

对于有效率指标,从真实有效的角度去度量,那我行监控误报很少,都能如实反应生产的情况。如果站在一个更高的要求去理解这个指标,有效率表示的是事件的数量和报警的比值,提升有效率能够减少无效报警的干扰,提升故障处置的效率。我们目前正在做的优化是基于规则和场景,按照报警的根因和业务影响的分析,这两个视角进行报警的合并和关联,减少孤立报警的数量,提升报警的有效率。

四、未来发展方向展望

最后我们对监控的未来发展,做个展望。总体的方向,我们认为是向数字化的转变。

光大银行统一监控平台,第二个选型(图21)

目标是提升对数字化运行态的洞察力和智能分析能力。这里面有4个方面:

1数字化的思维的建立和数字化的监控转型。

2基于这些大数据,进一步丰富完善算法,推广智能算法的应用场景。

3监控和服务的融合,在强化监控标准化的基础上,还要更加快速的纳管新的技术工具,提升自服务的应用范围和场景。

4监控云和云监控。监控云是以云原生方式构建监控,提升弹性和敏捷的能力,加强工具整合;云监控则是提升容器、k8s、分布式应用的监控能力,通过监控API的部署和使用,把运维和部门进行打通,提升云应用自身的主动监控能力。

>>>>Q&A

Q1:咱们有用到规则引擎吗?

A:用到了Spring SpEL,正在研究Drools。

Q2:请问Ignite持久化到RDMS有使用吗?

A:没有使用Ignite自身的机制持久化到RDMS,我们做了IDUC模块将所有告警的变更操作都同步到了RDMS,这个比Ignite本身持久化到RDMS更细致。

Q3:请问实时流事件处理是基于Ignite吗?

A:不是,Ignite只是用来做存储,实时流处理是我们自己的模块。

Q4:请问咱们Ignite可以支持多大的告警量?

A:支持千万级的实时告警量,支持亿级的历史告警量。

Q5: 监控的指标会有相应的区分吗?比如根据采集的手段:远程或者本地?

A:指标是一个抽象概念,跟具体的实现解耦。指标只包含名称、单位、数据类型等关键属性。

Q6:您好,想了解这里介绍的各个功能,是基本都已经实现的还是规划为主呢?

A:大部分已经实现。有一些功能还在推广过程中,如监控自服务和监控评价功能,还在持续提升工具的覆盖范围。

Q7:请问现在智能化监控落地的场景能讲一下吗?

A:交易基线分析、批量运行时长分析、交易异常点定位。

Q8:请问目前光大银行的自动化运维达到什么程度了呢?

A:和监控相关的自动化主要是监控策略自动部署,以及报警产生后推送到自动化运维平台和运维工具箱进行自动匹配。

Q9:请问表镜像用的是什么技术和工具?

A:使用Oracle Golden Gate实现Oracle数据库之间以及Oracle数据库到Kafka的实时数据同步。

Q10:可以谈一谈监控和CMDB,流程平台的关联关系吗?

A:监控对象的全集来自CMDB,目前是每天自动同步;和流程平台,目前已经实现了变更流程的维护期自动设置,还有报警转事件工单流程。

Q11:请问目前每天数据量有多少?

A:存量活动告警2万以内,历史告警新增记录数每天10w+。

Q12:晚上批处理监控有没有比较好的方法呢?特别是关键路径上的批处理时间的监控

A:我们是根据批量运行的历史数据计算批量运行时长的基线,再根据基线进行报警。

Q13:TCP链路追踪是指在网卡层进行分布式链路采集吗?

A:我行的TCP链路监控是通过网络交换机旁路抓包的方式对TCP报文进行分析和监控。

Q14:这个监控平台都是自己的吗?没有引入一些开源的监控工具吗?

A:基于开源工具进行自主的,具体的开源工具正文有介绍。

Q15:想了解下在存储方面如何做统一监控呢?

A:统一监控平台通过接收存储设备推送的trap报警实现故障监控。独立运行的存储平台实现存储设备及SAN交换机的性能监控。

Q16:请问做自研的监控平台,从哪方面入手更好?比如先做好数据采集?用哪些开源技术栈比较好?

A:需要看具体的需求和资源投入了,最好还是做好提前规划设计。最大化利用开源工具的能力,比如Prometheus、Zabbix。

Q17:请问监控数据在问题故障根因定位等方面是如何使用,在哪些方面或环节必须基于监控数据?

A:根因定位一般需要告警数据和配置数据两类数据,告警数据指告警记录本身,配置数据指描述对象的资源数据、描述业务的业务数据等等元描述数据。

Q18:请问应用的监控数据采集是通过什么方式?

A:应用监控数据采集方式主要包括:本地代理实时采集;外部服务探测;旁路网络抓包;数据库流水表同步镜像等方式。

Q19:请问自动发现引擎用的是Zabbix还是自研呢?

A:相关的自动发现是基于Zabbix的,网络设备发现和配置采集是自研的。

Q20:请问带外硬件设备的监控,和带内监控,关联关系建立方面,有相关经验可以吗?谢谢。

A:cmdb实现虚拟化OS和物理设备的收集汇总和关联关系的建立。监控同步cmdb的数据获取相关的关系。

Q21:咱们机器学习算法也是在分布式内存库内做吗?

A:不是,是在我们的大数据平台做的。

Q22:请教一下,告警收敛怎么实现?

A:在报警处理层面,通过预置场景,比如宕机、交易繁忙等关联规则,实现报警关联和抑制。在层面,对于报警状态未发生变化的情况,不会重复发送报警,且会对短信进行压缩处理。

Q23:咱们有服务拨测相关的监控功能吗?可以介绍一下吗?

A:我们采购了互联网厂商的服务,从全国各商对我行外网应用进行拨测,包括App和Web服务,监控数据实时同步到行内监控。在内网建设了私有化的拨测平台和探点,通过录制脚本和定期回放的方式监控重点应用。

Q24:告警关联是如何实现的?可否举个例子呢?

A:空间上,通过告警对象的关联关系,比如同一个应用下,如果数据库发生告警,那么依赖他的所有中间件、应用都会产生告警;时间上,通过时间窗,比如某个告警发生的前后几分钟之内的所有告警。规则引擎会根据上述条件对报警进行实时分析,同时在这两个维度有关联的,才会进行告警的关联。

Q25:请问告警风暴和根因分析这块儿,可以一下吗?

A:目前采用了分布式内存数据库和分布式并发处理,完全可以应付告警风暴;根因分析是根据预置场景规则进行报警的关联和压制。

Q26:请问老师可以一下指标的标准化体系建设吗?

A:监控指标体系最初建立是多年监控运行经验的积累。现阶段由监控团队负责监控指标的维护和,定期由专业团队和各领域专家进行重检。

获取本期PPT请添加菲菲VX:dbafeifei

本文相关词条概念解析:

报警

报警指因使国家、公共利益、本人或者他人的人身、财产和其他权利免受损失而通过电话、网络、信件等方式向警方报告危急情况或发出危急信号。清李渔《奈何天·攒羊》:“自从受事以来,探卒时时报警,饥军日日呼庚。”曹禺等《胆剑篇》第四幕:“我奉了文种大夫之命,在城楼上正装设报警大鼓。”

网友评论

相关文章