CN110858192A - 一种日志查询方法和***、日志排查***和查询终端 - Google Patents

Abstract

本申请提供了一种日志查询方法和***、日志排查***和查询终端，该方法包括：获取日志查询请求；响应于所述日志查询请求，向多个端设备获取日志数据；接收所述多个端设备按照统一的数据格式返回的日志数据；将接收到的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。在上述方案中，对于多个端设备而言，在给日志排查***返回日志数据的时候，是按照统一的数据格式返回的，从而使得日志排查***对日志处理时候较为方便，容易聚类分析，可以有效提升日志查询的效率，在查询终端显示日志数据的时候，通过自然语言的方式显示，提升了用户对日志文件的可读性，可以简单高效地实现日志排查。

Description

一种日志查询方法和***、日志排查***和查询终端

技术领域

本申请属于互联网技术领域，尤其涉及一种日志查询方法和***、日志排查***和查询终端。

背景技术

日志是用于记录***中事件的文件，在日常的开发过程中，无论是客户端还是服务端，日志都起到一个非常重要的作用，通过日志可以进行性能分析、问题定位排查等。

然而，由于各个开发者的习惯不同、需要输出的内容不同等原因，日志文件的内容往往很杂乱、表达能力不强，如果在一行日志里面，输出非常复杂结构，那么日志的可读性是很低的。且客户端与服务端的实现差异很大，同一个业务、同一链路的日志差异很大，很难在一起进行排查。

由于日志所存在规范程度，结构化不强的问题，就使得开发者通过日志定位问题的时候，排查效率比较低下。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请目的在于提供一种日志查询方法和***、日志排查***和查询终端，以达到简单高效进行日志查询的技术效果。

本申请提供一种日志查询方法和***、日志排查***和查询终端是这样实现的：

一种日志查询方法，所述方法包括：

获取日志查询请求；

响应于所述日志查询请求，向多个端设备去请求日志数据；

接收所述多个端设备按照统一的数据格式返回的日志数据；

将接收到的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

一种日志查询方法，所述方法包括：

获取日志查询请求；

响应于所述日志查询请求，向多个端设备请求日志数据；

将所述多个端设备返回的日志数据转换为统一的数据格式，得到转换后的日志数据；

将转换后的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

一种日志查询方法，包括：

获取用户通过日志查询界面输入的查询条件；

根据所述查询条件，生成查询请求并发送至日志查询***；

接收所述日志查询***返回的日志数据，其中，所述日志查询***返回的日志数据是多个端设备按照统一的数据格式上传至所述日志查询***的日志数据；

以自然语言的方式，通过所述日志查询界面显示返回的日志数据。

一种日志查询***，，包括：

查询终端，用于发起查询请求，并展示查询结果；

日志排查***，用于响应于所述查询请求向端设备请求日志数据；

多个端设备，用于按照统一的数据格式，向所述日志排查***返回日志数据。

一种日志查询***，包括：

查询终端，用于发起查询请求，并展示查询结果；

日志排查***，用于响应于所述查询请求向端设备请求日志数据；

多个端设备，用于向所述日志排查***返回日志数据；

所述日志排查***，还用于将返回的日志数据转换为统一的数据格式，并向所述查询终端返回查询结果。

一种日志排查***，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现如下步骤：

获取日志查询请求；

响应于所述日志查询请求，向多个端设备去请求日志数据；

接收所述多个端设备按照统一的数据格式返回的日志数据；

将接收到的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

一种日志排查***，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现如下步骤：

获取日志查询请求；

响应于所述日志查询请求，向多个端设备请求日志数据；

将所述多个端设备返回的日志数据转换为统一的数据格式，得到转换后的日志数据；

将转换后的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

一种查询终端，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

获取用户通过日志查询界面输入的查询条件；

根据所述查询条件，生成查询请求并发送至日志查询***；

接收所述日志查询***返回的日志数据，其中，所述日志查询***返回的日志数据是多个端设备按照统一的数据格式上传至所述日志查询***的日志数据；

以自然语言的方式，通过所述日志查询界面显示返回的日志数据。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现：

获取日志查询请求；

响应于所述日志查询请求，向多个端设备获取日志数据；

接收所述多个端设备按照统一的数据格式返回的日志数据；

将接收到的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现：

获取用户通过日志查询界面输入的查询条件；

根据所述查询条件，生成查询请求并发送至日志查询***；

接收所述日志查询***返回的日志数据，其中，所述日志查询***返回的日志数据是多个端设备按照统一的数据格式上传至所述日志查询***的日志数据；

以自然语言的方式，通过所述日志查询界面显示返回的日志数据。

本申请提供的日志查询方法和***、日志排查***和查询终端，对于多个具有不同日志格式的端设备而言，最终会转换为统一的数据格式，从而使得日志排查***对日志处理时候较为方便，容易聚类分析，可以有效提升日志查询的效率，在查询终端显示日志数据的时候，通过自然语言的方式显示，提升了用户对日志文件的可读性，可以简单高效地实现日志排查。

附图说明

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

图1是本申请提供的日志查询***的架构图；

图2是本申请提供的日志配置后台页面的示意图；

图3是本申请提供的日志查询的流程示意图；

图4是本申请提供的日志抓取页面的结构示意图；

图5是本申请提供的IM消息全链路排查结果示意图；

图6是本申请提供的日志查询***的另一架构图；

图7是本申请提供的日志查询方法的方法流程图；

图8是本申请提供的日志查询方法的另一方法流程图；

图9是本申请提供的计算机终端的架构示意图；

图10是本申请提供的日志查询装置的结构框图；

图11是本申请提供的日志查询装置的另一结构框图。

具体实施方式

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

考虑到现有的日志排查中所存在的效率低下，对排查人员的专业度要求比较高的问题，在本申请提供了一种日志查询***，如图1所示，包括：排查***101、多个端设备102、查询端103。因为多个端设备日志数据的格式是不同的，如果进行数据聚类等操作较为繁琐，因此，可以在对日志数据进行处理之前，将不同端设备的日志数据转换为统一的数据格式。

这些转换操作，可以在终端侧实现，也可以在排查***侧实现，例如，每个端设备可以按照统一的日志格式向排查***提供日志文件，也可以是日志排查***在接收到端设备返回的不同格式的日志数据之后，将这些日志数据转换为统一的数据格式。

对于每个端设备可以按照统一的日志格式向排查***提供日志文件在实际实现的时候，可以是在每个端设备侧植入一个进行格式转换的sdk，也可以是在排查***向端设备请求日志数据的时候，在请求消息中携带统一的数据格式的格式信息。具体采用哪种方式可以根据实际需要选择，本申请对此不作限定，只要保证排查***最终可以获得统一数据格式的日志数据即可。

通过上述的统一数据格式的日志数据的要求，使得查询端103在通过排查***进行日志查询的，排查***101最终可以得到按照统一格式的日志文件，处理起来更为简单，准确度也更高，有效提升了日志排查的效率。

上述的多个端设备102可以包括：客户端、服务端等，其中，客户端和服务端可以是不同操作类型的。例如，客户端可以是ios客户端、pc客户端、android客户端等等，服务端可以是Linux服务端、pc服务端等。只要是存在日志文件的端设备都可以作为本申请中的端设备，本申请对此不作限定。

在实现的时候，上述日志排查***还可以如图1所示包括：存储器104，其中，该存储器可以位于排查***中，也可以是单独设置的。用于存储排查***101从端设备102获取的并处理后的日志数据。

为了实现对日志的查询，可以从如下三个方面进行：查询展示界面的呈现(即，日志展示)、基于查询请求的日志抓取(即，日志抓取)、为了实现终端和服务端日志的有效抓取对日志的配置(即，日志配置)。下面从这三个方面说明如下：

1)日志配置：

考虑到现有的客户端和服务端记录日志的差异，以及不同开发者的习惯等，导致不同的客户端、服务端的日志形式很多都是不同的，因此，难以进行聚合排查。为此，在本例中，通过统一配置日志文件的记录格式，从而使得不同端设备可以将日志处理成统一格式的日志文件之后，再提供了排查***，从而使得在排查***侧可以进行对日志进行有序高效的处理。

在具体实现的时候，可以是在排查***向客户端和服务端请求日志数据的时候，携带统一格式的格式要求，也可以是如图2所示，根据客户端和服务端的不同，生成不同的sdk，将sdk集成在对应的客户端或服务端中，每个sdk中所限制的日志记录格式是相同。Sdk基于配置的日志规则生成的。例如：每条日志内容包括的具体内容：日志名称、关键字段、可选字段、关键字段的字段名称、关键字段的字段类型、可选字段的字段名称、可选字段的字段类型等都可以进行配置，在配置了规则之后，可以生成对应不同端设备的sdk，然后将生成的sdk集成到端设备中。

这样，当排查***接收到用户的查询请求后，可以从客户端和服务端请求日志数据，对于客户端和服务端而言，在接收到日志请求之后，通过集成的sdk将日志转换为sdk所限定的日志格式，然后返回给排查***。

排查***在收到客户端和服务端的日志文件之后，因为日志文件是统一格式的，因此可以对日志文件进行自动聚类，并按照一定的格式进行存储、建立索引，从而便于后续的查询，或者是传送到查询端，显示查询结果。

在日志配置界面，可以按照如图2所示的日志配置后台页面的配置方式进行日志配置，例如，为某种类型的日志设置日志名称：log1，对于log1这种日志，可以设置其对应的关键字段，例如：time、masgid，并可以为每个关键字段设置对应的字段类型，例如：Long、String等。同时，可以设置日志对应的可选字段，即，可以记录也可以不记录的字段，如果记录的话，哪些字段作为可选字段，以及这些可选字段的字段类型。在配置完成之后，可以根据语言、平台、需要支持的日志名等自动生成sdk。然后将sdk集成在各端设备中。

例如，这些端设备可以是：ios客户端、pc客户端、android客户端、linux服务端和一些其他类型的客户端。具体需要生成哪些端设备对应的sdk可以根据实际需要确定，本申请对此不作限定。

对于同一类型的日志，只需要配置一次，其中，上述日志名称用于唯一标识某一种类型的日志，关键字段可以设置多个，并为关键字段设定优先级，用于数据的聚合。对于排查***而言，从不同端设备收集的日志，如果关键字段都相同，那么可以认为是同一个链路的日志内容，最终这些内容会被展示在一起。可选字段用于日志的展示，通过可选字段可以展示每个事件节点发生时的各种信息。其中，关键字段和可选字段可以根据需求灵活地增加或者减少。

对于需要集成日志***的开发者，可以在日志指令仓库中，选择需要支持的指令、支持的平台、语言等，平台可以自动生成sdk供开发者集成在自己的程序中。对于端设备而言，在集成了sdk之后，就可以在排查***请求日志的时候，调用sdk的API接口将请求的日志转换为统一格式的日志文件再提供给排查***。对于端设备而言，自身的日志文件可以存储在本地文件中，也可以存储在数据库中，对此，可以根据实际需要选择，本申请不作限定。

2)日志抓取：

如图3所示，当用户(例如：开发或者测试人员)需要查询某些对象或者服务器的日志时，可以通过指令通道下发指令，如图4所示，在指令中设置了查询条件(例如，日志名称，起始时间，结束时间，和关键字段等)，用于指明本次查询对应的日志和查询范围以及关键字段的值。客户端或者服务端根据查询条件，通过sdk的API查询到对应的数据，然后可以通过数据上传通道返回到排查***。

其中，指令和下发通道等可以根据是需求和情况设定，例如，可以是基于TCP长连接的自定义协议、HTTP协议等设定的指令和下发通道。

在通过sdk抓取数据返回到排查***的时候，可以采取按需抓取的方式，也可以采用全量抓取的方式，其中，按需抓取就是仅抓取指令所请求的数据，全量抓取就是将所有日志数据都返回至排查***。

在进行日志抓取的时候，对于客户端而言，可以采用按需抓取的方式，这主要是考虑到客户端的用户量很大，实时存储所有用户的日志将耗费很多的资源。一般仅在遇到问题的时候，才需要查看客户端的日志，因此，可以采用按需抓取的方式，这样既可以获取到用户指定数据的日志，也可以减少数据的传输量和存储量。

对于服务端而言，可以采用全量抓取的方式，服务端将全链路的排查日志输入在本地后，可以通过本机的日志采集程序，将日志分发到排查***中，由排查***进行数据的清洗、过滤、解析、存储等操作。

3)日志展示：

在端设备侧将日志返回至排查***之后，可以将日志文件处理后存储在存储器中。然后，根据查询用户在查询页面的请求，将匹配得到的日志返回至查询页面进行显示，从而使得查询用户可以通过查询页面查询到指定查询范围的日志数据。

对于排查***而言，在将数据写入存储器的时候，可以抽取关键字等信息生成索引键，将具有相同关键字的事件日志聚合在一起，以表明这些是同一条链路的日志。基于查询请求，返回至查询页面展示的数据可以是按照时间进行排序的。

对于查询页面而言，展示方式或者展示时的具体显示可以是用户根据需要设定的，即，设置每个字段按照什么方式进行显示，例如，设置每个字段项都显示字段名称，以及所对应的字段值的文字含义，这样可以提升内容的可读性。

以IM消息为例，如图5所示，为IM消息全链路排查的显示界面示意图，消息的全链路包括多个服务，对于同一个消息的日志，可以根据消息的ID进行串联，按照发生的时间进行排序。如果需要查看某一条消息在某个服务的具体日志，那么可以点击该消息链路上的事件节点(例如：上行、路由、下行、数据中心网关等)，即可查看到对应事件节点的ip、日志时间等信息。例如：“发送类型”，如果在日志数据中，发送类型对应的字段是10号字段，那么可以设置10号字段如果为0，则显示：自动行为[0]，10号字段如果是1，则显示：手动行为[1]，从而可以提升日志查询结果的可读性。同样的对于其他的字段项，也可以按照这种方式设置显示模式。

如图5所示，查询用户查询的是七博在2018-02-22(11:00:00～23:59:59)的日志信息，在显示界面显示的结果中，2018-02-22 11:00:07.262对应的日志内容中，发生在2018-02-22(11:00:00～23:59:59)这个时间段的事件节点仅有消息已读，其它的诸如：上行、路由、下行等事件节点都是在2018-02-22 11:00:00之前发生的，因此，查询出的日志记录里是没有这些事件节点的。即，显示界面所返回的日志数据是基于所界定的范围返回并显示的。

然而，值得注意的是，上例是以IM消息为例进行的说明，在实际实现的时候，还可以是订单处理数据、物流数据、交互数据等等，本申请对此不作具体限定，这些日志数据都可以通过日志查询的方式进行查询和显示。

在上例中，通过配置的方式，使得同一链路上的日志的格式可以统一化，上层业务逻辑不需要关系日志对存储，同时可以兼容对字段的增减等需求，以便支持更为复杂的数据结构。通过集成sdk的方式，使得各个端设备的日志可以统一，以方便对各个端设备进行全链路排查。通过可视化展示，使得查询用户可以从黑白的日志中解放出来，很清楚地看到在整条链路上按照指定时序的各个事件，且可以展示每个事件节点的排查信息。

本申请还提供了一种日志查询***，如图6所示，包括：查询终端601、日志排查***602和多个端设备603，其中：

查询终端601，用于发起查询请求，并展示查询结果；

日志排查***602，用于响应于所述查询请求向端设备请求日志数据；

多个端设备603，用于按照统一的数据格式，向所述日志排查***返回日志数据。

在该日志查询***中，因为多个端设备返回的日志数据是按照统一的数据格式返回，使得日志排查***可以简单高效地对日志进行整合，得到全链路的日志信息。

为了使得各个端设备可以形成统一的数据格式，可以为各个端设备都集成有将日志数据转换为统一的数据格式的sdk，对于需要集成日志***的开发者，可以在日志指令仓库中，选择需要支持的指令、支持的平台、语言等，平台可以自动生成sdk供开发者集成在自己的程序中。对于端设备而言，在集成了sdk之后，就可以在排查***请求日志的时候，调用sdk的API接口将请求的日志转换为统一格式的日志文件再提供给排查***。

上述的多个端设备可以包括但不限于如下设备中的一个或多个：IOS客户端、PC客户端、Android客户端、Linux服务端。

为了在日志排查***中可以对日志数据进行存储备份，可以设置一个存储器，该存储器用于日志排查***存储多个端设备返回的日志数据。日志排查***在收到端设备返回的日志数据之后，可以按照一定的格式进行存储，并可以建立索引以便于后续的查询或调用。

基于上述的日志查询***，还提供了一种日志查询方法是基于日志排查***的，一种日志查询方法是基于查询终端中的，图7是本申请所述一种日志查询方法一个实施例的方法流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例描述及附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构连接进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至分布式处理环境)。

具体的如图7所示，本申请一种实施例提供的一种日志查询方法，基于日志排查***的，可以包括如下步骤：

步骤701：获取日志查询请求；

步骤702：响应于所述日志查询请求，向多个端设备请求日志数据；

步骤703：接收所述多个端设备按照统一的数据格式返回的日志数据；

其中，在通过sdk抓取数据返回到排查***的时候，可以采取按需抓取的方式，也可以采用全量抓取的方式，其中，按需抓取就是仅抓取指令所请求的数据，全量抓取就是将所有日志数据都返回至排查***。在进行日志抓取的时候，对于客户端而言，可以采用按需抓取的方式，这主要是考虑到客户端的用户量很大，实时存储所有用户的日志将耗费很多的资源。一般仅在遇到问题的时候，才需要查看客户端的日志，因此，可以采用按需抓取的方式，这样既可以获取到用户指定数据的日志，也可以减少数据的传输量和存储量。对于服务端而言，可以采用全量抓取的方式，服务端将全链路的排查日志输入在本地后，可以通过本机的日志采集程序，将日志分发到排查***中，由排查***进行数据的清洗、过滤、解析、存储等操作。即，可以接收所述多个端设备中的客户端返回的按需拉取的日志数据；接收所述多个端设备中的服务端返回的全量拉取的日志数据。

上述端设备中可以集成有将日志数据转换为统一的数据格式的sdk，通过该sdk不同端设备输送至日志排查***的日志数据是相同的格式的。也可以是在排查***向多个端设备请求日志数据的时候，向多个端设备发送数据格式，这样就使得端设备可以按照接收到的数据格式，将日志数据按照统一的数据格式返回到排查***，具体采用哪种方式可以根据实际需要选择，本申请对此不作限定。

其中，统一的数据格式可以包括：每种日志类型所包含的关键字段、每种日志类型所包含的可选字段、关键字段的字段类型、可选字段的字段类型。

步骤704：将接收到的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

因为是统一的数据格式，那么同一种日志类型的日志数据的关键字段的值就是相同的，对于日志排查***而言，在接收多个端设备按照统一的数据格式返回的日志数据之后，可以提取出接收到的日志数据中每条日志记录的各个关键字段的取值；将各个关键字段的取值相同的日志记录作为同一链路的日志记录。

在具体实现的时候，上述端设备与日志排查***之间的数据通道可以是预设的通道，这些预设通道可以是基于以下协议之一的：TCP长连接的协议、HTTP协议。

在本申请中还提供了一种日志查询方法，通过排查***进行数据格式的转换，基于此，可以包括如下步骤：

步骤1：获取日志查询请求；

步骤2：响应于所述日志查询请求，向多个端设备请求日志数据；

步骤3：将所述多个端设备返回的日志数据转换为统一的数据格式，得到转换后的日志数据；

其中，统一的数据格式可以包括：每种日志类型所包含的关键字段、每种日志类型所包含的可选字段、关键字段的字段类型、可选字段的字段类型。

步骤4：将转换后的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

在获取到转换后的日志数据之后，可以对数据进行整合，具体的，排查***可以按照如下方式进行数据整合：提取出转换后的日志数据中每条日志记录的各个关键字段的取值；将各个关键字段的取值相同的日志记录作为同一链路的日志记录。

如图8所示，提供了一种日志查询方法，基于查询终端侧，可以包括如下步骤：

步骤801：获取用户通过日志查询界面输入的查询条件；

步骤802：根据所述查询条件，生成查询请求并发送至日志查询***；

步骤803：接收所述日志查询***返回的日志数据，其中，所述日志查询***返回的日志数据是多个端设备按照统一的数据格式上传至所述日志查询***的日志数据；

步骤804：以自然语言的方式，通过所述日志查询界面显示返回的日志数据。

为了使得查询者可以更高效地查询日志信息，或者是给予查询者更为详细的日志信息，可以提供对每个事件节点详细信息的查询，例如，在以自然语言的方式，通过所述日志查询界面显示返回的日志数据之后，可以接收用户对事件节点的选择操作；响应于所述选择操作，显示所选择的事件节点的信息。

上述事件节点的信息可以但不限于包括：关键字段、关键字段的值、可选字段、可选字段的值。

本申请实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图9是本发明实施例的一种日志查询方法的计算机终端的硬件结构框图。如图9所示，计算机终端10可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输模块106。本领域普通技术人员可以理解，图9所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图9中所示更多或者更少的组件，或者具有与图9所示不同的配置。

存储器104可用于存储应用软件的软件程序以及模块，如本发明实施例中的日志查询方法对应的程序指令/模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的日志查询方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输模块106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在软件层面，提供了一种日志查询装置，位于日志排查***中，如图10所示，可以包括：获取模块1001、请求模块1002、接收模块1003和推送模块1004，其中：

获取模块1001，用于获取日志查询请求；

请求模块1002，用于响应于所述日志查询请求，向多个端设备请求日志数据；

接收模块1003，用于接收所述多个端设备按照统一的数据格式返回的日志数据；

推送模块1004，用于将接收到的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

在一个实施方式中，接收模块1003可以包括：第一接收单元，用于接收所述多个端设备中的客户端返回的按需拉取的日志数据；第二接收模块，用于接收所述多个端设备中的服务端返回的全量拉取的日志数据。

在一个实施方式中，所述多个端设备中各个端设备都集成有将日志数据转换为统一的数据格式的sdk。

在一个实施方式中，所述统一的数据格式可以包括：每种日志类型所包含的关键字段、每种日志类型所包含的可选字段、关键字段的字段类型、可选字段的字段类型。

在一个实施方式中，上述日志查询装置还可以包括：提取模块，用于在接收所述多个端设备按照统一的数据格式返回的日志数据之后，提取出接收到的日志数据中每条日志记录的各个关键字段的取值；生成模块，用于将各个关键字段的取值相同的日志记录作为同一链路的日志记录。

在一个实施方式中。接收模块1003具体可以接收所述多个端设备通过预设通道返回的日志数据，其中，所述预设通道是基于以下协议之一的：TCP长连接的协议、HTTP协议。

在软件层面，还提供了一种日志查询装置，位于查询终端中，如图11所示，可以包括：获取模块1101、生成模块1102、接收模块1103和显示模块1104，其中：

获取模块1101，用于获取用户通过日志查询界面输入的查询条件；

生成模块1102，用于根据所述查询条件，生成查询请求并发送至日志查询***；

第一接收模块1103，用于接收所述日志查询***返回的日志数据，其中，所述日志查询***返回的日志数据是多个端设备按照统一的数据格式上传至所述日志查询***的日志数据；

显示模块1104，用于以自然语言的方式，通过所述日志查询界面显示返回的日志数据。

在一个实施方式中，上述日志查询装置还可以包括：第二接收模块，用于在以自然语言的方式，通过所述日志查询界面显示返回的日志数据之后，接收用户对事件节点的选择操作；响应于所述选择操作，显示所选择的事件节点的信息。

在一个实施方式中，上述事件节点的信息可以包括：关键字段、关键字段的值、可选字段、可选字段的值。

本申请提供的日志查询方法和***、日志排查***和查询终端，对于多个端设备而言，在给日志排查***返回日志数据的时候，是按照统一的数据格式返回的，从而使得日志排查***对日志处理时候较为方便，容易聚类分析，可以有效提升日志查询的效率，在查询终端显示日志数据的时候，通过自然语言的方式显示，提升了用户对日志文件的可读性，可以简单高效地实现日志排查。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。当然，也可以将实现某功能的模块由多个子模块或子单元组合实现。

本申请中所述的方法、装置或模块可以以计算机可读程序代码方式实现控制器按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请所述装置中的部分模块可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的硬件的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，也可以通过数据迁移的实施过程中体现出来。该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请的全部或者部分可用于众多通用或专用的计算机***环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、移动通信终端、多处理器***、基于微处理器的***、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何***或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (22)

1.一种日志查询方法，其特征在于，所述方法包括：

获取日志查询请求；

响应于所述日志查询请求，向多个端设备去请求日志数据；

接收所述多个端设备按照统一的数据格式返回的日志数据；

将接收到的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

2.根据权利要求1所述的方法，其特征在于，接收所述多个端设备按照统一的数据格式返回的日志数据，包括：

接收所述多个端设备中的客户端返回的按需拉取的日志数据；

和/或，接收所述多个端设备中的服务端返回的全量拉取的日志数据。

3.根据权利要求1所述的方法，其特征在于，所述多个端设备中各个端设备都集成有将日志数据转换为统一的数据格式的sdk。

4.根据权利要求1所述的方法，其特征在于，在向所述多个端设备请求日志数据的时候，向所述多个端设备发送所述数据格式。

5.根据权利要求1所述的方法，其特征在于，所述统一的数据格式包括：每种日志类型所包含的关键字段、每种日志类型所包含的可选字段、关键字段的字段类型、可选字段的字段类型。

6.根据权利要求5所述的方法，其特征在于，在接收所述多个端设备按照统一的数据格式返回的日志数据之后，所述方法还包括：

提取出接收到的日志数据中每条日志记录的各个关键字段的取值；

将各个关键字段的取值相同的日志记录作为同一链路的日志记录。

7.根据权利要求1所述的方法，其特征在于，接收所述多个端设备按照统一的数据格式返回的日志数据，包括：

接收所述多个端设备通过预设通道返回的日志数据，其中，所述预设通道是基于以下协议之一的：TCP长连接的协议、HTTP协议。

8.一种日志查询方法，其特征在于，所述方法包括：

获取日志查询请求；

响应于所述日志查询请求，向多个端设备请求日志数据；

将所述多个端设备返回的日志数据转换为统一的数据格式，得到转换后的日志数据；

将转换后的日志数据中属于日志查询请求所请求的查询范围的数据，推送至请求端进行显示。

9.根据权利要求8所述的方法，其特征在于，所述统一的数据格式包括：每种日志类型所包含的关键字段、每种日志类型所包含的可选字段、关键字段的字段类型、可选字段的字段类型。

10.根据权利要求9所述的方法，其特征在于，在将所述多个端设备返回的日志数据转换为统一的数据格式，得到转换后的日志数据之后，所述方法还包括：

提取出转换后的日志数据中每条日志记录的各个关键字段的取值；

将各个关键字段的取值相同的日志记录作为同一链路的日志记录。

11.一种日志查询方法，其特征在于，包括：

获取用户通过日志查询界面输入的查询条件；

根据所述查询条件，生成查询请求并发送至日志查询***；

接收所述日志查询***返回的日志数据，其中，所述日志查询***返回的日志数据是多个端设备按照统一的数据格式上传至所述日志查询***的日志数据；

以自然语言的方式，通过所述日志查询界面显示返回的日志数据。

12.根据权利要求11所述的方法，其特征在于，在以自然语言的方式，通过所述日志查询界面显示返回的日志数据之后，所述方法还包括：

接收用户对事件节点的选择操作；

响应于所述选择操作，显示所选择的事件节点的信息。

13.根据权利要求12所述的方法，其特征在于，事件节点的信息包括：关键字段、关键字段的值、可选字段、可选字段的值。

14.一种日志查询***，其特征在于，包括：

查询终端，用于发起查询请求，并展示查询结果；

日志排查***，用于响应于所述查询请求向端设备请求日志数据；

多个端设备，用于按照统一的数据格式，向所述日志排查***返回日志数据。

15.根据权利要求14所述的***，其特征在于，所述多个端设备中各个端设备都集成有将日志数据转换为统一的数据格式的sdk。

16.根据权利要求14所述的***，其特征在于，还包括：

存储器，用于所述日志排查***存储所述多个端设备返回的日志数据。

17.根据权利要求14所述的***，其特征在于，所述多个端设备如下设备中的一个或多个：IOS客户端、PC客户端、Android客户端、Linux服务端。

18.一种日志查询***，其特征在于，包括：

查询终端，用于发起查询请求，并展示查询结果；

日志排查***，用于响应于所述查询请求向端设备请求日志数据；

多个端设备，用于向所述日志排查***返回日志数据；

所述日志排查***，还用于将返回的日志数据转换为统一的数据格式，并向所述查询终端返回查询结果。

19.一种日志排查***，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现权利要求1至7中任一项所述方法的步骤。

20.一种日志排查***，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现权利要求8至10中任一项所述方法的步骤。

21.一种查询终端，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现权利要求11至13中任一项所述方法的步骤。

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

Images