面向业务应用交易的IT运维监控系统建设思路

《面向业务应用交易的IT运维监控系统建设思路》由会员分享，可在线阅读，更多相关《面向业务应用交易的IT运维监控系统建设思路（4页珍藏版）》请在金锄头文库上搜索。

1、面向业务应用交易的IT运维监控系统建 设思路Ill作者：张晓丹来源：中国金融电脑2015年第1期中国工商银行股份有限公司数据中心（北京）专家 张晓丹为适应数据中心大规模集约化运营管理的需求，国内各企业陆续建立起了面向主机、平台、 网络、存储、环境动力、应用软件等的专业监控系统，实现了各个专业的监控事件和容量性能 数据的集中展现和处理，但仍存在如下不足：一是缺少对各业务应用交易的运行情况（交易量、 成功率、平均响应时间）的监控，难以全面、准确、及时地掌握业务应用系统的运行情况；二 是无法自动发现应用拓扑关系和交易访问路径，并以此为基础实现故障应用系统的自动定位； 三是无法将操作系统、中间件、数据

2、库、存储、网络、环境动力等IT基础设施专业事件与各 应用系统的业务交易或系统交易事件关联起来进行自动故障树分析。这导致IT运维中出现： 专业事件处理量大、业务影响分析困难、故障根源定位慢、故障节点难以自动隔离恢复等问题。 为此，企业需要以业务应用交易监控为中心，升级整合传统的IT运维监控系统。一、建设目标面向业务应用交易的运维监控系统建设目标主要包括：实时、准确掌握企业各业务应用 系统的运行状态和故障业务影响度，提升业务系统可用性、容量、性能等SLA服务级别管理水 平。自动发现业务应用系统拓扑关系和交易访问路径，进行故障应用系统或故障应用节点的 自动定位处理。自动关联专业事件与交易事件，进行交

3、易、故障树生成和业务影响度分析。 降低IT基础设施专业OLA运行级别管理水平。全面采集中间件、数据库、程序代码等运行 日志信息，深度分析处理各种难以进行实时指标监控的故障问题。自动发现和优化治理各种 IT组件的属性、访问关系等配置数据，支持各种专业和交易指标的智能处理和可视化展现。 跨领域整合主机、平台、网络、环境动力、应用软件等专业监控系统，建立统一的门户视图、 可用性、容量性能、事件等模块。二、建设思路参照Gartner APM应用性能监控的有关模型方法，面向业务应用交易的IT运维监控系统 规划设计可以分为5个维度（如图1所示）。1. 业务功能和交易访问用户体验监控将整个IT系统作为提供I

4、T服务的“黑盒”，从用户终端、网络接入端、渠道类（用户接 入）应用端实时获取各个业务交易代码、业务功能、服务渠道、对端客户机构等多维度的交易 量、成功率、响应时间等交易指标，并建立每个指标每分钟时点的采样值组成的动态基线，全 面准确反映业务应用系统的运行情况。交易指标的获取方式主要有两种：一种是通过TAP SWITCH镜像每个应用系统的APP节点的网络流量，实时解析还原网络流量中的交易报文获得; 另一种是由应用系统实时输出交易日志，再对这些日志进行实时指标加工处理。前者需要采购 投入专业的网络流量采集设备和流量解析加工处理系统，但对应用系统改动较少，只需规范应 用系统报文格式，在报文中增加UU

5、ID全局事件跟踪号、交易代码等信息。后者需要对应用系 统做较大改造，并建立统一的日志分析处理平台。该方案对应用服务器的性能开销有一定的影 响，但可以根据需要灵活方便地统计分析各种业务应用交易情况。2. 应用系统拓扑关系和交易访问路径自动发现将IT系统“黑盒”打开，全面采集各个非渠道类的业务应用系统交易数据，再基于手工 或自动发现的业务依赖模型，可视化地展示某个交易代码、业务功能模块或业务系统需要经过 的应用系统拓扑关系和交易路径（含应用逻辑节点的访问顺序关系）。通过对比交易路径或应 用拓扑图上不同应用系统的总量/分量交易指标的变化情况，可以将故障自动定位到某个应用 系统，甚至该应用系统的某个A

6、PP服务器节点。应用系统之间的访问拓扑关系，可以根据手工 录入到CMDB配置管理系统中的数据自动生成，也可以基于不同应用系统输出的交易日志中的 一些上下游关键字段信息自动生成，并自动更新CMDB中的数据项信息。在此过程中，通过手 工录入的方式对每个交易代码的交易路径进行维护的工作量大且难以保持一致性，必须通过实 时、详细、全面的输出和关联交易日志才能实现。3. 专业事件与交易事件的关联和业务影响分析前两个维度的交易指标监控，可以将大多数故障定位到某个应用系统的APP服务器节点。 但究竟是该APP服务器节点自身软硬件有问题，还是其上下游的Web和数据库服务器的软硬件 有问题，或者是相关网络和SA

7、N存储连接有问题？就需要根据监控对象依赖模型（配置项间的 影响和依赖关系）、监控指标依赖模型，自动关联IT组件的专业事件与业务应用的交易事件， 并自动生成以根源交易事件为根的故障分析树。这既可大幅减少事件处理的工作量，也可自动 发现一组事件根源问题，自动或半自动地隔离故障节点，快速恢复业务。4.IT组件深度监测分析诊断上述三个维度的工作，可以自动关联定位大量事件的根源故障节点，以进行自动或半自动 的隔离恢复处理。但对于不能自动生成故障树的情况，还需要通过提供相关的对象和指标的可 视化展现功能，以及手工启动各种自动化分析诊断脚本的功能，逐层钻取检查各个相关的IT 组件，以便快速确定故障根源。如：

8、当发现2个应用节点之间的网络连接中断后，可以调用相 关检查脚本TRACE网络连通情况，调出2个应用节点IP地址间经过的网络设备的运行状态和 网络连接状态，以便手工检查定位故障设备。再如：对于中间件、数据库、应用程序深层次的 Bug问题，不适宜通过穷举建立各种实时监控指标，而适宜在应用节点上部署一些专业化的故 障诊断工具，或者在开发阶段提高应用系统程序的可诊断性，内嵌各种故障检测排查代码，根 据需要全面采集相关数据，进行深度分析诊断。5.运维数据处理和报告展示通过上述4个维度的操作，产生了各种业务系统交易日志、事件性能数据、分析诊断信息、 配置资产信息、人员机构信息等数据。建设IT运维数据处理平

9、台可实现对这些数据的实时、 批量统计分析，为集中监控和运维统计分析处理、信息安全和科技风险管理、内外部审计检查 等提供支持。如：利用大数据、流式数据处理等数据加工方法，进行各种维度和粒度的交易量、 成功率、响应时间等指标分析，以及对这些指标的基线和上下限阈值的数据处理。此外，IT运 维数据处理平台还应具有自动可视化展现各种监控对象、指标、业务与应用的关联和访问关系 的功能。三、关键难点建设面向业务应用交易的运维监控系统的关键难点，主要包括最上层的业务应用交易日志 的获取；中间层的专业和交易事件的自动关联处理；最下层的配置数据的自动发现治理和可视 化展现，以及跨各层的运维管理流程优化。1. 业务

10、应用交易日志获取业务应用交易日志获取的方式主要有两种：通过实时解析网络流量还原报文；通过应用系 统实时输出交易日志。无论采用哪种方式都需要通过应用改造或网络流量截取的方法获得 UUID（全局事件跟踪号）、交易唯一标识、交易上下游节点名称或IP地址、交易响应时间等 数据。这些信息是生成各种交易指标、自动发现交易路径和应用拓扑的关键信息。采用应用改 造的方法，信息获取的成本和时间周期都比较长；采用网络流量解析的方法则难以获得所有数 据，且自主可控和灵活统计能力差。因此，可综合利用这两种技术方法，即对于渠道类应用优 先采用应用输出交易日志的方式；对于非渠道类应用优先应用网络流量解析的方式。2. 专业

11、事件和交易事件自动关联IT软硬件系统在运行过程中，会随着自身可靠性和负载大小的变化产生大量的专业事件。 这些事件中有些只是有关当前运行状态的提示信息。传统运维监控系统围绕专业指标进行管理， 各种IT组件产生专业事件后，很难通过事件以及产生事件的软硬件本身了解其对业务产生了 多大影响，更无法知道同一时段内产生的各种专业事件相互之间的关系。为此，很多企业尝试 对各种专业事件进行大数据分析，以期找到其中的一些相关性；或尝试基于软硬件的重要性和 运维关系规则对事件进行关联。但还存在规则方法不统一，难以确认事件业务影响度的问题。 解决的方法是，基于业务和交易与应用系统的依赖关系（通过交易日志自动发现或部

12、分手工录 入），建立各种IT组件（配置项或监控对象）依赖关系的对象模型，将Web、APP、DB服务器 的专业事件，以及应用软件的专业事件，与APP服务器或应用系统的交易事件进行关联。关联 过程中，根据各种监控指标之间的依赖关系（如存储的可用性、容量和性能指标与上层数据库 的可用性和性能指标的关系），自动建立一棵专业事件与交易事件关联的故障树，实现高效分 析处理一组事件。此种方法甚至可以做到自动隔离有冗余备份的故障应用节点，避免了此类故 障可能对业务造成的长时间影响。3. 配置数据自动发现、治理和可视化配置数据库是IT运维监控系统的核心。各种拓扑关系图、监控视图、事件丰富过滤关联、 问题分析、可

13、用性容量性能统计功能都需要依赖全面、准确的配置数据。以往企业主要以手工 输入、定期勘误的方式进行数据治理。实施交易监控过程中，可以利用交易日志或报文数据中 的一些上下游关联信息，自动发现各个应用节点之间的访问关系，以及某个业务交易所经过的 交易路径等配置数据。这些配置数据不仅可以作为手工输入的配置数据的补充，也可用于每日 例行数据库配置比对，自动或半自动地更新配置数据库，以确保配置数据的有效性和一致性。 同时，随着数据中心虚拟化、服务化发展，数据中心内部各种IT组件（配置项）之间的访问 和依赖关系配置数据，也需要有一种可视化的工具支持，自动产生运维管理人员所需要的视图 和拓扑图，以提高运维管理

14、效率。4. 运维流程优化企业原有各专业监控系统围绕交易监控关联整合后，有关可用性、容量、事件、问题、配 置等管理流程也需要相应地进行优化，以适应新系统的运行。如：各种专业事件不再需要直接 按业务影响程度定义业务级别，而是回归到对软硬件系统自身可能的影响自行定义专业级别。 同时，对于那些没有产生影响业务的交易事件的各个专业事件，不再需要人工逐个确认跟踪处 理。通过建立完善的交易指标监控体系，可以统一 IT部门与业务部门间的沟通语言和服务评价 标准，提升双方的SLA服务级别管理水平。通过建立各种专业事件与交易事件的关联并自动生 成故障树，可以整合原有分散建设的各专业监控系统，从而大幅提升IT故障的处理效率和质 量。因此，建设面向业务应用交易的运维监控系统，是企业IT运维部门从IT专业运营向业务服务运营转型的必由之路，也是以可用性管理为主的传统数据中心向以资源和服务管理为主的 云化数据中心发展过程中的一项基础性工作，需要提前做好规划设计。