银行业务交易应用系统常用监控技术浅析

概述

随着现代信息系统越来越庞大，机器数量呈现指数级增长，信息系统运维对平台化服务能力要求越来越高，建立有效的监控体系准确及时发现系统运行中出现的问题，对于保障应用系统稳定运行具有重要意义。

为提升生产问题感知及响应能力，通常会配置各种类型的监控，本文从单类型监控、业务交易之间聚合监控、业务交易与基础资源聚合监控等方面介绍监控常用技术方法，供读者进行参考学习。

单类型监控

单类型监控是指使用单一类型技术进行应用系统监控，常用的监控方法包括Ajax请求报文响应报文监控、业务日志监控、页面内容监控、业务数据监控、基础资源监控。

方面对几种监控类型详细介绍：

1、Ajax监控

通过第三方监控平台定时发送业务交易请求，并对响应报文进行断言的方法验证交易的正确性。

• 方法1

http 状态码监控。对http请求的状态码进行判断，是否符合预期结果，各类http状态码含义如下，我们仅需要配置状态码断言即可判断交易是否正常。

示例：

Request URL: https://msg.csdn.net/v1/web/message/view/unread

Request Method: POST

Status Code: 200

• 方法2

http响应报文监控，http状态码监控可以监控交易报文是否正常响应，但是无法判断交易逻辑是否正常，对http报文响应报文具体内容进行监控，可以弥补该问题。通过判断http响应报文中具体字段的值对交易进行监控。

示例：ajax响应报文中包含如下信息，则可以对message字段的值进行监控。

{message: "success"status: true}

适用场景：适用于对http协议响应报文、响应码进行监控。

2、日志监控

日志监控是对应用系统运行过程中产生的日志进行监控。以log4j为例，日志级别包括ALL、TRACE、DEBUG、INFO、WARN、ERROR、FATAL、OFF，其中ALL 是打印所有日志，OFF是所有日志都不打印，为了排查系统运行问题，通常开发人员根据需要会打点一定的日志，但是如果loglevel 配置的太低，则会打印过多的日志信息，从而影响系统性能。

日志监控通常可以基于ERROR、FATAL 类日志打印进行监控。开发人员在业务逻辑中进行相应的判断，并打印错误日志，例如：Log.error(“123456”);  监控平台可以抓取系统中打印的错误日志，并基于正则表达式判断是否符合异常告警条件。符合告警规则，则进行邮件、短信等告警。

日志告警可以精准获取异常告警的代码位置，从而便于进行问题分析。

适用场景：适用于系统开发人员在代码的关键逻辑中打点了日志信息时使用。

3、网页监控

对于DOC类型的请求，可以通过发送请求报文，对响应页面html内容设置监控，判断响应页面内容是否包含指定的内容，网页内容监控是指监控网页标题、网页关键词、网页描述、出站链接等内容信息进行监控。

使用方式：通过提取网页内容作为监控的对象，对比与上一次监测记录的变化情况，例如：<meta name ="keywords" content="网页关键词（被监控对象）" />。

页面监控配置流程：

适用场景：具有前端页面的系统可以采用该方法进行页面内容监控。

4、数据监控

通过定时执行数据库sql脚本或者数据分析，验证具有关联性的表是否出现不受控制的异常数据记录，数据内容监控可以发现业务逻辑异常造成的数据问题，并及时提供给运营人员进行后续处理，以应对数据不一致对用户产生的影响。

数据监控分类如下：

数据监控配置流程：

适用场景：对于熟悉数据表逻辑关系及不同表中字段之间逻辑关系时可以使用该方法。

5、资源监控

对于CPU、内存、硬盘等基础资源的监控，并设置阈值，对于分机房类应用系统，可以按照机房分别配置资源监控，可以及时发现底层资源故障，提示系统运维人员及时进行资源扩容或者问题排查，具体重要的意义。

通常当CPU、内存利用率超过80%时，系统性能将逐步出现瓶颈，从而会严重影响用户使用体现，因此可以设置CPU、内存等使用率超过80%时进行告警；对于数据库服务，可以对数据库的连接数、表空间、系统日志等信息进行监控；对于磁盘、网络设置可以监控IO速率的参数以发现相关问题。

但基础资源监控无法具体判断具体是哪些业务造成的资源问题，以及对哪些业务造成的影响比较大，结合其他监控方法可以达到更好的效果。

几种监控方法对比：

适用场景：对于依赖的底层资源的服务可以采用这种监控方法。

聚合类型监控

1、交易调用链路聚合监控

对于系统之间调用较为复杂的业务场景，仅仅通过单系统的监控难以具体定位到故障节点。交易接口之间聚合监控是指对已经建立的具有调用关系的接口监控项建立绑定关系，从而根据调用链路上各个节点的执行结果判断业务系统群的可用性情况及故障节点。

如下图所示，A系统的一个业务交易trans1, 调用B系统的交易和C系统的交易，B系统又会调用D系统交易。在这种场景下，仅仅对A系统业务交易进行监控，发生告警后，无法准备判断A、B、C、D 4个系统中哪个系统发生了故障，造成业务交易无法执行成功，需要开发人员根据交易链条逐个判断分析，大大增加了系统问题分析的难度。

使用交易调用链路聚合监控方法，拿A系统trans1交易这个场景来说，对A、B、C、D 4个系统分别配置监控案例mA、mB、mC、mD，并建立链路绑定关系（mA->mB、mB->mD、mB->mC）。这样在系统发生告警后，可以根据A、B、C、D 4个系统监控交易执行情况，迅速找到故障节点。

A系统Trans1交易监控案例绑定关系：

• 优势

能够快速找到故障节点，降低故障分析复杂程度。因为交易监控之间建立了绑定关系:mA->mB->mD、mB->mC，当mA、mB、mC、mD4个监控项按照一定频率执行时并获取到对应的执行结果后，可以根据根据交易之间的绑定关系判断故障节点。

例如：某时间节点：mD执行成功，mB执行失败，mA执行失败，可以判断是由于mB交易执行失败造成mA执行失败，从而提升问题处置效率。

• 缺点

配置复杂程度高，需要清楚交易调用链路，并分别配置监控案例，并建立绑定关系。

适用场景：对于交易链路比较复杂，难以判断问题故障具体出在什么位置的情况下建议增加使用该方法监控。

2、业务监控与资源监控聚合

随着信息系统复杂程度和可靠性要求的不断提高，信息系统的部署架构也越来越复杂。信息系统的部署会采用多地区多机房的部署方式，从而根据用户所在区域访问不同的后台服务，以提升系统响应能力。

业务监控与资源监控聚合是指将业务交易监控与资源级监控建立绑定关系，并根据各个监控项的执行结果进行聚合分析，从而判断系统故障节点的监控方法。

业务交易的可用性与基础资源是紧耦合的关系，基础资源的故障或性能瓶颈会严重影响业务交易的运行。通过业务交易监控无法准备定位到具体哪些基础资源故障引起。例如业务交易访问失败，可能是因为服务器停机、机器无法正常响应请求等问题造成。具体哪个资源故障造成业务交易无法正常执行却无法判断。

通过将业务交易监控和基础资源监控进行绑定聚合可以有效解决该问题。例如我们的业务系统已经配置了业务监控m1、 tomcat 服务器监控m2、数据库服务器监控m3 三个监控配置，通过建立监控项m1、m2、m3的绑定关系（如下图所示），当发生基础资源造成的业务交易报错后，可以迅速找到问题原因以进行问题响应。

适用场景：对于业务交易依赖底层资源，底层资源故障会造成部分业务交易报错的情况下可以使用该种监控方法。

总结

本文首先介绍了几种单应用系统环境监控方法及主要技术，包括ajax请求响应报文监控，日志监控、基础资源监控、业务数据监控、页面内容监控、高级脚本监控，并分析了这几种技术的主要使用场景，之后对业务交易聚合监控、业务交易与基础资源监控方法进行了介绍，希望给测试人员、应用环境运维人员、监控平台建设者提供一定的参考，提升信息系统运维服务能力。

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】

 这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！