前言

随着我行业务的快速发展，网络、应用系统自身的复杂度日益增高，同时数据中心与分支机构，以及人行、农信银等外部机构的流量及业务交互量均日益增长，银行业务互联网化，产生了大量新兴的互联网类的业务系统，给系统、网络和应用各条线的运维带来了巨大压力。然而当前行内运维监控系统的建设仅完成了基础监控与管理阶段，大多数监控数据采用AGENT、SNMP与系统日志等采样方式获取，数据实时性、精度较低且无法站在全行业务系统的统一管理视角进行监控。一旦业务系统运行出现问题，各组件的网络、系统及业务交易指标相互孤立，难以及时找出问题环节。在发生业务故障时，时间往往被耗费在低效的排查工作中，其中的主要问题在于：一旦发生问题，多科室同时开始根据各自经验诊断；缺乏统一视角的证据支持，没有入手点；若无法达成共识，则需要进一步线索进行反复排查。因此，为实现网络质量监控、业务性能监控，提高故障定位效率，保障银行系统业务连续性，急需引入先进、有效的网络及业务性能管理产品，以及基于Hadoop的运维大数据平台，对所涉及的运维数据进行深入挖掘与处理，智能统计分析与预测，以此帮助提高运维人员日常运维工作及故障响应的效率，实现业务系统端到端全链路的实时监控，在维护生产系统稳定、安全、高效运行的同时，发挥IT数据价值，帮助业务发展。
为了帮助大家解决在规划和建设一体化监控系统中遇到的难点与问题，社区于12月28日邀请了江西省农商银行运维专家分享了原创之作《银行业务系统端到端监控一体化方案规划设计》，并组织了一次线上交流与答疑活动，通过各路专家、IT工程师的共同探讨，本次活动的确给同业带来了一些参考思路，因此，为再次帮助大家了解本次活动的全部内容，理清思路、合理决策以及科学做好一体化监控的规划建设工作，现将本次活动作一次全面的总结，如有遗漏之处，还请见谅。活动的主要内容总结为以下四个方面：
1、运维体系建设与多监控系统间的联动方面
2、监控系统可能带来的性能影响问题方面
3、监控辅助故障快速定位方面
4、一体化监控平台整体架构、功能设计方面

一、运维体系建设与多监控系统间的联动方面

【Q1】监控涉及的业务和设备种类繁杂，如何避免数据之间的不互通造成数据孤岛？
邓毓 系统工程师 , 江西农信

数据之间目前确实很容易存在孤岛问题，比如基础监控和业务监控，和网络监控等，这些监控到的东西，无法形成统一的整体，割裂开来，造成网络做网络的监控、应用做业务的监控、系统做系统的基础监控，大家都是孤立的个体，最多通过统一的事件平台来展示和告警而已。这种现状，显然已经无法满足企业，尤其是银行企业的实际运维监控需求，因此如何把这些孤立的数据，协同、统一起来，变得十分的重要，有两种方式供大家参考。
第一种是：运维大数据，通过对多运维数据源的汇总，分析，归纳，统计，形成一个统一的可视化运维分析平台，出现故障，不再是割裂的，而是统一的各类信息的整合。另外运维大数据更重要的是多类监控数据源的数据，有结构化的、非结构化的数据，不断学习，做深入挖掘，帮助运维人员找出可能的根因。
第二种是：IT架构可视化，在统一的网络架构、业务逻辑架构、应用部署架构下，展示所有的运维数据，有实时的基础监控数据、业务性能数据（BPC）、网络性能数据（NPM）、运维大数据分析后的数据（ITOA）、APP终端性能数据（TPM）、流程数据（ITSM）等等，整个统一架构下的，不同数据源的整合，让运维人员，可视化的发现可能的根因。

asdf-asdf 研究学者 , cloudstone

数据之间的不互通, 需要多方面考虑, 各个监控产品都有对外开放的api;
开发软件最多的即时接口技术;
可使用固定接口规范完成 数据互通; 
也可使用目前火热的NLP方式, 开发接口完成学习能力 使接口适用于更广泛的监控平台。

**【Q2】如何对IT设施进行有效的监控整合？
IT监控是一件很复杂的事情，从机房基础环境到网络、存储、主机、系统、应用，从硬件到软件，从后台服务到前台服务，各个IT设施又涉及到厂商、型号、风扇、电源、控制器、温度、实时性能等等，如何能够将这些监控元素进行有效的整合？**
邓毓 系统工程师 , 江西农信

分类监控，比如动力环境监控、网络监控、基础监控（系统、数据库、中间件等）、硬件监控（HMC、X86硬件管理口等），业务性能监控、网络性能监控、日志监控等，通过建立不同的监控项目，实现监控的全覆盖。
再集中整合，首先是事件的统一集中，建立集中事件平台，对接所有的监控系统，事件集中了，告警出口就统一了。再就是建立事件、性能、数据的分析平台和统一可视化平台，比如运维大数据，和IT可视化等，这里不再详细展开。

**【Q3】自动化监控工作和自动化运维工具如何调配，才能使运维工作更为健全？
自动化监控工作和自动化运维工具如何调配，才能使运维工作更为健全？不至于浪费系统资源和重复的工作，使我们的运维平台做到信息共享。**
邓毓 系统工程师 , 江西农信

监控和运维是不同的两条线，做项目前，必须划定好清晰的边界，才能不至于造成资源浪费和功能重复。
监控是系统、网络、日志等数据的收集，重点在“监”
自动化运维是实现全运维链路端到端的运维自动化，重点在“动”
很明显，两者的边界很清晰，但两者也有融合，比如“监控”到了，采取什么“动作”，采取了“动作后”，“监控”到的指标有何改变。
当然，监控和运维两者还有共同的点，是CMDB，这是它们之间的基础数据，基础数据统一了，才不会“监控”和“动作”的对象不统一。

asdf-asdf 研究学者 , cloudstone

自动化监控工作和自动化运维, 两个定操作类型
自动化监控只能查询信息
自动化运维有能力修改信息
绝对不能混乱
监控系统只能做信息查询和警告,预警
自动化运维可以做操作类变更
目前自动化监控提供数据支撑自动化运维进行
但由于安全规范,不允许自动完成变更所以这个闭环没有打通的可能

【Q4】建设一体化监控平台，CMDB是否需要进行改造？
邓毓 系统工程师 , 江西农信

CMDB和监控平台是息息相关的，监控平台的事件翻译、事件丰富、事件关联、事件声音、短信、微信提醒、事件处理方式、建议等，都需要CMDB中的基础数据作为统一的来源，所以在建设监控平台，尤其是一体化监控平台时，CMDB中的数据结构，字段的设计都需要匹配监控平台的各种逻辑，这样的告警事件才会准确、统一，而不是有各种理解歧义的多条看似不相干的事件。

asdf-asdf 研究学者 , cloudstone

CMDB不是进行改造的问题,
cmdb要实时进行升级和扩展,
目前cmdb应包含一个设备的所有资产信息,采购合同开始到维保结束,内部vm数量 网络内容等
如果信息不全必须扩展或者升级,
如果是厂商系统可使用外围系统进行补充,如果是自主研发系统可进行内部数据库扩展和业务更新

**【Q5】端到端的业务性能监控、统一日志分析平台及应用性能监控有何定位上的不同？
端到端的业务性能监控、统一日志分析平台及应用性能监控有何定位上的不同，监控应用场景有何区别，引入这些监控系统，对现有应用或者系统有何影响？**
eximbank 系统架构师 , 某金融企业

准确断定端业务性能监控，确实还有很长一段路需要探索和实践。目前就某一种框架下的业务性能监控其实还是比较完善。比如某一个服务一秒钟调用了几次、一秒钟内调用多少服务及其链路情况进行分析，这些仅限于某一个框架下，比如SOA，Spring系等。但是诸如手机端/Web端--前置--业务逻辑--后台核心--数据库类似这样业务链路，其实就比较有挑战性，甚至说在业务应用程序中就得植入端到端的监控入口，并将这数据放入合成工厂，通过工厂来处理这些端到端的业务性能监控，如此其实投入巨大。所以现在很多银行采用旁路检测，只关注业务的有效性和失败性，即成功率的结果，也是不错的监控体系。
统一日志分析平台，作为业务监控还是很有必要，但是同样需要应用开发对日志进行统一和标准，形成可统一使用粒度的解析，以便获取准确分析结论。日志分析肯定是应用性能监控中不可替代的补充，尤其在为服务化下，日志分析对业务性能更具有不可或缺的作用。就看是采用 ELK 自主研发还是 splunk 的商业精品来服务应用性能监控了。

邓毓 系统工程师 , 江西农信

业务性能监控，其主要的监控点在于业务，通常通过捕获网络报文的方式获取实时的业务内部或者业务间的交互数据，再进行智能解码，分析出报文当中的不同字段的内容，并进行归纳、统计、分析、告警、展示等。
日志分析平台，其主要的监控点在于日志，通常通过ES+FLUME的方式，一方面实时收集日志，一方面实时分析日志，统计分析日志，按不同字段进行解析、分析等。
应用性能监控，其主要的监控点在于应用程序，通常通过AGENT代理的方式，实时捕获应用程序进程、线程、连接池、内存等详细内容，知晓当前应用程序运行到了哪一行代码，耗时如何，调用数据库时的耗时、SQL语句、数据库操作完成情况等。
因此，三个监控平台其实际上是有共性的部分的，比如交易量、响应时间、业务成功率等指标上的解析，三种监控都可以胜任，但三个监控平台的监控角度、倚重有所不同，一个是剖析业务层面的东西，例如交易类型、机构、区域、金额、渠道等指标；一个是解析日志的上下文，输出更友好、清晰的日志格式给运维人员查询，也有一些归纳、统计的指标，但并不偏向业务层面，更多的是技术层面；最后一个是解析应用程序代码，有很多种方式，比如应用程序预埋HOOK钩子输出，或者JAVA程序内嵌代码输出分析等，这种方式更倾向于深层次的技术细节，代码层的解析。

二、监控系统可能带来的性能影响问题方面

【Q1】在日常业务系统交易中，如何使监控系统对业务系统的影响降到最低？
邓毓 系统工程师 , 江西农信

尽量从旁路的方式进行监控，而不是嵌入程序代码进行，尽量减少AGENT代理的方式进行监控，除非是长期使用，有信赖与口碑的AGENT，监控服务端的节点尽量采用分布式，采集节点尽量分布式，减少网络带宽影响。

michael1983 技术经理 , 某证券

多用通用协议（ANMP等），少用Agent；
多从旁路监听，少用串联架构。

【Q2】监控大规模节点时，是否会对网络产生压力？
邓毓 系统工程师 , 江西农信

分为两个层面来看这个问题
一是基础监控，也就是性能型事件，和系统日志型事件，这种信息的采集，通常是通过SNMP、AGENT等方式，采集到的信息会先落到本地文件中缓存，再通过网络发送给基础监控平台，处理、事件丰富和转发等，这些采集到的信息通常不会太大，而且采集也是有一定的时间间隔，加上有本地文件做为缓存，对网络的压力不会太大，而监控服务端的采集节点是可以分布式的部署的，被监控的节点数越多，分布的监控服务端采集节点数也可以相应增多，这样整体网络的流量也分布开，整体网络压力不会对原有业务网络产生太大影响，更好的方式也可以采用，监控网络和业务网络分开，这样就更加避免了业务网络的压力。
二是镜像报文类的监控，在网络交换机上，对业务端口做镜像，镜像端口直连TAP设备，镜像流量全部汇聚到多台TAP设备上，再由多台监控服务器（BPC或者NPG）分别分析、处理这些TAP上的共享网络报文。这样一种方式，压力集中在TAP上，可以通过分布式TAP部署解决，监控服务器端的压力也可以分布式解决，问题在于交换机的镜像方面，多个业务端口镜像给一个端口，这个端口的流量可能会超过其能承受的最大带宽，所以对于这样的问题，可以采用万兆端口解决，一个万兆不够，可以多个分担，或者业务端口分组，哪些端口镜像给一个端口，需要提前规划好。
我想，通过以上的办法，来应付大规模节点的监控，还是比较好的。

asdf-asdf 研究学者 , cloudstone

分布式进行监控,
计算监控流量, 保证网络带宽
网络压力一般是生产业务量大导致,
把监控流量和生产流量分开,也可避免监控流量压力问题.

三、监控辅助故障快速定位方面

**【Q1】BPC告警可以定位到交易系统的交易异常节点服务器，但该节点是何原因导致应用异常又改如何快速定位?
BPC告警可以定位到交易系统的交易异常节点服务器，但该节点是何原因导致应用异常又改如何快速定位?贵行是如何做告警的快速准确定位的**
邓毓 系统工程师 , 江西农信

BPC通过旁路的方式，捕获交易系统节点的报文数据，从网络报文层，解码分析出业务指标，如业务量、业务成功率、业务类型、渠道、系统响应率、响应时间等等，如果某个节点处先问题，其响应时间、业务成功率或系统响应率都会出现异常，这是可以从BPC中的交易追踪中，找到成功率为0的交互报文，就能很清楚的从格式化后的网络报文中知晓发送过去的请求是超时了，还是业务返回码不对，从而知道是该应用节点确实有问题，但要精准知道为什么有问题，仅仅依靠BPC是不够的，我们是通过运维大数据平台，对各个方面的数据进行实时集中收集，发现问题，进行统一的故障现场还原，在统一的视图中，获取真相，或者依靠大数据的优势，深度挖掘，分析，给出一定的建议。

**【Q2】如何避免因业务系统繁多复杂造成的问题定位困难？
业务系统繁多，彼此关联更多，会给问题的定位和排查造成巨大的困难，这种情况下如何才能快速定位和解决问题？**
邓毓 系统工程师 , 江西农信

业务系统繁多，这时候清晰的IT架构可视化系统是很不错的选择，利用“IT架构图”与数据相互结合的方式，图可以分三类，一类是业务系统所在的网络架构，结合NPM的数据和流程数据，网络架构中的节点，可以关联CMDB的数据和NPM性能数据和告警数据等；二类是业务系统的业务逻辑架构，也就是该业务系统和其他系统的关联关系，这张图上的业务节点，可以关联业务性能指标和流程数据，清晰的知道该业务系统的健康状态，如业务量，业务成功率和系统响应率，和告警，或者近期有没有流程变更等；三类是业务系统的部署架构图，其中的各类组件，比如WEB、中间件、数据库、应用负载、非通用设备等，关联的数据是基础性能数据和流程等。
有了这样一套IT可视化系统，各类运维人员，无论是网络、系统还是应用运维人员都可以很清晰的知晓哪里有问题，哪里是关键节点，帮助迅速定位可能的原因。而不是每个运维人员心中一张图，各自定位，信息孤岛，排查问题低效。

我爱大锅饭 系统运维工程师 , 银行

赞同楼上的回答，不过邓老师的建议可能更多是从新建业务系统时就开始着手构建统一的CMDB，基于CMDB进行IT架构可视化，现实中不少单位的信息系统是由少增多，业务由简到繁，等到发现瓶颈时，原来的CMDB可能无法很快将IT架构可视化，重构CMDB成本太高，耗时很长，且很难对某一项具体的业务关联关系进行展现。在没有重构完成前，个人认为可通过引入网络、应用层面的监控工具，如BPC、SPLUNK等监控工具，依据管理员的经验，对重点业务交易链路进行布控，做到及时感知。

**【Q3】如何实现故障的快速定位和提前预警？
如果在业务高峰时段出现异常，没有太多时间给管理员进行故障排查的。一些应急处置的手段可能会破坏故障现场，使故障难以重现及定位。怎样才能在异常出现时或出现前准确定位故障点？**
邓毓 系统工程师 , 江西农信

我的想法是建立运维大数据平台，实时抓取不同数据源的监控数据，业务性能、网络性能、基础性能、事件、告警、日志等，一方面辅助运维人员在统一的视图进行问题排查与定位，另一方面，能够在统一的平台保留足够多的证据，为事后的问题原因分析，做数据支撑。
建立起的运维大数据平台更进一步的思路是，利用先进的算法，AIOPS、机器学习等，智能结合不同的数据源，进行数据挖掘，进行根因分析，给出一定的建议，辅助运维。

四、一体化监控平台整体架构、功能设计方面

**【Q1】如何站在全行、多数据中心、多机房的角度，统一、全面获取准确的网络旁路报文？
如何站在全行、多数据中心、多机房的角度，统一、全面获取准确的网络旁路报文，为网络性能和业务性能，或者其他基于网络报文分析平台提供集中、共享的网络实时报文仓库？**
eximbank 系统架构师 , 某金融企业

抱歉，我没有太明白您的要求和目标，只能按字面意识给您理解回答我的见解。我理解您是想旁路网络报文统一管理，多数据中心、不同维度的旁路报文所关注的内容肯定是不是相同粒度或者维度。因此首先要建立一个以报文为基础的模型，将所有相关的旁路报文丰富到这个模型中，不同的人使用不同模型的不同面来获取各自所要的信息。这样既统一了旁路报文,也数据集中，只要模型设计得到位，应该不难解决您的准确的顾虑。这是我的理解，不知道是否对您有帮助。

邓毓 系统工程师 , 江西农信

我们是建立了统一的报文捕获与管理架构，两个数据中心都能分别捕获实时的报文数据，并集中共享给不同的系统分析，比如业务性能监控、网络性能监控、异常风险等系统共享同一份报文数据，这样就避免了同一个业务端口，需要镜像三次给不同系统分析，增加了网络带宽，浪费了镜像端口，现在统一通过三层网络交换机的TAP和二层汇聚层的网络交换机的TAP，统一捕获报文。详情见http://www.talkwithtrend.com/Article/243093

**【Q2】运维大数据平台中的数据如何分类获取？如何为运维和业务带来更高价值？
运维大数据平台中的数据如何分类获取，如何为运维和业务带来更高价值，而不仅仅是杂乱运维数据的集中存放仓库。**
eximbank 系统架构师 , 某金融企业

大数据我涉猎不深，但是在2010年左右去DBS做过类似资源运维与业务关系一些，目标也是给预测、分析和决策提供科学依据。不过当时主要还是BI的角度分析。
我理解大数据平台是扩展了数据来源，可能不光是资源类（性能、日志等）、业务类（日志、连接数、队列数据等），其它非业务类诸如各种业务激励活动、双11、双12、圣诞等促销活动、甚至把诸如能源、天气等因素、人员支持、技能更新等等诸多信息都摄入运维大数据平台，然后根据事件发生点，从不同面获取不同维度的画像，从不同的渠道拿到的信息，进行不同粒度/噪音的语义分析，为运维和业务支撑提供更有意义的分析和决策。
不过说实话，我对这个是存在一些顾虑，顾虑的是投入和产出比，到底是什么价值趋向？毕竟每一次事件都是偶然事件，要从偶然事件找出必然规律的确是有点不太合乎科学，但是作为语义分析，去寻找root-cause分析和警惕粒度/噪音重现做好更稳夺的支持和应急策略，从这个方面是有意义和价值。寻找规律或者其他什么定性或定量的理论，个人觉得投入和产出比的参考价值有待商榷。

**【Q3】为什么要引入运维大数据平台？
为什么要引入运维大数据平台？与业务大数据平台的区别和定位如何界定，银行如何站在全行的角度规划大数据平台定位？**
eximbank 系统架构师 , 某金融企业

为什么要引入，这个只能谈谈个人见解，仅供参考。
当前不光谈运维大数据平台、也谈数字化运营，甚至对员工也采用大数据、数字化标签管理，其实这些都是业务的需求。如果说要找理由的话，个人觉得寻找每次运维incident的root-cause是运维大数据平台存在的必要条件，其它只能说仁者见仁、智者见智的理解。
我想在做运维大数据平台一定有比我更贴切和透彻的理由。

【Q4】一体化监控平台的架构设计要点有哪些？需要着重考虑哪些要点？
asdf-asdf 研究学者 , cloudstone

考虑多方面监控指标的汇聚和分析
vm的性能监控,业务的交易监控,日志监控,环境监控等等
全面的监控需要各个监控组件完成监控事件,并把这些监控事件提供给类似事件分析的系统
完成整个事件分析,
对未来智能运维打下良好基础

【Q5】一体化监控平台是否包含预警模块，如果包含，都包括哪些功能？
asdf-asdf 研究学者 , cloudstone

一体化监控平台,内部有很多监控模块,也报警模块,
还包括事件分析模块
事件分析和一体化监控平台可集成在一起或单独立项
如果集成一起必须包含预警模块, 事件分析完成发送预警信息给相关负责人完成事件闭环
如果单独立项,一体化监控平台内部也需要把警告信息发给事件分析平台,完成事件分析,
由一体化监控平台发送预警或者警告给相关人员, 这时事件分析平台类似分析工具,责任只是分析

【Q6】为了确保监控系统的持续有效和准确，需要做哪些工作？
邓毓 系统工程师 , 江西农信

我们的想法是分层次建立监控体系
最底层是采集层，采集各类监控点的数据，包括硬件，动环、网络、系统、数据库、中间件、业务性能、网络性能等等。
上面一层是基础数据处理，监控的数据经过策略或者情景的匹配，实现监控告警的功能、事件丰富、事件分发，实现事件的集中化。
在上一层是数据的集中收集，建立运维大数据平台，进行多类数据源数据的实时收集、分析、预测、统计等等。
另外，监控系统作为整个运维的一个重要系统，还需要和其他系统进行充分的联动，让监控成为流程当中的一部分，让外部CMDB为监控系统提供统一准确地数据源，让监控去驱动部分自动化运维系统的任务和调度。

**【Q7】金融行业监控平台一般有几套？
有基础硬件监控、应用监控、网络链路监控、日志监控、甚至还有微服务监控、云管监控。监控平台太多了，各自为战，不同厂商，金融行业一般都搭建几套啊？发现多了之后，管理成本很高。**
邓毓 系统工程师 , 江西农信

监控系统可以搭建多套，但集中事件平台，和多监控数据的整合、分析平台只能有一个，这样对外告警是集中统一的，所有的监控平台的告警事件都发送至集中监控平台，由它来进行事件丰富、翻译、转发等，多套监控的数据可以统一汇聚到运维大数据平台，进行集中分析、统计和智能策略，机器学习等，在统一的运维大数据平台下进行日志分析、数据查询、故障现场还原、数据预测、根因分析等等。
如果觉得监控系统太多，记不住那么多链接，那么多用户，那就弄一个统一科技门户，把所有的平台链接都整合到里面去，通过单点登录，来实现一个用户、不同监控平台用户权限的对应。

【Q8】如何对大文件日志或大量小文件日志进行实时的关键字匹配，实现对业务的监控？
邓毓 系统工程师 , 江西农信

目前比较成熟，和应用较广的方式是通过ES集群来做，再在ES之上做应用开发，您所说的关键字匹配，这些都是比较简单的，不用ES的话，用正则表达式匹配关键字，输出到监控平台即可。

asdf-asdf 研究学者 , cloudstone

任何日志分析目前我都建议上一个专用的 Elaticsearch 工具完成 日志内容汇聚和分析搜索
在未来运维进入到数据挖掘和故障分析, aipos 时候提供有力的 可分析内容
elk,目前已经技术非常成熟,简单维护可为日志分析和业务监控提供大量有用数据支撑.