CN109471768B - 业务问题的监控方法、装置以及电子设备 - Google Patents

Abstract

本发明实施例提供了一种业务问题的监控方法、装置以及电子设备。该方法包括：在加载业务代码时，调用已植入异常监控逻辑的底层代码，将所述异常监控逻辑添加到所述业务代码；运行所述业务代码，通过所述异常监控逻辑获取系统产生业务问题时生成的异常数据。本发明实施例通过对底层代码进行修改，来实现对业务代码的监控，以获取系统抛出异常情况下的业务问题。不需要在业务代码中手动添加大量的日志代码，能够降低开发和维护成本。且无须人工介入，避免了因人为因素而出现遗漏的风险，提高了系统性能。

Description

业务问题的监控方法、装置以及电子设备

技术领域

本发明涉及计算机技术领域，尤其涉及一种业务问题的监控方法、装置以及电子设备。

背景技术

在web系统中，当出现与正常系统功能不相符合的系统表现时，通常称为出现业务问题或bug。而对于系统中出现的业务问题，如果依赖测试人员手动或以脚本的方式进行验证，或者依赖线上用户的反馈，则效率非常低，且容易出现遗漏。

在现有技术中，一般采用分析日志的方式进行业务问题的监控。首先，在业务代码中添加日志记录代码，通过该日志记录代码实时或者定时地获取日志文件，对所有的日志文件进行文本分析、建立索引并存储。然后，用户通过设置关键词(用于识别错误日志)，进行检索，以获取符合条件的日志信息(即，业务问题信息)。

发明人在实现本发明的过程中，发现现有技术至少存在如下问题：基于日志分析进行业务问题监控的方式，需要在业务代码中手动设置充足的日志记录代码，设置和维护成本较高，开发工作量较大，且不可衡量充分性；对日志的记录和分析工作，需要消耗大量机器资源；需要人工编写和录入关键词，存在因人为因素而出现遗漏的风险。

发明内容

本发明实施例提供一种业务问题的监控方法、装置以及电子设备，以解决现有技术的缺陷，降低对web系统业务问题的监控成本，提高检测效率。

为达到上述目的，本发明实施例提供了一种业务问题的监控方法，包括：在加载业务代码时，调用已植入异常监控逻辑的底层代码，将所述异常监控逻辑添加到所述业务代码；运行所述业务代码，通过所述异常监控逻辑获取系统产生业务问题时生成的异常数据。

本发明实施例还提供了一种业务问题的监控装置，包括：添加模块，用于在加载业务代码时，调用已植入异常监控逻辑的底层代码，将所述异常监控逻辑添加到所述业务代码；获取模块，用于运行所述业务代码，通过所述异常监控逻辑获取系统产生业务问题时生成的异常数据。

本发明实施例还提供一种电子设备，包括：存储器，用于存储程序；处理器，用于运行所述存储器中存储的所述程序，以用于：在加载业务代码时，调用已植入异常监控逻辑的底层代码，将所述异常监控逻辑添加到所述业务代码；运行所述业务代码，通过所述异常监控逻辑获取系统产生业务问题时生成的异常数据。

本发明实施例提供的业务问题的监控方法、装置以及电子设备，通过对底层代码进行修改，实现对业务代码的监控，获取系统抛出异常情况下的业务问题，降低了开发和维护成本，避免了因人为因素而出现的遗漏，提高了系统性能。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例提供的业务系统的结构示意图；

图2为本发明提供的业务问题的监控方法一个实施例的流程图；

图3为本发明提供的业务问题的监控方法另一个实施例的流程图；

图4为本发明提供的业务问题的监控装置一个实施例的结构示意图；

图5为本发明提供的业务问题的监控装置另一个实施例的结构示意图；

图6为本发明提供的电子设备实施例的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

针对现有技术的缺陷，本申请提供一种解决方案，其主要原理是：在底层代码中植入异常监控逻辑。在程序的执行过程中，大多公共功能由底层代码提供，大部分业务代码的执行过程都需要调用底层代码来实现。所以，通过对底层代码的少量改动添加监控逻辑(例如，通过字节码增强的方式修改java中的jdk代码等)，便能够做到对全部业务代码的功能的覆盖，从底层实现对上层业务执行过程数据的更全面地获取。当业务代码调用底层代码时，执行该异常监控逻辑，为业务代码植入监控逻辑。当用户的访问请求访问已植入异常监控逻辑的业务代码时，开始执行监控程序，监控系统所抛出的异常代码。通过对底层代码进行修改，实现对业务代码的监控，获取系统抛出异常情况下的业务问题。现有的基于日志分析的监控方式中，日志记录代码是业务开发者为了发现问题而编写的一种业务代码，专门负责记录系统运行中出现的问题，完全依赖于开发者的意识，且日志记录代码的数量是随着业务代码的数量线性增加的，通常是业务代码总量的1％左右。而本申请提供的解决方案，不需要在业务代码中手动添加大量的日志代码，只需在底层代码中植入固定的异常监控逻辑，该异常监控逻辑可以对某一类问题全记录，具有一次编写长期复用的特性。因此，能够极大地降低开发和维护成本。且无须人工介入，避免因人为因素而出现遗漏的风险。

本发明实施例提供的方法可应用于任何提供web服务的业务系统。图1为本发明实施例提供的业务系统的结构示意图。如图1所示，业务系统中包括监控装置。该监控装置包括：添加模块和获取模块，可以用来执行下述图2所示的处理流程。首先，在底层代码中植入异常监控逻辑。当业务代码调用底层代码时，执行该异常监控逻辑，为业务代码植入监控逻辑。当用户通过客户端访问业务系统时，若访问请求访问的是已植入异常监控逻辑的业务代码，开始执行监控程序，监控系统所抛出的异常代码。若系统抛出异常代码，则通过异常监控逻辑获取该访问请求的相关数据。该业务系统通过对底层代码进行修改，来实现对业务代码的监控，以获取系统抛出异常情况下的业务问题。不需要在业务代码中手动添加大量的日志代码，能够降低开发和维护成本。且无须人工介入，避免了因人为因素而出现遗漏的风险。

上述实施例是对本发明实施例的技术原理和示例性的应用框架的说明，下面通过多个实施例来进一步对本发明实施例具体技术方案进行详细描述。

首先，对各实施例中出现的术语进行解释：

业务代码和底层代码：举例说明，编写“hello world”的java代码就是业务代码，而“hello world”要能执行，需要业务代码通过jdk来执行，jdk等公用的代码就是底层代码。在程序的执行过程中，一些公共的功能由底层代码提供，大部分业务代码的执行过程中都需要调用底层代码来实现。

异常监控逻辑：对业务代码进行监控的代码，能够获取系统抛出的异常代码。

异常数据：系统抛出异常代码时，异常监控逻辑获取到的访问请求的相关数据，包括：抛出异常代码的接口、接口的函数值、入参、参数结构、返回值、调用链等。

字节码增强工具：在Java语言中，当Java字节码生成之后，能够对字节码源文件进行修改的工具，从而增强字节码的功能，相当于对应用程序的二进制文件进行修改。

实施例一

图2为本发明提供的业务问题的监控方法一个实施例的流程图，该方法的执行主体可以为上述实施例所描述的业务系统中的监控装置。如图2所示，该业务问题的监控方法包括如下步骤：

S201，在加载业务代码时，调用已植入异常监控逻辑的底层代码，将异常监控逻辑添加到业务代码。

本发明实施例中，在加载业务代码之前，将异常监控逻辑植入到底层代码，从底层实现对上层业务执行过程数据的更全面地获取。在系统启动时，首先，通过classloader类加载器加载编译后的jdk底层代码(包括已植入的异常监控逻辑)。然后，在加载业务代码的过程中，调用底层代码，并执行底层代码中所植入的异常监控逻辑，为业务代码添加监控逻辑，直到系统完全启动成功。

S202，运行业务代码，通过异常监控逻辑获取系统产生业务问题时生成的异常数据。

在本发明实施例中，当运行添加了异常监控逻辑的业务代码时，如果系统产生业务问题，则通过异常监控逻辑获取系统生成的异常数据。

本发明实施例提供的业务问题的监控方法，通过对底层代码进行修改，来实现对业务代码的监控，以获取系统抛出异常情况下的业务问题。不需要在业务代码中手动添加大量的日志代码，能够降低开发和维护成本。且无须人工介入，避免了因人为因素而出现遗漏的风险，提高了系统性能。

实施例二

图3为本发明提供的业务问题的监控方法另一个实施例的流程图。如图3所示，在图2所示上述实施例的基础上，本实施例提供的业务问题的监控方法可以进一步包括以下步骤：

S301，将异常监控逻辑植入到底层代码。

在本发明实施例中，可以通过字节码增强的方式，将异常监控逻辑植入到底层代码。具体地，在加载底层代码时，通过字节码增强工具修改底层代码，以将异常监控逻辑植入到底层代码，从底层实现对上层业务执行过程数据的更全面地获取。

S302，在加载业务代码时，调用已植入异常监控逻辑的底层代码，根据底层代码中预先设置的接口参数，将异常监控逻辑添加到业务代码的指定接口。

在系统启动时，首先，通过classloader类加载器加载编译后的jdk底层代码(包括已植入的异常监控逻辑)。然后，在加载业务代码的各接口时，根据底层代码中预先设置的接口参数，判断该接口是否被设置为需要添加异常监控逻辑，如果需要，则调用并执行底层代码中所植入的异常监控逻辑，为业务代码添加监控逻辑，直到系统完全启动成功。

S303，运行业务代码，在执行访问请求时，若系统抛出异常代码，则通过异常监控逻辑获取该访问请求的相关数据。

当用户访问业务系统时，若访问请求访问的是已植入异常监控逻辑的接口，则开始执行异常监控逻辑，监控系统所抛出的异常代码。当系统抛出异常代码时，通过异常监控逻辑获取该访问请求的相关数据(即，异常数据)，该相关数据是系统的运行态数据，是按照代码的函数结构有一定结构规范的数据，包括抛出异常代码的接口，进一步可以包括接口的函数值、入参、参数结构、返回值、调用链等。获取到的异常数据可以通过异常统计和分析系统进行统计和分析，以便对该业务问题进行修复。

S304，从异常数据中解析上述接口的入参，根据该入参，重新调用上述接口，根据接口的执行结果，验证上述业务问题。

进一步地，在本发明实施例中，还提供对业务问题的验证方案。通过上述步骤获取到的异常数据是结构化数据，可用来重新执行该问题程序，来实现对业务问题的验证。通过步骤S304来验证业务问题是否被正确修复。即，从监控到的异常数据中解析出现业务问题的接口的入参，根据该入参，重新调用该接口。当接口未抛出异常代码时，确认上述业务问题已被修复。如果执行结果仍然抛出异常代码，则确认该业务问题未被正确修复。

本发明实施例提供的业务问题的监控方法，通过对底层代码进行修改，从底层实现对上层业务代码的监控，以获取系统抛出异常情况下的业务问题。可选择需要监控的业务代码接口进行监控，以提高监控效率。同时，对业务问题的修复进行验证，从而进一步提高系统性能。

实施例三

图4为本发明提供的业务问题的监控装置一个实施例的结构示意图，可以用于执行如图2所示的方法步骤。如图4所示，该装置可以包括：添加模块41和获取模块42。

其中，添加模块41用于在加载业务代码时，调用已植入异常监控逻辑的底层代码，将异常监控逻辑添加到业务代码；获取模块42用于运行业务代码，通过异常监控逻辑获取系统产生业务问题时生成的异常数据。

在本发明实施例中，在系统加载业务代码的过程中，添加模块41调用底层代码，并执行底层代码中所植入的异常监控逻辑，为业务代码添加监控逻辑。当系统运行添加了异常监控逻辑的业务代码时，如果系统产生业务问题，则获取模块42通过异常监控逻辑获取系统生成的异常数据。

本发明实施例提供的业务问题的监控装置，通过对底层代码进行修改，来实现对业务代码的监控，以获取系统抛出异常情况下的业务问题。不需要在业务代码中手动添加大量的日志代码，能够降低开发和维护成本。且无须人工介入，避免了因人为因素而出现遗漏的风险，提高了系统性能。

实施例四

图5为本发明提供的业务问题的监控装置另一个实施例的结构示意图。如图5所示，在上述图4所示实施例的基础上，该业务问题的监控装置还可以包括：植入模块51。

该植入模块51可以用于在加载业务代码之前，将异常监控逻辑植入到底层代码(例如，可以通过字节码增强的方式)。

本发明实施例中，在加载业务代码之前，植入模块51将异常监控逻辑植入到底层代码，具体地，在加载底层代码时，植入模块51通过字节码增强工具修改底层代码，以将异常监控逻辑植入到底层代码，从底层实现对上层业务执行过程数据的更全面地获取。在系统启动时，通过classloader类加载器加载编译后的jdk底层代码(包括已植入的异常监控逻辑)。在加载业务代码的各接口时，添加模块41根据底层代码中预先设置的接口参数，判断该接口是否被设置为需要添加监控逻辑，如果需要，则调用并执行底层代码中所植入的异常监控逻辑，为业务代码添加监控逻辑，直到系统完全启动成功。

进一步地，获取模块42还可以用于在执行访问请求时，若系统抛出异常代码，则通过异常监控逻辑获取该访问请求的相关数据，该相关数据包括抛出异常代码的接口。

当用户访问业务系统时，若访问请求访问的是已植入异常监控逻辑的接口，则开始执行监控程序，监控系统所抛出的异常代码。当系统抛出异常代码时，获取模块42通过异常监控逻辑获取该访问请求的相关数据(即，异常数据)，该相关数据是系统的运行态数据，是按照代码的函数结构有一定结构规范的数据，包括抛出异常代码的接口，进一步可以包括接口的函数值、入参、参数结构、返回值、调用链等。获取到的异常数据可以通过异常统计和分析系统进行统计和分析，以便对该业务问题进行修复。

更进一步地，本发明实施例提供的业务问题的监控装置，还可以包括：验证模块52。该验证模块52可以用于从异常数据中解析接口的入参；根据入参，重新调用该接口；根据接口的执行结果，验证上述业务问题。

在本发明实施例中，还提供对业务问题的验证方案。获取模块42获取到的异常数据是结构化数据，可用来重新执行该问题程序，来实现对业务问题的验证。验证模块52从监控到的异常数据中解析出现业务问题的接口的入参，根据该入参，重新调用该接口。当接口未抛出异常代码时，确认上述业务问题已被修复。如果执行结果仍然抛出异常代码，则确认该业务问题未被正确修复。

本发明实施例提供的业务问题的监控装置，通过对底层代码进行修改，从底层实现对上层业务代码的监控，以获取系统抛出异常情况下的业务问题。可选择需要监控的业务代码接口进行监控，以提高监控效率。同时，对业务问题的修复进行验证，从而进一步提高系统性能。

实施例五

以上描述了业务问题的监控装置的内部功能和结构，该装置可实现为一种电子设备。图6为本发明提供的电子设备实施例的结构示意图。如图6所示，该电子设备包括存储器61和处理器62。

存储器61，用于存储程序。除上述程序之外，存储器61还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器61可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器62，与存储器61耦合，执行存储器61所存储的程序，以用于：

在加载业务代码时，调用已植入异常监控逻辑的底层代码，将异常监控逻辑添加到业务代码；运行业务代码，通过异常监控逻辑获取系统产生业务问题时生成的异常数据。

上述的具体处理操作已经在前面实施例中进行了详细说明，在此不再赘述。

进一步，如图6所示，电子设备还可以包括：通信组件63、电源组件64、音频组件65、显示器66等其它组件。图6中仅示意性给出部分组件，并不意味着电子设备只包括图6所示组件。

通信组件63被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件63经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件63还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

电源组件64，为电子设备的各种组件提供电力。电源组件64可以包括电源管理系统，一个或多个电源，及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件65被配置为输出和/或输入音频信号。例如，音频组件65包括一个麦克风(MIC)，当电子设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器61或经由通信组件63发送。在一些实施例中，音频组件65还包括一个扬声器，用于输出音频信号。

显示器66包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (11)

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

在加载业务代码时，调用已植入异常监控逻辑的底层代码，将所述异常监控逻辑添加到所述业务代码；

运行所述业务代码，通过所述异常监控逻辑获取系统产生业务问题时生成的异常数据，

其特征在于，在加载所述业务代码之前，还包括：

将所述异常监控逻辑植入到所述底层代码，

所述将所述异常监控逻辑添加到所述业务代码，包括：

根据所述底层代码中预先设置的接口参数，将所述异常监控逻辑添加到所述业务代码的指定接口。

2.根据权利要求1所述的业务问题的监控方法，其特征在于，所述将所述异常监控逻辑植入到所述底层代码，具体为：

通过字节码增强的方式，将所述异常监控逻辑植入到所述底层代码。

3.根据权利要求2所述的业务问题的监控方法，其特征在于，所述通过字节码增强的方式，将所述异常监控逻辑植入到所述底层代码，包括：

在加载所述底层代码时，通过字节码增强工具修改所述底层代码，以将所述异常监控逻辑植入到所述底层代码。

4.根据权利要求1所述的业务问题的监控方法，其特征在于，所述通过所述异常监控逻辑获取系统产生业务问题时生成的异常数据，包括：

在执行访问请求时，若系统抛出异常代码，则通过所述异常监控逻辑获取所述访问请求的相关数据，所述相关数据包括抛出所述异常代码的接口。

5.根据权利要求4所述的业务问题的监控方法，其特征在于，还包括：

从所述异常数据中解析所述接口的入参；

根据所述入参，重新调用所述接口；

根据所述接口的执行结果，验证所述业务问题。

6.根据权利要求5所述的业务问题的监控方法，其特征在于，所述根据所述接口的执行结果，验证所述业务问题，包括：

当所述接口未抛出异常代码时，确认所述业务问题已被修复。

7.一种业务问题的监控装置，包括：

添加模块，用于在加载业务代码时，调用已植入异常监控逻辑的底层代码，将所述异常监控逻辑添加到所述业务代码；

获取模块，用于运行所述业务代码，通过所述异常监控逻辑获取系统产生业务问题时生成的异常数据；

其特征在于，还包括：

植入模块，用于在加载所述业务代码之前，将所述异常监控逻辑植入到所述底层代码，

所述将所述异常监控逻辑添加到所述业务代码，包括：

根据所述底层代码中预先设置的接口参数，将所述异常监控逻辑添加到所述业务代码的指定接口。

8.根据权利要求7所述的业务问题的监控装置，其特征在于，所述植入模块还用于，在加载所述底层代码时，通过字节码增强工具修改所述底层代码，以将所述异常监控逻辑植入到所述底层代码。

9.根据权利要求7所述的业务问题的监控装置，其特征在于，所述获取模块还用于，在执行访问请求时，若系统抛出异常代码，则通过所述异常监控逻辑获取所述访问请求的相关数据，所述相关数据包括抛出所述异常代码的接口。

10.根据权利要求9所述的业务问题的监控装置，其特征在于，还包括验证模块，用于从所述异常数据中解析所述接口的入参；根据所述入参，重新调用所述接口；根据所述接口的执行结果，验证所述业务问题。

11.一种电子设备，其特征在于，包括：

存储器，用于存储程序；

处理器，用于运行所述存储器中存储的所述程序，以用于：

在加载业务代码时，调用已植入异常监控逻辑的底层代码，将所述异常监控逻辑添加到所述业务代码；

运行所述业务代码，通过所述异常监控逻辑获取系统产生业务问题时生成的异常数据，

在加载所述业务代码之前，还包括：

将所述异常监控逻辑植入到所述底层代码，

所述将所述异常监控逻辑添加到所述业务代码，包括：

根据所述底层代码中预先设置的接口参数，将所述异常监控逻辑添加到所述业务代码的指定接口。

Images