随着我行业务的快速发展，网络、应用系统自身的复杂度日益增高，同时数据中心与分支机构，以及人行、农信银等外部机构的流量及业务交互量均日益增长，银行业务互联网化，产生了大量新兴的互联网类的业务系统，给系统、网络和应用各条线的运维带来了巨大压力。然而当前行内运维监控系统的建设仅完成了基础监控与管理阶段，大多数监控数据采用AGENT、SNMP与系统日志等采样方式获取，数据实时性、精度较低且无法站在全行业务系统的统一管理视角进行监控。一旦业务系统运行出现问题，各组件的网络、系统及业务交易指标相互孤立，难以及时找出问题环节。在发生业务故障时，时间往往被耗费在低效的排查工作中，其中的主要问题在于：一旦发生问题，多科室同时开始根据各自经验诊断；缺乏统一视角的证据支持，没有入手点；若无法达成共识，则需要进一步线索进行反复排查。

因此，为实现网络质量监控、业务性能监控，提高故障定位效率，保障银行系统业务连续性，急需引入先进、有效的网络及业务性能管理产品，以及基于Hadoop的运维大数据平台，对所涉及的运维数据进行深入挖掘与处理，智能统计分析与预测，以此帮助提高运维人员日常运维工作及故障响应的效率，实现业务系统端到端全链路的实时监控，在维护生产系统稳定、安全、高效运行的同时，发挥IT数据价值，帮助业务发展。

2、方案简介

2.1业务性能监控（BPC）解决方案

BPC解决方案基于先进的协议解码技术，充分利用可靠的网络数据资源，帮助我行信息科技部门建立业务性能管理平台。以业务服务为中心，围绕服务路径图，提供交易量、成功率、响应时间、响应率、返回码五大关键指标，并区分交易类型、交易渠道、或自定义的统计维度，展现业务服务组件的运行状态。实现了应用可用性、性能、负载量的全面可视化。同时能直接查询全量的交易明细报文，实现单笔交易级别的监控与管理。BPC系统实时产生的全量、实时、可信的业务交易性能数据，可帮助我行运维科室实时监控各个系统节点的性能状态，快速定位故障点，快速恢复；全量实时的业务数据，能实时的对业务状况进行分析，帮助我行业务的发展。

BPC业务性能监控系统整体架构由数据采集层和数据处理层二个层次构成，如下图所示，其原理是由BPC系统服务器网卡直接抓包，实时输出数据；解码引擎对业务数据包进行实时解码，并且解码引擎可灵活配置；可以自动发现节点之间的连接关系，为业务路径配置提供信息；最后由上层交易监控系统服务和呈现层进行交易性能指标监控、统计输出、追踪和告警。其产生有价值的实时业务数据和运维数据均可通过RestfulAPI与其他系统或平台进一步对接，直接产生业务和管控效益，如风控、用户行为及画像、精准营销等。

2.2网络性能管理（NPM）解决方案

NPM解决方案充分利用网络数据包建立覆盖重要链路、关键设备端口、核心服务的全面监控视图，并且按照我行网络科室的工作流程组织功能与操作，使其能够广泛适用于各种需要场景。以服务为导向的网络性能管理方法使NPM 能够直接体现网络基础架构对业务应用的支撑能力，为评估、判定网络服务质量提供可以信赖的数据依据。 依托真实的网络流量，快速发现、定义应用，梳理服务路径，并提供数据正确性、变更结果验证能力，大大提升网络流量的可视化覆盖率和工作效率。运用先进的数据统计分析技术，发现、告警模拟等功能极大简化了过去繁冗复杂的操作过程。围绕业务的网络性能监控视角，为业务交易故障的排查，提供了更直观和统一的监控界面，帮助网络质量问题的快速发现、快速定位。NPM网络性能监控的原理是：从重要线路、设备端口或各业务系统群镜像或分光出来的流量经过TAP Switch后，可完成汇聚、过滤及等功能，经过TAP Switch处理后的流量再进入Smart Probe采集探针，Smart Probe对流量进行存储和处理，并将处理后的数据发送给NPM Server进行应用梳理、实时监控、故障诊断及报表等功能。由于本行为双数据中心运营模式，因此需要考虑NPM的跨中心的扩容，其方法如下：比如以数据中心A为主中心，增加数据中心B为从中心的监控。A中心的拓扑和配置均不变，在B中心部署本地Smart Probe和NPM从服务器，将B中心的流量镜像到本地Smart Probe，所有网络数据分析在本地NPM从服务器上进行处理并发送统计结果给A中心的NPM主服务器进行呈现。A、B中心各自独立处理数据，互不干扰。

2.3运维大数据平台解决方案

本次运维大数据平台的建设，是建立在我行已完成的生产环境集中监控系统项目建设的基础上（基础监控及集中事件平台），在大数据分析和智能运维技术日益成熟的背景下，继续推进监控平台建设和迭代升级，既能服务于新一代数据中心建设，也能更好地推动IT运维管理服务能力不断提升。其总体目标是建立基于运维大数据平台的实时、历史性能分析和日志统一查询、分析平台，并开展智能运维的建设。通过建立运维大数据平台，来整合所有的基础性能数据、网络性能数据、业务性能数据等结构化指标型数据，以及事件告警数据、应用日志数据、系统日志数据、网络报文数据等非结构化日志型数据等。指标性数据通过对接大数据的Kalfka消息集群，进入Spark/Storm进行实时流数据分析，例如基线分析、单/多指标性能预测、容量预测和策略决策等；日志型数据进入ES集群，进行结构化处理、统计分析、单日志/多日志字段分析与关联等等；指标性和日志型的历史数据统一存入HDFS中，进一步供大数据挖掘，产出例如告警事件与指标性数据的关联，进行智能分析，得出可能的原因，定位告警源；应用/系统日志上下文历史挖掘分析；告警事件的周期型规律分析；告警成对成组出现分析；告警相关与因果分析；告警事件与变更流程的关联分析等等。运维大数据不仅仅是简单的数据集中化和展示，更深层次的目标是数据挖掘和分析，以此来推进运维工作的自动化和智能化，甚至将运维数据业务化，推进业务创新，提高用户体验。整个运维大数据平台分为源系统、数据加载、计算引擎和应用功能四层架构，如下图所示：

3、一体化监控方案架构设计

本方案的主要目的在于建立基于业务系统角度的端到端一体化监控系统，方案主要涉及业务性能管理和网络性能管理、运维大数据平台，以及和原有基础性能监控、集中事件平台的紧密结合与联动。整体方案架构包含物理部署拓扑和功能逻辑架构图。

3.1 物理部署架构设计

下面为业务性能及网络性能监控的物理部署架构图，分网络接入层和汇聚层两个层次对网络流量报文进行捕获和深入分析。

物理部署架构设计说明：

（1）通过4台TAP设备获取青山湖和艾溪湖两个数据中心、五个机房相关应用服务器接入交换机的镜像流量，并进行规则过滤；
（2）通过1台高性能汇聚TAP来获取艾溪湖数据中心二层汇聚交换机和核心交换机的镜像流量，并进行规则过滤；
（3）艾溪湖主数据中心各机房接入层TAP设备的流量共享给汇聚TAP设备；
（4）BPC系统的5台BPC服务器在两个数据中心的每个机房进行分布式部署、解码和分析，并集中展示；
（5）NPM系统在艾溪湖数据中心部署一台管理端服务器，并在每个数据中心各部署一台NPM探针服务器，通过分布式部署、捕获数据，集中监控展示的方式，监控两个数据中心的各业务系统的网络性能；
（6）通过双数据中心、多机房分布式部署的方式，端到端的监控业务在各个环节的流转情况，实时监控，快速定位。

下面为运维大数据平台的物理部署拓扑图，分为三个集群，Hadoop集群、ES日志集群和Kalfka消息集群。

物理部署架构设计说明：

（1）配置多台服务器做Hadoop集群，满足不同应用和系统日志的单系统与跨系统交易日志统计与分析，满足数千个基础监控分区的基础性能分析与运行性能指标预测等，以及指性能标入库与历史日志数据入库的存储需要。
（2）配置多台服务器做ES集群，承载实时统一日志查询与分析平台的任务，满足数天至一个月不同需求的日志查询和分析需求，历史日志查询需要从HDFS中将数据导入至ES中，进行二次查询。
（3）配置多台服务器做Kafka集群用于实时的指标型与日志型数据流的采集，满足实时监控的需求。

3.2 功能逻辑架构设计

下面为业务及网络性能管理、运维大数据平台及与现有的基础监控和集中事件平台联动的整体功能逻辑架构图：

功能逻辑架构设计说明：

（1）网络流量报文通过TAP设备发送至NPM服务器和BPC服务器的采集口；NPM系统和BPC系统实时解码模块，对网络原始比特流进行解析，输出网络层指标和业务应用层指标；业务层和网络层数据分析模块实时分析性能指标：交易量、业务成功率、系统响应率、响应时间、交易渠道、交易类型、金额、TCP连接状态、丢包状态、网络时延……等等指标；

（2）NPM和BPC前台展示模块从运维角度，可以实时的展示每一个节点的业务层和网络层指标情况，并配置实时告警，做到快速发现、快速定位、快速恢复；
NPM和BPC前台展示模块从业务运营角度，可以对全行交易情况进行实时大屏展示，对业务交易渠道、交易机构、交易金额、交易量、自定义的统计维度等进行实时分类统计分析；

（3）BPC可以在选定的条件中搜索符合条件的交易条目，并通过列表进行展示。
在搜索条件栏中，运维人员不仅可以根据交易类型、服务器IP、交易结果、返回码等条件进行过滤搜索，还可以以后台配置输出的其他业务字段作为条件（如卡号、流水号等），进行更精确的交易条目搜索，同时，支持对特定敏感字段进行屏蔽或加扰。利用交易追踪，BPC能够对一笔交易经过路径中的每个节点进行关联展示，并能够同时输出指定时间段内所有交易的关联结果，解析每一笔交易在多个业务节点中的流转、处理结果、延迟；利用NPM的故障定位，运维人员即可通过实时的告警信息，使用 NPM的钻取功能迅速定位、分析故障发生的根本原因，同时，可以在任意位置导出指定的原始数据报文，供更深层次的分析或取证使用。

（4）业务性能监控和网络性能监控系统对外的接口包括数据输出接口、交易明细输出、告警接口：数据输出接口可将业务监控系统统计的交易性能数据和交易明细数据按JSON、CSV、xml等方式实时输出，提供给第三方系统。或者第三方系统可以通过RestfulAPI的方式来查询所产生的统计数据、告警数据、明细报文数据等。告警信息可通过syslog、socket等方式发送到第三方事件管理平台进行集成，统一进行汇总处理。本次实时解析的各系统性能数据，业务交易字段等实时推送给运维大数据平台，为实时运维大数据分析提供真实可信的数据源；业务交易及网络性能监控产生的告警事件，实时推送到现有集中事件平台；运维大数据平台产生的告警事件，实时推送到现有集中事件平台；

（5）在集中了性能、配置、日志、事件等运维数据的基础上，以运维大数据平台为核心，开展智能运维在监控方面的建设，如单、多指标预测和分析、建议，告警事件自动关联知识库，指导运维人员快速解决问题，结合多类监控数据，进行可能的根因分析，辅助运维人员快速定位故障源，并在告警日志上下文历史挖掘分析、同类告警周期性规律分析、告警成对成组出现分析、告警相关与因果分析等等方面，进行智能分析，推进运维工作自动化和智能化；

（6）运维大数据平台根据运维数据的实时性，分类获取不同运维数据源数据，实时型数据通过Flume采集至Kafka集群等待消费，例如性能型数据和日志型数据，非实时性数据直接落地至Hadoop集群，例如经BPC和NPM处理后的网络报文数据和T+1表数据。集中监控平台的告警事件为实时型数据，以该数据和时间戳为基准，自动关联前几个小时的各类运维数据、基线数据和预测数据，可根据故障发生时间点，复原一段时间内的系统告警事件、性能、日志、网络报文等信息，辅助故障分析和快速解决。通过统一的运维大数据故障分析界面，还可以进一步链接至BPC和NPM的页面，利用BPC和NPM的单笔业务精确定位和交易跟踪功能，更精准的定位故障根源；

（7）在各数据源数据统一接入运维大数据平台后，特别是利用将来接入的WEB终端、柜面客户端，ATM终端，手机APP终端，IPAD终端等的性能和体验监控平台的运维数据后，通过不同的方式收集各类终端的行为或体验数据，数据收集方式如WEB ACCESS日志，应用日志，嵌入式程序，应用程序HOOK等。可为不同的用户的终端行为进行画像，供以后的精准营销或者风控项目消费，进一步指导业务的运营和管理等。