光大银行监控平台实践，含详细工具及架构选型思路

本文根据胖亚鹏老师在〖deeplus直播第222期〗线上分享演讲内容整理而成。

胖亚鹏

光大银行科技部系统架构师

• 光大银行科技部系统架构师、技术专家，具有十余年监控系统建设的项目实施经验。目前主要负责光大银行统一监控管理平台的总体架构规划和栏目内部研发管理等工作。

• 对监控系统的管理模型优化、监控服务化的实现以及分布式监控等领域有较深入的研究和理解。对于将AI技术运用到监控领域有浓厚兴趣。

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

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

一、监控系统发展现状分析

1、发展背景

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

这个过程中，对银行科技运维和运营都带来了很大的挑战，主要表现在：

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

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

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

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

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

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

• 底线思维：不漏报、不误报、全覆盖，监控系统自身高可用，安全可靠；

• 闭环思维：监控能力建设要向开发、测试前移，监控策略的部署、故障处置、定位和后分析，要形成闭环持续优化；

• 发展思维: 是研究和引入新的监控手段和管理方法，适应和满足新的管理要求；

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

2、建设历程

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

1）2005年开始配置独立的监控工具。

2）2011年开始进入平台化建设，报警统一。

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

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

5）2019年科技运营数据平台投产，这个系统通过产学研合作的方式落地 AI分析处理能力，监控系统向着数字化转型。

3、思考总结

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

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

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

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

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

变化的内容就比较多了，比如：

• 监控对象更复杂；

• 监控技术和工具日新月异；

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

• 更加认识到数据的价值；

• 引入很多智能算法；

• 运维和开发更加紧密合作等等。

  

我们回顾和总结这个变化，对我们监控系统建设有很强的指导作用。不变的点更多是管理相关的能力和要求，这在市场上没有完全满足我们要求的产品，于是我们选择了自主进行研发，最终形成了监控管理平台。

而对于更多变化的内容，我们的策略是快速引入专业领域的监控工具纳入到我行监控体系中使用，对接到管理平台进行统一管理。发展趋势中，大数据平台的作用和价值凸显，我们也以此作为监控乃至IT运营的转型的方向，基于开源的产品重点建设和优化。

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

1、总体架构

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

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

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

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

3）统一展示层，根据不同用户的角色和场景，提供PC、大屏和手机端展示。

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

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

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

2、交易监控

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

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

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

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

4）通过网络抓包和日志Api的方式进行端到端追踪系统应用间和应用系统内部的交易路径。这个功能目前在部分新架构下的应用系统已经实现，更多传统的应用系统正在改造过程中。

3、大数据和智能化

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

对银行业最重要的就是联机交易和批量执行，智能监控为传统监控提供了重要的补充手段：

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

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

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

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

4、技术栈

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

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

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

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

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

三、监控管理平台建设实践分享

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

1、管理平台功能架构

这是监控管理平台的总体功能架构图：

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

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

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

2、监控报警引擎

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

首先，我们先来分析报警管理的技术和业务特点：

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

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

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

基于上述报警管理的特点，我们制定了报警处理引擎的选型和开发的目标：

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

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

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

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

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

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

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

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

    

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

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

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

关于 Apache Ignite，是基于Java语言开发的，可以用作一个分布式的缓存，也是一个分布式内存数据库，可以作为关系数据库使用。它的数据储存在堆外内存的，不受GC影响，性能更好。作为内存数据库，它还能将数据持久化到磁盘，保证数据不丢失。另外一些特点比如支持事务、可配置为CP或者AP使用，支持SQL函数扩展以及内置消息订阅发布模型。

作为报警引擎来讲，我们更加关注分布式缓存、分布式数据库、和持久化。

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

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

    

从技术产品框架的视角看，最下层是自主开发的事件采集器 使用了spring boot + akka。应用层采用Dubbo的分布式处理集群，集群内运行多个事件处理节点，事件处理节点使用的技术包括：ANTLR 语法分析、java 动态编译tools 以及Java RMI。使用zookeeper作为服务发布和订阅的管理，ignite是报警存储库。最上层是报警视图的前后端服务。

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

主要内容包括：

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

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

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

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

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

App的类型，包括：

• 最普通的流App和批量App；

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

• 订阅型批量是和上述类型App组合使用的，用于数据的汇总和再处理；

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

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

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

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

3、监控标准化

前面讲了监控管理平台的报警引擎，下面要再来分享标准化管理的内容。

在前面介绍监控系统演进过程时我们讲到过，监控管理的模型到目前为止还是依然适用的：

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

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

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

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

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

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

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

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

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

3）策略方面，要支持通用的公式编辑器，利用指标生成策略。对于一些单向支持的工具，支持策略从工具进行抽取。

4、监控自动化和自服务

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

自动化分为两个层次：

• 自动化，就是监控的实施人员进行的自动化部署；

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

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

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

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

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

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

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

5、监控评价

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

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

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

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

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

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

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

6、监控自动化和自服务

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

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

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

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

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

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

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

7、监控管理的整体评价

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

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

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

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

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

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

四、未来发展方向展望

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

目标是提升对数字化运行态的洞察力和智能分析能力。这里面有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：监控指标体系最初建立是多年监控系统运行经验的积累。现阶段由监控团队负责监控指标的维护和管理，定期由专业团队和各领域专家进行重检。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼

如有收获，点个在看，诚挚感谢