一种日志处理方法、装置、系统及存储介质与流程

1.本发明实施例涉及计算机应用技术领域，尤其涉及一种日志处理方法、装置、系统及存储介质。


背景技术：

2.在各业务系统交互频繁的应用场景中，通常需要记录各种日志信息，这些日志信息可以为后续的异常定位提供依据。
3.在实现本发明的过程中，发明人发现现有技术中存在以下技术问题：各业务系统在交互过程中出现异常时，各业务系统的系统负责人需要在各自的业务系统中进行日志查询以定位出该异常关联的业务系统，异常定位效率较低。


技术实现要素：

4.本发明实施例提供了一种日志处理方法、装置、系统及存储介质，解决了异常定位效率较低的问题。
5.第一方面，本发明实施例提供了一种日志处理方法，该方法应用于日志处理系统，日志处理系统可与多个已连接业务系统相连，日志处理系统的日志数据库中存储有各已连接业务系统的日志信息，日志信息包括业务系统来源信息，该方法可以包括：
6.在监测到异常定位的定位触发事件时，获取定位触发事件对应的查询条件，并根据查询条件在日志数据库中进行查询；
7.根据查询结果从各日志信息中筛选出与查询条件匹配的目标日志信息，并将目标日志信息进行显示。
8.第二方面，本发明实施例还提供了一种日志处理装置，该装置配置于日志处理系统，日志处理系统与多个已连接业务系统相连，日志处理系统的日志数据库中存储有各已连接业务系统的日志信息，日志信息包括业务系统来源信息，该装置可以包括：
9.日志查询模块，用于在监测到异常定位的定位触发事件时，获取定位触发事件对应的查询条件，并根据查询条件在日志数据库中进行查询；
10.日志显示模块，用于根据查询结果从各日志信息中筛选出与查询条件匹配的目标日志信息，并将目标日志信息进行显示。
11.第三方面，本发明实施例还提供了一种日志处理系统，可以包括：
12.一个或多个处理器；
13.存储器，用于存储一个或多个程序；
14.当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现本发明任意实施例所提供的日志处理方法。
15.第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本发明任意实施例所提供的日志处理方法。
16.本发明实施例的技术方案，日志处理系统在获取到与异常定位相关的查询条件
时，可以根据该查询条件在日志数据库中进行查询，该日志数据库是日志处理系统中的数据库；由于各已连接业务系统的日志信息均存储于日志数据库，即日志数据库中的日志信息来源于各个已连接业务系统，则根据查询结果从各日志信息中筛选出的与查询条件匹配的目标日志信息也可来源于各已连接业务系统，且考虑到目标日志信息中包括业务系统来源信息，在对目标日志信息进行显示之后，用户根据显示出来的目标日志信息即可定位出存在异常的已连接业务系统。上述技术方案，通过日志处理系统提供的唯一入口来查询出与查询条件有关的目标日志信息，以便用户根据该目标日志信息中的业务系统来源信息定位出存在异常的已连接业务系统，由此实现了存在异常的已连接业务系统的快速定位的效果。
附图说明
17.图1是本发明实施例一中的一种日志处理方法的流程图；
18.图2是本发明实施例一中的一种日志处理方法中目标日志信息的示意图；
19.图3是本发明实施例一中的一种日志处理方法中的查询结果的示意图；
20.图4是本发明实施例二中的一种日志处理方法的流程图；
21.图5是本发明实施例二中的一种日志处理方法中的数据流的示意图；
22.图6是本发明实施例三中的一种日志处理方法的流程图；
23.图7是本发明实施例四中的一种日志处理装置的结构框图；
24.图8是本发明实施例五中的一种日志处理系统的结构示意图。
具体实施方式
25.下面结合附图和实施例对本发明作进一步详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
26.在介绍本发明实施例之前，先对本发明实施例的应用场景进行示例性说明：现有技术中，若想从相互交互的各业务系统中定位出存在异常的业务系统，各业务系统的系统负责人需要基于与该异常相关的查询条件在各自的业务系统的日志信息中进行查询，如在订单系统的日志信息中基于订单单号进行查询、在配送系统的日志信息中基于配送单号进行查询等等；进而，系统负责人可根据查询结果确定出自己负责的业务系统中是否存在异常。需要说明的是，即使同一查询条件在至少两个业务系统中均适用，比如同一订单单号在至少两个业务系统中均适用，这也需要根据该同一查询条件在至少两个业务系统中分别进行查询，显然，这样的异常定位效率比较低。另外，上述业务系统可以是实现某业务功能的系统，如订单系统、配送系统等；上述系统负责人可以是业务系统的运维人员、开发人员、测试人员等等；上述订单单号、配送单号可以是业务单号的一种，即业务单号在不同的业务系统中可以具有不同的含义。
27.相应的，本发明实施例提出的日志处理方法可以应用于日志处理系统，该日志处理系统与多个已连接业务系统通讯连接，该已连接业务系统可以是与日志处理系统相连接的用于实现某种业务功能的业务系统，该日志处理系统包括日志数据库，各已连接业务系统的日志信息均存储于日志数据库中。这样一来，用户仅需要根据查询条件在日志处理系
统中进行查询即可，具体来说是在日志数据库的各日志信息中进行查询即可，这样可以从中查询出与该查询条件匹配的目标日志信息，该目标日志信息可以来源于各已连接业务系统，该用户可以是日志处理系统的运营人员、开发人员、测试人员等等。需要说明的是，每条日志信息均包括业务系统来源信息，该业务系统来源信息可以表明该日志信息来源于哪个已连接业务系统。由此，用户在从各目标日志信息中筛选出存在异常的目标日志信息之后，可以根据该存在异常的目标日志信息中的业务系统来源信息直接定位出存在异常的已连接业务系统。换言之，在异常定位时，用户无需逐个联系各已连接业务系统的系统负责人在各已连接业务系统中分别进行查询，用户通过日志处理系统这唯一入口即可以查询出存在异常的已连接业务系统，由此提高了异常定位效率。
28.实施例一
29.图1是本发明实施例一中提供的一种日志处理方法的流程图。本实施例可适用于将日志处理系统作为唯一入口来查询出与查询条件匹配的目标日志信息的情况。该方法可以由本发明实施例提供的日志处理装置来执行，该装置可以由软件和/或硬件的方式实现，该装置可以集成在日志处理系统上。
30.参见图1，本发明实施例的方法具体包括如下步骤：
31.s110、在监测到异常定位的定位触发事件时，获取定位触发事件对应的查询条件，并根据查询条件在日志数据库中进行查询。
32.其中，定位触发事件可以是用户触发的用于进行异常定位的事件，该异常可以是用户和/或客户发现的异常，该客户可以是已连接业务系统的使用者，如物流系统的寄货方、订单系统的购买方等等。示例性，日志处理系统在获取到用户通过前端页面输入的查询条件时，即为监测到异常定位的定位触发事件，该前端页面可以是用于输入查询条件的页面。
33.进一步，获取定位触发事件对应的查询条件，该查询条件可以是与该异常有关的关键词，如时间段、业务单号等等，该业务单号可以是订单单号、配送单号等等。由此，由于日志处理系统的日志数据库中存储有与其相连的各已连接业务系统的日志信息，那么，根据该查询条件可以在日志数据库中进行查询。
34.s120、根据查询结果从各日志信息中筛选出与查询条件匹配的目标日志信息，并将目标日志信息进行显示。
35.其中，在根据查询条件于日志数据库中进行查询时，可以从各日志信息中筛选出与该查询条件匹配的目标日志信息，该目标日志信息可以是与异常直接关联的日志信息，这样的日志信息中可以包含异常信息，该异常信息可以显示出异常的具体情况；或者，该目标日志信息可以是与异常间接关联的日志信息，如某业务链上包括多个业务环节，该目标日志信息可以是出现异常的业务链上的日志信息，但其并非是该业务链上的出现异常的环节上的日志信息，这样的日志信息并未包含异常信息；等等。进一步，对目标日志信息进行显示，由于每条目标日志信息包括业务系统来源信息，这意味着用户根据显示出来的目标日志信息中的业务系统来源信息可以确定出该条目标日志信息来源于哪个已连接业务系统，这可根据各目标日志信息快速定位出存在异常的已连接业务系统。
36.在此基础上，可选的，有些目标日志信息包括异常信息、且有些目标日志信息未包括异常信息，比如，以下单业务链中的预分拣校验、客户信息校验、揽派站点信息校验和面
单库存校验这四个环节为例，假设预分拣校验的接口被请求调用，该接口的返回结果正常，即本次请求调用过程对应的日志信息中未包含异常信息；客户信息校验的接口被请求调用，该接口的返回结果异常，即本次请求调用过程对应的日志信息中包含异常信息，如错误堆栈信息。那么，在对目标日志信息进行显示时，可基于不同的显示效果对包括异常信息的目标日志信息和未包括异常信息的目标日志信息进行区分，如包括异常信息的目标日志信息以红色底色标记且未包括异常信息的目标日志信息以绿色底色标记，这样有助于用户从大量的目标日志信息中快速定位出存在异常信息的目标日志信息，进而根据该存在异常信息的目标日志信息中的业务系统来源信息快速定位出存在异常的已连接业务系统。再可选的，每条目标日志信息中还可包括业务系统联系人，该业务系统联系人可以是与业务系统来源信息对应的已连接业务系统的系统负责人。由此，用户在定位出存在异常的已连接业务系统之后，可以通知该已连接业务系统的业务系统联系人对该已连接业务系统进行相应调整优化等等。示例性的，目标日志信息的显示效果如图2所示，包含异常信息的目标日志信息以灰色底色标记。
37.本发明实施例的技术方案，日志处理系统在获取到与异常定位相关的查询条件时，可以根据该查询条件在日志数据库中进行查询，该日志数据库是日志处理系统中的数据库；由于各已连接业务系统的日志信息均存储于日志数据库，即日志数据库中的日志信息来源于各个已连接业务系统，则根据查询结果从各日志信息中筛选出的与查询条件匹配的目标日志信息也可来源于各已连接业务系统，且考虑到目标日志信息中包括业务系统来源信息，在对目标日志信息进行显示之后，用户根据显示出来的目标日志信息即可定位出存在异常的已连接业务系统。上述技术方案，通过日志处理系统提供的唯一入口来查询出与查询条件有关的目标日志信息，以便用户根据该目标日志信息中的业务系统来源信息定位出存在异常的已连接业务系统，由此实现了存在异常的已连接业务系统的快速定位的效果。
38.在此基础上，一种可选的技术方案，目标日志信息的数量是至少两个，将目标日志信息进行显示，具体可以包括：获取各目标日志信息关联的请求单号，其中，请求单号是已连接业务系统中的接口被请求调用时生成的单号；根据请求单号对各目标日志信息进行分组显示。其中，接口是可以实现一定功能的接口，该接口也可以理解为服务、方法、函数等等。在接口被请求调用时，相应的请求单号将会生成，该请求单号主要用来将本次的接口请求调用的链路串联起来，示例性的，该请求单号的格式可以是时间字符串+多位随机数。因此，在对至少两个目标日志信息进行显示时，可以获取各目标日志信息关联的请求单号，并将与同一请求单号关联的目标日志信息作为一组进行显示。
39.需要说明的是，一个接口被请求调用时会生成一个请求单号，但是该接口可能会包括多个子接口，该接口的请求调用意味着其内部的多个子接口会依次被调用，这些子接口的调用过程不会再生成新的请求单号，这也正是上文所述一个请求单号可以将本次的接口请求调用的链路串联起来的意义。但是，这些子接口的调用过程依然会产生日志信息，这意味着与同一请求单号关联的目标日志信息的数量可能是一个、两个或是多个。
40.为了更好地理解上述步骤的具体实现过程，下面结合具体示例，对本实施例的日志处理方法进行示例性的说明。示例性的，如图3所示，日志处理系统中的查询机的前端页面提供业务单号或是请求单号的输入框，其可以通过下拉菜单进行选择，在此以某个下单
业务的业务单号为例，当获取到用户在输入框中输入的业务单号之后，根据该业务单号在hbase集群中进行查询，该hbase集群是由多个hbase构成的集群，其中存储有各已连接业务系统的日志信息。进而，根据查询结果可以确定与该下单业务中有关的目标日志信息，该目标日志信息可以来源于不同的已连接业务系统。需要说明的是，一个业务单号下可能涉及到多个请求单号，如下单业务和修改业务在一个业务单号下分别对应两个请求单号，因此，可以将隶属于同一请求单号下的各目标日志信息在同一页签下进行显示，以便将本次请求调用的完整链路展现出来。当然，一条业务链上的某个环节中可能涉及到一个、两个、或是多个接口被请求调用，即某环节中的日志信息可关联一个、两个、或是多个请求单号，在此未做具体限定。
41.实施例二
42.图4是本发明实施例二中提供的一种日志处理方法的流程图。本实施例以上述各技术方案为基础进行优化。在本实施例中，可选的，日志处理系统可以包括信息发送客户端，已连接业务系统可以通过如下步骤将日志信息存储于日志数据库中：在监测到接口调用的调用触发事件时，获取调用触发事件对应的日志信息，并将日志信息存储于上下文中；在接口调用结束时，将上下文中的日志信息发送至信息发送客户端，以通过信息发送客户端将日志信息存储至日志数据库中，删除上下文中的日志信息；其中，日志信息可以包括参数信息、或是参数信息和异常信息，参数信息包括入参参数和出参参数。其中，与上述各实施例相同或相应的术语的解释在此不再赘述。
43.参见图4，本实施例的方法具体可以包括如下步骤：
44.s210、在监测到接口调用的调用触发事件时，获取调用触发事件对应的日志信息，并将日志信息存储于上下文中，其中，日志信息包括参数信息、或是参数信息和异常信息，参数信息包括入参参数和出参参数。
45.其中，调用触发事件可以是某已连接业务系统中的某个接口被调用时触发的事件，如与下单业务相关的已连接业务系统在监测到下单按钮被点击后，其可以调用预分拣校验的接口，此时，该已连接业务系统可以监测到接口调用的调用触发事件。进一步，接口调用时，已连接业务系统可以获取到该接口的调用过程中生成的日志信息，将该日志信息存储在上下文中。需要说明的是，接口调用过程中可涉及到入参参数和出参参数，这些参数信息是日志信息的一部分。另外，在接口调用出现异常时，还可能出现异常信息，该异常信息也可以是日志信息中的一部分。
46.s220、在接口调用结束时，将上下文中的日志信息发送至信息发送客户端，以通过信息发送客户端将日志信息存储至日志数据库中，删除上下文中的日志信息。
47.其中，在接口调用结束时，与本次接口调用有关的全部日志信息均已存储至上下文中，此时可以将上下文中存储的日志信息发送至信息发送客户端，以通过信息发送客户端将该日志信息存储至日志数据库中，在日志信息发送出去之后可以删除上下文中的日志信息。
48.在实际应用中，针对上述经由已连接业务系统执行的日志写入逻辑，示例性的，日志处理系统可以将与日志写入相关的处理逻辑封装为jar包，以使已连接业务系统通过引入该jar包来执行相应的日志写入功能，该日志写入功能可以通过注解、api调用等等方式来实现，二者的具体实现逻辑基本一致。以注解方式为例，已连接业务系统在监测到调用触
发事件时，可以基于切面技术获取到相应的入参参数和出参参数，当然，在存在调用异常时还可以获取到异常信息，通过threadlocal技术将这些信息保存在上下文中，它们均是日志信息中的一部分。需要说明的是，某个接口可以基于其内部的多个子接口的依次调用来实现相应功能，这些子接口的调用过程的入参参数、出参参数、异常信息等等信息也会存储到上下文中，它们可以通过堆栈方式进行存储。此时，在接口调用结束后，堆栈中的信息将会一层一层地依次返回，这些返回出去的信息可以经由mq客户端发送至一个消费端，再经由该消费端将它们消费到hbase集群中。当然，在信息发送出去之后，可以删除上下文中的信息。
49.s230、在监测到异常定位的定位触发事件时，获取定位触发事件对应的查询条件，并根据查询条件在日志数据库中进行查询。
50.s240、根据查询结果从各日志信息中筛选出与查询条件匹配的目标日志信息，并将目标日志信息进行显示。
51.在此基础上，示例性的，如图5所示，各已连接业务系统(如星辰系统、众邮订单系统和订单中台系统)的日志信息可以通过mq集群发送至hbase集群中，查询机可以在该hbase集群中查询到与查询条件匹配的目标日志信息。
52.本发明实施例的技术方案，已连接业务系统在监测到接口调用的调用触发事件时可以将与调用触发事件对应的日志信息存储于上下文中；在接口调用结束时可以将上下文中存储的日志信息发送至信息发送客户端，以通过信息发送客户端将日志信息存储至日志数据库中，且日志信息发送后删除上下文中的日志信息，由此实现了将已连接业务系统中的日志信息写入日志处理系统的效果。
53.一种可选的技术方案，在实际应用中，在基于注解方式实现上述日志写入功能时，可能会遇到因为已连接业务系统的异常而致使某些参数被吞没掉的情况，如该显示的异常提示未显示、该输出的出参参数未输出等等，这些参数可以称为异常参数，此时，注解方式中的注解无法获取到该异常参数。因此，上述日志处理方法，还可包括：在监测到参数异常的异常触发事件时，获取异常触发事件对应的异常参数和参数设置接口，调用参数设置接口设置异常参数；确定异常参数对应的异常信息，将异常参数和异常信息存储于上下文中。即，通过设置于接口内部的参数设置接口来对上下文中的日志信息进行操作，由此重新获取或是重新设置那些被吞没的异常参数，进而将该异常参数对应的异常信息和该异常参数存储于上下文中，可选的，该参数设置接口可以是api接口。
54.实施例三
55.图6是本发明实施例三中提供的一种日志处理方法的流程图。本实施例以上述各技术方案为基础进行优化。在本实施例中，可选的，上述日志处理方法，还可以包括：在监测到业务系统连接的连接触发事件时，获取该连接触发事件对应的待连接业务系统的待连接日志类型，其中，待连接日志类型可包括业务类型、操作类型以及业务系统来源信息；若待连接日志类型和已连接业务系统的已连接日志类型不一致，则允许待连接业务系统连接至日志处理系统。其中，与上述各实施例相同或相应的术语的解释在此不再赘述。
56.参见图6，本实施例的方法具体可以包括如下步骤：
57.s310、在监测到业务系统连接的连接触发事件时，获取连接触发事件对应的待连接业务系统的待连接日志类型，其中，待连接日志类型包括业务类型、操作类型以及业务系
统来源信息。
58.其中，日志处理系统监测到的连接触发事件可以是用户通过前端页面输入用于连接的待连接日志类型之后触发的事件，该待连接日志类型包括用户根据实际情况进行设定的待连接业务系统的日志信息的类型，该待连接业务系统是还未连接到日志处理系统上的业务系统。因此，在监测到业务系统连接的连接触发事件时，可以获取到该连接触发事件对应的待连接业务系统的待连接日志类型，该待连接日志类型可包括业务类型、操作类型和业务系统来源信息，也可以包括业务系统联系人等等，在此未做具体限定。换言之，待连接业务系统在连接到日志处理系统之前，用户可以先为其到日志处理系统中申请配置其所需要的待连接日志类型。如待连接业务系统是订单系统，其业务系统来源信息可以是订单系统，业务类型可以是下单业务，操作类型可以是下单业务中的一个环节，如预分拣校验、客户信息校验、揽派站点信息校验、面单库存校验等。
59.s320、若待连接日志类型和已连接业务系统的已连接日志类型不一致，则允许待连接业务系统连接至日志处理系统中。
60.其中，已连接日志类型可以是已连接至日志处理系统中的已连接业务系统的日志信息的类型，类似于待连接日志类型，该已连接日志类型可以包括业务类型、操作类型以及业务系统来源信息，也可以包括业务系统联系人等，在此未做具体限定。每个已连接业务系统的已连接日志类型具有唯一性，因此可以将待连接日志类型与各已连接日志类型进行比较，若待连接日志类型未与各已连接日志类型冲突，则日志处理系统可以允许该待连接业务系统连接至该日志处理系统上，此时可以将待连接业务系统的待连接日志类型返回给待连接业务系统。当然，在存在冲突时可返回相应的提示信息以提示用户对待连接业务系统的待连接日志类型进行修改，以使待连接业务系统成功连接至日志处理系统。
61.s330、在监测到异常定位的定位触发事件时，获取定位触发事件对应的查询条件，并根据查询条件在日志数据库中进行查询。
62.s340、根据查询结果从各日志信息中筛选出与查询条件匹配的目标日志信息，并将目标日志信息进行显示。
63.其中，由于各已连接日志类型具有唯一性，该已连接日志类型也可以体现在已连接业务系统的日志信息中，由此在根据查询条件匹配出的目标日志信息中可以包含有业务系统来源信息、业务类型和操作类型，这有助于用户从目标日志信息中获知其隶属于哪个已连接业务系统下的哪个业务类型下的哪个操作类型，由此提高了后续的异常定位的效率。特别地，已连接日志类型的设置，实现了按照业务系统来源信息、业务类型以及操作类型的多维度下的分布式场景下的日志信息的有效统一的效果。
64.本发明实施例的技术方案，日志处理系统通过将连接触发事件对应的待连接业务系统的待连接日志类型和已连接业务系统的已连接日志类型进行比较，在二者未存在冲突的情况下，允许待连接业务系统连接至该日志处理系统上，由此实现了待连接业务系统与日志处理系统的有效连接的效果。
65.一种可选的技术方案，在监测到生命周期配置的配置触发事件时，将配置触发事件对应的各已连接日志类型作为一个生命周期；相应的，将目标日志信息进行显示，具体可包括：从各生命周期中确定出目标日志信息关联的目标生命周期；若存在隶属于目标生命周期内且未包含于目标日志信息的各已连接日志类型内的缺失类型，则显示目标日志信息
以及缺失类型。
66.其中，配置触发事件可以是用户在前端页面输入用于配置的已连接日志类型之后触发的事件，用户在前端业页面输入的已连接日志类型的数量可以是一个、两个或是多个，即可以将至少一个已连接日志类型作为一个生命周期。如假设用户输入的已连接日志类型包括订单系统、下单业务和预分拣校验，订单系统、下单业务和客户信息校验，订单系统、下单业务和揽派站点信息，以及订单系统、下单业务和面单库存校验，这意味着下单业务中的四个环节可以作为一个生命周期。
67.在此基础上，可以从已配置的各生命周期中确定出与目标日志信息关联的目标生命周期，具体的，因已连接至日志处理系统的各已连接业务系统的已连接日志类型具有唯一性，该已连接日志类型可以包含在已连接业务系统的日志信息中，即，目标日志信息中包含有已连接日志类型，在此基础上，由于生命周期是根据已连接日志类型配置得到，因此，根据目标日志信息中包含的已连接日志类型和各生命周期相应的已连接日志类型，可以从各生命周期中确定出与目标日志信息关联的目标生命周期。例如，各条目标日志信息的已连接日志类型包括日志类型1、日志类型3和日志类型4，某生命周期是根据日志类型1、日志类型2、日志类型3和日志类型4配置得到，这意味着该生命周期是与各目标日志信息关联的目标生命周期。
68.进一步，将目标生命周期内的各已连接日志类型和各目标日志信息包含的各已连接日志类型进行比较，若某已连接日志类型隶属于目标生命周期内且未包含于目标日志信息的各已连接日志类型内，这样的已连接日志类型可以称为缺失类型，显示目标日志信息以及缺失类型。示例性，上述例子中的日志类型2就是缺失类型。为了更好地理解生命周期的应用效果，以上述下单业务中的4个环节为例，如图3所示，若日志类型1是订单系统、下单业务和预分拣校验，日志类型2是订单系统、下单业务和客户信息校验，日志类型3是订单系统、下单业务和揽派站点信息，以及日志类型4是订单系统、下单业务和面单库存校验，在进行显示时，可将根据目标日志信息的已连接日志类型匹配出的相应的目标生命周期进行显示，且由于日志类型2是缺失类型，可以将日志类型2中的客户信息校验进行加粗显示，这有助于用户快速确认该目标生命周期内是否存在遗漏环节，即该下单业务中是否缺少一个环节，由此进一步提高了异常定位效率。
69.一种可选的技术方案，由于某个接口可能存在多个调用方，该调用方可以是某个已连接业务系统中的某个接口，例如，接口a的调用方是业务系统1中的接口b和业务系统2中的接口c，现有技术是仅对接口a的调用过程进行异常监控，这样的区分度较低，因为其无法针对具体的已连接业务系统(如业务系统1、业务系统2)和具体的接口(如接口b、接口c)对接口a的调用过程进行区分，这不利于用户后续的异常分析。
70.为解决上述问题，上述日志处理方法，还可包括：获取各已连接日志类型中的目标日志类型匹配的预设数量阈值；若在第一预设时间范围内预存储至日志数据库中的属于目标日志类型的日志信息的数量大于预设数量阈值，则发出报警信息。其中，目标日志类型可以是预设定的存在异常监控需求的日志类型，获取其对应的预设数量阈值，该预设数量阈值是预先设定的某个数值；在第一预设时间范围内预存储至日志数据库中的属于目标日志类型的日志信息的数量大于预设数量阈值时，即在第一预设时间范围内与该目标日志类型对应的接口的调用次数大于预设数量阈值时，这时可能存在调用异常情况，可以发出报警
信息。也就是说，上述方案可以理解为正常业务流程的多次操作的预警机制，当正常业务流程在多次操作时可能会对已连接业务系统构成潜在威胁，为避免该情况的发生，日志处理系统可以按照业务系统来源信息、业务类型和操作类型进行多维度的操作频率监控，并在出现异常时给予警示。示例性的，以订单状态回传的接口调用为例，当其在一分钟内回传次数大于2次时发出报警信息。
71.除此之外，在异常监控方面，日志处理系统还可以基于统计分析确定每种已连接日志类型在第二预设时间范围内的正常数量和异常数量，该第二预设时间范围可以是每天、每小时、每分钟等等。这样一来，若某种已连接日志类型对应的异常数量出现突增时，可以发出报警信息。另外，日志处理系统还可以按照业务系统来源信息、业务类型和操作类型等等不同维度进行异常展示，也可以提供不同时间维度上的异常曲线分析功能等等，在此未做具体限定。
72.实施例四
73.图7为本发明实施例四提供的日志处理装置的结构框图，该装置用于执行上述任意实施例所提供的日志处理方法。该装置与上述各实施例的日志处理方法属于同一个发明构思，在日志处理装置的实施例中未详尽描述的细节内容，可以参考上述日志处理方法的实施例。参见图7，该装置配置于日志处理系统，日志处理系统与多个已连接业务系统相连，日志处理系统的日志数据库中存储有各已连接业务系统的日志信息，日志信息包括业务系统来源信息，该装置具体可以包括：日志查询模块410和日志显示模块420。
74.其中，日志查询模块410，用于在监测到异常定位的定位触发事件时，获取定位触发事件对应的查询条件，并根据查询条件在日志数据库中进行查询；
75.日志显示模块420，用于根据查询结果从各日志信息中筛选出与查询条件匹配的目标日志信息，并将目标日志信息进行显示。
76.可选的，在此基础上，该装置还可包括：
77.日志类型获取模块，用于在监测到业务系统连接的连接触发事件时，获取连接触发事件对应的待连接业务系统的待连接日志类型，其中待连接日志类型包括业务类型、操作类型以及业务系统来源信息；
78.业务系统连接模块，用于若待连接日志类型和已连接业务系统的已连接日志类型不一致，则允许待连接业务系统连接至日志处理系统中。
79.可选的，在此基础上，该装置还可包括：
80.生命周期配置模块，用于在监测到生命周期配置的配置触发事件时，将配置触发事件对应的各已连接日志类型作为一个生命周期；
81.相应的，日志显示模块420，具体可以包括：
82.目标生命周期筛选单元，用于从各生命周期中确定出目标日志信息关联的目标生命周期；
83.缺失类型显示单元，用于若存在隶属于目标生命周期内且未包含于目标日志信息的各已连接日志类型内的缺失类型，则显示目标日志信息以及缺失类型。
84.可选的，在此基础上，该装置还可包括：
85.阈值获取模块，用于获取各已连接日志类型中目标日志类型匹配的预设数量阈值；报警模块，用于若在第一预设时间范围内预存储至日志数据库中的属于目标日志类型
的日志信息的数量大于预设数量阈值，则发出报警信息。
86.可选的，目标日志信息的数量是至少两个，在此基础上，日志显示模块420，具体可包括：
87.请求单号获取单元，用于获取各目标日志信息关联的请求单号，其中，请求单号是已连接业务系统中的接口被请求调用时生成的单号；
88.日志显示单元，用于根据请求单号对各目标日志信息进行分组显示。
89.可选的，日志处理系统包括信息发送客户端，日志信息通过如下模块存储于日志数据库中：
90.第一存储模块，用于在监测到接口调用的调用触发事件时，获取调用触发事件对应的日志信息，并将日志信息存储于上下文中，其中，日志信息包括参数信息、或是参数信息和异常信息，参数信息包括入参参数和出参参数；
91.第二存储模块，用于接口调用结束时，将上下文中的日志信息发送至信息发送客户端，以通过信息发送客户端将日志信息存储至日志数据库中，删除上下文中的日志信息。
92.可选的，在此基础上，该装置还可以包括：
93.异常设置模块，用于在监测到参数异常的异常触发事件时，获取异常触发事件对应的异常参数和参数设置接口，调用参数设置接口设置异常参数；
94.第三存储模块，用于确定异常参数对应的异常信息，并将异常参数和异常信息存储于上下文中。
95.本发明实施例四提供的日志处理装置，通过日志查询模块在获取到与异常定位相关的查询条件时，可以根据该查询条件在日志数据库中进行查询，日志数据库是日志处理系统中的数据库；由于各已连接业务系统的日志信息均存储于日志数据库中，即日志数据库中的日志信息来源于各个已连接业务系统，则日志显示模块根据查询结果从各日志信息中筛选出的与查询条件匹配的目标日志信息也可以来源于各已连接业务系统，且考虑到目标日志信息中包括业务系统来源信息，在对目标日志信息进行显示之后，用户根据显示出来的目标日志信息即可定位出存在异常的已连接业务系统。上述装置，通过日志处理系统提供的唯一入口来查询出与查询条件有关的目标日志信息，以便用户根据该目标日志信息中的业务系统来源信息定位出存在异常的已连接业务系统，由此实现了存在异常的已连接业务系统的快速定位的效果。
96.本发明实施例所提供的日志处理装置可执行本发明任意实施例所提供的日志处理方法，具备执行方法相应的功能模块和有益效果。
97.值得注意的是，上述日志处理装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。
98.实施例五
99.图8为本发明实施例五提供的一种日志处理系统的结构示意图，如图8所示，该日志处理系统包括存储器510、处理器520、输入装置530和输出装置540。日志处理系统中的处理器520的数量可以是一个或多个，图8中以一个处理器520为例；日志处理系统中的存储器510、处理器520、输入装置530和输出装置540可以通过总线或其它方式连接，图8中以通过总线550连接为例。
100.存储器510作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的日志处理方法对应的程序指令/模块(例如，日志处理装置中的日志查询模块410和日志显示模块420)。处理器520通过运行存储在存储器510中的软件程序、指令以及模块，从而执行日志处理系统的各种功能应用以及数据处理，即实现上述的日志处理方法。
101.存储器510可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据日志处理系统的使用所创建的数据等。此外，存储器510可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器510可进一步包括相对于处理器520远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
102.输入装置530可用于接收输入的数字或字符信息，以及产生与装置的用户设置以及功能控制有关的键信号输入。输出装置540可包括显示屏等显示设备。
103.实施例六
104.本发明实施例六提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种日志处理方法，该方法应用于日志处理系统，日志处理系统可与多个已连接业务系统相连，日志处理系统的日志数据库中存储有各已连接业务系统的日志信息，日志信息包括业务系统来源信息，该方法可以包括：
105.在监测到异常定位的定位触发事件时，获取定位触发事件对应的查询条件，并根据查询条件在日志数据库中进行查询；
106.根据查询结果从各日志信息中筛选出与查询条件匹配的目标日志信息，并将目标日志信息进行显示。
107.当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所提供的日志处理方法中的相关操作。
108.通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。依据这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read-only memory,rom)、随机存取存储器(random access memory,ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
109.注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。