面向业务应用交易的IT运维监控思路
张晓丹 CIO之家的朋友们

为适应数据中心大规模集约化运营管理的需求,国内各企业陆续建立起了面向主机、平台、网络、存储、环境动力、应用软件等的专业监控系统,实现了各个专业的监控事件和容量性能数据的集中展现和处理,但仍存在如下不足:一是缺少对各业务应用交易的运行情况(交易量、成功率、平均响应时间)的监控,难以全面、准确、及时地掌握业务应用系统的运行情况;二是无法自动发现应用拓扑关系和交易访问路径,并以此为基础实现故障应用系统的自动定位;三是无法将操作系统、中间件、数据库、存储、网络、环境动力等IT基础设施专业事件与各应用系统的业务交易或系统交易事件关联起来进行自动故障树分析。这导致IT运维中出现:专业事件处理量大、业务影响分析困难、故障根源定位慢、故障节点难以自动隔离恢复等问题。为此,企业需要以业务应用交易监控为中心,升级整合传统的IT运维监控系统。


一、建设目标

        面向业务应用交易的运维监控系统建设目标主要包括:①实时、准确掌握企业各业务应用系统的运行状态和故障业务影响度,提升业务系统可用性、容量、性能等SLA服务级别管理水平。②自动发现业务应用系统拓扑关系和交易访问路径,进行故障应用系统或故障应用节点的自动定位处理。③自动关联专业事件与交易事件,进行交易、故障树生成和业务影响度分析。降低IT基础设施专业OLA运行级别管理水平。④全面采集中间件、数据库、程序代码等运行日志信息,深度分析处理各种难以进行实时指标监控的故障问题。⑤自动发现和优化治理各种IT组件的属性、访问关系等配置数据,支持各种专业和交易指标的智能处理和可视化展现。⑥跨领域整合主机、平台、网络、环境动力、应用软件等专业监控系统,建立统一的门户视图、可用性、容量性能、事件等模块。

二、建设思路

        参照Gartner APM应用性能监控的有关模型方法,面向业务应用交易的IT运维监控系统规划设计可以分为5个维度(如图1所示)。 

image.png

  1.业务功能和交易访问用户体验监控

        将整个IT系统作为提供IT服务的“黑盒”,从用户终端、网络接入端、渠道类(用户接入)应用端实时获取各个业务交易代码、业务功能、服务渠道、对端客户机构等多维度的交易量、成功率、响应时间等交易指标,并建立每个指标每分钟时点的采样值组成的动态基线,全面准确反映业务应用系统的运行情况。交易指标的获取方式主要有两种:一种是通过TAP SWITCH镜像每个应用系统的APP节点的网络流量,实时解析还原网络流量中的交易报文获得;另一种是由应用系统实时输出交易日志,再对这些日志进行实时指标加工处理。前者需要采购投入专业的网络流量采集设备和流量解析加工处理系统,但对应用系统改动较少,只需规范应用系统报文格式,在报文中增加UUID全局事件跟踪号、交易代码等信息。后者需要对应用系统做较大改造,并建立统一的日志分析处理平台。该方案对应用服务器的性能开销有一定的影响,但可以根据需要灵活方便地统计分析各种业务应用交易情况。

        2.应用系统拓扑关系和交易访问路径自动发现

        将IT系统“黑盒”打开,全面采集各个非渠道类的业务应用系统交易数据,再基于手工或自动发现的业务依赖模型,可视化地展示某个交易代码、业务功能模块或业务系统需要经过的应用系统拓扑关系和交易路径(含应用逻辑节点的访问顺序关系)。通过对比交易路径或应用拓扑图上不同应用系统的总量/分量交易指标的变化情况,可以将故障自动定位到某个应用系统,甚至该应用系统的某个APP服务器节点。应用系统之间的访问拓扑关系,可以根据手工录入到CMDB配置管理系统中的数据自动生成,也可以基于不同应用系统输出的交易日志中的一些上下游关键字段信息自动生成,并自动更新CMDB中的数据项信息。在此过程中,通过手工录入的方式对每个交易代码的交易路径进行维护的工作量大且难以保持一致性,必须通过实时、详细、全面的输出和关联交易日志才能实现。

        3.专业事件与交易事件的关联和业务影响分析

        前两个维度的交易指标监控,可以将大多数故障定位到某个应用系统的APP服务器节点。但究竟是该APP服务器节点自身软硬件有问题,还是其上下游的Web和数据库服务器的软硬件有问题,或者是相关网络和SAN存储连接有问题?就需要根据监控对象依赖模型(配置项间的影响和依赖关系)、监控指标依赖模型,自动关联IT组件的专业事件与业务应用的交易事件,并自动生成以根源交易事件为根的故障分析树。这既可大幅减少事件处理的工作量,也可自动发现一组事件根源问题,自动或半自动地隔离故障节点,快速恢复业务。

        4.IT组件深度监测分析诊断

        上述三个维度的工作,可以自动关联定位大量事件的根源故障节点,以进行自动或半自动的隔离恢复处理。但对于不能自动生成故障树的情况,还需要通过提供相关的对象和指标的可视化展现功能,以及手工启动各种自动化分析诊断脚本的功能,逐层钻取检查各个相关的IT组件,以便快速确定故障根源。如:当发现2个应用节点之间的网络连接中断后,可以调用相关检查脚本TRACE网络连通情况,调出2个应用节点IP地址间经过的网络设备的运行状态和网络连接状态,以便手工检查定位故障设备。再如:对于中间件、数据库、应用程序深层次的Bug问题,不适宜通过穷举建立各种实时监控指标,而适宜在应用节点上部署一些专业化的故障诊断工具,或者在开发阶段提高应用系统程序的可诊断性,内嵌各种故障检测排查代码,根据需要全面采集相关数据,进行深度分析诊断。

        5.运维数据处理和报告展示

        通过上述4个维度的操作,产生了各种业务系统交易日志、事件性能数据、分析诊断信息、配置资产信息、人员机构信息等数据。建设IT运维数据处理平台可实现对这些数据的实时、批量统计分析,为集中监控和运维统计分析处理、信息安全和科技风险管理、内外部审计检查等提供支持。如:利用大数据、流式数据处理等数据加工方法,进行各种维度和粒度的交易量、成功率、响应时间等指标分析,以及对这些指标的基线和上下限阈值的数据处理。此外,IT运维数据处理平台还应具有自动可视化展现各种监控对象、指标、业务与应用的关联和访问关系的功能。

三、关键难点

        建设面向业务应用交易的运维监控系统的关键难点,主要包括最上层的业务应用交易日志的获取;中间层的专业和交易事件的自动关联处理;最下层的配置数据的自动发现治理和可视化展现,以及跨各层的运维管理流程优化。

       1.业务应用交易日志获取

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

        2.专业事件和交易事件自动关联

        IT软硬件系统在运行过程中,会随着自身可靠性和负载大小的变化产生大量的专业事件。这些事件中有些只是有关当前运行状态的提示信息。传统运维监控系统围绕专业指标进行管理,各种IT组件产生专业事件后,很难通过事件以及产生事件的软硬件本身了解其对业务产生了多大影响,更无法知道同一时段内产生的各种专业事件相互之间的关系。为此,很多企业尝试对各种专业事件进行大数据分析,以期找到其中的一些相关性;或尝试基于软硬件的重要性和运维关系规则对事件进行关联。但还存在规则方法不统一,难以确认事件业务影响度的问题。解决的方法是,基于业务和交易与应用系统的依赖关系(通过交易日志自动发现或部分手工录入),建立各种IT组件(配置项或监控对象)依赖关系的对象模型,将Web、APP、DB服务器的专业事件,以及应用软件的专业事件,与APP服务器或应用系统的交易事件进行关联。关联过程中,根据各种监控指标之间的依赖关系(如存储的可用性、容量和性能指标与上层数据库的可用性和性能指标的关系),自动建立一棵专业事件与交易事件关联的故障树,实现高效分析处理一组事件。此种方法甚至可以做到自动隔离有冗余备份的故障应用节点,避免了此类故障可能对业务造成的长时间影响。

        3.配置数据自动发现、治理和可视化

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

        4.运维流程优化

        企业原有各专业监控系统围绕交易监控关联整合后,有关可用性、容量、事件、问题、配置等管理流程也需要相应地进行优化,以适应新系统的运行。如:各种专业事件不再需要直接按业务影响程度定义业务级别,而是回归到对软硬件系统自身可能的影响自行定义专业级别。同时,对于那些没有产生影响业务的交易事件的各个专业事件,不再需要人工逐个确认跟踪处理。

  通过建立完善的交易指标监控体系,可以统一IT部门与业务部门间的沟通语言和服务评价标准,提升双方的SLA服务级别管理水平。通过建立各种专业事件与交易事件的关联并自动生成故障树,可以整合原有分散建设的各专业监控系统,从而大幅提升IT故障的处理效率和质量。因此,建设面向业务应用交易的运维监控系统,是企业IT运维部门从IT专业运营向业务服务运营转型的必由之路,也是以可用性管理为主的传统数据中心向以资源和服务管理为主的云化数据中心发展过程中的一项基础性工作,需要提前做好规划设计。


CIO之家 www.ciozj.com 公众号:imciow
关联的文档
也许您喜欢