CN111782456A - 异常检测方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及人工智能领域，通过根据异常类型对应的检测策略对应用服务层面和/或数据库层面进行异常检测，实现全方面进行异常检测，提高了异常检测的准确性。尤其涉及一种异常检测方法、装置、计算机设备和存储介质，该异常检测方法包括：获取数据调用过程中产生异常事件的异常消息，根据异常消息从硬件层面和基础组件层面进行异常检测；当硬件层面和基础组件层面不存在异常时，根据数据调用过程对应的数据调用请求确定异常事件对应的异常类型；确定异常类型对应的预设的检测策略，根据检测策略对应用服务层面和/或数据库层面进行异常检测，以确定异常事件对应的异常原因。此外，本申请还涉及区块链技术，检测策略可存储于区块链中。

Description

异常检测方法、装置、计算机设备和存储介质

技术领域

本申请涉及人工智能领域，尤其涉及一种异常检测方法、装置、计算机设备和存储介质。

背景技术

在数据调用过程中，数据管理系统需要与数据请求方、数据提供方的软硬件设备进行对接，存在跨地域、跨网络、跨系统、跨设备间协调工作。因此需要对数据管理系统和数据请求方、数据提供方的软硬件之间进行监控，监控是否出现异常以及出现异常时进行定位和排查。

在现有技术中，可以通过运维工程师进行异常检测或通过大数据监控工具Ambari进行异常检测。如果是通过运维工程师进行人工排查异常，解决时间取决于运维工程师的经验积累和对系统整体环境的熟悉度；当运维工程师定位不及时或人手不够时，则会降低用户方的使用体验度。如果基于大数据监控工具Ambari进行异常检测，虽然Ambari可以检测应用服务的运行状态，但是无法全方面地对数据调用过程产生的异常进行检测，因此无法提高异常检测的准确性。

因此如何提高数据调用过程中的异常检测的准确度成为亟需解决的问题。

发明内容

本申请提供了一种异常检测方法、装置、计算机设备和存储介质，通过在确定硬件层面和基础组件层面不存在异常后，根据异常类型对应的检测策略对应用服务层面和/或数据库层面进行异常检测，实现全方面进行异常检测，提高了异常检测的准确性。

第一方面，本申请提供了一种异常检测方法，所述方法包括：

获取数据调用过程中产生异常事件的异常消息，根据所述异常消息从硬件层面和基础组件层面进行异常检测；

当所述硬件层面和所述基础组件层面不存在异常时，根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型；

确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因。

第二方面，本申请还提供了一种异常检测装置，所述装置包括：

第一检测模块，用于获取数据调用过程中产生异常事件的异常消息，根据所述异常消息从硬件层面和基础组件层面进行异常检测；

异常类型确定模块，用于当所述硬件层面和所述基础组件层面不存在异常时，根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型；

第二检测模块，用于根据确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因。

第三方面，本申请还提供了一种计算机设备，所述计算机设备包括存储器和处理器；

所述存储器，用于存储计算机程序；

所述处理器，用于执行所述计算机程序并在执行所述计算机程序时实现如上述的异常检测方法。

第四方面，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时使所述处理器实现如上述的异常检测方法。

本申请公开了一种异常检测方法、装置、计算机设备和存储介质，通过获取数据调用过程中产生异常事件的异常消息，根据异常消息从硬件层面和基础组件层面进行异常检测，可以优先对硬件层面和基础组件层面进行异常排查，提高了异常检测的效率；当硬件层面和基础组件层面不存在异常时，根据数据调用过程对应的数据调用请求确定异常事件对应的异常类型，通过确定异常类型，可以有针对性地对不同异常类型的异常事件采取不同的检测策略；通过根据检测策略对应用服务层面和/或数据库层面进行异常检测以确定异常事件对应的异常原因，实现全方面进行异常检测，提高了异常检测的准确性。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请的实施例提供的一种异常检测方法的示意流程图；

图2是本申请的实施例提供的确定异常类型的示意性框图；

图3是本申请的实施例提供的另一种确定异常类型的示意性框图；

图4是图1中根据检测策略进行异常检测的子步骤的示意性框图；

图5是图4中根据第一检测策略对应用服务层面进行检测的子步骤的示意流程图；

图6是图4中根据第二检测策略对数据库层面进行检测的子步骤的示意流程图；

图7是图6中对数据表的数据内容进行检测的子步骤的示意流程图；

图8为本申请实施例提供的一种异常检测装置的示意性框图；

图9为本申请实施例提供的一种计算机设备的结构示意性框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

附图中所示的流程图仅是示例说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解、组合或部分合并，因此实际执行的顺序有可能根据实际情况改变。

应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

本申请的实施例提供了一种异常检测方法、装置、计算机设备和存储介质。其中，该异常检测方法可以应用于服务器或终端中的数据管理系统，实现当检测硬件层面和基础组件层面不存在异常时，根据异常类型对应的检测策略对应用服务层面和/或数据库层面进行异常检测，实现全方面进行异常检测，提高了异常检测的准确性。

其中，服务器可以为独立的服务器，也可以为服务器集群。终端可以是智能手机、平板电脑、笔记本电脑和台式电脑等电子设备。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

如图1所示，异常检测方法包括步骤S10至步骤S30。

步骤S10、获取数据调用过程中产生异常事件的异常消息，根据所述异常消息从硬件层面和基础组件层面进行异常检测。

需要说明的是，本申请实施例中的数据管理系统用于对数据请求方、数据提供方、各种异构数据库、多个业务系统以及多个服务器等软硬件设备系统进行管理。在数据调用过程时，数据管理系统存在跨地域、跨网络、跨系统、跨设备间的相互协调。其中，数据调用是指数据请求方从数据提供方中调用数据内容。

示例性的，数据请求方和数据提供方可以是数据系统或操作系统等等，比如政府部门、公司企业的数据系统。其中，数据请求方和数据提供方可以是财政局、发改委、劳动局、税务局以及教育局等部门的数据系统。例如，教育局的数据系统作为数据请求方，向税务局的数据系统发送数据调用请求。

示例性的，硬件层面包括网络环境和硬件设备。例如，数据管理系统、数据请求方以及数据提供方的网络环境和硬件设备。例如，检测数据管理系统、数据请求方以及数据提供方中的网络和各硬件设备是否出现异常。

示例性的，基础组件层面可以包括但不限于NGINX服务器、数据库、REDIS缓存、MQ消息队列、ES搜索引擎以及业务系统等等。

在一些实施例中，可以根据大数据监控工具Ambari对硬件层面和基础组件层面进行异常检测。

示例性的，通过大数据监控工具Ambari检测数据管理系统、数据请求方以及数据提供方中的服务器的网络是否正常接通；检测各硬件设备的磁盘空间是否空间不足、检测各硬件设备是否出现硬件故障等等。

示例性的，通过大数据监控工具Ambari检测数据管理系统、数据请求方以及数据提供方中的NGINX服务器、数据库、REDIS缓存、MQ消息队列以及ES搜索引擎等基础组件是否出现异常；检测各个业务系统是否正常启动、检测各个业务系统依赖的微服务是否正常工作。

通过先使用大数据监控工具Ambari从硬件层面和基础组件层面进行异常排查，可以快速、及时地发现硬件层面和基础组件层面中存在的异常，能够有效提高检测异常的效率。

步骤S20、当所述硬件层面和所述基础组件层面不存在异常时，根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型。

需要说明的是，在数据调用过程中，数据请求方需要向数据管理系统发送数据调用请求，由数据管理系统根据数据调用请求从数据提供方获取对应的目标数据内容，并将目标数据内容返回数据请求方。

在一些实施例中，根据数据调用过程对应的数据调用请求确定异常事件对应的异常类型，可以确定数据调用请求对应的请求类型，根据请求类型确定异常事件对应的异常类型。如图2所示，图2是根据数据调用请求对应的请求类型确定异常事件对应的异常类型的示意性框图。

示例性的，请求类型可以包括服务调用请求和数据表调用请求。异常类型可以包括服务调用异常和数据表调用异常。可以理解的是，服务调用请求用于调用数据提供方中的应用服务对应的数据，在服务调用过程中出现的异常归类为服务调用异常。数据表调用请求用于调用数据提供方中的数据表中的数据，在数据表调用过程中出现的异常归类为数据表调用异常。

具体地，确定数据调用请求对应的请求类型，可以包括：获取数据调用请求中的来源信息项，根据来源信息项确定数据调用请求对应的请求类型。其中，来源信息项包括应用服务或数据表。

需要说明的是，数据调用请求中的来源信息项，来源信息项用于描述数据内容的来源。示例性的，若数据调用请求中的来源信息项包括APP字段，则表示来源信息项为应用服务。可以理解的是，这里的应用服务可以包括智能手机中的APP程序、计算机中的应用程序或软件等等。示例性的，若数据调用请求中的来源信息项包括DB字段，则表示来源信息项为数据表。

其中，数据管理系统中预先存储有来源信息项与请求类型之间预设的对应关系。通过该对应关系，可以根据数据调用请求中的来源信息项，确定数据调用请求的请求类型。

示例性的，当来源信息项为应用服务时，可以确定数据调用请求对应的请求类型为服务调用请求。

示例性的，当来源信息项为数据表时，可以确定数据调用请求对应的请求类型为数据表调用请求。

在另一些实施例中，根据数据调用过程对应的数据调用请求确定异常事件对应的异常类型，可以确定数据调用请求对应的处理方式，根据处理方式确定异常事件对应的异常类型。如图3所示，图3是根据数据调用请求对应的处理方式确定异常事件对应的异常类型的示意性框图。

可以理解的是，由于数据调用请求包括服务调用请求和数据表调用请求两种请求类型，因此不同的请求类型的数据调用请求对应的处理方式不一样。

示例性的，处理方式可以包括第一处理方式和第二处理方式。其中，第一处理方式用于根据服务调用请求获取数据内容，第二处理方式用于根据数据表调用请求获取数据内容。

具体地，第一处理方式包括：确定服务调用请求对应的服务地址，以及识别服务调用请求对应的数据格式；基于区块链存储的服务地址和数据格式规范的对应关系，根据服务调用请求对应的服务地址确定服务调用请求对应的数据格式规范；若数据格式规范与服务调用请求对应的数据格式不一致，则根据数据格式规范将服务调用请求转成服务调用通知，其中，服务调用通知包括服务地址；将服务调用通知发送至数据提供方，以使数据提供方根据服务调用通知中的服务地址获取对应的应用服务中的目标数据内容，并返回目标数据内容。

具体地，第二处理方式可以包括：根据数据表调用请求中的数据查询信息生成查询语句，从预先生成的虚拟数据表中获取查询语句对应的目标数据内容。

需要说明的是，由于第一处理方式用于根据服务调用请求获取数据内容，第二处理方式用于根据数据表调用请求获取数据内容；因此，在执行第一处理方式中出现的异常归类为服务调用异常，在执行第二处理方式中出现的异常归类为数据表调用异常。数据管理系统可以在执行过程中，记录第一处理方式和第二处理方式，并存储至数据库中。

在一些实施例中，可以将处理方式与异常类型进行关联并存储在数据管理系统或区块链中。其中，第一处理方式与服务调用异常对应关联，第二处理方式与数据表调用异常对应关联。因此，在需要确定异常事件对应的异常类型时，可以基于处理方式与异常类型之间的关联关系，根据数据调用请求对应的处理方式，确定异常事件对应的异常类型。

在一些实施例中，从数据管理系统或区块链中获取处理方式与异常类型之间预设的关联关系；若数据调用请求对应记录的处理方式为第一处理方式，则可以确定异常事件对应的异常类型为服务调用异常。若数据调用请求对应记录的处理方式为第二处理方式，则可以确定异常事件对应的异常类型为数据表调用异常。

在一些实施例中，在数据调用过程中，若同一时间接收到数据请求方发送的多个数据调用请求，其中数据调用请求包括服务调用请求和数据表调用请求；则在进行异常检测时，对应的异常类型包括服务调用异常和数据表调用异常。

需要强调的是，为进一步保证上述第一处理方式和第二处理方式的私密和安全性，上述第一处理方式和第二处理方式还可以存储于一区块链的节点中。

通过获取数据请求方发送的数据调用请求，可以根据数据调用请求对应的请求类型或处理方式，确定异常事件对应的异常类型；后续可以针对不同异常类型的异常事件采用不同的检测策略进行确定异常原因。

步骤S30、确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因。

需要说明的是，在本发明实施例中，预设的检测策略包括第一检测策略和/或第二检测策略。其中，第一检测策略用于对应用层面进行检测；第二检测策略用于对数据库层面进行检测。

需要强调的是，为进一步保证上述检测策略的私密和安全性，可以将上述检测策略存储于一区块链的节点中。

请参阅图4，步骤S30中确定异常类型对应的预设的检测策略，根据检测策略对应用服务层面和/或数据库层面进行异常检测，具体可以包括以下步骤S31至步骤S33中的其中一个步骤。

步骤S31、若所述异常类型为服务调用异常，则确定所述检测策略包括第一检测策略，根据所述第一检测策略对所述应用服务层面进行检测。

步骤S32、若所述异常类型为数据表调用异常，则确定所述检测策略包括第二检测策略，根据所述第二检测策略对所述数据库层面进行检测。

步骤S33、若所述异常类型为服务调用异常和数据表调用异常，则确定所述检测策略包括第一检测策略和第二检测策略，根据所述第一检测策略对所述应用服务层面进行检测，以及根据所述第二检测策略对所述数据库层面进行检测，其中，所述第一检测策略和所述第二检测策略存储在区块链中。

可以理解的是，当异常类型为服务调用异常时，可以通过第一检测策略对应用服务层级进行检测，而不需要对数据库层面进行检测。当异常类型为数据表调用异常时，可以通过第二检测策略对数据库层级进行检测，而不需要对应用服务层面进行检测。还存在一种情况，当异常类型同时包括服务调用异常和数据表调用异常，则需要同时对应用服务层级和数据库层级进行检测。

示例性的，第一检测策略的检测步骤可以包括但不限于：对数据管理系统和注册应用服务之间的网络和网络端口进行检测，以确定数据管理系统和注册应用服务之间的网络是否通畅和网络端口是否被禁用；对数据管理系统和注册应用服务之间的服务接口进行检测，以确定服务接口是否发生变化；检测数据提供方的应用服务是否出现异常。

其中，注册应用服务是指数据提供方在数据管理系统中注册的应用服务。数据请求方可以通过服务接口，获取已注册的应用服务中的数据内容。

需要说明的是，第一检测策略的检测步骤可以依次进行；在检测过程中，当在某个检测步骤检测到异常后，可以确定异常事件对应的异常原因，剩余的检测步骤可以继续检测，也可以停止检测。

示例性的，第二检测策略的检测步骤可以包括但不限于：对数据库进行链路检测和连接信息检测，以确定数据库是否出现异常；对数据库的运行状态进行查询和对数据表中的元数据信息进行检测，以确定数据表是否出现异常；对数据表的数据内容进行对比分析，以确定数据表的数据内容是否出现异常。

其中，元数据信息可以包括数据表的字段类型、增删字段以及表名称等。

需要说明的是，第二检测策略的检测步骤可以依次进行。在某个检测步骤检测到异常后，可以确定异常事件对应的异常原因，剩余的检测步骤可以继续检测，也可以停止检测。

请参阅图5，步骤S31和S33中根据第一检测策略对应用服务层面进行检测，具体可以包括以下步骤S401至步骤S403。

步骤S401、若检测到数据管理系统和注册应用服务之间中的网络不通和/或网络端口被禁用，则确定所述异常原因为通信异常。

具体地，对数据管理系统和注册应用服务中之间的网络和网络端口进行检测，以确定数据管理系统和注册服务之间的网络是否通畅以及网络端口是否被禁用。

需要说明的是，当检测到网络断开和/或网络端口被禁用时，都可以确定异常原因为通信异常。

在一些实施例中，若检测到数据管理系统和注册应用服务之间的网络是断开的，则可以确定异常事件对应的异常原因为通信异常。

在一些实施例中，若检测到数据管理系统和注册应用服务之间的网络端口由于网络策略的调整而被禁用，则可以确定异常事件对应的异常原因为通信异常。

在一些实施例中，若检测到数据管理系统和注册应用服务之间的网络为畅通且网络接口也正常连接，则可以确定数据管理系统和注册应用服务中之间的通信为正常状态。

步骤S402、当确定通信正常时，若检测到数据管理系统和注册应用服务之间的服务接口对应的查询参数发生变化，则确定所述异常原因为服务接口异常。

具体地，可以对服务接口的查询参数进行检测，以确定服务接口的查询参数是否发生变化；若检测服务接口的查询参数发生变化，则确定异常原因为服务接口异常。

示例性的，检测服务接口的查询参数是否发生变化可以包括：获取服务接口对应的schema描述信息以及获取存储的历史schema描述信息；根据服务接口对应的schema描述信息和历史schema描述信息进行对比，以确定服务接口的查询参数是否发生变化。

其中，schema描述信息包括服务接口当前对应的查询参数；历史schema描述信息包括服务接口正常返回数据内容时的查询参数。查询参数用于从数据提供方的应用服务中查询对应的数据内容。

需要说明的是，schema是用于描述和规范XML文档的逻辑结构的一种语言，它最大的作用就是验证XML文件逻辑结构的正确性。

在一些实施方式中，可以通过XFire框架获取服务接口对应的schema描述信息。若检测到服务接口对应的schema描述信息和存储的历史schema描述信息不一致，则可以确定服务接口对应的查询参数发生变化，从而可以确定异常原因为服务接口异常。

在另一些实施方式中，若检测到服务接口对应的schema描述信息和存储的历史schema描述信息保持一致，则可以确定服务接口对应的查询参数未发生变化，从而可以确定数据管理系统和注册应用服务之间的服务接口为正常状态。

需要说明的是，XFire框架是新一代的Java Web服务引擎，构建了POJO和SOA之间的桥梁，主要特性就是支持将POJO通过简单的方式发布成Web服务，简化了Java应用转化为Web服务的步骤和过程，也直接降低了SOA的实现难度。

步骤S403、当确定服务接口为正常状态时，若根据历史查询参数重新对应用服务进行调用时出现异常，则确定所述异常原因为应用服务异常，其中，所述历史查询参数为前一次对所述应用服务调用成功的查询参数，所述历史查询参数存储在区块链中。

具体地，根据通过Java反射机制，查询区块链存储的前一次对应用服务调用成功的历史查询参数，根据历史查询参数重新对数据提供方中的应用服务进行调用；若本次服务调用不成功，则基于服务的幂等性，可以确定数据提供方中的应用服务出现异常。

需要说明的是，Java反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为Java语言的反射机制。

可以理解的是，幂等性是指根据同样的参数重复请求相同的服务，得到相同的结果。在本发明实施例中，如果根据历史查询参数重新对数据提供方中的应用服务进行调用时不成功，则说明应用服务出现异常。

在本发明实施例中，以数据请求方为住建局、数据提供方为社保局为例，根据第一检测策略对应用服务层面进行检测的过程，作详细说明。

需要说明的是，在数据调用过程中，社保局对外提供居民社保信息查询服务；住建局通过服务接口，根据居民身份证号码查询到最近社保缴纳时间、参保单位以及社保账户余额信息。若服务接口发生变化，需要通过居民社保账号信息才能查询，则数据请求方住建局根据居民身份证号码进行查询时，出现数据查询异常的异常事件。

示例性的，根据第一检测策略对应用服务层面进行检测的过程如下：

检测数据管理系统与社保局之间的网络是否通畅以及检测数据交换系统之间的网络接口是否被禁用，以及检测数据管理系统与社保局之间的网络接口是否被禁用。若检测到数据管理系统和注册应用服务之间的网络为断开或网络端口被禁用，则可以确定异常事件对应的异常原因为通信异常。

当确定数据管理系统和注册应用服务之间的通信正常时，根据XFire框架获取服务接口对应的schema描述信息和获取区块链存储的历史schema描述信息。

示例性的，查询参数可以包括但不限于居民身份证号码、居民社保账号等等。若服务接口对应的schema描述信息中的查询参数为居民社保账号，而历史schema描述信息中的查询参数为居民身份证号码，则可以确定异常事件产生的异常原因为服务接口异常。

通过根据第一检测策略对应用服务层面进行检测，可以实现对数据管理系统与注册应用服务之间的网络、网络端口、服务接口以及对数据提供方中的应用服务进行异常检测，可以快速地确定异常事件对应的异常原因。

请参阅图6，步骤S32和S33中根据第二检测策略对数据库层面进行检测，具体可以包括以下步骤S501至步骤S503。

需要说明的是，在根据数据表调用请求调用数据内容时，需要从数据提供方的数据库中获取数据表中的目标数据内容，然后将目标数据内容发送至数据请求方，并存储在数据请求方对应的数据库的数据表中。因此当异常类型为数据表调用异常时，数据请求方和数据提供方中的数据库、数据表以及数据内容都有可能导致出现异常；因此，需要对数据提供方、数据请求方各自对应的数据库、数据表以及数据内容一一进行检测，以确定异常事件对应的异常原因。

步骤S501、若检测到数据请求方和数据提供方中的数据库的链路和连接信息出现变化，则确定所述异常原因为数据库异常。

具体地，对数据库进行链路检测和连接信息检测，以确定数据库是否出现异常可以包括：对数据请求方中的数据库与数据管理系统中的数据库进行链路检测和连接信息检测，以确定数据请求方的数据库是否出现异常；对数据提供方中的数据库与数据管理系统中的数据库进行链路检测和连接信息检测，以确定数据提供方的数据库是否出现异常。

其中，可以根据链路检测协议对数据库之间进行链路检测。连接信息可以包括但不限于数据库地址、数据库用户名、数据库表前缀以及连接数据的密码等等信息。

在一些实施例中，若检测到数据请求方中的数据库与数据管理系统中的数据库之间的链路和/或连接信息出现变化，则可以确定数据请求方的数据库出现异常。

在另一些实施例中，若检测到数据提供方中的数据库与数据管理系统中的数据库之间的链路和/或连接信息出现变化，则可以确定数据提供方的数据库出现异常。

示例性的，若未检测到数据请求方中的数据库与数据管理系统中的数据库之间的链路和/或连接信息出现变化，也未检测到数据提供方中的数据库与数据管理系统中的数据库之间的链路和/或连接信息出现变化，则可以确定数据库为正常状态。

步骤S502、当确定数据库为正常状态时，若检测到所述数据请求方和所述数据提供方中的数据表的状态为异常或数据表的元数据信息不一致，则确定所述异常原因为数据表异常。

在一些实施例中，分别查询数据请求方与数据提供方中的数据表的状态，若检测到数据请求方和/或数据提供方中的数据表的状态为异常状态，则可以确定异常原因为数据表异常。

示例性的，查询数据表的状态，可以通过以下查询代码实现。也可以通过其它语言的代码实现，在此不作限制。

查询代码：SHOW TABLE STATUS FROM sites WHERE NAME＝'site'；

SHOW TABLE STATUS FROM db_name WHERE NAME＝'table_name'。

在一些实施例中，对数据库的元数据信息进行对比，以确定数据表是否出现异常。

示例性的，分别获取数据请求方中的数据表和数据提供方中的数据表各自对应的字段类型、增删字段以及表名称；然后对数据请求方与数据提供方的同一数据表对应的字段类型、增删地址以及表名称分别一一对比。

例如，若检测到数据请求方与数据提供方的同一数据表对应的字段类型不一致，则可以确定异常原因为数据表异常。

例如，若检测到数据请求方与数据提供方的同一数据表对应的增删地址不一致，则可以确定异常原因为数据表异常。

若未检测到数据请求方中的数据表和数据提供方中的数据表的状态为异常和未检测到数据请求方中的数据表和数据提供方中的数据表对应的元数据信息不一致，则可以确定数据请求方和数据提供方中的数据库为正常状态。

步骤S503、当确定数据表为正常状态时，若检测到所述数据请求方和所述数据提供方之间的数据表的数据内容不一致，则确定所述异常原因为数据内容异常。

请参阅图7，图7是步骤S503中若检测到数据请求方和数据提供方之间的数据表的数据内容不一致，则确定异常原因为数据内容异常的示意性流程图，具体可以包括以下步骤S5031至步骤S5034。

S5031、获取数据提供方发送的第一数据内容和获取数据请求方接收的第二数据内容，以及获取数据管理系统存储的第三数据内容。

需要说明的是，在数据调用过程中，数据管理系统将数据提供方中的数据表中目标数据内容发送至数据提供方时，数据管理系统可以将目标数据内容作为第三数据内容存储至数据管理系统的数据库中。

需要强调的是，为进一步保证上述第三数据内容的私密和安全性，还可以将上述第三数据内容存储于一区块链的节点中。

可以理解的是，在确定数据提供方还是数据请求方出现数据内容异常时，可以以数据管理系统或区块链存储的第三数据内容为基准；例如，将数据提供方发送的第一数据内容与第三数据内容进行对比，若第一数据内容与第三数据内容不一致，则说明数据提供方出现数据内容异常。将数据请求方接收的第二数据内容与第三数据内容进行对比，若第二数据内容与第三数据内容不一致，则说明数据请求方出现数据内容异常。

S5032、对所述第一数据内容、所述第二数据内容和所述第三数据内容分别进行编号、划分编号组以及对编号组匹配特征值，得到所述第一数据内容对应的第一特征值、所述第二数据内容对应的第二特征值以及所述第三数据内容对应的第三特征值。

需要说明的是，编号是指对数据内容中的数据记录进行编号。

具体地，对第一数据内容、第二数据内容和第三数据内容分别进行编号，得到第一数据内容、第二数据内容和第三数据内容各自对应的编号；然后，根据预设的编号值，分别对第一数据内容、第二数据内容和第三数据内容各自对应的编号进行划分，得到第一数据内容、第二数据内容和第三数据内容各自对应的编号组；最后，对第一数据内容、第二数据内容和第三数据内容各自的编号组匹配特征值，得到第一数据内容对应的第一特征值、第二数据内容对应的第二特征值以及第三数据内容对应的第三特征值。

示例性的，若第三数据内容包括50条数据记录；对第三数据内容中的数据记录进行编号，得到的1-50为编号。在本发明实施例中，预设的编号值可以是10，当然也可以是其它数值。根据预设的编号值，对第三数据内容对应的编号进行划分，例如，每10条数据记录划分为一个编号组，得到编号为1-10，11-20，21-30，31-40，41-50的五个编号组。对第三数据内容的编号组匹配特征值，例如，对第一编号组匹配特征值A，对第二编号组匹配特征值B，对第三编号组匹配特征值C，对第四编号组匹配特征值D，对第五编号组匹配特征值E。

其中，特征值A、B、C、D和E为第三数据内容对应的第一特征值。

S5033、根据所述第一特征值和所述第三特征值进行对比，若判定所述第一数据内容与所述第三数据内容不一致，则确定所述异常原因为所述数据提供方中的数据表的数据内容出现异常。

在一些实施例中，将第一特征值和第三特征值进行对比，以确定第一数据内容与第三数据内容是否一致；当确定第一数据内容与第三数据内容不一致时，可以确定异常原因为数据提供方中的数据表的数据内容出现异常。

需要说明的是，当第一数据内容与第三数据内容中的数据记录相同时，对应的特征值也是相同的；当第一数据内容与第三数据内容中的数据记录有区别时，对应的特征值也发生变化。

示例性的，以数据请求方为财政委员会、数据提供方为市委员会为例，对检测到数据请求方和数据提供方之间的数据表的数据内容是否一致，作详细说明。例如，财政委员会通过服务器获取市委员会的数据库中的2022年XX市公路基础建设项目数据表；若市委员会中的数据表中记录金额大于5000万的第一数据内容为51条数据记录，而数据管理系统或区块链中存储的第三数据内容为50条数据记录，则说明市委员会的数据表中的数据内容出现异常。原因可能是市委员会的数据表中的数据内容更新后，没有同步到财政委员会的数据库中。

示例性的，确定市委员会的数据表中的数据内容出现异常的检测过程如下：

对市委员会中的第一数据内容中的51条数据记录进行编号、划分编号组以及对编号组匹配特征值，得到第一数据内容对应的第一特征值为A、B、C、D、E和F。对数据管理系统或区块链中存储的第三数据内容中的50条数据记录进行编号、划分编号组以及对编号组匹配特征值，得到第三数据内容对应的第三特征值为A、B、C、D和E。

根据第一特征值A、B、C、D、E和F与第三特征值A、B、C、D和E进行对比，可以确定第一特征值中的特征值F与第三特征值不一样，则判定第一数据内容与第三数据内容不一致。由于特征值F对应的第51条数据记录，因此，可以确定第一数据内容比第三数据内容多了第51条数据记录。从而，可以确定异常原因为市委员会的数据表中的数据内容出现异常。

S5034、根据所述第二特征值和所述第三特征值进行对比，若判定所述第二数据内容与所述第三数据内容不一致，则确定所述异常原因为所述数据请求方中的数据表的数据内容出现异常。

示例性的，财政委员会通过服务器获取市委员会的数据库中的2022年XX市公路基础建设项目数据表；若财政委员会中的数据表中记录金额大于5000万的第二数据内容为49条数据记录和1条空值记录，而数据管理系统或区块链中存储的第三数据内容为50条数据记录，则说明财政委员会的数据表中的数据内容出现异常。原因可能是财政委员会删除了1条数据记录或者少接收1条数据记录。

示例性的，确定财政委员会的数据表中的数据内容出现异常的检测过程如下：

对财政委员会中的第二数据内容中的49条数据记录和1条空值记录进行编号、划分编号组以及对编号组匹配特征值，得到第二数据内容对应的第二特征值为A、B、C、D和E1。对数据管理系统或区块链中存储的第三数据内容中的50条数据记录进行编号、划分编号组以及对编号组匹配特征值，得到第三数据内容对应的第三特征值为A、B、C、D和E。

根据第二特征值A、B、C、D和E1与第三特征值A、B、C、D和E进行对比，可以确定第二特征值中的特征值E1与第三特征值中的特征值E不一样，则判定第二数据内容与第三数据内容不一致。由于特征值E1对应的第41-49条数据记录和1条空值记录，因此，可以确定第二数据内容中的第41-50条数据记录出现错误。从而，可以确定异常原因为财政委员会的数据表中的数据内容出现异常。

通过第二检测策略，可以对数据提供方、数据请求方各自对应的数据库、数据表以及数据内容一一进行检测，可以快速地确定数据提供方、数据请求方存在数据异常的地方，提高了对异常事件的检测效率。

在一些实施例中，在根据检测策略对应用服务层面和/或数据库层面进行异常检测，以确定异常事件对应的异常原因之后，还包括：统计应用服务层面和数据库层面出现异常事件对应的异常次数；若存在异常次数大于预设次数的应用服务或数据库，则对异常次数大于预设次数的应用服务和/或数据库添加异常标签，以当再次出现异常事件时，对带有异常标签的应用服务和/或数据库预先进行检测。

其中，预设次数可以根据实际情况设定，具体数值在此不作限定。

示例性的，若数据提供方中的应用服务A1出现异常事件对应的异常次数大于预设次数，则对该应用服务A1添加异常标签。当再次出现异常事件时，可以优先对应用服务A1进行异常检测。

示例性的，若数据请求方中的数据库B2出现异常事件对应的异常次数大于预设次数，则对该数据库B2添加异常标签。当再次出现异常事件时，可以优先对数据库B2进行异常检测。

通过对异常次数大于预设次数的应用服务或数据库添加异常标签，可以在出现异常事件时，优先对带有异常标签的应用服务或数据库进行异常检测，可以提高异常检测的处理效率。

在一些实施例中，在根据检测策略对应用服务层面和/或数据库层面进行异常检测，以确定异常事件对应的异常原因之后，还包括：将异常事件的异常原因和异常类型发送给作业人员，以使作业人员根据异常原因和异常类型对异常事件进行修复。

具体地，在确定异常事件对应的异常原因和异常类型之后，根据异常事件对应的异常原因和异常类型以邮件和/或短信的方式发送至作业人员；作业人员可以根据异常事件对应的异常原因和异常类型对异常事件进行修复。从而，可以减轻作业人员的工作量和缩小作业人员的排查范围，降低人力成本和沟通成本，有效提高用户的满意度。

上述实施例提供的异常检测方法，通过先使用大数据监控工具Ambari从硬件层面和基础组件层面进行异常排查，可以快速、及时地发现硬件层面和基础组件层面中存在的异常，能够有效提高检测异常的效率；通过获取数据请求方发送的数据调用请求，可以根据数据调用请求对应的请求类型或处理方式，确定异常事件对应的异常类型；后续可以针对不同异常类型的异常事件采用不同的检测策略进行确定异常原因；通过根据第一检测策略对应用服务层面进行检测，可以实现对数据管理系统与注册应用服务之间的网络、网络端口、服务接口以及对数据提供方中的应用服务进行异常检测，可以快速地确定异常事件对应的异常原因；通过第二检测策略，可以对数据提供方、数据请求方各自对应的数据库、数据表以及数据内容一一进行检测，可以快速地确定数据提供方、数据请求方存在数据异常的地方，提高了对异常事件的检测效率；从而实现全方面进行异常检测，提高了异常检测的准确性。

请参阅图8，图8是本申请的实施例还提供一种异常检测装置100的示意性框图，该异常检测装置用于执行前述的异常检测方法。其中，该异常检测装置可以配置于服务器或终端中。

如图8所示，该异常检测装置100，包括：第一检测模块101、异常类型确定模块102以及第二检测模块103。

第一检测模块101，用于获取数据调用过程中产生异常事件的异常消息，根据所述异常消息从硬件层面和基础组件层面进行异常检测。

异常类型确定模块102，用于当所述硬件层面和所述基础组件层面不存在异常时，根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型。

第二检测模块103，用于根据确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因。

需要说明的是，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和各模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

上述的装置可以实现为一种计算机程序的形式，该计算机程序可以在如图9所示的计算机设备上运行。

请参阅图9，图9是本申请实施例提供的一种计算机设备的结构示意性框图。该计算机设备可以是服务器或终端。

请参阅图9，该计算机设备包括通过系统总线连接的处理器和存储器，其中，存储器可以包括非易失性存储介质和内存储器。

处理器用于提供计算和控制能力，支撑整个计算机设备的运行。

内存储器为非易失性存储介质中的计算机程序的运行提供环境，该计算机程序被处理器执行时，可使得处理器执行任意一种异常检测方法。

应当理解的是，处理器可以是中央处理单元(Central Processing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

其中，在一个实施例中，所述处理器用于运行存储在存储器中的计算机程序，以实现如下步骤：

获取数据调用过程中产生异常事件的异常消息，根据所述异常消息从硬件层面和基础组件层面进行异常检测；当所述硬件层面和所述基础组件层面不存在异常时，根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型；确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因。

在一个实施例中，所述处理器在实现根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型时，用于实现：

确定所述数据调用请求对应的请求类型，根据所述请求类型确定所述异常事件对应的异常类型；或确定所述数据调用请求对应的处理方式，根据所述处理方式确定所述异常事件对应的异常类型；其中，所述异常类型包括服务调用异常和数据表调用异常。

在一个实施例中，所述检测策略包括第一检测策略和/或第二检测策略；所述处理器在实现确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测时，用于实现：

若所述异常类型为服务调用异常，则确定所述检测策略包括第一检测策略，根据所述第一检测策略对所述应用服务层面进行检测；或若所述异常类型为数据表调用异常，则确定所述检测策略包括第二检测策略，根据所述第二检测策略对所述数据库层面进行检测；或若所述异常类型为服务调用异常和数据表调用异常，则确定所述检测策略包括第一检测策略和第二检测策略，根据所述第一检测策略对所述应用服务层面进行检测，以及根据所述第二检测策略对所述数据库层面进行检测，其中，所述第一检测策略和所述第二检测策略存储在区块链中。

在一个实施例中，所述处理器在实现根据所述第一检测策略对所述应用服务层面进行检测时，用于实现：

若检测到数据管理系统和注册应用服务之间中的网络不通和/或网络端口被禁用，则确定所述异常原因为通信异常；当确定通信正常时，若检测到数据管理系统和注册应用服务之间的服务接口对应的查询参数发生变化，则确定所述异常原因为服务接口异常；当确定服务接口为正常状态时，若根据历史查询参数重新对应用服务进行调用时出现异常，则确定所述异常原因为应用服务异常，其中，所述历史查询参数为前一次对所述应用服务调用成功的查询参数，所述历史查询参数存储在区块链中。

在一个实施例中，所述处理器在实现根据所述第二检测策略对所述数据库层面进行检测时，用于实现：

若检测到数据请求方和数据提供方中的数据库的链路和连接信息出现变化，则确定所述异常原因为数据库异常；当确定数据库为正常状态时，若检测到所述数据请求方和所述数据提供方中的数据表的状态为异常或数据表的元数据信息不一致，则确定所述异常原因为数据表异常；当确定数据表为正常状态时，若检测到所述数据请求方和所述数据提供方之间的数据表的数据内容不一致，则确定所述异常原因为数据内容异常。

在一个实施例中，所述处理器在实现若检测到所述数据请求方和所述数据提供方之间的数据表的数据内容不一致，则确定所述异常原因为数据内容出现异常时，用于实现：

获取数据提供方发送的第一数据内容和获取数据请求方接收的第二数据内容，以及获取数据管理系统存储的第三数据内容；对所述第一数据内容、所述第二数据内容和所述第三数据内容分别进行编号、划分编号组以及对编号组匹配特征值，得到所述第一数据内容对应的第一特征值、所述第二数据内容对应的第二特征值以及所述第三数据内容对应的第三特征值；根据所述第一特征值和所述第三特征值进行对比，若判定所述第一数据内容与所述第三数据内容不一致，则确定所述异常原因为所述数据提供方中的数据表的数据内容出现异常；或根据所述第二特征值和所述第三特征值进行对比，若判定所述第二数据内容与所述第三数据内容不一致，则确定所述异常原因为所述数据请求方中的数据表的数据内容出现异常。

在一个实施例中，所述处理器在实现根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因之后，还用于实现：

统计所述应用服务层面和所述数据库层面出现异常事件对应的异常次数；若存在异常次数大于预设次数的应用服务或数据库，则对异常次数大于预设次数的所述应用服务和/或所述数据库添加异常标签，以当再次出现异常事件时，对带有异常标签的所述应用服务和/或所述数据库预先进行检测。

本申请的实施例中还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序中包括程序指令，所述处理器执行所述程序指令，实现本申请实施例提供的任一项异常检测方法。

其中，所述计算机可读存储介质可以是前述实施例所述的计算机设备的内部存储单元，例如所述计算机设备的硬盘或内存。所述计算机可读存储介质也可以是所述计算机设备的外部存储设备，例如所述计算机设备上配备的插接式硬盘，智能存储卡(SmartMedia Card，SMC)，安全数字卡(Secure Digital Card，SD Card)，闪存卡(Flash Card)等。

进一步地，所述计算机可读存储介质可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据区块链节点的使用所创建的数据等。

本申请所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种异常检测方法，其特征在于，包括：

获取数据调用过程中产生异常事件的异常消息，根据所述异常消息从硬件层面和基础组件层面进行异常检测；

当所述硬件层面和所述基础组件层面不存在异常时，根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型；

确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因。

2.根据权利要求1所述的异常检测方法，其特征在于，所述根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型，包括：

确定所述数据调用请求对应的请求类型，根据所述请求类型确定所述异常事件对应的异常类型；或

确定所述数据调用请求对应的处理方式，根据所述处理方式确定所述异常事件对应的异常类型；

其中，所述异常类型包括服务调用异常和数据表调用异常。

3.根据权利要求2所述的异常检测方法，其特征在于，所述检测策略包括第一检测策略和/或第二检测策略；所述确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，包括：

若所述异常类型为服务调用异常，则确定所述检测策略包括第一检测策略，根据所述第一检测策略对所述应用服务层面进行检测；或

若所述异常类型为数据表调用异常，则确定所述检测策略包括第二检测策略，根据所述第二检测策略对所述数据库层面进行检测；或

若所述异常类型为服务调用异常和数据表调用异常，则确定所述检测策略包括第一检测策略和第二检测策略，根据所述第一检测策略对所述应用服务层面进行检测，以及根据所述第二检测策略对所述数据库层面进行检测，其中，所述第一检测策略和所述第二检测策略存储在区块链中。

4.根据权利要求3所述的异常检测方法，其特征在于，所述根据所述第一检测策略对所述应用服务层面进行检测，包括：

若检测到数据管理系统和注册应用服务之间中的网络不通和/或网络端口被禁用，则确定所述异常原因为通信异常；

当确定通信正常时，若检测到数据管理系统和注册应用服务之间的服务接口对应的查询参数发生变化，则确定所述异常原因为服务接口异常；

当确定服务接口为正常状态时，若根据历史查询参数重新对应用服务进行调用时出现异常，则确定所述异常原因为应用服务异常，其中，所述历史查询参数为前一次对所述应用服务调用成功的查询参数，所述历史查询参数存储在区块链中。

5.根据权利要求3所述的异常检测方法，其特征在于，所述根据所述第二检测策略对所述数据库层面进行检测，包括：

若检测到数据请求方和数据提供方中的数据库的链路和连接信息出现变化，则确定所述异常原因为数据库异常；

当确定数据库为正常状态时，若检测到所述数据请求方和所述数据提供方中的数据表的状态为异常或数据表的元数据信息不一致，则确定所述异常原因为数据表异常；

当确定数据表为正常状态时，若检测到所述数据请求方和所述数据提供方之间的数据表的数据内容不一致，则确定所述异常原因为数据内容异常。

6.根据权利要求5所述的异常检测方法，其特征在于，所述若检测到所述数据请求方和所述数据提供方之间的数据表的数据内容不一致，则确定所述异常原因为数据内容出现异常，包括：

获取数据提供方发送的第一数据内容和获取数据请求方接收的第二数据内容，以及获取数据管理系统存储的第三数据内容；

对所述第一数据内容、所述第二数据内容和所述第三数据内容分别进行编号、划分编号组以及对编号组匹配特征值，得到所述第一数据内容对应的第一特征值、所述第二数据内容对应的第二特征值以及所述第三数据内容对应的第三特征值；

根据所述第一特征值和所述第三特征值进行对比，若判定所述第一数据内容与所述第三数据内容不一致，则确定所述异常原因为所述数据提供方中的数据表的数据内容出现异常；或

根据所述第二特征值和所述第三特征值进行对比，若判定所述第二数据内容与所述第三数据内容不一致，则确定所述异常原因为所述数据请求方中的数据表的数据内容出现异常。

7.根据权利要求1-6中任一项所述的异常检测方法，其特征在于，所述根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因之后，还包括：

统计所述应用服务层面和所述数据库层面出现异常事件对应的异常次数；

若存在异常次数大于预设次数的应用服务或数据库，则对异常次数大于预设次数的所述应用服务和/或所述数据库添加异常标签，以当再次出现异常事件时，对带有异常标签的所述应用服务和/或所述数据库预先进行检测。

8.一种异常检测装置，其特征在于，包括：

第一检测模块，用于获取数据调用过程中产生异常事件的异常消息，根据所述异常消息从硬件层面和基础组件层面进行异常检测；

异常类型确定模块，用于当所述硬件层面和所述基础组件层面不存在异常时，根据所述数据调用过程对应的数据调用请求确定所述异常事件对应的异常类型；

第二检测模块，用于根据确定所述异常类型对应的预设的检测策略，根据所述检测策略对应用服务层面和/或数据库层面进行异常检测，以确定所述异常事件对应的异常原因。

9.一种计算机设备，其特征在于，所述计算机设备包括存储器和处理器；

所述存储器，用于存储计算机程序；

所述处理器，用于执行所述计算机程序并在执行所述计算机程序时实现如权利要求1至7任一项所述的异常检测方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时使所述处理器实现如权利要求1至7任一项所述的异常检测方法。

Images