前言

随着银行业务的快速发展，网络、应用系统自身的复杂度日益增高，同时数据中心与分支机构，以及人行、农信银等外部机构的流量及业务交互量均日益增长，银行业务互联网化，产生了大量新兴的互联网类的业务系统，给系统、网络和应用各条线的运维带来了巨大压力。然而当前行内运维监控系统的建设仅完成了基础监控与管理阶段，大多数监控数据采用AGENT、SNMP与系统日志等采样方式获取，数据实时性、精度较低且无法站在全行业务系统的统一管理视角进行监控。一旦业务系统运行出现问题，各组件的网络、系统及业务交易指标相互孤立，难以及时找出问题环节。在发生业务故障时，时间往往被耗费在低效的排查工作中，其中的主要问题在于：一旦发生问题，多科室同时开始根据各自经验诊断；缺乏统一视角的证据支持，没有入手点；若无法达成共识，则需要进一步线索进行反复排查。因此，为实现网络质量监控、业务性能监控，提高故障定位效率，保障银行系统业务连续性，急需引入先进、有效的网络及业务性能管理产品，以及基于Hadoop的运维大数据平台，对所涉及的运维数据进行深入挖掘与处理，智能统计分析与预测，以此帮助提高运维人员日常运维工作及故障响应的效率，实现业务系统端到端全链路的实时监控，在维护生产系统稳定、安全、高效运行的同时，发挥IT数据价值，帮助业务发展。

在规划和设计业务系统一体化监控方案时，会遇到以下几个问题的困扰，在社区组织的银行业务系统端到端监控一体化方案规划设计线上答疑活动，江西省农商银行的嘉宾与各位同行也都给出了实际工作中的一些建议：

1.监控涉及的业务和设备种类繁杂，如何避免数据之间的不互通造成数据孤岛？

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

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

asdf-asdf 研究学者 , cloudstone

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

2.如何对IT设施进行有效的监控整合？

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

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

3.监控大规模节点时，是否会对网络产生压力？

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

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

asdf-asdf 研究学者 , cloudstone

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

4.如何避免因业务系统繁多复杂造成的问题定位困难？

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

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

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

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

5.如何站在全行、多数据中心、多机房的角度，统一、全面获取准确的网络旁路报文？

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

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

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

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