2、日志监控：日志监控是对应用系统运行过程中形成的日志进行监控。以log4j为例，日志级别包括ALL、TRACE、DEBUG、INFO、WARN、ERROR、FATAL、OFF，其中ALL是复印所有日志，OFF是所有日志都不复印，为了排查系统运行问题，通常开发人员按照须要会打点一定的日志，但是假如loglevel配置的太低，则会复印过多的日志信息，从而影响系统性能。
日志监控一般可以基于ERROR、FATAL类日志复印进行监控。开发人员在业务逻辑中进行相应的判定，并复印错误日志，例如：Log.error(“123456”);监控平台可以抓取系统中复印的错误日志，并基于正则表达式判定是否符合异常告警条件。符合告警规则，则进行短信、短信等告警。
日志告警可以精准获取异常告警的代码位置，从而易于进行问题剖析。
适用场景：适用于系统开发人员在代码的关键逻辑中打点了日志信息时使用。
3、网页监控：对于DOC类型的恳求，可以通过发送恳求报文，对响应页面html内容设置监控，判断响应页面内容是否包含指定的内容，网页内容监控是指监控网页标题、网页关键词、网页描述、出站链接等内容信息进行监控。
使用方法：通过提取网页内容做为监控的对象，对比与上一次检测记录的变化情况，例如：。
页面监控配置流程：
适用场景：具有后端页面的系统可以采用该方式进行页面内容监控。
4、数据监控：通过定时执行数据库sql脚本或则数据剖析，验证具有关联性的表是否出现不受控制的异常数据记录，数据内容监控可以发觉业务逻辑异常导致的数据问题，并及时提供给营运人员进行后续处理，以应对数据不一致对用户形成的影响。
数据监控分类如下：
数据监控配置流程：
适用场景：对于熟悉数据表逻辑关系及不同表中主键之间逻辑关系时可以使用该技巧。
5、资源监控：对于CPU、内存、硬盘等基础资源的监控，并设置阀值，对于分机房类应用系统，可以根据机房分别配置资源监控，可以及时发觉底层资源故障网络监控图像不定时几个卡的原因，提示系统运维人员及时进行资源扩容或则问题排查，具体重要的意义。
通常当CPU、内存利用率超过80%时，系统性能将逐渐出现困局，从而会严重影响用户使用彰显，因此可以设置CPU、内存等使用率超过80%时进行告警；对于数据库服务，可以对数据库的连接数、表空间、系统日志等信息进行监控；对于c盘、网络设置可以监控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恳求响应报文监控，日志监控、基础资源监控、业务数据监控、页面内容监控、高级脚本监控，并剖析了这几种技术的主要使用场景，之后对业务交易聚合监控、业务交易与基础资源监控方式进行了介绍，希望给测试人员、应用环境运维人员、监控平台建设者提供一定的参考，提升信息系统运维服务能力。
最后：
1）关注+私信回复：“测试”，可以免费发放一份10G软件测试工程师笔试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Mysql数据库、抓包工具、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试中级持续集成、测试构架开发测试框架、性能测试等。
2）关注+私信回复："入群" 就可以约请你步入软件测试群学习交流~~
