CN103295155A

CN103295155A - 证券核心业务***监控方法

Info

Publication number: CN103295155A
Application number: CN2012105017404A
Authority: CN
Inventors: 曾宏祥; 邹建东; 袁维举; 高�勋; 成晨; 胡谊东; 杨子军; 张敏; 王厦
Original assignee: Guotai Junan Securities Co Ltd
Current assignee: Guotai Junan Securities Co Ltd
Priority date: 2012-11-30
Filing date: 2012-11-30
Publication date: 2013-09-11
Anticipated expiration: 2032-11-30
Also published as: CN103295155B

Abstract

一种证券核心业务***监控方法，包括：将监控指标划分为IT基础设施层面、计算机硬件层面、操作***层面、业务程序内部层面、业务逻辑层面，并且，每个层面有不同的监控指标以及相应的监控方式，在操作***层面上将其划分为数据库服务器、业务中间件、通讯中间件、其他业务程序这四种类型，且针对这四种类型，操作***层面的监控指示的取值范围、监控重点各不相同；业务程序内部层面以业务为导向，建立并保存各个层面之间的相互关系，以此建立树形结构；当各个营业网点、数据中心在对应的监控方式下产生预先设定方式下的报警时，显示该报警下影响的相关树形结构信息以客户体验为导向的业务全流程监控。

Description

证券核心业务***监控方法

技术领域

本发明旨在提供一种控制领域，尤其涉及证券核心业务***监控方法。

背景技术

在证券领域，核心业务***一般放置在机房内，由硬件和软件组成。机房IT基础设施主要包括电力、UPS、门禁、消防、漏水检测、空调、机柜、网络安全、存储等设备。硬件还包括各种型号的计算机（主要包括小型机、服务器、PC机）。软件部分的基础是操作***，而数据库***、业务中间件、通讯中间件、其他业务程序等都属于软件的一部分，继承了软件的特性。通过把数据库***、业务中间件、通讯中间件、其他业务程序等部分按照业务规则整合，就构成了核心业务***。核心业务***由集中交易***、网上交易***、融资融券***、第三方存管***等组成。

现有核心业务***一般都是各个券商各自为政，互通性极其差。并且，扩展性也不佳。

并且，现有核心业务***的监控是针对机器做监控，当机器出现问题而引起故障报警时，现有的维护人员也仅针对该机器进行维修，而对该机器出现问题而引发的上下游问题，现有的监控***是没有办法做监控。也就是说，现有的监控***只能做出点监控，而无法做到对整个业务进行监控。

还有，分支机构业务***部署在各分支机构机房内，对分支机构业务***的监控现在并未纳入监控体系中。分支机构故障并没有能够在各分支机构本地报警，并且报警信息虽然能实时传送到总部，但是总部并不能实时展现各分支机构业务***运行状况。

发明内容

本发明提供了一种证券核心业务***监控方法，包括以下步骤：

将包括各个营业网点、数据中心的在内的各项业务及硬件，进行统一集中监控；

将监控指标划分为IT基础设施层面、计算机硬件层面、操作***层面、业务程序内部层面、业务逻辑层面，并且，每个层面有不同的监控指标以及相应的监控方式，在操作***层面上将其划分为数据库服务器、业务中间件、通讯中间件、其他业务程序这四种类型，且针对这四种类型，操作***层面的监控指示的取值范围、监控重点各不相同；

业务程序内部层面以业务为导向，建立并保存各个层面之间的相互关系，以此建立树形结构；

当各个营业网点、数据中心在对应的监控方式下产生预先设定方式下的报警时，显示该报警下影响的相关树形结构信息。

机房环境监控的主要方式有检测电力、UPS、门禁、消防、空调、温度、湿度、漏水检测设备；网络安全设备的监控方式有对网络安全设备的报警Syslog 的监控、对广域网接入线路网络流量的监控；存储设备的监控方式有对存储设备的报警Syslog的监控，对机房环境的监控需要部署PLC、DCS工控设备采集数据信息，通过网络把这些信息传送给SNMP管理站，使SNMP管理站收到这些环境数据，进而能够统一处理机房环境的监控数据，对网络安全设备的监控应当采取SNMP规范进行安全检测。

通过WMI访问、配置、管理和监视几乎所有的Windows资源：用户通过WMI在远程计算机上启动一个进程；设定一个在特定日期和时间运行的进程；远程启动计算机；获得本地或远程计算机的已安装程序列表；查询本地或远程计算机的Windows事件日志。

对于Linux***，设备被监控后会自动通过SNMP协议从其设备模板中获取CPU利用率、内存使用率、磁盘使用率、磁盘剩余空间在内监控信息。

业务程序内部层面的监控主要是监控应用程序日志；

应用程序日志的监控主要是根据日志检测错误关键字，根据关键字的报警级别进行监控；业务程序内部监控是指应用程序内部把检测到的故障信息发送给监控代理；

程序内部的监控技术主要采用日志分析技术，通过对日志关键字的甄别，分析出程序的运行状态，也可以预先把需要分析的日志导入到数据库或者云服务器中，然后使用规则引擎对这些数据进行分析，进而能够统计出我们监控需要的各种数据，或者生成各种实时的报警事件。

业务逻辑层面的监控指标包括客户委托状态、交易所委托状态、委托、成交笔数、非交易期间客户委托笔数过大、模拟客户登录

并通过以下方式来进行监控

解到采用实时库保存数据，并根据实时库的特性来压缩数据、存储历史数据、查询数据，并且实时库根据标签来存储数据和查询数据，标签定义的文本文件包括标签名,类型,存盘,压缩,精度%,描述,单位

在查询时可通过标签来进行查询。

根据报警的严重程度，将报警分为INFO（提示信息）、WARNING（警告）、MINOR（次要）、CRITICAL（重大）、CONTINUED（持续报警）五个等级，可以根据实际情况划分具体的报警级别，

报警管理***能够对相同的报警进行压缩，压缩报警的个数需得到实时显示或根据需要过滤不希望上报的报警。

结合附图，根据下文的通过示例说明本发明主旨的描述可清楚本发明的其他方面和优点。

附图说明

结合附图，通过下文的述详细说明，可更清楚地理解本发明的上述及其他特征和优点，其中：

图1为管理原理图；

图2为树形结构示例图。

具体实施方式

参见示出本发明实施例的附图，下文将更详细地描述本发明。然而，本发明可以以许多不同形式实现，并且不应解释为受在此提出之实施例的限制。相反，提出这些实施例是为了达成充分及完整公开，并且使本技术领域的技术人员完全了解本发明的范围。这些附图中，为清楚起见，可能放大了层及区域的尺寸及相对尺寸。

在本实例中，监控的指标主要分为5个层面：IT基础设施层面、计算机硬件层面、操作***层面、业务程序内部层面、业务逻辑层面。每个层面有不同的监控指标以及相应的监控方式。对核心业务***的监控需要支持证券交易日与非交易日的配置。

5.1.IT基础设施层面

5.1.1.监控指标

IT基础设施是IT运维管理的基础，相应的监控指标主要包括：

机房环境：包括电力、UPS、门禁、消防、空调、温度、湿度、漏水检测设备。

网络安全设备

存储

5.1.2.监控方式

机房环境监控的主要方式有检测电力、UPS、门禁、消防、空调、温度、湿度、漏水检测设备等；网络安全设备的监控方式有对网络安全设备的报警Syslog的监控、对广域网接入线路网络流量的监控；存储设备的监控方式有对存储设备的报警Syslog的监控。

5.1.3.监控技术

对机房环境的监控需要部署PLC（Programmable Logic Controller，可编程逻辑控制器）、DCS（Distributed Control System，分布式控制***）等工控设备采集数据信息，通过网络把这些信息传送给SNMP管理站，使SNMP管理站收到这些环境数据，进而能够统一处理机房环境的监控数据。

对网络安全设备的监控应当采取SNMP（Simple Network ManagementProtocol，简单网络管理协议）规范进行安全检测。

SNMP是目前最常用的环境管理协议。SNMP被设计成与协议无关，所以它可以在IP，IPX，AppleTalk，OSI 以及其他用到的传输协议上被使用。SNMP是一系列协议组和规范，它们提供了一种从网络上的设备中收集网络管理信息的方法。SNMP也为设备向网络管理工作站报告问题和错误提供了一种方法。

该协议能够支持网络管理***，用以监测连接到网络上的设备是否有任何引起管理上关注的情况。它由一组网络管理的标准组成，包含一个应用层协议（Application Layer Protocol）、数据库模型（Database Schema）和一组数据对象。

5.2.计算机硬件层面

5.2.1.监控指标

计算机硬件层面的监控主要有以下指标：

整机：整机故障；组成部件（电源、主板、CPU、内存、磁盘、网卡、风扇等）的故障。

CPU：温度。

硬盘驱动器：最高传输速率、最低传输速率、平均传输速率。

电源：功耗。

风扇：速度。

5.2.2.监控方式

根据计算机硬件层面的监控指标的取值范围、监控重点，设置监控指标如下表所示：

注：对于计算机整机的监控，可以通过间接的方法判断计算机是否宕机：一种方法是通过监控代理的心跳信号；另一种是定期Ping计算机。如果在排除网络故障之后，仍然存在没有心跳信号或者Ping不通被监控计算机的情况，则判断计算机可能已经宕机并且报警。

5.2.3.监控技术

在计算机主机监控方面，不论是Windows类操作***还是Unix/Linux类操作***，均支持SNMP协议。SNMP数据采集接口规范能直接满足计算机硬件的采集需求，SNMP的管理模型包括管理***（NMS），代理（Agent），管理信息库（MIB）和网络管理协议四个关键元素，其构成部分及相互关系如图1所示。驻留在被管设备上的AGENT从UDP端口161接受来自管理站的串行化报文，经解码、团体名验证、分析得到管理变量在MIB树中对应的节点，从相应的模块中得到管理变量的值，再形成响应报文，编码发送回管理站。管理站得到响应报文后，再经同样的处理，最终显示结果。

被监控的计算机都关联了基于SNMP协议的监视器，代理（Agent）在这些计算机上获取到主机硬件的监控指标，通过网络把这些信息传送给SNMP管理站，使SNMP管理站收到这些硬件指标数据，进而能够统一处理和展示。

5.3.操作***层面

5.3.1.监控指标

操作***层面的监控主要有以下指标：

CPU利用率：包括平均CPU利用率、最大CPU利用率。

内存使用率：包括内存使用率、可用内存。

进程是否存在：包括进程是否存在，进程个数。

磁盘使用率：磁盘繁忙程度、磁盘读写性能。

磁盘剩余空间：包括剩余空间百分比、剩余空间字节数。

网络使用率：包括网络带宽使用百分比、错误包百分比。

监控代理进程是否存在

其中在操作***级别上，根据计算机的使用目标不同，所要监控的指标也不同、指标数值也不同，监控取决于***的应用特性。

5.3.2.监控方式

操作***层面的监控，按照业务类型可将计算机划分为数据库服务器、业务中间件、通讯中间件、其他业务程序等四种类型。根据这四种***类型，操作***层面的监控指标的取值范围、监控重点各不相同。具体指标如下表所示：

5.3.3.监控技术

针对操作***层面的监控，对于Windows***应当采用WMI（WindowsManagement Instrumentation，Windows管理规范）技术，而对于Linux***应当根据需求配置不同的监控工具。

WMI，是一项核心的Windows管理技术，是Windows管理***的核心，WMI作为一种规范和基础结构，通过它可以访问、配置、管理和监视几乎所有的Windows资源，例如，用户可以在远程计算机上启动一个进程；设定一个在特定日期和时间运行的进程；远程启动计算机；获得本地或远程计算机的已安装程序列表；查询本地或远程计算机的Windows事件日志等。

对于Linux***，设备被监控后会自动通过SNMP协议从其设备模板中获取CPU利用率、内存使用率、磁盘使用率、磁盘剩余空间等监控信息。例如，针对Linux计算机，默认的Linux***模板关联了基于SNMP协议的监视器，于是所有的Linux计算机都将关联基于SNMP协议的监视器。

服务器模板提供了更加丰富的资源信息，默认除CPU、内存、磁盘等监视器外，还有很多服务、应用、链接等监视器来辅助监控。

5.4.业务程序内部层面

5.4.1.监控指标

业务程序内部层面的监控主要有以下指标：

应用程序日志

业务程序内部监控

5.4.2.监控方式

应用程序日志的监控主要是根据日志检测错误关键字，根据关键字的报警级别进行监控；业务程序内部监控是指应用程序内部把检测到的故障信息发送给监控代理。

5.4.3.监控技术

程序内部的监控技术主要采用日志分析技术，通过对日志关键字的甄别，分析出程序的运行状态，达到监控目的。为了更好的对日志进行分析，可以预先把需要分析的日志导入到数据库或者云服务器中，然后使用规则引擎对这些数据进行分析，进而能够统计出我们监控需要的各种数据，或者生成各种实时的报警事件。

5.5.业务逻辑层面

5.5.1.监控指标

业务逻辑层面的监控主要有以下指标：

客户委托状态

交易所委托状态

委托、成交笔数

非交易期间客户委托笔数过大

模拟客户登录

5.5.2.监控方式

业务逻辑层面的监控和证券公司所处理的业务规则息息相关，完全应当根据实际的业务逻辑处理监控方式。

具体规则如下表所示：

5.5.3.监控技术

业务逻辑层面的监控，需要根据证券的业务规则，对不同的监控指标进行相应的逻辑分析，判断出应当采用的技术。例如，对交易所委托状态监控指标的监控，需要对业务数据库进行查询操作，并根据数据库中的标识变量，确定指标的状态，这就需要数据库的远程动态查询技术。

6.1.IT基础设施监控消息

6.1.1.业务功能

a 机房环境（业务功能码：10001）；

b 网络安全设备（业务功能码：10002）；

c 存储（业务功能码：10003）；

6.1.2.标签名称

本消息体的标签名称为：<Sysm.001.01>。

6.1.3.业务要素

监控消息的业务要素见下表。

6.1.4.使用规则

a ***根据消息头中的业务功能码确定消息的具体业务功能。

b 每个业务功能对象获得数据的单位不同。

c 每个业务功能号会根据实际的需要，输入不同的参数，来获取不同对象上的数据。

d 重设区间、重发消息时，数据包序号将表示在两个序号之间的闭区间需要重设和重发。如果某项值为0，表示为无穷大。

e 根据业务功能，消息中的功能名称为相应的功能号。

6.2.IT基础设施监控回执

6.2.1.业务功能

回应IT基础设施监控消息。

6.2.2.标签名称

本消息体的标签名称为：<Sysm.002.01>。

6.2.3.业务要素

回执消息的业务要素下表。

索引	要素名称	英文名称	XML Tag	元素类型	备注
						1	消息头	MessageHeader	<MsgHdr>	String
2	返回结果	ReturnResult	<Rst>	Int

6.2.4.使用规则

a本消息用来回应对方发来的监控消息，消息头中的业务功能码应与回应消息中的业务功能码一致。

b返回结果指示业务操作是否成功，返回结果中，如果出现异常则根据返回码表，返回相应的错误序号，正常则返回0。

6.3.计算机硬件监控消息

6.3.1.业务功能

a 整机（业务功能码：11001）；

b CPU（业务功能码：11002）；

c 硬盘驱动器（业务功能码：11003）；

d 电源（业务功能码：11004）；

e 风扇（业务功能码：11005）；

6.3.2.标签名称

本消息体的标签名称为：<Sysm.003.01>。

6.3.3.业务要素

监控消息的业务要素见下表。

监控消息

索引	要素名称	英文名称	XML Tag	元素类型	备注
						1	消息头	MessageHeader	<MsgHdr>	String
2	认证数据	AuthenticData	<AuthData>	String
						3	密钥	PasswordKey	<PwdKey>	String
4	数据包序号	SequenceNo	<SeqNo>	Int
						5	摘要	Digest	<Dgst>	String
6	对象名称	ObjectName	<ObjName>	String
						7	功能名称	FunctionName	<FuncName>	Int

6.3.4.使用规则

a ***根据消息头中的业务功能码确定消息的具体业务功能。

b 每个业务功能对象获得数据的单位不同。

d 重设区间、重发消息时，数据包序号将表示在两个序号之间的闭区间需要重设和重发；如果某项值为0，表示为无穷大。

e 根据业务功能，消息中的功能名称为相应的功能号。

f 计算机作为一个对象，内存、风扇等作为构成计算机的一个部件，可以根据对象名称来获取相应的监控数据。

6.4.计算机硬件监控回执

6.4.1.业务功能

回应计算机硬件监控消息。

6.4.2.标签名称

本消息体的标签名称为：<Sysm.004.01>。

6.4.3.业务要素

监控回执消息的业务要素见表

索引	要素名称	英文名称	XML Tag	元素类型	备注
						1	消息头	MessageHeader	<MsgHdr>	String
2	返回结果	ReturnResult	<Rst>	Int
						3	返回数据	Data	<Data>	Int

6.4.4.使用规则

a 本消息用来回应对方发来的监控消息，消息头中的业务功能码应与回应消息中的业务功能码一致。

b 返回结果指示业务操作是否成功，返回结果中，如果出现异常则根据返回码表，返回相应的错误序号，正常则返回0。

c 根据不同的业务功能，返回相应的数据。

6.5.操作***监控消息

6.5.1.业务功能

a CPU利用率（业务功能码：12001）；

b 内存使用率（业务功能码：12002）；

c 进程是否存在（业务功能码：12003）；

d 磁盘使用率（业务功能码：12004）；

e 磁盘剩余空间（业务功能码：12005）；

f 网络使用率（业务功能码：12006）；

g 监控代理进程是否存在（业务功能码：12007）

6.5.2.标签名称

本消息体的标签名称为：<Sysm.005.01>。

6.5.3.业务要素

索引	要素名称	英文名称	XML Tag	元素类型	备注
						1	消息头	MessageHeader	<MsgHdr>	String
2	认证数据	AuthenticData	<AuthData>	String
						3	密钥	PasswordKey	<Pwd Key>	String
4	数据包序号	SequenceNo	<SeqNo>	Int
						5	摘要	Digest	<Dgst>	String
6	功能名称	FunctionName	<FuncName>	Int
						7	方法名称	MethodName	<MethodName>	String

[0172] 6.5.4.使用规则

a ***根据消息头中的业务功能码确定消息的具体业务功能。

b 每个业务功能对象获得数据的单位不同，比如磁盘使用率是百分比。

e 根据业务功能，消息中的功能名称为相应的功能号。

f 根据不同的方法，获取不一样的监控数据格式。

6.6.操作***监控回执

6.6.1.业务功能

回应操作***监控消息。

6.6.2.标签名称

本消息体的标签名称为：<Sysm.006.01>。

6.6.3.业务要素

监控回执消息的业务要素见下表。

6.6.4.使用规则

b 返回结果指示业务操作是否成功。

c 不同的业务功能，返回数据的单位不同，格式也不同。

6.7.业务程序内部监控消息

6.7.1.业务功能

a 应用程序日志（业务功能码：13001）；

b 业务程序内部监控（业务功能码：13002）；

6.7.2.标签名称

本消息体的标签名称为：<Sysm.007.01>。

6.7.3.业务要素

监控消息的业务要素见下表。

索引	要素名称	英文名称	XMLTag	元素类型	备注
						1	消息头	MessageHeader	<MsgHdr>	String
2	认证数据	AuthenticData	<AuthData>	String
						3	密钥	PasswordKey	<PwdKey>	String
4	数据包序号	SequenceNo	<SeqNo>	Int
						5	摘要	Digest	<Dgst>	String
6	日志关键字	KeyWord	<KeyWord>	String

6.7.4.使用规则

a ***根据消息头中的业务功能码确定消息的具体业务功能。

b 每个业务功能对象获得数据的单位不同。

e 根据日志的关键字，分析不同的日志消息。

6.8.业务程序内部监控回执

6.8.1.业务功能

回应业务程序内部监控消息。

6.8.2.标签名称

本消息体的标签名称为：<Sysm.008.01>。

6.8.3.业务要素

监控回执消息的业务要素见下表。

6.8.4.使用规则

b返回结果指示业务操作是否成功。

6.9.业务逻辑监控消息

6.9.1.业务功能

a 客户委托状态（业务功能码：14001）；

b 交易所委托状态（业务功能码：14002）；

c 委托、成交笔数（业务功能码：14003）；

d 非交易期间客户委托笔数过大（业务功能码：14004）；

e 模拟客户登录（业务功能码：14005）；

6.9.2.标签名称

本消息体的标签名称为：<Sysm.009.01>。

6.9.3.业务要素

监控消息的业务要素见下表。

索引	要素名称	英文名称	XMLTag	元素类型	备注
						1	消息头	MessageHeader	<MsgHdr>	String
2	认证数据	AuthenticData	<AuthData>	String
						3	密钥	PasswordKey	<PwdKey>	String
4	数据包序号	SequenceNo	<SeqNo>	Int
						5	摘要	Digest	<Dgst>	String
6	查询语句	QueryString	<QueryString>	String

6.9.4.使用规则

a ***根据消息头中的业务功能码确定消息的具体业务功能。

b 每个业务功能对象获得数据的单位不同。

e 根据不同的查询语句，动态的返回查询数据。

6.10.业务逻辑监控回执

6.10.1.业务功能

回应业务逻辑监控消息。

6.10.2.标签名称

本消息体的标签名称为：<Sysm.010.01>。

6.10.3.业务要素

监控回执消息的业务要素见下表。

索引	要素名称	英文名称	XMLTag	元素类型	备注
						1	消息头	MessageHeader	<MsgHdr>	String
2	返回结果	ReturnResult	<Rst>	Int
						3	返回数据	Data	<Data>	String

6.10.4.使用规则

b 返回结果指示业务操作是否成功。

c 返回使用字符串保存的当前会话数据。

在实际的生产应用中，不仅需要查看各种实时数据，而且需要对历史数据进行回顾、分析、统计。那么海量监控数据的存储、快速查询成为必须面对的难题。例如，要监控一台计算机，其中监控指标包括CPU使用率、可用内存、剩余硬盘容量等，并且设定10秒采集一次数据，则一天采集的数据量为8640条。假设一组计算机有300台，则一天采集的总数据量为2592000条。那么，需要选择适当的方法才能够保存如此巨大的数据。

经过验证，较好的方法是采用实时库保存数据，并根据实时库的特性来压缩数据、存储历史数据、查询数据。

实时库的特点：

海量存储，高达20万标签80RTB的海量历史存储。

高效服务，高并发客户连接，连接池+线程池模式，极速连接，无需等待。

可配置的分段线性压缩和例外偏差过滤，在保证数据精度的前提下最大限度的节约存储空间。

页面二次无损压缩节约1-32倍存储空间。

立即无缓冲按扇区对齐写盘保证数据写盘逻辑的正确性。

基于TCP的应用层协议采用LZO 高速实时压缩报文，极大的节约网络资源，提高了数据传输速度。

由于实时库根据标签来存储数据、查询数据，那么对标签的定义就成了重中之重，下面是一个保存标签定义的文本文件：

标签名,类型,存盘,压缩,精度%，描述,单位

交易业务.核心1.柜台委托笔数,float32,no,no,0.000,,

交易业务.核心2.柜台委托笔数,float32,no,no,0.000,,

交易业务.核心3.柜台委托笔数,float32,no,no,0.000,,

7.2.监控数据查询

根据生产应用需求，可以根据实际的接口函数来查询实时库中的内容。

8.报警管理

8.1.报警分级

根据报警的严重程度，将报警分为INFO（提示信息）、WARNING（警告）、MINOR（次要）、CRITICAL（重大）、CONTINUED（持续报警）五个等级，可以根据实际情况划分具体的报警级别。

8.2.报警过滤与压缩

8.3.报警响应

8.3.1.自动响应

当***收到特定的告警时（特定的告警由预先设定的规则判定）执行指定的任务。例如发现某些服务、进程处于Down的状态时，可以自动重新启动这些服务和进程，同时存储日志记录。

8.3.2.短信、邮件报警

报警支持短信、邮件等发送方式。

对于短信和邮件报警，针对不同的运维人员可以设置不同的用户组，每个用户组可以接收并且管理特定的短信或邮件报警。对于某个用户组，可以对短信或邮件报警进行定制，即

可以选择接收来自哪些***的故障报警，可以具体设置短信和邮件报警的发送时间段，并且支持证券交易日与非交易日的配置。

8.3.3.语音报警

报警支持语音方式。

对于语音报警，可以对具体的报警进行定制，即可以选择接收来自哪些***的故障报警，可以具体设置语音报警的报警时间段，并且支持证券交易日与非交易日的配置。

应用例

目前已经把公司总部约40个业务***2000台设备与各分支机构各类业务***约1000台关键设备进行集中监控，不仅实现了机房环境、网络、主机、操作***、进程等通用类监控功能，而且实现了业务***业务特性监控和业务运行质量等全流程监控功能。大量重复性日常操作与检查工作已由平台自动或辅助完成，平台多次提前预警并辅助运维人员解决***故障。

集中监控平台特点：

1.统一监控平台集成了集中交易***KCMM监控、网管***NETCOOL监控、机房环境监控、OA***监控、虚拟机监控等各种现有的监控工具，可实时展现各项业务***的运行健康状况、各类资源的利用状况、各项业务的统计数据，并能展示当前与历史事件与性能报表。在统一事件平台上对事件与性能数据进行统一的分析与处理。

2.设置报警规则与策略，对不同类型的告警事件按规则进行处理，包括：事件压缩、事件过滤、自动关闭、手工关闭等。

3.监控业务KPI指标，包括：CPU、内存、网络流量、物理磁盘、IO等。

4.性能数据集中展现和总控界面展示。

5.业务逻辑与业务影响关系分析，及时准确定位故障点与故障影响范围。

6.平台本身的可靠性高、对业务***影响小。

7.业务数据展示和报表展示。

8.平台集成接口模块开发和接口规范定义。

9.集成自动化操作功能。

10.集成ISO20000IT服务管理***。

11.权限管理功能，包括用户建立、用户组建立、方案管理、方案共享、邮件通知、语音通知、短信通知。

自动化运维的特点：

1、在集中的可视化界面中执行自动化操作，提高用户的全局判断能力，提高工作效率。

2、高可靠性：自动化操作的执行过程经过严格评审，避免了人为因素导致的失误。因此，建立基于流程的自动化运维平台，实现券商的基础设施和应用***的自动化操作。

自动化操作平台自2011-10-10上线，目前已配置的流程约110个，覆盖范围包括集中交易的12个核心及总控，运行基本稳定。流程分为定时触发流程和人工触发流程：

定时触发流程主要设定交易日中需要定时执行的流程，现阶段主要配置：12个核心及总控的报盘的开启，机器的证券初始化等；人工触发的流程主要需要人工触发并且执行时间不定的流程，现阶段主要配置：12个核心和总控的KCBP、KCXP的开启、关闭等。上述流程运行基本正常。

该软件是个可配置化的平台***，用户可以根据需要从随时增减和变更流程和功能。

主要特点

1、定义了证券行业核心业务全流程监控与自动化控制的SBPC(Security BusinessProcess Control)规范。各类IT***按照接口规范进行集中监控和控制，以工业控制OPC(OLE for Process Control)与WSDL(Web Services Description Language)为基础，结合证券业务特性产生。

2、以客户体验为导向的业务全流程监控。面向客户体验，以业务流程为中心，将客户的感知转化为客观数据；以前客户反映交易慢、难以定位具体慢的环节，现可测量一笔交易总体耗时与各环节耗时，获取客户全流程交易速度与具体耗时的环节，提高***运行质量和效率，增强客户***使用的满意度。

模拟交易本质上属于自动化测试，是通过模拟证券公司的最终用户（股民等投资者）在真实交易***中的各种行为，如行情查阅、买卖委托等，获得国泰君安支持这些业务过程的业务***各环节的性能数据。模拟交易相对于监控***所获得业务***构成环节性能数据而言，其特点：

1）更加直接。从价值链的角度来看，证券公司业务***构建的目的是为了更加有效、高效地服务客户，从而更好的保有、赢得客户。自动化测试直接模拟客户在业务***的动作及行为，更加直接获得客户在使用公司提供***服务的真实感受。

2）以业务流程为中心，以客户为中心。模拟化交易过程获得的业务环节支持***与模块的性能数据是以完整业务过程的形式展现的，是以支持客户业务行为的业务流程为中心的主题性能数据。

3）更加真实。模拟化交易可以在不同的***负载情形下进行，更加真实。

4）目的更加明确地支持问题导向，提高客户服务水平。当用户使用***中出现功能、性能上的问题，向公司报告问题现象，IT运维人员接到问题报告后立即进行模拟交易测试，获得与问题发现者同样的业务场景，便于分析***中可能存在的问题。

模拟交易测试本质上是自动化测试的内容，自动化测试可以分为两大类：黑箱测试与白箱测试。

黑箱测试，是指以支持客户业务操作的业务流程为基础，将支持客户业务的应用***看作一个整体，无需明确业务流程中各业务环节的输入输出信息细部结构及其相互关联关系，从流程整体的输入输出表现来观察***的性能，仅模拟***的使用者的角度对***进行输入，捕获***整体、***组成环节的反应速度作为输出。

白箱测试，同样是以支持客户业务操作的业务流程为基础，需要进一步明确业务流程中各IT支撑环节的输入输出信息细部结构及相互约束关系，继而按照业务流程中业务节点及相互关系，对支持这些业务环节的***组件进行单独激励（输入），捕获各业务组件的性能表现，再根据业务流程组合从而既获得业务组件细节的性能表现信息又具有整体性能信息，其目的和黑箱测试是一致的，仅在测试前提和测试方式有区别。

通过主动发送专用测试包或特殊标记的包，这些专用的测试包在经过关键路径时，被业务***识别通过日志或者回送响应包反馈给测试者，测试者即可利用日志或者测试响应包来跟踪信息，计算各种指标，获取***的整体运行情况或者用于故障定位。

基于黑盒的模拟检测和基于白盒的仿真检测对业务质量进行实时监控；以前***监控指标与客户实际感受有时不一致，新平台以客户直接感受来衡量业务***运行状况，把对客户的服务质量作为监控指标。

3、核心业务***业务影响关系分析。发生故障时可展开***业务影响关系图，定位故障点，展示受影响的组件；传统监控以机器为监控对象，新平台通过业务流程分析，把机器间的关系与功能抽象为功能组件，可从功能组件角度检测业务运行状况。根据业务逻辑梳理与业务影响分析模型，可自动定义故障点，分析对整个业务的影响程度。

如图2所示，在业务影响分析图的最底层包括计算机硬件层面、操作***层面、业务程序内部层面。在此层以上的层面均是与其有关系的业务逻辑，即可能受其影响的业务。如果以上层面发生故障，对应的***就会改变颜色，受其影响的各种业务也会相应的改变为相同的颜色。其中不同的颜色表示不同的告警等级。在业务影响分析中，通过正向分析和反向分析，可以定位***的故障点和由故障点查找已经受到此故障点影响的业务，因此可以准确、有效、快速的定位整条故障链，便于维护人员处理和恢复***的故障部分。当无法准确定位***的故障点时，可以通过业务影响分析，找到可以发现或已经发现的不能正常进行的业务，然后可以定位影响此业务的因素（业务），由此逐级定位，就可以准确找到***的故障点，即正向定位。如果发现的不能正常工作的业务不是处在最上层，就可以由此业务推断出受此业务影响的业务，直至推到最上层的业务。当第一时间能够找到***的故障点，仍然可以通过业务影响分析找到受此故障点影响可能不在正常工作状态下的各种业务，直至最上层的业务，运维人员可在使故障点恢复后将不正常工作的业务恢复，即反向分析。从而保证整条业务链在物理层面和逻辑层面上都能够正常。

4、基于策略和规则的报警。可预先设置事件报警的策略与规则，对发生的事件进行分级、过滤、压缩、分析，再统一进行报警与展示。

5、支持多数据中心、大量分支机构、复杂架构监控。营业网点、其他数据中心通过另一个网络架构图来展现，部署在分支机构的监控代理将分支机构***的性能和告警事件采集后以消息的形式传递给集中监控平台，其中信息的内容及传输格式将与预先设定的字段与格式进行匹配，集中监控平台的综合处理引擎将对接收到的报警消息进行解析，根据预先设定的消息体与业务对照表确定消息业务类型，并且通过XML消息中的机构名称确定是哪个分支机构的***发生了故障，进而获取准确的信息。

我公司现有上海延平路主机房、上证通灾备机房、陆家嘴办公机房、深圳异地数据备份中心四个机房。我公司现有二十多家分公司，近二百家营业部，近四百万客户。我公司现有两百多台网络安全设备，通讯链路有地面网、卫星网、VPN接入网、同城直连光纤网；网络架构复杂，其中集中交易***分为多个网段。平台通过通讯中继技术，实现了监控与控制信息在多中心、复杂网络架构中的及时传递。

6、自动化控制指令集动态扩展与复杂流程执行控制。

由于监控目标与操作种类繁多，变化迅速，平台可动态扩展指令集，允许用户添加新功能。可视化的流程设计、控制，执行结果与监控平台集成。控制和状态监视一体化设计，采用实时数据库采集状态信息，支持高速大数据采集和存储。

7、监控与自动化控制集成的构件***。

集监控与控制于一体的构件***，具有高度安全性和可靠性。Agent事件采样间隔最短1秒，事件处理响应时间最低为2秒，对主机性能影响小于5%。服务端可处理2000并发连接/秒，可处理500任务/秒。

证券核心业务***全流程监控与自动化控制平台上线前，公司IT监控工具多，事件报警数量多，故障定位难，故障影响范围难以快速确定；日常运维操作数量多与运维人员相对不足的矛盾比较突出，***复杂度增强与应急效率的矛盾比较突出。

为整合各种IT监控工具，我们制定了《证券核心业务***监控规范》，各类IT***按照该规范可以进行了集中监控，该规范正在行业内完善推广，我们相信随着该规范的完善推广，必将极大地提高证券行业IT运行水平，有力地保障证券行业各项业务顺利开展。

该平台上线后，把各IT***的监控集成到统一的管理平台，对故障报警进行了智能过滤与分析，能自动定位故障点与影响范围，并能自动执行预先设定的应急方案。可实时展现近二百家分支机构的主要业务***运行情况，可实时监控分支机构柜台***、行情***、***交易软件、电话委托软件等***的运行状况，发生故障时通过语音报警及时通知分支机构运行人员。多次提前预警核心业务***的故障，这两年集中交易***运行保障率为99.999%，有效保障了各项业务***的正常运行；提高了IT运维工作的准确性与效率，提高了应急预案的执行速度；提高了客户对业务***的满意度，有利地促进了公司各项业务工作地顺利开展。

平台可自动实现涉及大量机器、复杂流程的程序自动化操作，可设置节假日不执行；可自动实现硬件巡检、时间同步、程序升级、数据备份功能；可进行大量程序运行状态的检查；可提示或自动对故障进行应急处理。

以前核心交易***重要服务器例行重启一般需要5个人45分钟完成，自动化控制平台上线后只需要2个人15分钟即可完成。以前核心交易主服务器故障切换备机一般需要3个人3分钟完成，自动化控制平台上线后只需要1个人1.5分钟即可完成，提高了IT运维工作的准确性与效率。

在项目开发与上线过程中，我们在技术研发、企业管理、***运行管理等三个领域培养了大量的人才。

本项目的部署和应用能够有效提高证券行业的IT运行管理水平，提升整个证券行业的IT服务水平，为证券市场安全、高效运行提供强有力的技术保障，具有很高的社会和经济效益。本***部署之后，可有效降低IT运行成本、有效降低以往由于IT***中断造成的经济损失，提高IT资源利用率。有力地保障了公司各项业务的稳定运行，增加了股民对证券行业的信心。

平台根据定义的接口规范对业务全流程进行了集中和全面地监控，从客户体验角度实时展现了业务质量，改善了***体验性，提高了客户的满意度。

发生复杂故障时平台能够自动分析、展现故障点和故障影响范围，实现准确地故障预警或报警，并能够提示或自动进行应急处理。

平台对各项日常IT运维工作进行了自动化控制，提高了运维工作的效率与准确度，缓解了运维人员相对不足的情况。

平台与ISO20000 IT服务管理平台有机集成，提高了事件、配置、容量管理流程的运作效率。

因本技术领域的技术人员应理解，本发明可以以许多其他具体形式实现而不脱离本发明的精神或范围。尽管业已描述了本发明的实施例，应理解本发明不应限制为这些实施例，本技术领域的技术人员可如所附权利要求书界定的本发明精神和范围之内作出变化和修改。

Claims

1.一种证券核心业务***监控方法，其特征在于，包括以下步骤：

当各个业务程序在对应的监控方式下产生预先设定方式下的报警时，显示该报警下影响的相关树形结构信息。

2.如权利要求1所述的方法，其特征在于，还包括以下步骤：

机房环境监控的主要方式有检测电力、UPS、门禁、消防、空调、温度、湿度、漏水检测设备；网络安全设备的监控方式有对网络安全设备的报警Syslog的监控、对广域网接入线路网络流量的监控；存储设备的监控方式有对存储设备的报警Syslog的监控，对机房环境的监控需要部署PLC、DCS工控设备采集数据信息，通过网络把这些信息传送给SNMP管理站，使SNMP管理站收到这些环境数据，进而能够统一处理机房环境的监控数据，对网络安全设备的监控应当采取SNMP规范进行安全检测。

3.如权利要求简介所述的方法，其特征在于，还包括以下步骤：

4.如权利要求1所述的方法，其特征在于，还包括以下步骤：

业务程序内部层面的监控主要是监控应用程序日志；

5.如权利要求1所述的方法，其特征在于，还包括以下步骤：业务逻辑层面的监控指标包括客户委托状态、交易所委托状态、委托、成交笔数、非交易期间客户委托笔数过大、模拟客户登录

并通过以下方式来进行监控

6.如权利要求1所述的方法，其特征在于，还包括以下步骤：

采用实时库保存数据，并根据实时库的特性来压缩数据、存储历史数据、查询数据，并且实时库根据标签来存储数据和查询数据，标签定义的文本文件包括标签名,类型,存盘,压缩,精度%,描述,单位在查询时可通过标签来进行查询。

7.如权利要求1所述的方法，其特征在于，还包括：

8.如权利要求1所述的方法，其特征在于，还包括：

营业网点、其他数据中心通过另一个网络架构图来展现，部署在分支机构的监控代理将分支机构***的性能和告警事件采集后以消息的形式传递给集中监控平台，其中信息的内容及传输格式将预先设定的字段与格式进行匹配，集中监控平台的综合处理引擎将对接收到的报警消息进行解析，根据预先设定的的消息体与业务对照表确定消息业务类型，并且通过XML消息中的机构名称确定是哪个分支机构的***发生了故障，进而获取准确的信息。