CN113961611A - 日志的处理方法、装置、设备以及存储介质 - Google Patents

Abstract

本申请提供一种日志的处理方法、装置、设备以及存储介质。该方法包括：获取用户的查询请求，根据查询请求，在从n个业务系统中获取到的日志中确定目标日志，n为大于1的正整数，该查询请求包括请求标识ID或者查询词，该请求ID为获取n个业务系统的日志时n个业务系统中的第一业务系统生成的，查询词包括关键词和/或正则表达式，并推送该目标日志。实现了从多个软件系统的日志中获取所需监控的或者待分析的日志，为针对多个业务系统的日志进行监控或者分析，实现准确识别异常提供了可能。

Description

日志的处理方法、装置、设备以及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种日志的处理方法、装置、设备以及存储介质。

背景技术

在计算机技术领域，日志作为对运行于计算机中的软件系统的运行数据的记录，常用于监控或者分析软件的运行状态。例如，当软件系统的运行存在异常时，可以基于该软件的日志进行异常分析。

目前，因各软件系统的日志相互隔离，在对多个相关的软件系统进行异常分析时，无法获取该多个软件系统的日志，进而无法基于多个软件系统的日志进行异常分析，逐一对每个软件系统基于各自的日志进行异常分析，导致处理效率较低，甚至无法准确识别异常。因而，如何基于多个业务系统的日志查询所需监控的或者待分析的日志，是当前亟待解决的问题。

发明内容

本申请提供一种日志的处理方法、装置、设备以及存储介质，能够从多个软件系统的日志中获取所需监控的或者待分析的日志，进而实现对多个软件系统的日志的监控，并为基于多个软件系统的日志联合进行异常分析提供了可能。

第一方面，本申请实施例提供一种日志的处理方法，所述方法包括：获取用户的查询请求；根据所述查询请求，在从n个业务系统中获取到的日志中确定目标日志，n为大于1的正整数，所述查询请求包括请求标识ID或者查询词，所述请求ID为获取所述n个业务系统的日志时所述n个业务系统中的第一业务系统生成的，所述查询词包括关键词和/或正则表达式；推送所述目标日志。

在一种可能的实现方式中，在所述查询请求包括请求标识ID时，所述根据所述查询请求，在所述n个业务系统的日志中确定目标日志，包括：根据所述请求ID，确定所述目标日志为所述n个业务系统的日志。

在一种可能的实现方式中，所述查询请求包括关键词和/或正则表达式，所述根据所述查询请求，在所述n个业务系统的日志中确定目标日志，包括：根据所述关键词和/或正则表达式，在所述n个业务系统的日志中确定与所述关键词和/或正则表达式对应的目标日志。

在一种可能的实现方式中，所述方法还包括：接收所述n个业务系统发送的多个第一日志，所述第一日志包括请求ID、业务ID和日志内容，所述请求ID为获取所述n个业务系统的日志时所述n个业务系统中的第一业务系统生成的，所述业务ID为日志内容对应的业务流程标识；根据所述至少一个第一日志中每个第一日志的请求ID和接收时间，对所述至少一个第一日志进行筛选，得到所述n个业务系统的日志。

在一种可能的实现方式中，所述接收所述n个业务系统发送的至少一个第一日志，包括：通过生产者与消费者模型将所述n个业务系统发送的多个第一日志按照第一排序规则进行存储，所述第一排序规则为预设的或者用户指令指示的。

在一种可能的实现方式中，所述接收所述n个业务系统发送的多个第一日志，包括：通过生产者与消费者模型中的生产者线程，将所述n个业务系统发送的多个第一日志划分至所述业务系统对应的日志队列；通过所述生产者与消费者模型中的消费者线程，从内存空间中读取所述多个第一日志各自的偏移量，并根据所述第一日志各自的偏移量从所述n个业务系统分别对应的日志队列中，提取所述多个第一日志。

在一种可能的实现方式中，所述方法还包括：删除所述n个业务系统的日志中生成时长超过第一时长的日志，所述第一时长为预设时长或者为基于所述n个业务系统的每秒查询率QPS确定的。

第二方面，本申请实施例提供一种日志的处理方法，所述方法包括：第一业务系统生成请求ID，所述请求ID用于请求获取所述第一业务系统和至少一个第二业务系统的日志；所述第一业务系统将所述请求ID发送给至少一个第二业务系统；所述第一业务系统根据所述请求ID，生成至少一个第一日志；所述第一业务系统将所述至少一个第一日志发送至所述日志监控系统。

第三方面，本申请实施例提供一种电子设备，包括：获取单元，用于获取用户的查询请求；处理单元，用于根据所述查询请求，在从n个业务系统中获取到的日志中确定目标日志，n为大于1的正整数，所述查询请求包括请求标识ID或者查询词，所述请求ID为获取所述n个业务系统的日志时所述n个业务系统中的第一业务系统生成的，所述查询词包括关键词和/或正则表达式；推送单元，用于推送所述目标日志。

第四方面，本申请实施例提供一种电子设备，包括存储器和处理器；所述存储器存储计算机执行指令；所述处理器执行所述存储器存储的计算机执行指令，使得所述处理器执行如第一方面以及第一方面各实现方式中的方法。

第五方面，本申请实施例提供一种电子设备，包括存储器和处理器；所述存储器存储计算机执行指令；所述处理器执行所述存储器存储的计算机执行指令，使得所述处理器执行如第二方面以及第二方面各实现方式中的方法。

第六方面，本申请实施例提供一种存储介质，包括：可读存储介质和计算机程序，所述计算机程序用于实现第一方面以及第一方面各实现方式中的方法。

第七方面，本申请实施例提供一种存储介质，包括：可读存储介质和计算机程序，所述计算机程序用于实现第二方面以及第二方面各实现方式中的方法。

本申请实施例提供的日志的处理方法、装置、设备以及存储介质，通过从多个业务系统的日志中确定所需的目标日志，为针对多个业务系统的日志进行监控或者分析，实现准确识别异常提供了可能。

附图说明

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

图1为本申请实施例提供的一种日志的处理系统100的应用场景示意图；

图2为本申请实施例提供的一种日志的处理方法200的流程示意图；

图3为本申请实施例提供的一种日志的处理方法300的交互流程示意图；

图4为本申请实施例提供的一种日志监控系统的结构示意图；

图5为本申请实施例提供的一种基于Kafka的日志监控系统的结构示意图；

图6为本申请实施例提供的一种电子设备400的结构示意图；

图7为本申请实施例提供的一种电子设备500的结构示意图；

图8为本申请实施例提供的电子设备600的结构框图。

具体实施方式

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

通过日志监控平台对业务系统的日志进行监控，有利于及时发现并解决系统问题。由于当前存在多业务系统协同的场景，例如电商平台可以由商品系统、订单系统、库存系统、售后系统等组成。每个业务系统均维护有自身的日志数据，例如每个业务系统对应一个日志监控平台，通过每个业务系统的日志监控平台监控该业务系统的日志，并进行日志分析。然而，因各业务系统的日志相互隔离，逐一对业务系统的日志进行监控以及分析，导致对日志的处理效果较低，并且逐一根据每个业务系统的日志进行异常问题分析，无法联合多业务系统的日志进行综合的分析，导致分析结果的准确性较低。因而，如何基于多个业务系统的日志查询所需监控的或者待分析的日志，是当前亟待解决的问题。

针对上述问题，本申请实施例可以从多个业务系统的日志中确定所需的目标日志，为针对多个业务系统的日志进行监控或者分析，实现准确识别异常提供了可能。

图1为本申请实施例提供的一种日志的处理系统100的应用场景示意图。日志的处理系统100可以包括日志监控系统110和n个业务系统120，n为大于1的正整数。如图1所示，在一些实施例中，日志监控系统110和每个业务系统120均部署在不同的电子设备上，该电子设备例如可以是服务器、终端设备、芯片等，其中终端设备例如可以是智能手机、笔记本电脑、平板电脑、个人台式电脑等。

可选的，日志监控系统110和n个业务系统120分别部署于一个电子设备；或者日志监控系统110和n个业务系统120部署于同一电子设备；或者日志监控系统110部署在第一电子设备，n个业务系统120部署在第二电子设备；或者日志监控系统11以部署在第一电子设备，n个业务系统中的上游业务系统部署在第二电子设备，其余业务系统部署在第三电子设备。本申请实施例不限于上述所例举的部署方式，可以将日志监控系统和n个业务系统在至少一个电子设备中进行任意组合的部署。

在一些实施例中，日志监控系统或业务系统均可以部署在多个电子设备中，通过多个电子设备协同实现系统的运行。

可选的，运行有日志监控系统的电子设备可以是搜索服务器(ElasticSearch，ES)；或者日志监控系统与ES通过有限或者无线的方式连接。

图2为本申请实施例提供的一种日志的处理方法200的流程示意图。图2所示实施例提供的方法，其执行主体可以是上述日志监控系统110，或者部署有日志监控系统110的电子设备。示例性的，如图1所示，该方法包括：

S210：获取用户的查询请求；

S220：根据查询请求，在从n个业务系统中获取到的日志中确定目标日志，n为大于1的正整数；

S230：推送目标日志。

针对S210需要说明的是：该查询请求可以是接收用户输入的、或者接收用户侧客户端发送的。

在一些实施例中，日志监控系统可以在用户侧客户端推送网络(web)可视化页面，用户可以在该web可视化页面中输入查询指令。可选的，该web可视化页面为基于ELK框架生成的。

需要说明的是，日志监控系统能够提供从n个业务系统获取的日志，以供用户查询所需的目标日志。

示例性的，日志监控系统可以预先从n个业务系统获取日志，并将其存储于自身的存储空间或者所连接的服务器的存储空间中。在用户查询日志时读取所需的目标日志。

需要说明的是，n个业务系统的日志可以是n个业务系统的全量日志(即n个业务系统的全部历史日志)或者可以是n个业务系统的增量日志(即日志监控系统当前获取日志时间与上一次获取日志时间之间的日志)。

进一步地，日志监控系统将目标日志推送给用户或者用户的客户端。例如，可以通过显示设备显示该目标日志，该显示设备可以是部署日志监控系统的电子设备自身的显示屏，或者电子设备连接的显示设备。

本申请实施例中，日志监控系统可以提供以下至少两种可能的查询模式。

模式一：日志监控系统可以将n个业务系统的日志作为目标日志向用户进行推送。

在模式一中，上述S210中获取的用户的查询指令应包括请求标识(Identitydocument，ID)。需要说明的是，该请求ID为获取n个业务系统的日志时n个业务系统中的第一业务系统生成的。该第一业务系统可以是n个业务系统中的任一业务系统，或者可以是n个业务系统中预先指定的业务系统。例如，n个业务系统为具有上下游关系的业务系统，将最上游的业务系统作为第一业务系统。可以理解的是，上游业务系统可以对下游业务系统传递指令信息或者业务数据，下游业务系统可以基于指令信息或业务数据执行对应的操作，例如在上游业务系统生成商品订单后，下游业务系统完成该商品订单的支付。

需要说明的是，n个业务系统的日志均与请求ID具有映射关系。例如以键值对的形式进行存储，即请求ID为关键字(key)每个日志内容为值(value)。

模式二：日志监控系统可以在n个业务系统的日志中确定查询请求所需查询的目标日志。

在模式二中，上述S210中获取的用户的查询指令应包括查询词，该查询词例如可以包括关键词和/或正则表达式。日志监控系统根据该关键词和/或正则表达式在n个业务系统的日志中进行匹配，得到对应的目标日志。可选的，关键词和/或正则表达式可以用于表述所需目标日志的生成时间、存储时间、业务ID、日志内容的部分或者全部字符。其中，业务ID为日志内容对应的业务流程标识，例如在业务系统执行一次商品销售流程时，生成业务ID，该业务系统执行该次商品销售流程时产生的日志均与该业务ID对应。

本申请实施例中，通过从多个业务系统的日志中确定所需的目标日志，为针对多个业务系统的日志进行监控或者分析，实现准确识别异常提供了可能。

图3为本申请实施例提供的一种日志的处理方法300的交互流程示意图。如图3所示，该方法300以日志监控系统和业务系统的交互为例对日志监控系统获取n个业务系统的日志的过程进行说明，该日志监控系统可以是上述图1中的日志监控系统110，或者部署有日志监控系统110的电子设备，该业务系统可以是上述业务系统120，或部署有业务系统的电子设备。该方法包括以下至少部分步骤：

S301：第一业务系统生成请求ID，所述请求ID用于请求获取该第一业务系统和至少一个第二业务系统的日志；

S302：第一业务系统将请求ID发送给至少一个第二业务系统；

S303：第一业务系统根据请求ID，生成至少一个第一日志；

S304：第一业务系统将至少一个第一日志发送至日志监控系统；

S305：至少一个第二业务系统中的每个第二业务系统根据该请求ID，生成所述第二业务系统对应的至少一个第一日志；

S306：至少一个第二业务系统中的每个第二业务系统将其生成的至少一个第一日志发送至日志监控系统。

与S304和S306相应的，日志监控系统接收第一业务系统和至少一个第二业务系统发送的多个第一日志，该第一日志包括请求ID、业务ID和日志内容，该请求ID为获取n个业务系统(包括第一业务系统和至少一个第二业务系统)的日志时n个业务系统中的第一业务系统生成的，业务ID为日志内容对应的业务流程标识；

S307：日志监控系统根据至少一个第一日志中每个第一日志的请求ID和接收时间，对至少一个第一日志进行筛选，得到n个业务系统的日志。

需要说明的是，本实施例对上述S302和S303的执行顺序不作限制。若S302在S303之前执行，本实施例中S303～S304与S305～S306的执行顺序不作限制。

针对上述S301需要说明的是，第一业务系统可以根据用户的日志存储操作生成请求ID，或者可以在预设的时间生成请求ID，或者可以周期性生成请求ID。

该请求ID为一种全局ID，例如可以通过通用唯一识别码(Universally UniqueIdentifier，UUID)或者雪花算法等生成该请求ID。

在上述S302中，第一业务系统将该请求(request)ID发送至至少一个第二业务系统。例如可以将请求ID发送给每个第二业务系统；或者可以将请求ID发送给第一业务系统下游的第一层业务系统，再由第一层业务系统将请求ID发送给第一层业务系统下游的第二层业务系统。示例性的，每个业务系统将该请求ID透传给其下游的业务系统，可以理解的是透传也即透明传输(pass-through)，指的是不对请求ID做任何改变，将请求ID直接由接收端传输到目标端。

在上述S303中，第一业务系统将请求ID和日志内容组合得到第一日志。例如，将请求ID作为key，将日志内容作为value，得到的键值对即为第一日志。

在一些实施例中，第一日志还包括业务ID和/或日志生成时间。业务ID和/或日志生成时间在日志生成时即存在，也可以理解为日志内容的一部分。

S305与上述S303类似，此处不再赘述。

在S304或S306中，各业务系统向日志监控系统发送第一日志，相应的，日志监控系统接收各业务系统发送的第一日志。作为一种可能的实现方式，在日志监控系统接收第一日志的过程中，为了便于对n个业务系统的日志进行监控，可以通过日志监控系统的生产者与消费者模型将n个业务系统发送的多个第一日志按照第一排序规则进行存储，该第一排序规则为预设的或者用户指令指示的。

示例性的，日志监控系统可以通过生产者与消费者模型中的生产者线程，将n个业务系统发送的多个第一日志划分至业务系统对应的日志队列；并通过生产者与消费者模型中的消费者线程，从内存空间中读取多个第一日志各自的偏移量，并根据第一日志各自的偏移量从n个业务系统分别对应的日志队列中，提取多个第一日志。

可选的，日志监控系统可以为基于Kafka消息队列的系统，Kafka是一个高性能跨语言分布式发布/订阅消息队列。

下面以Kafka消息队列为例进行说明，Kafka通过生产者线程将接收到的业务系统的第一日志放入该业务系统对应的topic，当第一日志到达Kafka的服务端(Broker)时，日志监控系统会开启多个输入/输出(Input/Output，I/O)线程进行消息(即第一日志)的消费。Kafka通过消费者线程消费消息时，会将消费者位移(也即偏移量)提交至ZooKeeper，ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务。当消费者可以从ZooKeeper中读取消费者位移，基于读取的消费者位移继续消费消息。然而消费者位移是一个更新十分频繁的变量，频繁对ZooKeeper写入消费者位移降低了ZooKeeper的性能。因此，本实施例中可以预先确定多个第一日志分别对应的偏移量，并将多个第一日志分别对应的偏移量存储在内存中，进而可以从内容中读取每个第一日志对应的偏移量来提取日志队列中的第一日志。从而避免对ZooKeeper的频繁写入操作。

在一些实施例中，由于Kafka无法保证消息的顺序性以及幂等性，因此可以将消费者线程提取的第一日志放入一个并发队列(sendQueue)中，再通过一个线程从队列中取出消息放入一个Map结构的缓存中，key为消息的时间戳(timestap)，也即日志监控系统接收消息的时间，value为一个优先队列，如果map中的key已经存在，则后者直接覆盖前者，到达去重的目的。

再通过一个worker线程按照用户定义的排序规则取出消息，将消息顺序存储到ES中。

示例性的，Kafka会将n个业务系统的日志存储在ES上。由于存储的日志的数据量较大，为了优化ES性能，本实施例做出如下优化：1)关闭不需要查询字段的来源(source)功能，不将此存储在ES中，以节省磁盘空间；

2)以多线程的方式批量写入，写入线程数一般和ES节点数量相同，在测试环境通过Kibana(Kibana是一个开源的分析与可视化平台)观察ES性能曲线以此来确定线程数；3)增加分片(segments)的刷新时间以获取最新的日志索引；4)内存分配方面，留ES系统50％的内存给搜索引擎(Lucene)做文件缓存，以支持搜索引擎承担较大的任务量，每个ES节点的内存可以为64G以上；5)采用SSD固态硬盘。

本实施例中，日志监控系统接收n个业务系统发送的多个第一日志，并对多个第一日志进行去重、排序后得到n个业务系统的日志，进而存储n个业务系统的日志，以便于用户对n个业务系统的日志进行监控，或者在n个业务系统的日志中进行目标日志的查询，或者基于n个业务系统的日志或者从n个业务系统的日志中查询的目标日志进行日志分析。

在一些实施例中，日志监控系统还可以删除n个业务系统的日志中生成时长超过第一时长的日志，该第一时长为预设时长或者为基于n个业务系统的每秒查询率QPS确定的。

第一时长例如可以为7天，例如，日志监控系统可以删除7天前的日志。

或者第一时长可以是根据n个业务系统的QPS确定的，可以理解的是，业务系统的QPS越大，表明该业务系统生成的日志越多，那么第一时长应越短。示例性的，根据n个业务系统的QPS确定第一时长例如可以是根据各业务系统对应的QPS中的最大值确定第一时长，或者根据各业务系统对应的QPS中的最小值确定第一时长，或者根据各业务系统对应的QPS的中值确定第一时长，或者根据各业务系统对应的QPS的平均值确定第一时长，等等。

图4为本申请实施例提供的一种日志监控系统的结构示意图。如图4所示。该日志监控系统包括消息发送模块、消息接收模块、消息处理模块、消息存储模块、消息查询模块和消息删除模块中的至少一种。其中，消息发送模块用于通过生产者线程接收n个业务系统发送的多个第一日志，并将多个第一日志放入日志队列；消息接收模块用于通过消费者线程提取生产者线程放入日志队列的第一日志；消息处理模块用于对提取的多个第一日志进行去重和排序；消息存储模块用于将n个业务系统的日志存储在ES中，并通过设置ES的相应参数和部件提高存储性能；消息查询模块用于根据查询指令从n个业务系统的日志中确定目标日志；消息删除模块用于自动删除n个业务系统的日志中超期的日志，以减小存储的压力并提高日志查询的速度。

图5为本申请实施例提供的一种基于Kafka的日志监控系统的结构示意图。如图5所示，Kafka中的多个生产者线程(producer)分别用于接收多个业务系统发送的第一日志，并将第一日志放入Kafka的服务端(broker)中，再由消费者线程(cosumer)进行消息消费提取broker中的第一日志。在一些实施例中，Kafka还包括Zookeeper，用于为消费者线程提供消费者位移。

如图5所示，日志监控系统还可以包括基于ELK框架生成的web可视化界面，用于接收用户的查询指令。

如图5所示，日志监控系统还可以通过日志删除线程定期对超期日志进行清理。

图6为本申请实施例提供的一种电子设备400的结构示意图，如图6所示，该电子设备400包括：

获取单元410，用于获取用户的查询请求；

处理单元420，用于根据所述查询请求，在从n个业务系统中获取到的日志中确定目标日志，n为大于1的正整数，该查询请求包括请求标识ID或者查询词，该请求ID为获取该n个业务系统的日志时该n个业务系统中的第一业务系统生成的，该查询词包括关键词和/或正则表达式；

推送单元430，用于推送所述目标日志。

本申请实施例提供的一种电子400，包括获取模块410、处理模块420和推送模块430，通过从多个业务系统的日志中确定所需的目标日志，进而实现对多个业务系统的日志进行监控或者分析，相对于现有技术进行逐一对每个业务系统进行日志监控和分析，提高了处理效率；并且，基于多个业务系统的日志进行异常问题分析，提高了分析结果的准确性。

在一种可能的设计中，处理模块420具体用于根据所述请求ID，确定所述目标日志为所述n个业务系统的日志，所述查询请求包括请求ID。

在一种可能的设计中，处理模块420具体用于根据所述关键词和/或正则表达式，在所述n个业务系统的日志中确定与所述关键词和/或正则表达式对应的目标日志。

在一种可能的设计中，电子设备400还包括接收单元440，用于接收所述n个业务系统发送的多个第一日志，所述第一日志包括请求ID、业务ID和日志内容，所述请求ID为获取所述n个业务系统的日志时所述n个业务系统中的第一业务系统生成的，所述业务ID为日志内容对应的业务流程标识；所述处理单元还用于根据所述至少一个第一日志中每个第一日志的请求ID和接收时间，对所述至少一个第一日志进行筛选，得到所述n个业务系统的日志。

在一种可能的设计中，该接收单元具体用于：通过生产者与消费者模型将所述n个业务系统发送的多个第一日志按照第一排序规则进行存储，所述第一排序规则为预设的或者用户指令指示的。

在一种可能的设计中，该接收单元具体用于：通过生产者与消费者模型中的生产者线程，将所述n个业务系统发送的多个第一日志划分至所述业务系统对应的日志队列；

通过所述生产者与消费者模型中的消费者线程，从内存空间中读取所述多个第一日志各自的偏移量，并根据所述第一日志各自的偏移量从所述n个业务系统分别对应的日志队列中，提取所述多个第一日志。

在一种可能的设计中，处理单元420还用于：删除所述n个业务系统的日志中生成时长超过第一时长的日志，所述第一时长为预设时长或者为基于所述n个业务系统的每秒查询率QPS确定的。

上述实施例提供的电子设备，可以执行上述方法实施例中日志监控系统侧的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

图7为本申请实施例提供的一种电子设备500的结构示意图，如图7所示，该电子设备500包括：

处理单元510，用于生成请求ID，所述请求ID用于请求获取第一业务系统和至少一个第二业务系统的日志；

发送单元520，用于将所述请求ID发送给至少一个第二业务系统；

所述处理单元510还用于根据所述请求ID，生成至少一个第一日志；

所述发送单元520还用于将所述至少一个第一日志发送至所述日志监控系统。

上述实施例提供的电子设备，可以执行上述方法实施例中第一业务系统侧的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

本申请实施例还提供一种电子设备，参见图8，本申请实施例仅以图8为例进行说明，并不表示本申请仅限于此。

图8为本申请实施例提供的一种电子设备600示意性结构图。如图6所示的电子设备600包括处理器610，处理器610可以从存储器中调用并运行计算机程序，以实现本申请实施例中的方法。

可选地，如图8所示，电子设备600还可以包括存储器630。其中，处理器610可以从存储器630中调用并运行计算机程序，以实现本申请实施例中的方法。

其中，存储器630可以是独立于处理器610的一个单独的器件，也可以集成在处理器610中。

可选地，如图8所示，电子设备600还可以包括收发器620，处理器610可以控制该收发器620与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。

其中，收发器620可以包括发射机和接收机。收发器620还可以进一步包括天线，天线的数量可以为一个或多个。

可选地，该电子设备600可以实现本申请实施例的各个方法中日志监控系统对应的相应流程，为了简洁，在此不再赘述。

可选地，该电子设备600可以实现本申请实施例的各个方法中业务系统对应的相应流程，为了简洁，在此不再赘述。

应理解，本申请实施例的处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(DirectRambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

应理解，上述存储器为示例性但不是限制性说明，例如，本申请实施例中的存储器还可以是静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synch link DRAM，SLDRAM)以及直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)等等。也就是说，本申请实施例中的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本申请实施例还提供了一种计算机可读存储介质，用于存储计算机程序。

可选的，该计算机可读存储介质可应用于本申请实施例中的电子设备，并且该计算机程序使得计算机执行本申请实施例的各个方法中由日志监控系统或业务系统执行的相应流程，为了简洁，在此不再赘述。

本申请实施例还提供了一种计算机程序产品，包括计算机程序指令。

可选的，该计算机程序产品可应用于本申请实施例中的电子设备，并且该计算机程序指令使得计算机执行本申请实施例的各个方法中由日志监控系统或业务系统执行的相应流程，为了简洁，在此不再赘述。

本申请实施例还提供了一种计算机程序。

可选的，该计算机程序可应用于本申请实施例中的电子设备，当该计算机程序在计算机上运行时，使得计算机执行本申请实施例的各个方法中由日志监控系统或业务系统执行的相应流程，为了简洁，在此不再赘述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。针对这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (12)

1.一种日志的处理方法，其特征在于，所述方法包括：

获取用户的查询请求；

根据所述查询请求，在从n个业务系统中获取到的日志中确定目标日志，n为大于1的正整数，所述查询请求包括请求标识ID或者查询词，所述请求ID为获取所述n个业务系统的日志时所述n个业务系统中的第一业务系统生成的，所述查询词包括关键词和/或正则表达式；

推送所述目标日志。

2.根据权利要求1所述的方法，其特征在于，在所述查询请求包括请求ID时，所述根据所述查询请求，在所述n个业务系统的日志中确定目标日志，包括：

根据所述请求ID，确定所述目标日志为所述n个业务系统的日志。

3.根据权利要求1所述的方法，其特征在于，在所述查询请求包括关键词和/或正则表达式时，所述根据所述查询请求，在所述n个业务系统的日志中确定目标日志，包括：

根据所述关键词和/或正则表达式，在所述n个业务系统的日志中确定与所述关键词和/或正则表达式对应的目标日志。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：

接收所述n个业务系统发送的多个第一日志，所述第一日志包括请求ID、业务ID和日志内容，所述请求ID为获取所述n个业务系统的日志时所述n个业务系统中的第一业务系统生成的，所述业务ID为日志内容对应的业务流程标识；

根据所述多个第一日志中每个第一日志的请求ID和接收时间，对所述多个第一日志进行筛选，得到所述n个业务系统的日志。

5.根据权利要求4所述的方法，其特征在于，所述接收所述n个业务系统发送的至少一个第一日志，包括：

通过生产者与消费者模型将所述n个业务系统发送的多个第一日志按照第一排序规则进行存储，所述第一排序规则为预设的或者用户指令指示的。

6.根据权利要求4所述的方法，其特征在于，所述接收所述n个业务系统发送的多个第一日志，包括：

通过生产者与消费者模型中的生产者线程，将所述n个业务系统发送的多个第一日志划分至所述业务系统对应的日志队列；

通过所述生产者与消费者模型中的消费者线程，从内存空间中读取所述多个第一日志各自的偏移量，并根据所述第一日志各自的偏移量从所述n个业务系统分别对应的日志队列中，提取所述多个第一日志。

7.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：

删除所述n个业务系统的日志中生成时长超过第一时长的日志，所述第一时长为预设时长或者为基于所述n个业务系统的每秒查询率QPS确定的。

8.一种日志的处理方法，其特征在于，所述方法包括：

第一业务系统生成请求ID，所述请求ID用于请求获取所述第一业务系统和至少一个第二业务系统的日志；

所述第一业务系统将所述请求ID发送给至少一个第二业务系统；

所述第一业务系统根据所述请求ID，生成至少一个第一日志；

所述第一业务系统将所述至少一个第一日志发送至所述日志监控系统。

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

获取单元，用于获取用户的查询请求；

处理单元，用于根据所述查询请求，在从n个业务系统中获取到的日志中确定目标日志，n为大于1的正整数，所述查询请求包括请求标识ID或者查询词，所述请求ID为获取所述n个业务系统的日志时所述n个业务系统中的第一业务系统生成的，所述查询词包括关键词和/或正则表达式；

推送单元，用于推送所述目标日志。

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

处理单元，用于生成请求ID，所述请求ID用于请求获取第一业务系统和至少一个第二业务系统的日志；

发送单元，用于将所述请求ID发送给至少一个第二业务系统；

所述处理单元还用于根据所述请求ID，生成至少一个第一日志；

所述发送单元还用于将所述至少一个第一日志发送至所述日志监控系统。

11.一种电子设备，其特征在于，包括：存储器和处理器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，使得所述处理器执行如权利要求1至8任一项所述的方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至8任一项所述的方法。

Images