CN110784374A - 业务系统运行状态的监控方法、装置、设备和系统 - Google Patents

Abstract

本申请涉及一种业务系统运行状态的监控方法、装置、设备和系统。所述方法包括：基于预先配置的接口测试脚本，向业务系统发送接口请求；获取业务系统对接口请求的处理结果；判断处理结果与预设的期望结果是否一致；若处理结果与期望结果不一致，确定业务系统运行出错，收集业务系统出错时的明细信息，以及触发预先配置的告警脚本。如此设置，通过将接口测试发散至实时模拟用户调用接口，将所有数据的交换作为检查点，从而能够对业务系统出现异常或与期望结果不符等情况进行监控，即实现用户到业务系统的可用性监控，进一步的，通过持续运行接口测试脚本来模拟用户操作，能够全天24小时对业务系统进行监控。

Description

业务系统运行状态的监控方法、装置、设备和系统

技术领域

本申请涉及互联网技术领域，尤其涉及一种业务系统运行状态的监控方法、装置、设备和系统。

背景技术

随着互联网技术的发展，目前企业通常会通过业务系统进行流程管理和业务处理等工作，在此基础上，为了维持业务系统的正常运行，需要对其运行状态进行实时监控。

相关技术中，通常通过将监控工具(例如听云、CAT等)接入业务系统从而对业务系统进行监控，不过传统的监控工具主要应用于业务系统的资源层面和应用服务器报错的监控，主要是关注各种服务器资源的运行状况，不能全局反映出业务系统的运行状况，存在一定的局限性。

发明内容

本申请提供一种业务系统运行状态的监控方法、装置、设备和系统，以实施用户到业务系统的(即从用户实际使用角度的)可用性监控，从而至少在一定程度上减弱传统的监控方法存在的局限性。

本申请的上述目的是通过以下技术方案来实现的：

第一方面，本申请实施例提供一种业务系统运行状态的监控方法，所述方法包括：

基于预先配置的接口测试脚本，向业务系统发送接口请求；

获取业务系统对所述接口请求的处理结果；

判断所述处理结果与预设的期望结果是否一致；

若所述处理结果与所述期望结果不一致，确定业务系统运行出错，收集业务系统出错时的明细信息，以及触发预先配置的告警脚本。

可选的，所述基于预先配置的接口测试脚本，向业务系统发送接口请求之前，还包括：

获取主服务器发送的预先配置的接口测试脚本。

可选的，所述接口测试脚本的生成过程包括：

获取入参，获取用户添加的期望结果断言以判断返回的处理结果是否准确，以及获取用户添加的请求返回超时时间以判断业务系统是否发生卡顿。

可选的，所述收集业务系统出错时的明细信息包括：

通过正则表达式收集业务系统出错时的接口URL、入参和返回的处理结果。

可选的，所述触发预先配置的告警脚本包括：

触发预先配置的第一告警脚本，以通过即时通讯软件发送告警消息至监控人员；和/或，触发预先配置的第二告警脚本，以通过手机短信发送告警消息至监控人员。

可选的，所述方法还包括：

将监控过程中的所有监控信息发送至主服务器。

第二方面，本申请实施例还提供一种业务系统运行状态的监控装置，所述装置包括：

发送模块，用于基于预先配置的接口测试脚本，向业务系统发送接口请求；

获取模块，用于获取业务系统对所述接口请求的处理结果；

判断模块，用于判断所述处理结果与预设的期望结果是否一致；

处理模块，用于若所述处理结果与所述期望结果不一致，确定业务系统运行出错，收集业务系统出错时的明细信息，以及触发预先配置的告警脚本。

可选的，所述装置还包括：

脚本获取模块，用于获取主服务器发送的预先配置的接口测试脚本。

可选的，所述处理模块包括：

收集单元，用于通过正则表达式收集业务系统出错时的接口URL、入参和返回的处理结果。

可选的，所述处理模块包括：

第一告警单元，用于触发预先配置的第一告警脚本，以通过即时通讯软件，例如微信、钉钉等，发送告警消息至监控人员；

第二告警单元，用于触发预先配置的第二告警脚本，以通过手机短信发送告警消息至监控人员。

可选的，所述装置还包括：

监控信息发送模块，用于将监控过程中的所有监控信息发送至主服务器。

第三方面，本申请实施例还提供一种业务系统运行状态的监控设备，所述设备包括：

存储器和与所述存储器相连接的处理器；

所述存储器，用于存储程序，所述程序至少用于执行上述任一种业务系统运行状态的监控方法；

所述处理器，用于调用并执行所述存储器存储的所述程序。

第四方面，本申请实施例还提供一种业务系统运行状态的监控系统，所述系统包括：主服务器和上述的监控设备；

所述主服务器用于获取监控人员编写的接口测试脚本，以及将所述接口测试脚本发送至所述监控设备；所述主服务器还用于获取所述监控设备在监控过程中的所有监控信息。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请的实施例提供的技术方案中，通过接口测试脚本模拟用户操作，实时向业务系统发送接口请求，在获取业务系统对接口请求的处理结果之后，再通过判断处理结果与期望结果是否一致，来判断业务系统是否正常运行，且在业务系统运行出错后自动收集出错时的明细信息以及向监控人员告警。如此设置，通过将接口测试发散至实时模拟用户调用接口，将所有数据的交换作为检查点，从而能够对业务系统出现异常或与期望结果不符等情况进行监控，即实现用户到业务系统的可用性监控，进一步的，通过持续运行接口测试脚本来模拟用户操作，能够全天24小时对业务系统进行监控。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例一提供的一种业务系统运行状态的监控方法的流程示意图；

图2为本申请实施例二提供的一种业务系统运行状态的监控方法的流程示意图；

图3为本申请实施例三提供的一种业务系统运行状态的监控装置的结构示意图；

图4为本申请实施例四提供的一种业务系统运行状态的监控设备的结构示意图；

图5为本申请实施例五提供的一种业务系统运行状态的监控系统的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在对本申请的技术方案进行详细说明之前，首先对相关技术中的系统监控方法、监控工具以及其存在的问题等内容进行说明。

目前，常用的系统监控工具例如听云(北京基调网络股份有限公司旗下的应用性能监测软件品牌)和CAT(Central Application Tracking，大众点评网的实时应用监控平台)等，可以提供对业务系统的性能指标、健康状况、基础告警等监控功能，不过上述的传统监控工具主要应用于业务系统的资源层面和应用服务器报错的监控，主要是关注各种服务器资源的运行状况，没有实施用户到业务系统的(即从用户实际使用角度的)可用性监控，从而不能全局反映出业务系统的运行状况，例如，不能解决业务系统返回的数据与期望不服的场景(比如期望返回结果按从大到小排序，业务系统误被改成从小到大排序或未排序，则现有技术无法监测)，也不能发现用户实际使用中遇到的逻辑异常，即只能监控业务系统抛出异常(抛出异常，即程序不捕获的异常)，无法监控被程序捕获的异常。此外，部分监控工具在系统卡顿时无法准确判断卡顿对用户的影响，无法判断是否需要告警，并且，一些监控工具在业务系统发生宕机后无法运行。

针对上述问题，本申请实施例首先提供一种业务系统运行状态的监控方法。

实施例一

请参阅图1，图1为本申请实施例一提供的一种业务系统运行状态的监控方法的流程示意图。如图1所示，该方法包括以下步骤：

S101：基于预先配置的接口测试脚本，向业务系统发送接口请求；

具体的，接口请求，即用户访问业务系统时通过客户端等途径发送的调用接口的请求。目前，接口的请求类型包括get、post、put、delete、head、options、trace和connect，其中，前4种为常用的请求类型，其功能分别为：get：向特定的资源发出请求，并返回实体主题；post：向指定资源提交数据进行处理请求(例如提交表单或者上传文件)，数据被包含在请求体中，该请求可能会导致新的资源的创建和/或已有资源的修改；put：向指定资源位置上传其最新内容，从客户端向服务器传送的数据取代指定的文档的内容；delete：请求服务器删除Request-URL所标识的资源，也就是删除所指定的页面。

接口测试是测试系统组件间接口的一种测试。其主要用于检测外部系统(例如用户客户端)与系统(例如业务系统)之间以及(业务系统)内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

而脚本(Script)，简单地说就是一条条的文字命令，这些文字命令是可以看到的(如可以用记事本打开查看、编辑)，脚本程序在执行时，是由系统的一个解释器，将其一条条的翻译成机器可识别的指令，并按程序顺序执行。通过运行脚本，可以控制计算机进行一系列运算操作动作。

本步骤即通过运行预先编写的接口测试脚本，使监控设备自动向业务系统发送接口请求，从而模拟用户通过客户端访问业务系统的操作。

一些实施例中，该步骤S101之前还可以包括：获取主服务器发送的预先配置的接口测试脚本。

也就是说，接口测试脚本可以不是在运行其的监控设备上编写，而是由主服务器发送而来。即，可以将发送接口测试脚本的主服务器看作主监控设备，而运行接口测试脚本的监控设备作为从监控设备。如此设置的优点在于，在实际应用时，用户可能在不同地域、通过不同电信网络访问业务系统，为了对所有的用户访问(即接口请求)进行监控，因此，需要设置多台监控设备，如果对于每台监控设备都分别编写接口测试脚本，那么会需要较多时间成本，且当需要增加监控的区域时，则需要对新增的监控设备进行脚本配置。而通过主从机制，所有的脚本编写过程都在主服务器(即主监控设备)完成，增加从监控设备时，只需将编写好的脚本发送至从监控设备即可，从而可以支持无限扩展监控设备来监控不同地域和不同电信网络中的业务系统的运行状态。此外，基于主从机制，可以通过主监控设备快速控制每台从监控设备的运行和停止，便于企业的统一管理。

一些实施例中，可以通过JMeter工具或其他类似的接口测试工具编写接口测试脚本，只要该工具允许使用正则表达式或类似的方式创建断言即可。

进一步的，接口测试脚本的生成过程包括：

获取入参，获取用户添加的期望结果断言以判断返回的处理结果是否准确，以及获取用户添加的请求返回超时时间以判断业务系统是否发生卡顿。

以上过程是针对接口测试工具所描述的，如果从用户一方描述，即输入入参，添加期望结果断言以判断返回的处理结果是否准确，以及添加请求返回超时时间以判断系统是否发生卡顿。

其中，入参，即传入参数，也就是将数据传给函数使用，基于此可以得到函数的返回值传出参数(出参)。

关于断言，在编写代码时，编写者会做出一些假设，假设某个特定点该表达式值为真。断言即用于在代码中捕捉这些假设，其表示为一些布尔表达式。编程人员可以在任何时候启用或禁用断言验证。

上述实施例中，编写脚本测试工具的过程，即用户通过输入所需的入参来编写程序(即所需的脚本)，使程序能够向业务系统发送接口请求，然后添加断言判断业务系统返回的处理结果是否符合期望，例如排序是否正确、是否发生宕机等，另外，添加请求返回超时时间来判断业务系统是否发生卡顿。其中，返回超时时间可以根据不同的用户能接受的不同响应时间来设置，例如设置为2秒、5秒、8秒或其他值。

S102：获取业务系统对所述接口请求的处理结果；

具体的，本实施例是模拟的用户通过客户端等途径正常访问业务系统的过程，因此业务系统的处理过程与正常情况下相同，对此不再详述。

此外需要注意的是，在实际应用时，步骤S101与本步骤S102中，监控设备向业务系统发送接口请求，以及业务系统返回处理结果，都是通过电信网络运营商(例如中国移动、中国联通等)转发实现的。即监控设备先发送接口请求至电信网络运营商，再由电信网络运营商转发至业务系统，同理，业务系统先返回处理结果至电信网络运营商，再由电信网络运营商转发至对应的监控设备。

S103：判断所述处理结果与预设的期望结果是否一致；

具体的，根据步骤S101的描述，处理结果至少包括业务系统对所述接口请求进行处理后的数据以及返回处理结果所耗费的时间。需要注意的是，对于业务系统发生宕机的情况，可以通过上述步骤S101所述的添加断言的方式进行判断，也可以根据超时仍未返回处理结果的方式进行判断。同时，由于上述监控方法由各监控设备独立运行，因此不会受业务系统宕机的影响。

此外，通过断言比对处理结果与期望结果，可以发现返回的处理结果正常但不符合期望的情况，以及发现已经被程序捕获的异常，便于相关人员分析后进行改进以提升用户体验。

S104：若所述处理结果与所述期望结果不一致，确定业务系统运行出错，收集业务系统出错时的明细信息，以及触发预先配置的告警脚本。

具体的，所述收集业务系统出错时的明细信息，可以包括：

通过正则表达式收集业务系统出错时的接口URL(Uniform Resource Locator；统一资源定位系统)、入参和返回的处理结果等，便于监控人员快速定位问题。正则表达式，又称规则表达式，通常被用来检索、替换那些符合某个模式(规则)的文本。当然，除了正则表达式，也可以通过其他方式收集所需的信息，对此不作限制。

此外，所述触发预先配置的告警脚本，可以包括：

触发预先配置的第一告警脚本，以通过即时通讯软件，例如微信、钉钉等，发送告警消息至监控人员；和/或，触发预先配置的第二告警脚本，以通过手机短信发送告警消息至监控人员。

此外，一些实施例中，如果按照主从机制进行设置，上述方法还可以包括：将监控过程中的所有监控信息发送至主服务器，以便监控人员随时统一查看。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请的实施例提供的技术方案中，通过接口测试脚本模拟用户操作，实时向业务系统发送接口请求，在获取业务系统对接口请求的处理结果之后，再通过判断处理结果与期望结果是否一致，来判断业务系统是否正常运行，且在业务系统运行出错后自动收集出错时的明细信息以及向监控人员告警。如此设置，通过将接口测试发散至实时模拟用户调用接口，将所有数据的交换作为检查点，从而能够对业务系统出现异常或与期望结果不符等情况进行监控，即实现用户到业务系统的可用性监控，进一步的，通过持续运行接口测试脚本来模拟用户操作，能够全天24小时对业务系统进行监控。

为了对本申请的技术方案进行更好的说明，以下将通过具体示例对上述实施例一中的业务系统运行状态的监控方法的整体流程进行说明。

请参阅图2，图2为本申请实施例二提供的一种业务系统运行状态的监控方法的流程示意图。如图2所示，该方法包括以下步骤：

S201：生成接口测试脚本；

S202：主服务器发送接口测试脚本；

S203：监控设备接收并运行接口测试脚本；

S204：监控设备发送接口请求；

S205：电信运营商接收监控设备发送的接口请求；

S206：电信运营商转发监控设备发送接口请求；

S207：业务系统接收并处理监控设备发送的接口请求；

S208：业务系统返回对监控设备发送的接口请求的处理结果；

S209：电信运营商接收业务系统返回的对监控设备发送的接口请求的处理结果；

S210：电信运营商转发业务系统返回的对监控设备发送的接口请求的处理结果；

S211：监控设备接收并判断处理结果与预设的期望结果是否一致，；

S212：处理结果与期望结果不一致时，确定业务系统运行出错，收集业务系统出错时的明细信息，以及触发预先配置的告警脚本；

S213：监控设备发送监控汇总结果。

其中，主服务器将接口测试脚本发送至所有监控设备，各监控设备互相独立运行，分别基于接口测试脚本向业务系统发送接口请求，接口请求由监控设备所接入的电信网络运营商转发至业务系统，业务系统对各监控设备发送的接口请求分别进行处理，得出的处理结果再经由同一电信网络运营商返回至对应的监控设备，监控设备根据处理结果和预设的期望结果判断业务系统是否正常运行，若业务系统运行出错，则自动收集出错时的明细信息以及触发告警脚本向监控人员告警。此外，各监控设备还将自身的所有监控结果汇总后发送至主服务器，供监控人员统一查看和管理。

需要注意的是，实施例二中每个步骤的具体实现方式，可以参照实施例一中的相同或相似内容来实现，在此不再详述。

本申请的实施例提供的技术方案可以包括以下有益效果：

通过主从机制可无限扩展监控设备，不受地域、电信网络等的限制；通过接口测试脚本将接口测试发散至实时模拟用户调用接口，将所有数据的交换作为检查点，从而能够对业务系统出现异常或与期望结果不符等情况进行监控，即实现用户到业务系统的可用性监控；进一步的，通过持续运行接口测试脚本来模拟用户操作，能够全天24小时对业务系统进行监控；在监控到业务系统运行出错时，自动收集出错时的明细信息，便于监控人员及时查看和快速定位问题。

为了对本申请的技术方案进行更全面的说明，对应于本申请上述实施例提供的业务系统运行状态的监控方法，本申请实施例还提供一种业务系统运行状态的监控装置。

实施例三

请参阅图3，图3为本申请实施例三提供的一种业务系统运行状态的监控装置的结构示意图。如图3所示，该装置包括：

发送模块31，用于基于预先配置的接口测试脚本，向业务系统发送接口请求；

获取模块32，用于获取业务系统对所述接口请求的处理结果；

判断模块33，用于判断所述处理结果与预设的期望结果是否一致；

处理模块34，用于若所述处理结果与所述期望结果不一致，确定业务系统运行出错，收集业务系统出错时的明细信息，以及触发预先配置的告警脚本。

可选的，所述装置还包括：

脚本获取模块，用于获取主服务器发送的预先配置的接口测试脚本。

可选的，所述处理模块34包括：

收集单元，用于通过正则表达式收集业务系统出错时的接口URL、入参和返回的处理结果。

可选的，所述处理模块34包括：

第一告警单元，用于触发预先配置的第一告警脚本，以通过即时通讯软件，例如微信、钉钉等，发送告警消息至监控人员；

第二告警单元，用于触发预先配置的第二告警脚本，以通过手机短信发送告警消息至监控人员。

可选的，所述装置还包括：

监控信息发送模块，用于将监控过程中的所有监控信息发送至主服务器。

具体的，上述每个功能模块的功能的具体实现方式可以参照上述业务系统运行状态的监控方法中的内容来实现，对此不再详述。

为了对本申请的技术方案进行更全面的说明，对应于本申请上述实施例提供的业务系统运行状态的监控方法，本申请实施例还提供一种业务系统运行状态的监控设备。

实施例四

请参阅图4，图4为本申请实施例四提供的一种业务系统运行状态的监控设备的结构示意图。如图4所示，该设备包括：

存储器41和与存储器41相连接的处理器42；

存储器41用于存储程序，所述程序至少用于执行上述任一种业务系统运行状态的监控方法；

处理器42用于调用并执行存储器41存储的所述程序。

具体的，该监控设备可以是计算机或类似的设备，其中程序的功能的具体实现方式可以参照上述业务系统运行状态的监控方法中的内容来实现，对此不再详述。

为了对本申请的技术方案进行更全面的说明，对应于本申请上述实施例提供的业务系统运行状态的监控方法，本申请实施例还提供一种业务系统运行状态的监控系统。

实施例五

请参阅图5，图5为本申请实施例五提供的一种业务系统运行状态的监控系统的结构示意图。如图5所示，该系统包括：

主服务器5和上述的监控设备4；

主服务器5用于获取监控人员编写的接口测试脚本，以及将所述接口测试脚本发送至监控设备4；主服务器5还用于获取监控设备4在监控过程中的所有监控信息。

具体的，主服务器5可以通过电信网络运营商连接多台监控设备4，各监控设备4基于接口测试脚本对业务系统进行监控，并将监控信息发送至主服务器5。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种业务系统运行状态的监控方法，其特征在于，包括：

基于预先配置的接口测试脚本，向业务系统发送接口请求；

获取业务系统对所述接口请求的处理结果；

判断所述处理结果与预设的期望结果是否一致；

若所述处理结果与所述期望结果不一致，确定业务系统运行出错，收集业务系统出错时的明细信息，以及触发预先配置的告警脚本。

2.根据权利要求1所述的方法，其特征在于，所述基于预先配置的接口测试脚本，向业务系统发送接口请求之前，还包括：

获取主服务器发送的预先配置的接口测试脚本。

3.根据权利要求2所述的方法，其特征在于，所述接口测试脚本的生成过程包括：

获取入参，获取用户添加的期望结果断言以判断返回的处理结果是否准确，以及获取用户添加的请求返回超时时间以判断业务系统是否发生卡顿。

4.根据权利要求1所述的方法，其特征在于，所述收集业务系统出错时的明细信息包括：

通过正则表达式收集业务系统出错时的接口URL、入参和返回的处理结果。

5.根据权利要求1所述的方法，其特征在于，所述触发预先配置的告警脚本包括：

触发预先配置的第一告警脚本，以通过即时通讯软件发送告警消息至监控人员；和/或，触发预先配置的第二告警脚本，以通过手机短信发送告警消息至监控人员。

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

将监控过程中的所有监控信息发送至主服务器。

7.一种业务系统运行状态的监控装置，其特征在于，包括：

发送模块，用于基于预先配置的接口测试脚本，向业务系统发送接口请求；

获取模块，用于获取业务系统对所述接口请求的处理结果；

判断模块，用于判断所述处理结果与预设的期望结果是否一致；

处理模块，用于若所述处理结果与所述期望结果不一致，确定业务系统运行出错，收集业务系统出错时的明细信息，以及触发预先配置的告警脚本。

8.根据权利要求7所述的装置，其特征在于，所述处理模块包括：

收集单元，用于通过正则表达式收集业务系统出错时的接口URL、入参和返回的处理结果。

9.一种业务系统运行状态的监控设备，其特征在于，包括：

存储器和与所述存储器相连接的处理器；

所述存储器，用于存储程序，所述程序至少用于执行如权利要求1-6任一项所述的业务系统运行状态的监控方法；

所述处理器，用于调用并执行所述存储器存储的所述程序。

10.一种业务系统运行状态的监控系统，其特征在于，包括：主服务器和如权利要求9所述的监控设备；

所述主服务器用于获取监控人员编写的接口测试脚本，以及将所述接口测试脚本发送至所述监控设备；所述主服务器还用于获取所述监控设备在监控过程中的所有监控信息。

Images