CN113760641A - 业务监控方法、装置、计算机系统和计算机可读存储介质 - Google Patents

Abstract

本公开提供了一种业务监控方法、业务监控装置、计算机系统、计算机可读存储介质和计算机程序产品。其中，业务监控方法包括：获取被监控业务中至少一个被监控接口的目标日志信息，其中，被监控业务被划分为多个业务节点，多个业务节点之间具有关联关系；获取被监控业务的配置信息，其中，配置信息包括每个业务节点与至少一个被监控接口之间的映射关系；根据配置信息确定与目标日志信息对应的目标业务节点；根据目标日志信息和目标业务节点生成业务节点事件信息；以及根据业务节点事件信息对被监控业务进行监控。

Description

业务监控方法、装置、计算机系统和计算机可读存储介质

技术领域

本公开涉及计算机技术领域，更具体地，涉及一种业务监控方法、业务监控装置、计算机系统、计算机可读存储介质和计算机程序产品。

背景技术

随着互联网的迅速发展，微服务化大行其道，业务复杂多样，如何快速检测和发现系统业务异常已变得至关重要。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题，现有业务监控实现方案不够通用，定制化严重，不利于复杂业务场景中的业务异常监控。

发明内容

有鉴于此，本公开提供了一种业务监控方法、业务监控装置、计算机系统、计算机可读存储介质和计算机程序产品。

本公开的一个方面提供了一种业务监控方法，包括：获取被监控业务中至少一个被监控接口的目标日志信息，其中，所述被监控业务被划分为多个业务节点，所述多个业务节点之间具有关联关系；获取所述被监控业务的配置信息，其中，所述配置信息包括每个所述业务节点与至少一个被监控接口之间的映射关系；根据所述配置信息确定与所述目标日志信息对应的目标业务节点；根据所述目标日志信息和所述目标业务节点生成业务节点事件信息；以及根据所述业务节点事件信息对所述被监控业务进行监控。

根据本公开的实施例，上述业务监控方法还包括：获取用于将不同系统的业务接入业务监控平台的接入操作；以及响应于所述接入操作，将所述不同系统的业务的应用实例信息输入所述业务监控平台，以便将所述不同系统的业务接入所述业务监控平台。

根据本公开的实施例，上述业务监控方法还包括：根据所述不同系统的业务场景，对所述不同系统的业务的业务流程进行业务节点划分及编排。

根据本公开的实施例，获取被监控业务中至少一个被监控接口的目标日志信息包括：根据用于采集所述被监控业务的日志信息的自定义日志组件采集日志信息；在所述日志信息属于预设日志级别的情况下，判断所述日志信息是否为所述被监控接口所对应的日志信息；以及将与所述被监控接口相对应的日志信息作为所述目标日志信息。

根据本公开的实施例，根据所述业务节点事件信息对所述被监控业务进行监控包括：获取所述业务节点事件信息中的目标业务节点和所述目标业务节点的目标执行状态，其中，所述目标执行状态包括成功和异常；在所述目标执行状态为成功的情况下，确定所述目标业务节点以第一展示效果进行展示；在所述目标执行状态为异常的情况下，确定所述目标业务节点以第二展示效果进行展示。

根据本公开的实施例，上述业务监控方法还包括：获取与所述被监控业务相关的业务关键字；构建所述业务关键字和所述业务节点事件信息的索引关系；以及将所述索引关系存储至数据库中，以便根据所述业务关键字查询所述被监控业务的执行状态信息。

根据本公开的实施例，上述业务监控方法还包括：根据所述业务关键字确定业务标识信息或关联信息；以及根据所述业务标识信息或关联信息查询所述被监控业务的执行状态信息。

本公开的另一个方面提供了一种业务监控装置，包括：第一获取模块，用于获取被监控业务中至少一个被监控接口的目标日志信息，其中，所述被监控业务被划分为多个业务节点，所述多个业务节点之间具有关联关系；第二获取模块，用于获取所述被监控业务的配置信息，其中，所述配置信息包括每个所述业务节点与至少一个被监控接口之间的映射关系；确定模块，用于根据所述配置信息确定与所述目标日志信息对应的目标业务节点；生成模块，用于根据所述目标日志信息和所述目标业务节点生成业务节点事件信息；以及监控模块，用于根据所述业务节点事件信息对所述被监控业务进行监控。

本公开的另一方面提供了一种计算机系统，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上所述的业务监控方法。

本公开的另一方面提供了一种计算机可读存储介质，其上存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的业务监控方法。

本公开的另一方面提供了一种计算机程序产品，所述计算机程序产品包括计算机可执行指令，所述指令在被执行时用于实现如上所述的业务监控方法。

根据本公开的实施例，通过采用了获取被监控业务中至少一个被监控接口的目标日志信息，其中，被监控业务被划分为多个业务节点，多个业务节点之间具有关联关系；获取被监控业务的配置信息，其中，配置信息包括每个业务节点与至少一个被监控接口之间的映射关系；根据配置信息确定与目标日志信息对应的目标业务节点；根据目标日志信息和目标业务节点生成业务节点事件信息；以及根据业务节点事件信息对被监控业务进行监控的技术手段，由于通过日志信息和业务节点对被监控业务进行监控，所以至少部分地克服了现有业务监控不够通用的技术问题，进而实现了一种通用的业务监控方法，达到了可以对各种复杂的业务场景实施监控的技术效果。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的可以应用业务监控方法的示例性系统架构；

图2示意性示出了根据本公开实施例的业务监控方法的流程图；

图3示意性示出了根据本公开实施例的应用接入流程图；

图4示意性示出了根据本公开实施例的业务异常数据采集流程图；

图5示意性示出了根据本公开实施例的业务异常数据接收流程图；

图6示意性示出了根据本公开实施例的业务监控方法构建的业务监控平台的总设计图；

图7示意性示出了根据本公开实施例的业务异常查询流程图；

图8示意性示出了根据本公开实施例的业务异常展示图；

图9示意性示出了根据本公开实施例的业务异常详细信息展示图；

图10示意性示出了根据本公开的实施例的业务监控装置的框图；以及

图11示意性示出了根据本公开实施例的适于实现业务监控方法的计算机系统的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

目前业务监控系统多种多样，但内部实现方案大致相同，比如各业务系统根据自身业务特点单独实现一套业务监控系统，评估所需监控点，并在核心业务模块埋点进行异常数据采集或业务报警；又或者实现一套通用业务监控平台，并提供对应数据采集API供业务系统接入，相关人员接收到异常报警后，确认异常所属业务模块，协调多个关联系统进行异常排查。

发明人在实现本公开构思的过程中发现，现有业务监控实现方案主要存在以下几点不足：不够通用，定制化比较严重，跟具体业务耦合较重，每个业务系统需要自己实现一套业务监控系统，增加研发及维护成本；应用接入代码侵入性较强，特别是针对老旧系统，改动较多，风险较大；业务系统之间业务异常脱节，无法做到跨系统进行业务监控；缺乏业务整体流程视角，不够直观，不便于非研发类用户进行问题排查。

本公开的实施例提供了一种业务监控方法、业务监控装置、计算机系统、计算机可读存储介质和计算机程序产品。该方法包括获取被监控业务中至少一个被监控接口的目标日志信息，其中，被监控业务被划分为多个业务节点，多个业务节点之间具有关联关系；获取被监控业务的配置信息，其中，配置信息包括每个业务节点与至少一个被监控接口之间的映射关系；根据配置信息确定与目标日志信息对应的目标业务节点；根据目标日志信息和目标业务节点生成业务节点事件信息；以及根据业务节点事件信息对被监控业务进行监控。

图1示意性示出了根据本公开实施例的可以应用业务监控方法的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线和/或无线通信链路等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端和/或社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的业务监控方法一般可以由服务器105执行。相应地，本公开实施例所提供的业务监控装置一般可以设置于服务器105中。本公开实施例所提供的业务监控方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的业务监控装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。或者，本公开实施例所提供的业务监控方法也可以由终端设备101、102、或103执行，或者也可以由不同于终端设备101、102、或103的其他终端设备执行。相应地，本公开实施例所提供的业务监控装置也可以设置于终端设备101、102、或103中，或设置于不同于终端设备101、102、或103的其他终端设备中。

例如，被监控业务可以原本存储在终端设备101、102、或103中的任意一个(例如，终端设备101，但不限于此)之中，或者存储在至少一个外部存储设备上并可以导入到终端设备101中。然后，终端设备101可以在本地执行本公开实施例所提供的业务监控方法，或者将被监控业务发送到其他终端设备、服务器、或服务器集群，并由接收该被监控业务的其他终端设备、服务器、或服务器集群来执行本公开实施例所提供的业务监控方法。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图2示意性示出了根据本公开实施例的业务监控方法的流程图。

如图2所示，该方法包括操作S201～S205。

在操作S201，获取被监控业务中至少一个被监控接口的目标日志信息，其中，被监控业务被划分为多个业务节点，多个业务节点之间具有关联关系。

根据本公开的实施例，上述被监控业务例如可以包括具有各种复杂的业务流程的业务，其中，业务流程例如是为实现特定的业务而由不同的业务功能模块分别共同完成的一系列活动，且活动之间有一定先后顺序限定。上述被监控接口例如可以为被监控业务中需要监控的接口方法。上述业务节点例如可以为将整个业务流程按业务功能模块划分得到的业务节点，节点之间的关联关系例如可以由业务流程中各业务功能模块之间的逻辑关系确定，上述业务节点例如还可以为将整个业务流程按活动类型划分得到的业务节点，节点之间的关联关系例如可以由业务流程中活动的先后顺序确定。

在操作S202，获取被监控业务的配置信息，其中，配置信息包括每个业务节点与至少一个被监控接口之间的映射关系。

根据本公开的实施例，业务节点可以为根据业务功能模块或活动类型划分得到，由于每一个业务功能模块或业务活动均可以包括一个或多个接口方法，因此通过一个业务节点可以监控一个或多个接口方法(即上述被监控接口)，通过对需要监控的接口方法配置业务节点信息(例如可以包括接口方法、所属业务节点、业务功能描述等信息)，实现节点与实际业务场景(如业务中的被监控接口)的关联，从而可建立业务节点与其需要监控的接口方法之间的映射关系，得到上述配置信息，为后续业务监控的实现提供基础。

在操作S203，根据配置信息确定与目标日志信息对应的目标业务节点。

根据本公开的实施例，由于目标日志信息可以是针对被监控接口的日志信息，根据配置信息中业务节点与被监控接口的映射关系，即可确定相应的被监控接口的目标日志信息对应的业务节点，即上述目标业务节点。

在操作S204，根据目标日志信息和目标业务节点生成业务节点事件信息。

根据本公开的实施例，上述业务节点事件信息例如可以为一次业务流程处理中业务节点产生的节点事件对应的信息，其中，节点事件例如可以包括如异常事件，成功事件等，业务节点事件信息例如可以包括业务相关信息、日志中信息以及节点本身的信息，该业务节点事件信息的格式例如可以为：

NodeEvent#{″domainId″：业务域id，″appId″：应用id，″sceneId″：流程id，″nodeId″：业务节点id，″flowChartId″：流程图id，″executeStatus″：执行状态，″bizId″：″业务id″，″content″：″异常信息″，″params″：″入参″，″result″：″出参″，″associateKey″：″关联key″，″createTime″：″创建时间″，″modifyTime″：″修改时间″}

其中，应用id例如为业务节点所属应用对应的id(标识符)，流程id，例如为业务节点所属业务流程对应的id，业务节点id例如为相应的业务节点对应的id，流程图id例如为业务流程节点编排图对应的id，执行状态例如即为相应的业务节点的执行状态，例如可以包括异常、成功、未执行等状态，业务id例如为业务流程关联的业务关键字，用于后续查询及搜索，关联key例如可以为一次业务请求的唯一关联key，用于串联多个业务系统。

在操作S205，根据业务节点事件信息对被监控业务进行监控。

根据本公开的实施例，可以根据业务节点事件信息中的详细内容监控每一个业务节点的处理细节，从而可监控整个被监控业务的处理流程。

通过本公开的上述实施例，由于将业务系统划分为了多个业务节点，并通过采集日志的方式构建业务节点事件信息，实现对业务系统中的各个业务节点进行监控，监控方法可无需侵入业务系统，从而实现监控过程与业务系统的解耦，并可进一步通用于各种复杂业务场景，实现各种业务场景下的业务异常监控。

下面参考图3～图9，结合具体实施例对图2所示的方法做进一步说明。

图3示意性示出了根据本公开实施例的应用接入流程图。

如图3所示，其展示了在进行上述业务监控方法之前的操作，包括操作S301～S302。

在操作S301，业务系统接入。

需要说明的是，上述被监控业务例如可以是来自多个不同系统的业务，为了保证业务监控的准确性，此时即需要对该多个系统同步实施监控。

根据本公开的实施例，需要进行业务监控的系统需首先通过业务监控平台管理端进行应用接入，录入相关应用信息，例如可以包括：appId，token(一种用于识别应用示范可接入的标识)，及所属业务域等信息。

为实现上述目的，该操作S301例如可以包括：获取用于将不同系统的业务接入业务监控平台的接入操作；以及响应于该接入操作，将不同系统的业务的应用实例信息输入业务监控平台，以便将不同系统的业务接入业务监控平台。

在操作S302，业务流程编排。

根据本公开的实施例，在业务接入业务监控平台后，即对业务场景进行绘制以实现对业务流程的编排，该编排例如可以包括对业务流程进行节点划分以及将业务流程中涉及的多个业务节点根据依赖关系进行编排。

为实现上述目的，该操作S302例如可以包括：根据不同系统的业务场景，确定针对业务场景的节点划分方式及编排方式；获取用于将业务场景划分为业务节点的划分操作，其中，该划分操作例如可以包括用户输入的节点创建操作；获取用于实现业务节点间依赖关系的编排的编排操作，其中，该编排操作例如可以包括用户输入的根据节点间依赖关系确定的某些节点间的连接操作；以及响应于该划分操作和该编排操作，即可在业务监控平台中实现对不同系统的业务的业务流程进行业务节点划分及编排。

通过本公开的上述实施例，由于采用业务流程节点化的方式，可以对所有需要监控的业务流程按业务节点划分，得到的业务节点分别归属各个业务系统，并通过流程编排，串联整个业务系统，可以以整体流程视角展示业务异常，实现了业务异常可视化、直观化以及可跨系统进行业务监控的能力。

根据本公开的实施例，在应用接入业务监控平台之后，上述操作S201例如可以包括：根据用于采集被监控业务的日志信息的自定义日志组件采集日志信息；在日志信息属于预设日志级别的情况下，判断日志信息是否为被监控接口所对应的日志信息；以及将与被监控接口相对应的日志信息作为目标日志信息。

图4示意性示出了根据本公开实施例的业务异常数据采集流程图。

如图4所示，其展示了上述操作S201的具体实现流程，包括操作S401～S408。

需要说明的是，为了支持上述操作S201所对应的方法，本方法还引入了日志采集客户端，实现上述目标日志信息的采集。

在操作S401，自动定位日志组件类型logback/log4j。其中，logback和log4j属于不同类型的日志组件。

在操作S402，创建自定义日志Appender。其中，Appender作为日志组件中的一个核心子组件，可以定义日志信息输出的目的地。

在操作S403，扫描应用已有Logger，并追加自定义Appender。其中，Logger作为日志组件中的另一个核心子组件，负责生成日志，并能够对日志信息进行分类筛选。

在操作S404，业务日志打印。

根据本公开的实施例，应用按现有日志打印方式可以输出不同级别(例如可以包括debug、info、warn、Error、Fatal等级别)的日志信息，无需做任何修改。

在操作S405，自定义Appender日志拦截。

根据本公开的实施例，针对上述操作S401～S405，由于接入的应用不同，在进行日志采集时的日志组件也可能不同，因此，在应用启动后，日志采集客户端将会首先自动定位应用所用日志组件(logback/log4j)，并创建用于日志采集的自定义日志Appender，同时，扫描应用现有Logger并追加自定义Appender，后续所有Logger日志打印将会输出到自定义Appender实现日志拦截。自定义Appender拦截日志信息后，例如可以通过如下操作S406～S407对拦截的日志信息进行日志过滤，以得到所需的目标日志信息。

在操作S406，是否指定日志级别，如Error。

根据本公开的实施例，在该操作的判断结果为否的情况下，即拦截的日志信息不是指定的日志级别，则对该日志信息进行过滤，不对其采集。在该操作的判断结果为是的情况下，即拦截的日志信息是指定的日志级别，则需要进一步判断该日志信息是否配置了相应的业务节点信息，即操作S407。

在操作S407，是否配置业务节点信息。

根据本公开的实施例，在该操作的判断结果为否的情况下，即拦截的日志信息没有配置相应的业务节点信息，则同样对该日志信息进行过滤，不对其采集。在该操作的判断结果为是的情况下，即拦截的日志信息有配置相应的业务节点信息，则可以根据上述配置信息构建对应的业务节点事件信息。

在操作S408，构建业务异常事件并发送MQ(消息队列)。

根据本公开的实施例，该业务异常事件例如即属于上述业务节点事件信息的一部分，该信息例如可以通过发送MQ的方式上报至业务监控平台。

通过本公开的上述实施例，采用自定义日志Appender并追加到应用已有Logger进行日志拦截及上报的方式，实现了一种无侵入日志拦截业务异常采集及自动上报的方案，进一步解决了传统业务异常监控不通用的问题，可应用于各种复杂的业务场景中。

需要说明的是，上述无侵入日志拦截也可通过字节码修改技术实现，不同的是，字节码修改技术需要修改日志打印类字节码，新增日志拦截代码，通过增加注解的方式打印错误日志，注解里可以包括与相应的日志信息关联的节点id。

图5示意性示出了根据本公开实施例的业务异常数据接收流程图。

如图5所示，展示了业务监控平台接收到业务节点事件信息后的一系列操作，包括操作S501～S506。

在操作S501，接收业务异常事件。

在操作S502，解析业务异常事件。

在操作S503，是否报警。

根据本公开的实施例，该操作例如为根据业务配置来判断，例如，业务配置规定了某些异常事件无需业务报警，则即使在监控到该些事件时也不会触发报警，反之，则可以触发报警。基于该规则可以自定义实现业务流程监控。

在操作S504，业务监控报警。

根据本公开的实施例，该操作在操作S503的操作结果为是的情况下实现。

在操作S505，解析业务关键字存储索引关系。

根据本公开的实施例，例如可以通过解析业务节点事件信息中的业务id，得到该业务关键字，并可通过ES(Elasticsearch，一种非关系型数据库)中的分词算法构建该业务关键字与其对应的业务节点事件记录(即该业务关键字对应的事件详细信息)的索引关系，该索引关系最终可以持久化存储在ES中，用于实现后续的业务流程状态查询。

需要说明的是，该业务节点事件记录例如可以为上述业务节点事件信息，或者也可以为基于上述业务节点事件信息进一步得到的更为详细的信息。

在操作S506，构建业务节点异常记录并持久化到HBase。

根据本公开的实施例，该业务节点异常记录例如可以基于上述业务节点事件记录得到，通过将该业务节点异常记录绑定到对应业务节点后再持久化存储到HBase中，以便为后续的业务流程状态查询过程中的异常事件提供可查询的详细信息。

需要说明的是，也可以将上述业务节点事件记录绑定到对应业务节点并持久化存储到HBase中，以便未后续的业务流程状态查询过程中的每一个事件均可提供可查询的详细信息。上述业务节点事件记录的存储也可以采用数据库或其他存储服务替代HBase，在此不做限定。

根据本公开的上述实施例，通过将业务节点事件记录与业务节点进行绑定，并将业务节点事件记录持久化存储在HBase中，可容易实现上述操作S205中根据业务节点事件信息对被监控业务进行监控的目的。在此基础上，该操作S205例如还可以包括：获取业务节点事件信息中的目标业务节点和该目标业务节点的目标执行状态，其中，目标执行状态包括成功和异常；在目标执行状态为成功的情况下，确定目标业务节点以第一展示效果进行展示；在目标执行状态为异常的情况下，确定目标业务节点以第二展示效果进行展示。

根据本公开的实施例，上述目标执行执行状态也可仅包括异常，此时，若在一个业务流程中存在一个业务节点对应的执行状态为异常的情况下，将该业务节点以第二展示效果进行展示，并可以直接判定在该业务节点之前的业务节点的执行状态为成功，从而将该业务节点之前的业务节点以第一展示效果进行展示，同时，还可以直接判定在该业务节点之后的业务节点为未执行状态，并可以将该业务节点之后的业务节点以第三展示效果进行展示。

需要说明的是，上述第一、第二、第三展示效果例如可以以颜色(例如包括绿色、红色、灰色等)作为区分，或者也可以以其他渲染类的动画作为区分，在此不做限定。

通过本公开的上述实施例，由于将业务异常事件与业务节点绑定，业务异常数据可以上报至指定的所属业务节点，业务节点状态来源也可业务异常事件相互对应，通过结合前述业务节点的编排操作，以及将业务节点根据状态采用不同颜色标识的设计，可以可视化的展示业务流程所卡住的业务节点，进而实现更直观的展现业务监控结果的目的。

结合本公开的上述实施例，图6示意性示出了根据本公开实施例的业务监控方法构建的业务监控平台的总设计图。

如图6所示，该业务监控平台例如可以包括业务监控管理端、业务监控引擎和日志采集客户端。其中，业务监控管理端实现对需要进行业务监控的系统的应用接入以及对需要监控的业务流程进行业务节点划分及编排的操作；日志采集客户端例如可以为由业务系统各应用实例所引入，通过针对需要采集的接口方法配置相应的业务节点信息，在应用启动后可以由日志采集客户端自动开始业务异常日志拦截并上报到消息中间件；业务监控引擎可以将应用接入过程中录入的相关应用信息(如上述的appId、token和所述业务域等信息)存储至数据库(如Mysql)中，也可以监听并接收消息中间件的业务异常事件，并可以对该业务异常事件进行解析，进一步的实现业务报警及分析存储，例如可以包括实现上述图5所述的实施例中的相关操作，还可以在查询过程中搜索关键字，实现对业务异常数据的查询。

根据图6所示的实施例，用户(业务、产品或研发)可登陆该业务监控平台，并根据业务关键字或业务其他相关信息查询对应业务流程执行状态，以确定业务流程是否发生异常。

根据本公开的一实施例，例如可以根据业务关键字进行相关查询，该过程例如可以包括：获取与被监控业务相关的业务关键字；构建业务关键字和业务节点事件信息的索引关系；以及将索引关系存储至数据库中，以便根据业务关键字查询被监控业务的执行状态信息。

根据本公开的另一实施例，例如还可以根据业务其他相关信息进行相关查询，该过程例如可以包括：根据业务关键字确定业务标识信息或关联信息；以及根据业务标识信息或关联信息查询被监控业务的执行状态信息。

图7示意性示出了根据本公开实施例的业务异常查询流程图。

如图7所示，例如可以为基于上述业务监控平台，或者基于上述业务监控方法实现的业务异常查询的流程，包括操作S701～S705。

在操作S701，选择业务域及业务流程。

在操作S702，获取所选业务流程图。

根据本公开的实施例，通过业务域和业务流程可以确定唯一的业务流程节点编排图，即可以确定唯一的业务流程图。

在操作S703，输入业务关键字查询业务id/traceid。

根据本公开的实施例，业务关键字例如可以为从业务异常信息、日志信息或业务节点事件信息等中提取的关键字，通过业务关键字可以查询得到与该关键字对应的业务id和traceid(即上述关联key)。

在操作S704，根据关键字查询ES获取业务节点Rowkey。

根据本公开的实施例，上述业务节点Rowkey例如为基于ES中存储的关键字与业务节点事件记录的索引关系查询到的与相应的关键字对应的业务节点的主键信息。

在操作S705，根据业务节点Rowkey查询各业务节点异常数据。

根据本公开的实施例，根据上述业务节点Rowkey即可从HBase中查询到相应的业务节点的详细记录，从而可以获得存在异常的业务节点的详细异常数据。

图8示意性示出了根据本公开实施例的业务异常展示图。

根据图8所示的实施例，针对上述操作S701，用户在选择了所属业务域(例如可对应上述业务域id)为海外交易，监控场景(即所需监控的业务流程，例如可对应上述流程id)为印尼下EPT订单流程之后，业务监控引擎即可基于此确定上述操作S702中得到的业务流程图(例如可对应上述流程图id)例如即为具有图8中业务节点和节点间关系的结构的业务流程图。

接着，用户可进一步输入业务关键字查询流程状态，结合前述实施例，用户可以首先根据业务关键字查询得到相应的业务id和traceid，然后根据该业务id或traceid即可获取业务流程图中各业务节点对应的事件信息，通过根据各该业务节点事件信息的类型采用不同颜色呈现业务节点，即可查询得到具体的包含各业务节点执行状态的业务监控结果。例如用户可以在图8中的业务编码处输入该业务id，或者在图8中的关联key处输入该traceid，由于业务id和traceid都对应至具体的业务流程，因此可以得到对应于上述业务关键字的业务监控结果。

如图8中的流程展示结果即为针对海外交易的印尼下EPT订单流程中业务编码为1025780305的业务的监控结果，图8中，“接受下单请求”这一节点例如为以绿色展示，“下EPT单”这一节点例如为以红色展示，其余节点例如为以灰色展示，则用户可据此分析得到，“接受下单请求”这一节点对应的事件均已执行成功，但业务在运行至“下EPT单”这一节点时发生了异常，导致业务流程不能进行下去，其余节点也因此未能被执行。

通过点击图8中相应的业务节点，可进一步查看没个业务节点的详细执行信息，例如，通过点击图8中“下EPT单”这一节点可查看该节点对应的详细异常信息，如图9所示。

图9示意性示出了根据本公开实施例的业务异常详细信息展示图。

如图9所示，通过单击右侧的查看日志按钮，可进一步查看该业务异常所在方法的出入参信息，从而看进一步确定异常产生原因，促进异常排查。

通过本公开的上述实施例，解决了复杂业务场景中业务异常监控不通用，不直观，同时缺乏跨系统监控能力等问题。在一方面，应用接入简单，并且在异常采集时可做到无侵入，同时可以在不修改现有应用代码前提下，引入日志拦截方案进行业务异常日志采集，实现了监控系统与业务系统的解耦，解决了不通用的问题；在另一方面，将复杂业务场景按业务节点划分并进行编排，业务异常事件与业务节点绑定，业务节点可以根据事件状态采用不同颜色标识，实现可视化呈现业务流程执行状态，可有效助力产品、业务问题排查，并可提升问题排查效率，释放研发资源，实现了业务异常的可视化、直观化；在又一方面，通过将业务流程节点化，业务节点分别归属各个业务系统，串联整个业务系统，以整体流程视角展示业务异常，实现了跨系统监控业务的能力。

图10示意性示出了根据本公开的实施例的业务监控装置的框图。

如图10所示，业务监控装置1000包括第一获取模块1010、第二获取模块1020、第一确定模块1030、生成模块1040和监控模块1050。

第一获取模块1010，用于获取被监控业务中至少一个被监控接口的目标日志信息，其中，被监控业务被划分为多个业务节点，多个业务节点之间具有关联关系；

第二获取模块1020，用于获取被监控业务的配置信息，其中，配置信息包括每个业务节点与至少一个被监控接口之间的映射关系；

第一确定模块1030，用于根据配置信息确定与目标日志信息对应的目标业务节点；

生成模块1040，用于根据目标日志信息和目标业务节点生成业务节点事件信息；以及

监控模块1050，用于根据业务节点事件信息对被监控业务进行监控。

根据本公开的实施例，上述业务监控装置还包括第三获取模块和接入模块。

第三获取模块，用于获取用于将不同系统的业务接入业务监控平台的接入操作。

接入模块，用于响应于接入操作，将不同系统的业务的应用实例信息输入业务监控平台，以便将不同系统的业务接入业务监控平台。

根据本公开的实施例，上述业务监控装置还包括编排模块。

编排模块，用于根据不同系统的业务场景，对不同系统的业务的业务流程进行业务节点划分及编排。

根据本公开的实施例，上述第一获取模块包括采集单元、判断单元和定义单元。

采集单元，用于根据用于采集被监控业务的日志信息的自定义日志组件采集日志信息采集。

判断单元，用于在日志信息属于预设日志级别的情况下，判断日志信息是否为被监控接口所对应的日志信息。

定义单元，用于将与被监控接口相对应的日志信息作为目标日志信息。

根据本公开的实施例，上述监控模块包括获取单元、第一确定单元和第二确定单元。

获取单元，用于获取业务节点事件信息中的目标业务节点和目标业务节点的目标执行状态，其中，目标执行状态包括成功和异常。

第一确定单元，用于在目标执行状态为成功的情况下，确定目标业务节点以第一展示效果进行展示。

第二确定单元，用于在目标执行状态为异常的情况下，确定目标业务节点以第二展示效果进行展示。

根据本公开的实施例，上述业务监控装置还包括第四获取模块、构建模块和第一查询模块。

第四获取模块，用于获取与被监控业务相关的业务关键字。

构建模块，用于构建业务关键字和业务节点事件信息的索引关系。

第一查询模块，用于将索引关系存储至数据库中，以便根据业务关键字查询被监控业务的执行状态信息。

根据本公开的实施例，上述业务监控装置还包括第二确定模块和第二查询模块。

第二确定模块，用于根据业务关键字确定业务标识信息或关联信息。

第二查询模块，用于根据业务标识信息或关联信息查询被监控业务的执行状态信息。

根据本公开的实施例的模块、单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，第一获取模块1010、第二获取模块1020、第一确定模块1030、生成模块1040和监控模块1050中的任意多个可以合并在一个模块/单元中实现，或者其中的任意一个模块/单元可以被拆分成多个模块/单元。或者，这些模块/单元中的一个或多个模块/单元的至少部分功能可以与其他模块/单元的至少部分功能相结合，并在一个模块/单元中实现。根据本公开的实施例，第一获取模块1010、第二获取模块1020、第一确定模块1030、生成模块1040和监控模块1050中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，第一获取模块1010、第二获取模块1020、第一确定模块1030、生成模块1040和监控模块1050中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

需要说明的是，本公开的实施例中业务监控装置部分与本公开的实施例中业务监控方法部分是相对应的，业务监控装置部分的描述具体参考业务监控方法部分，在此不再赘述。

图11示意性示出了根据本公开实施例的适于实现业务监控方法的计算机系统的框图。图11示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图11所示，根据本公开实施例的计算机系统1100包括处理器1101，其可以根据存储在只读存储器(ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(RAM)1103中的程序而执行各种适当的动作和处理。处理器1101例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1101还可以包括用于缓存用途的板载存储器。处理器1101可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 1103中，存储有系统1100操作所需的各种程序和数据。处理器1101、ROM1102以及RAM 1103通过总线1104彼此相连。处理器1101通过执行ROM 1102和/或RAM 1103中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 1102和RAM 1103以外的一个或多个存储器中。处理器1101也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统1100还可以包括输入/输出(I/O)接口1105，输入/输出(I/O)接口1105也连接至总线1104。系统1100还可以包括连接至I/O接口1105的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被处理器1101执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质。例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 1102和/或RAM 1103和/或ROM 1102和RAM 1103以外的一个或多个存储器。

本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行本公开实施例所提供的方法的程序代码，当计算机程序产品在电子设备上运行时，该程序代码用于使电子设备实现本公开实施例所提供的业务监控方法。

在该计算机程序被处理器1101执行时，执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。

在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分1109被下载和安装，和/或从可拆卸介质1111被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如Java，C++，python，“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (11)

1.一种业务监控方法，包括：

获取被监控业务中至少一个被监控接口的目标日志信息，其中，所述被监控业务被划分为多个业务节点，所述多个业务节点之间具有关联关系；

获取所述被监控业务的配置信息，其中，所述配置信息包括每个所述业务节点与至少一个被监控接口之间的映射关系；

根据所述配置信息确定与所述目标日志信息对应的目标业务节点；

根据所述目标日志信息和所述目标业务节点生成业务节点事件信息；以及

根据所述业务节点事件信息对所述被监控业务进行监控。

2.根据权利要求1所述的方法，还包括：

获取用于将不同系统的业务接入业务监控平台的接入操作；以及

响应于所述接入操作，将所述不同系统的业务的应用实例信息输入所述业务监控平台，以便将所述不同系统的业务接入所述业务监控平台。

3.根据权利要求2所述的方法，还包括：

根据所述不同系统的业务场景，对所述不同系统的业务的业务流程进行业务节点划分及编排。

4.根据权利要求1所述的方法，其中，获取被监控业务中至少一个被监控接口的目标日志信息包括：

根据用于采集所述被监控业务的日志信息的自定义日志组件采集日志信息；

在所述日志信息属于预设日志级别的情况下，判断所述日志信息是否为所述被监控接口所对应的日志信息；以及

将与所述被监控接口相对应的日志信息作为所述目标日志信息。

5.根据权利要求1所述的方法，其中，根据所述业务节点事件信息对所述被监控业务进行监控包括：

获取所述业务节点事件信息中的目标业务节点和所述目标业务节点的目标执行状态，其中，所述目标执行状态包括成功和异常；

在所述目标执行状态为成功的情况下，确定所述目标业务节点以第一展示效果进行展示；

在所述目标执行状态为异常的情况下，确定所述目标业务节点以第二展示效果进行展示。

6.根据权利要求1所述的方法，还包括：

获取与所述被监控业务相关的业务关键字；

构建所述业务关键字和所述业务节点事件信息的索引关系；以及

将所述索引关系存储至数据库中，以便根据所述业务关键字查询所述被监控业务的执行状态信息。

7.根据权利要求6所述的方法，还包括：

根据所述业务关键字确定业务标识信息或关联信息；以及

根据所述业务标识信息或关联信息查询所述被监控业务的执行状态信息。

8.一种业务监控装置，包括：

第一获取模块，用于获取被监控业务中至少一个被监控接口的目标日志信息，其中，所述被监控业务被划分为多个业务节点，所述多个业务节点之间具有关联关系；

第二获取模块，用于获取所述被监控业务的配置信息，其中，所述配置信息包括每个所述业务节点与至少一个被监控接口之间的映射关系；

确定模块，用于根据所述配置信息确定与所述目标日志信息对应的目标业务节点；

生成模块，用于根据所述目标日志信息和所述目标业务节点生成业务节点事件信息；以及

监控模块，用于根据所述业务节点事件信息对所述被监控业务进行监控。

9.一种计算机系统，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器实现权利要求1至7中任一项所述的方法。

11.一种计算机程序产品，包括计算机可执行指令，所述指令在被执行时用于实现权利要求1至7中任一项所述的方法。

Images