案例|安信证券监控平台如何设计和实现？

大家好，我分享的主题是安信证券监控平台的设计和实现，包含四部分：背景、演进、实现、展望。

背景有四个方面：第一，既有传统应用也有互联网应用，系统部署方式有：集中部署、分布式部署、容器化部署、云上部署。第二，自研系统与外部系统异构并存，各系统还有关联关系，但技术栈、标准化程度不一样。第三，数据库种类多样，各类关系型数据库、NoSQL数据库都存在。第四，较多系统部署于Windows操作系统，比例接近50%。

券商特点：业务连续性、系统稳定性、安全性要求高，系统RTO、RPO期望趋近于0。事前预防，海恩法则：任何事故的发生之前一定有很多个征兆。做监控更多是做预防。墨菲定律：可能发生的一定会发生。提前介入进行系统巡检。

券商运维现在还呈现双态运维的一个特点，对于核心的业务，是采用稳态运维的方式，利用的是ITIL的一个模式。对于非核心业务，是采用敏态运维的方式，采用的是DevOps的模式。当然还有一个特点，我们是强监管的一个特性，以核心业务为例，就是RTO要求5分钟，RPO是30秒，超过这个时间系统就出现任何异常都要去上报证监局的。我们系统出现任何异常也好，领导第一句话就是问监控有没有提前发现，注意两个词，提前，事先有没有任何征兆？所以我们就很慌。所以说我们对“无监控不运维”体会非常深刻。

但是也不用怕，就从我们用波浪展示的图上看，虽然运维复杂程度很高，但是有规律可循。你可以看到我们正常情况下的业务量和在线人数都是在开售期间达到峰值。其他时间段基本上都是平稳的。

我们进行运维平台的建设，理想的情况是什么样子呢？是我们先制定监控管理的规范，标准化监控部署，采用自动发现的手段进行监控纳管，打造统一监控平台，加入AI,实现智能运维。但现实情况会有点不一样。为什么呢？

随着运维的不断深入，需求不断升级，做体系建设分层建设，但实践可能不允许。因为我们监控是并行建设的。其次我们打造监控平台，场景覆盖，理想情况下肯定是做需求调研，把所有的场景都调研到，但是可能吗？可能有小伙伴说可能，是的，那是理想情况。实际情况我们的工作场景会越来越多，可能不光服务于我们的应用场景，还会服务我们的业务场景。

随着我们技术的发展，现在应该有一个共识，就是监控平台不是一次建设就成功的，是需要持续演进的。打造持续演进的统一监控平台，看一下我们安信证券是怎么来进行演进的？首先小伙伴是不是都用过IBM的Tivoli，有的可能没接触过。恭喜你。如果你没用过，很好，你已经跳过这个阶段了，用过的你对我们会感受比较深刻。其实严格来讲，Tivoli作为一个成熟的商业产品，它在集成性、扩展性方面还是不错的，支持了主机系统、数据库、应用网络等等。从监控层级来说，应该是说支持了各层级的监控，这是理想情况。

这是阶段二的统一监控平台的逻辑架构图，对于通用监控开发了一个adaptor，对通用资源的这些数据采集处理是用adaptor。刚才也讲了券商系统，windows的系统比例占比很大，还是保留了KCKK来进行监控，因为windows系统有很多是这种窗体界面的一些监控，还是保留KCMM。事件处理统一用OMNIbus。告警和现场数据统一存到Elasticsearch上面。对于专业领域是做集成工作，集成了带外、vCenter、OEM、网络工具、自研工具、cat、skywalking等等都进行了集成。当然我们是定义了标准化的接口。当然刚才也讲了我们做专业化的工具其实在这个阶段也在发展，我们这个平台就应该能快速支持更多的第三方工具。好了，这个阶段。ES、OMNIbus、adaptor是我们监控平台的核心。

可以说在这个阶段我们是打通了通用领域监控和专业领域的监控。从技术层面来看，应该是做到了统一，但是我们这套系统是要给业务人员应用的，实际业务人员在用的过程中发现，这个是做了统一了，但是好像以我这个工作，这场景的紧密程度还是不是那么够。体现在这几方面，第一点我们告警和性能关联性不强，一个监控系统，一个报警系统。第二点是我们开发的adaptor，告警的特点还是采用固定模板的方式，对一些复杂的场景还需要进行二次开发。性能展示的内容自助性也不高。当然还有一点，缺乏统一的资源配置信息。

遇到这些问题看一下我们如何来解决的。首先建立统一的监控portal，势在必行，这块最后会形成我们的运维门户。我们监控的一定要从用户的角度出发，而不是从技术的角度出发。技术是服务于业务的。第三点我们要以告警作为切入点，监控以我们的录制大数据、性能分析，拓扑可视化进行联动。第四点还是要采用实用的原则，不要重复造轮子，我们会引入开源的模块，能快速提供一些自助化的服务。当然我们配置信息其实从我们建好的CMDB里面就可以实现自动的同步了。

这是现阶段监控平台的整体架构。我们实现了统一监控的portal，集成了Grafana的数据展现服务，iCube日志管理服务，APM的业务性能管理服务，还有smartBI的报表服务等等。监控覆盖的对象包括系统应用、业务、数据库、中间件、网络等等，应该是说我们监控模型中的前站。对于通用的领域，我们引入了开放的Zabbix平台，进行数据的统一采集处理。刚才说了我们还是有部分系统是不存在windows平台的，KCMM得以保留，但是这块我们对它的性能和接口进行了升级，采用rsyslog的方式推送到Omnibus，高检的数据统一还是推送到Omnibus。性能促进我们这个都会推到我们的ES，最后的数据都汇总到应用大数据平台，做深度的数据挖掘分析。

现在来看一下我们Tivoli监控平台具体的实现情况。首先这套监控平台是作为运维工作的抓手，定义了监控首页，默认的是有管理首页和运维首页。当然各个系统负责人也可以自己定义个性化的首页，以达到千人千面的效果。这里我把它屏蔽掉了，因为是我个人的定制。从管理首页我们可以看到，我们可以有资产统计信息，有告警的总数、分项，还有我们活动告警的时间、散点分布图，还有我们的维护器计划等等，都集中在首页。业务人员或者是系统管理员只要看到首页页面就够了。当然了，监控最主要的工作是告警。在活动告警页面可以看到，对于一套系统来说，有来源于Zabbix监控的，有来源于专业领域综合监控的，有来源于其他相关的一些监控系统的，但是在我们北斗监控平台，大家能看到Zabbix的影子吗？看不到。能看到prometheus的影子吗？看不到。但是我们就是做这样一份工作，这就是我们的运维监控平台。

正常的日常工作的场景，其实还是要以告警作为切入点的。其实还是以使用的原则，直接右键就可以查看我们告警上下文日志，性能情况，拓扑图情况。这是我们北斗监控平台基于运维工作场景的一些集锦图，我们点开一个告警可以看到它对应的原始日志和格式化日志，以便进行详细的问题分析。这块是关联影响分析，可以看到告警的主体所在的部署架构拓扑图。当然通过grafana定制了很多这种系统的仪表盘用于系统的巡检。在性能趋势分析，是打通了告警和性能数据的展示。当然了对于Zabbix用户来说，也提供了延伸监控数据的展示，Dashboard、Graph都可以。通过Zabbix通用数据采集，Grafana整体数据展示，实现了就说1+1大于2的效果。可以看出其实已经实现了系统中间件、应用、业务各层级的监控。

打造了统一的监控portal，接下来我们怎么做？

其实北斗监控平台，或者是要打造监控平台，不光应该是指服务于运维人员的，应该把这个平台推广出去，服务于我们的研发人员，更要服务我们的业务人员。其实对运维人员来说，对监控平台很熟悉了，通过监控来了解系统状态，容量情况，发现系统异常，恢复业务连续性，预防故障，实施部署扩容工作，这都是业务人员经常要做的事。研发人员要怎么呢？要通过我们这个平台能做什么呢？发现系统各服务和应用组件的历史性能趋势，实施架构和代码优化工作。对业务人员，业务人员是最关注的。是要通过我们监控掌握我们业务的当前运转情况，客户的实际体验，基于这些信息展开一些针对性的营销活动。

期望我们的北斗监控平台成为运维人员的传感器，研发人员的指南针，业务人员的工作小助手，这是基于工作场景规划的整体的IT运维平台。我们监控在这一块。对我们监控平台持续进行优化改进，要打造成监、管、控、营四位一体的IT运维平台。

刚才我们也讲了，理想的情况下是先进行标准化工作，后面来进行运维平台的建设。运维监控平台在实际建设是反向推动我们业务工作的标准化的。第二点，我们经过了三次的演进，因为统一的运维监控平台，还需要提供更多的自助化的服务，为运维赋能，同时运维监控的数据落到运维大数据平台，我们要进行深入发掘和数据的分析，探索运维数据的价值落地，要按照标准化、平台化、一体化、智能化的方向继续前行。

谢谢大家。ppt可在文末留言区获取。

2021在线课第一节课将于本月29日开课！思德结合自身使用经验和群内用户的提问，设计如下课表。线上直播上课，互动性更强，欢迎提问交流。

在线课不仅包含专家系列课，还有官方主题课，课表见报名链接。