CN106559241B - 应用日志的收集、发送方法、装置、系统及日志服务器 - Google Patents

Abstract

本申请实施例中提供了一种应用日志的收集方法、装置、系统及日志服务器，该方法包括：查询日志服务器中会话队列的状态，其中，会话队列中存储日志内容，会话队列的状态是日志服务器根据接收到来自客户端的日志获取请求的第一时刻确定的；根据会话队列的状态触发代理端Agent收集或停止收集应用日志。采用本申请实施例中的方案，能够避免Agent所在的计算机的资源的浪费，提高计算机资源的利用率。

Description

应用日志的收集、发送方法、装置、系统及日志服务器

技术领域

本申请涉及计算机技术，具体涉及一种应用日志的收集、方法方法、装置、系统及日志服务器。

背景技术

当应用出现问题时，基于应用的日志文件来判断导致问题的原因是非常重要的线上调试手段。为了获取应用日志，通常是到出现问题的应用所在的计算机上抓取应用日志文件，然后以此为基础推测问题的原因。

现有技术中，从计算机上实时抓取应用日志的方法主要是在应用所在的计算机上部署代理端Agent。当用户请求应用日志时，用户通过客户端向特定计算机上的Agent发送指令要求开始收集应用日志。Agent开始监听相应的端口，不断收集应用日志，然后等待指令将收集的日志发送给客户端。同时，客户端也会不断发送指令以请求日志内容，Agent将收集到的日志内容发送给客户端。当用户期望停止获取日志内容时，客户端发送停止日志指令给Agent，Agent停止日志收集。整个过程如图1所示。

但是，通常情况下，在期望停止获取日志内容时，大部分用户的习惯是直接关闭客户端，而不会向Agent发送停止指令。此时，Agent不知道在什么时间点关闭日志传输通道，所以会一直收集日志文件，但是这部分的文件不会被用户所获取，从而导致Agent所在的计算机的资源的浪费。

发明内容

本申请实施例中提供了一种应用日志的收集、发送方法、装置、系统及日志服务器，用于解决现有技术中Agent所在计算机资源浪费的问题。

根据本申请实施例的第一个方面，提供了一种应用日志的收集方法，包括：查询日志服务器中会话队列的状态，其中，会话队列中存储日志内容，会话队列的状态是日志服务器根据接收到来自客户端的日志获取请求的第一时刻确定的；根据会话队列的状态触发代理端Agent收集或停止收集应用日志。

根据本申请实施例的第二个方面，提供了一种应用日志的收集方法，包括：日志服务器根据接收到来自客户端的日志获取请求的第一时刻，确定会话队列的状态，其中，会话队列中存储：日志获取请求对应的日志内容；接收Agent对会话队列的状态查询；将会话队列的状态反馈给Agent。

根据本申请实施例的第三个方面，提供了一种应用日志的发送方法，包括：接收来自客户端的日志获取请求，日志获取请求携带日志内容标识；根据日志内容标识查询日志服务器是否存在对应的会话队列；如果存在，则将对应的会话队列中的日志内容发送给客户端。

根据本申请实施例的第四个方面，提供了一种应用日志收集装置，包括：查询模块，用于查询日志服务器中会话队列的状态，其中，会话队列中存储日志内容，会话队列的状态是日志服务器根据接收到来自客户端的日志获取请求的第一时刻确定的；确定模块，用于根据会话队列的状态触发代理端Agent收集或停止收集应用日志。

根据本申请实施例的第五个方面，提供了一种日志服务器，包括：会话队列状态确定模块，用于根据接收到来自客户端的日志获取请求的第一时刻确定会话队列的状态，其中，会话队列中存储：日志获取请求对应的日志内容；第一接收模块，用于接收Agent对会话队列的状态查询；状态反馈模块，用于将会话队列的状态反馈给Agent。

根据本申请实施例的第六个方面，提供了一种应用日志发送装置，包括： 第三接收模块，用于接收来自客户端的日志获取请求，日志获取请求携带日志内容标识；查询模块，用于根据日志内容标识查询日志服务器是否存在对应的会话队列；第二发送模块，用于在存在时，将对应的会话队列中的日志内容发送给客户端。

根据本申请实施例的第七个方面，提供了一种应用日志收集系统，包括：客户端，向日志服务器发送日志获取请求，并从日志服务器接收日志内容；如上述的日志服务器；如上述的日志发送装置；包括如上述的日志收集装置的Agent。

采用本申请实施例中的应用日志的收集方法，查询日志服务器中存储相应日志内容的会话队列的状态，该状态是根据客户端的日志获取请求的时刻确定的，并根据该状态触发Agent收集或停止收集应用日志；从而使得Agent能够获知停止收集日志的时机，避免Agent所在的计算机的资源的浪费，提高计算机资源的利用率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术中的应用日志收集方法流程图；

图2为本申请实施例一所示的应用日志的收集方法流程图；

图3为本申请实施例二所示的应用日志的收集方法流程图；

图4为本申请实施例三所示的应用日志的发送方法流程图

图5为本申请实施例四所示应用日志收集装置的结构示意图；

图6为本申请实施例五所示日志服务器的结构示意图；

图7为本申请实施例六所示应用日志发送装置的结构示意图；

图8为本申请实施例七所示应用日志收集系统的结构示意图

图9为本申请实施例七所示应用日志收集系统中客户端与日志服务器之间 的交互流程图；

图10为本申请实施例七所示应用日志收集系统中日志服务器与Agent之间的交互流程图。

具体实施方式

为了使本申请实施例中的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本申请实施例中提供的方案能够应用于需要进行多个应用日志的收集、发送的场景中。例如，可以应用于如PaaS(Platform-as-a-Service，平台即服务)产品EDAS(Enterprise Distributed Application Service，企业级分布式应用服务)等的中间件中。

为了解决现有技术中Agent所在计算机资源浪费的问题，本申请实施例中提供了一种应用日志的收集、发送方法，其核心在于，在客户端和代理Agent之间新增日志服务器，在日志服务器中维护各日志内容对应的会话队列，在该会话队列中，维护相应的日志内容；并根据客户端发送的日志获取请求和Agent存储日志内容的动作来设置会话队列的状态，并根据会话队列的状态来触发Agent收集日志或是停止收集日志。从而使得Agent能够获知停止收集日志的时机，避免Agent所在的计算机的资源的浪费，提高计算机资源的利用率。

图2为本申请实施例一所示的应用日志的收集方法流程图。

如图2所示，本申请实施例一所示的应用日志的收集方法包括如下步骤：

S202，查询日志服务器中会话队列的状态，其中，会话队列中存储日志内容，该会话队列的状态是日志服务器根据接收到来自客户端的日志获取请求的第一时刻确定的；

S204，根据会话队列的状态触发代理端Agent收集或停止收集应用日志。

在具体实施时，本方法可应用于Agent，也可独立于Agent；此时Agent不直接和客户端交互，而是从日志服务器接受日志收集指令，收集日志后将日志内容发送给日志服务器。同时，Agent并不接受停止收集日志的指令，而是不断查询日志服务器中相应的会话队列的状态，并根据该状态确定是否收集应用日志。

在具体实施时，日志服务器中的会话队列可以是预先创建的，也可以是在接收到客户端发送的日志获取请求后，发现还没有相应的会话队列之后创建的新会话队列。

在具体实施时，在Agent查询会话队列状态之前，日志服务器可以在接收到客户端的日志获取请求之后，创建一个新的会话队列，并为该会话生成一个新的日志收集指令；日志收集指令至少包括日志文件路径和日志收集配置(如日志文件扫描频率、日志级别、初始日志行数等)；Agent从自己的任务队列中获取实时日志收集指令，开始收集日志。在初始阶段，Agent会根据指令配置发送若干已有日志内容到日志服务器，之后开始监听日志文件；在存在新的日志内容的情况下，日志Agent将新的日志项推送到日志服务器。

采用本申请实施例中的应用日志的收集方法，查询日志服务器中存储相应日志内容的会话队列的状态，该状态是根据客户端的日志获取请求的时刻确定的，并根据该状态触发Agent收集或停止收集应用日志；从而使得Agent能够获知停止收集日志的时机，避免Agent所在的计算机的资源的浪费，提高计算机资源的利用率。

采用本申请实施例中的应用日志的收集方法，即使Agent与日志服务器之间的通信通道出现问题，虽然日志内容无法传输到日志服务器，但是由于客户端一直在发送日志获取请求，使得日志服务器中的会话队列的状态不变，此时Agent将仍然收集日志内容，如果在超时重试时间内，Agent与日志服务器之间的通信通道能够恢复，客户端仍然能够得到新的日志内容，提升了用户体验。

优选地，根据会话队列的状态触发代理端Agent收集或停止收集应用日志 具体包括：当会话队列的状态为有效时，触发代理端Agent收集应用日志；当会话队列的状态为失效时，触发代理端Agent停止收集应用日志。

在具体实施时，可以以预定周期查询会话队列的状态，也可以在每次推送日志内容后查询会话队列的状态。

在具体实施时，在查询到会话队列的状态为失效时，还可以开始失效计数检测；在失效检测期间，Agent可以仍然将新收集的日志内容发送给日志服务器；在失效次数达到预先设定的阈值时，日志Agent停止收集和推送日志内容。

采用本申请实施例中的应用日志的收集方法，即使客户端异常停止或是客户端与日志服务器之间的通信通道出现问题，Agent将仍然保持与日志服务器的通信，直到该失效计数超过预先设定的阈值。如果客户端在超时时间内重新连接上日志服务器，该会话仍然有效。

图3为本申请实施例二所示的应用日志的收集方法流程图。

如图3所示，本申请实施例二所示的应用日志的收集方法包括以下步骤：

S302，日志服务器根据接收到来自客户端的日志获取请求的第一时刻，确定会话队列的状态，其中，会话队列中存储：日志获取请求对应的日志内容；

S304，接收Agent对会话队列的状态查询；

S306，将会话队列的状态反馈给Agent。

在具体实施时，客户端是用户用来查看日志文件的工具；用户可以通过客户端查看某台计算机上某个应用的日志文件的列表，打开日志文件查看日志内容，或是设置日志文件收集配置等；在具体实施时，客户端可以是浏览器或是定制的PC端软件。

在具体实施时，日志服务器为每一个应用的日志文件分配一个会话队列，该会话队列用于存储来自Agent收集的应用日志内容。该会话队列支持两种操作：获取get和放入put。Get用于从日志队列中根据位置获取日志内容，put用于将日志消息按照顺序放入日志队列。

优选地，日志服务器根据接收到来自客户端的日志获取请求的时刻确定会话队列的状态具体包括：记录最近一次接收到日志获取请求的第一时刻，并开始第一计时；根据第一时刻和第一计时时长确定会话队列的状态。

在具体实施时，日志服务器可以为每个会话队列维护两个操作时间：获取get时间和放入put时间。Get时间用来保存最近一次的日志获取时间，该日志获取时间可以是接收到来自客户端的日志获取请求或是会话ID的时间；Put时间即是该第一时刻，用来标示最近一次接收到来自Agent的日志内容插入的时间；日志服务器通过Get时间来判断是否有客户端仍然在查询该会话队列的数据，并以此判断会话队列是否有效。

在具体实施时，该第一计时时长可以是预先设置的，也可以是根据经验值计算得到的。

优选地，会话队列为多个，日志获取请求中携带日志内容标识，在日志服务器接收来自客户端的日志获取请求之后，记录最近一次接收到所述日志获取请求的第一时刻，并开始第一计时之前，还包括：根据日志内容标识判断会话队列是否已存在。

优选地，如果判断结果为否，则在记录最近一次接收到日志获取请求的第一时刻，并开始第一计时之前，方法还包括：创建日志内容对应的会话队列。

在具体实施时，如果是客户端第一次向日志服务器发起请求，则该日志内容标识可以是日志所在计算机的唯一标识和日志文件路径；如果客户端已获知日志服务器中存在相应日志内容的会话队列，则该日志内容标识可以是之前获取的会话队列的ID等；本领域技术人员应当理解，该日志获取请求能够唯一标识待获取的日志内容，使日志服务器确定相应的会话队列即可。

采用本申请实施例中的应用日志的收集方法，日志服务器根据接收到日志获取请求的时刻来确定会话队列的状态，并将该状态反馈给Agent；从而使得Agent能够获知停止收集日志的时机，避免Agent所在的计算机的资源浪费，提高计算机资源的利用率。

另外，采用相关技术中的应用日志的收集方法，需要为每一个用户建立一条日志通道来传输日志内容。在不同的用户请求同一个应用日志的情况下，会导致Agent反复向不同的客户端发送同样的数据，从而导致Agent所在的计算机的资源的浪费。

而采用本申请实施例中的应用日志的收集方法，日志服务器将来自Agent的日志内容存储在会话队列中，各客户端直接从日志服务器上获取日志内容，所以各Agent只需要向日志服务器发送一次日志内容即可，能够节约Agent所在的计算机的资源。

在具体实施时，日志服务器接受到客户端的日志获取请求后判断是否已经存在用于存储该待获取日志内容的会话队列；如果有，则返回日志会话ID，日志客户端使用该会话ID开始查询日志内容，否则，日志服务器创建一个新的会话队列。

优选地，如果判断结果为是，则记录最近一次接收到所述日志获取请求的第一时刻，并开始第一计时具体包括：更新接收到的日志获取请求的第一时刻，并重启第一计时。

在具体实施时，该Get时间和Put时间可以是一个时间序列，分别记录了每次接收到的日志获取请求的时刻和每次接收到日志内容的时刻，也可以是一个时间值，在每次新接收到日志获取请求和每次接收到日志内容后，进行更新。

在具体实施时，该第一计时可以是与每个日志获取请求相对应的多个，每个日志获取请求触发一个计时，但在接收到新的日志获取请求后，该计时停止，并启动另一个计时；该计时也可以是一个，该计时受日志获取请求触发，并在接收到新的日志获取请求后归零并重新开始计时。为减少日志服务器的资源消耗，每个会话队列优选维护一个Get时间和一个计时。

优选地，根据第一时刻和第一计时时长确定会话队列的状态具体包括：在计时时长达到预定时长时，将会话队列的状态设置为失效，否则将会话队列的状态设置为有效。

在具体实施时，该预定时长可以是预先设置的，也可以是根据经验值计算得到的。计时时长达到预先设置的预定时长表明在预定时间内没有客户端来拉取日志内容。

采用本申请实施例中的应用日志的收集方法，日志服务器根据接收到日志获取请求时间来确定会话队列是否失效，当有一个客户端在查询日志队列，该会话队列就将保持有效，从而有效的解决并发环境下协同的问题。

优选地，根据本申请实施例的应用日志的收集方法还包括：记录最近一次将日志内容存储至会话队列的第二时刻，并开始第二计时；在第二计时时长超过预定阈值时，关闭会话队列。

在具体实施时，日志服务器在会话队列失效后，还可以进一步根据Put操作的最近一次更新时刻，即，第二时刻来判断是否关闭会话队列。当最近一次Put时间已经超过预定的时长没有更新后，判断Agent已经停止Put操作，日志服务器关闭会话队列，并清除会话队列中的日志内容。

优选地，根据本申请实施例的应用日志的收集方法还包括：接收来自Agent的日志内容；将日志内容存储至相应的会话队列。

在具体实施时，日志服务器可以将来自客户端的日志获取请求放入Agent的任务队列中，Agent从任务队列提取任务，根据任务指令开始推送日志内容给日志服务器；日志服务器为每一个日志会话保存一个会话队列，Agent发送的日志数据都会保存在相应的日志队列中；日志服务器在接收到日志内容后，将该日志内容放入相应的会话队列，并更新Put时间。

采用相关技术中的应用日志的收集方法，在某些安全性要求较高的场景下将存在无法获取应用日志的情况，例如，某些应用所在的计算机不允许用户客户端连接并获取信息。比如，在VPC环境下，缺省情况下所有应用对外接收请求的端口都是封闭的，此时，客户端与Agent之间无法建立可信的通信通道，也无法实时获取日志文件。

而采用本申请实施例中的应用日志的收集方法，日志Agent不会对外开放 任何端口。下发日志收集指令时，日志服务器会将该指令存入Agent的任务队列，Agent会从自己的日志队列中提取指令。在推送日志数据时，日志Agent会将日志内容推送到日志服务器。该设计不需要日志Agent开放任何端口，所以能够更好的适应安全性要求高的环境。

优选地，根据本申请实施例的应用日志的收集方法还包括：接收来自客户端的日志获取请求；根据接收到日志获取请求的第一时刻和将日志获取请求对应的日志内容存储至会话队列的第二时刻，在会话队列中确定客户端请求的日志内容；将确定的日志内容发送给客户端。

在具体实施时，日志服务器接收到新的日志内容后，将日志内容存入对应的会话队列，还可以更新Put操作时间。

在具体实施时，该第一时刻即是Get时间，该第二时刻为Put时间。日志服务器通过Put时间来判断是否有新的日志内容插入会话队列。日志服务器接收到客户端的日志获取请求后，首先更新Get时间，即表明会话队列状态仍然有效，然后根据该Get时间和Put时间判断在会话队列中是否存在未获取的新日志内容，如果存在，则返回给日志客户端。例如，上一次的Get时间是1：00，而最近一次的Put时间为2：00，最近一次的Get时间为2：10，说明存在未获取的新的日志内容，日志服务器可以将2：00的Put操作放入的日志内容发送给客户端；如果上一次的Get时间是1：00，而最近一次的Put时间为0：30，最近一次的Get时间为1：10，说明不存在未获取的新的日志内容。

采用本申请实施例中的应用日志的收集方法，日志服务器对会话队列的处理只依赖于最基本的Get和Put操作，不依赖于任何显式指令；有效解决了在不稳定的网络环境下实时日志获取的问题。

图4为本申请实施例三所示的应用日志的发送方法流程图。

如图4所示，本申请实施例三所示的应用日志的收集方法包括以下步骤：

S402，接收来自客户端的日志获取请求，日志获取请求携带日志内容标识；

S404，根据日志内容标识查询日志服务器是否存在对应的会话队列；

S406，如果存在，则将对应的会话队列中的日志内容发送给客户端。

在具体实施时，本申请实施例中的应用日志的收集方法可以应用于日志服务器，也可以独立于日志服务器以外实施。

优选地，如果不存在，则创建日志获取请求对应的会话队列。

优选地，该日志内容标识为会话队列标识。

在具体实施时，如果是客户端第一次向日志服务器发起请求，则该日志内容标识可以是日志所在计算机的唯一标识和日志文件路径；如果客户端已获知日志服务器中存在相应日志内容的会话队列，则该日志内容标识可以是之前获取的会话队列的ID等的会话队列标识；本领域技术人员应当理解，该日志获取请求能够唯一标识待获取的日志内容，使日志服务器确定相应的会话队列即可。

采用本申请实施例中的应用日志的收集方法，根据接收到日志获取请求中的日志内容标识来确定相应的会话队列，并将该会话队列中的日志内容发送给客户端，在多个用户请求同一日志内容的情况下，各客户端能够直接从日志服务器中的存储该日志内容的会话队列中获取日志内容，所以各Agent只需要向日志服务器发送一次日志内容即可，能够节约Agent所在的计算机的资源。

基于同一发明构思，本申请实施例中还提供了一种日志收集装置，由于该装置解决问题的原理与本申请实施例所一提供的应用日志收集方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

图5为本申请实施例四所示应用日志收集装置的结构示意图。

如图5所示，本申请实施例四所示应用日志收集装置500，包括：查询模块502，用于查询日志服务器中会话队列的状态，其中，会话队列中存储日志内容，会话队列的状态是日志服务器根据接收到来自客户端的日志获取请求的第一时刻确定的；确定模块504，用于根据会话队列的状态触发代理端Agent 收集或停止收集应用日志。

在具体实施时，该日志收集装置可与Agent合设，也可以独立于Agent，本申请对此不作限制。

优选地，确定模块具体包括：第一触发子模块，用于在会话队列的状态为有效时，触发Agent收集应用日志；第二触发子模块，用于在会话队列的状态为失效时，触发Agent停止收集应用日志。

采用本申请实施例中的应用日志收集装置，查询日志服务器中存储相应日志内容的会话队列的状态，该状态是根据客户端的日志获取请求的时刻确定的，并根据该状态来确定是否收集应用日志；从而使得Agent能够获知停止收集日志的时机，避免Agent所在的计算机的资源的浪费，提高计算机资源的利用率。

采用本申请实施例中的应用日志收集装置，即使Agent与日志服务器之间的通信通道出现问题，虽然日志内容无法传输到日志服务器，但是由于客户端一直在发送日志获取请求，使得日志服务器中的会话队列的状态不变，此时Agent将仍然收集日志内容，如果在超时重试时间内，Agent与日志服务器之间的通信通道能够恢复，客户端仍然能够得到新的日志内容，提升了用户体验。

基于同一发明构思，本申请实施例中还提供了一种日志服务器，该服务器解决问题的原理与本申请实施例二所提供的应用日志收集方法相似，因此该服务器的实施可以参见方法的实施，重复之处不再赘述。

图6为本申请实施例五所示日志服务器的结构示意图。

如图6所示，本申请实施例四所示日志服务器600，包括：会话队列状态确定模块602，用于根据接收到来自客户端的日志获取请求的第一时刻，确定会话队列的状态，其中，会话队列中存储：日志获取请求对应的日志内容；第一接收模块604，用于接收Agent对会话队列的状态查询；状态反馈模块606，用于将会话队列的状态反馈给所述Agent。

优选地，所述会话队列状态确定模块具体包括：第一时刻记录子模块，用 于记录最近一次接收到日志获取请求的第一时刻；第一计时子模块，用于开始第一计时；状态确定子模块，用于根据第一时刻和第一计时时长确定会话队列的状态。

优选地，会话队列为多个，日志获取请求中携带日志内容标识，日志服务器还包括：判断模块，用于根据日志内容标识判断会话队列是否已存在。

优选地，当判断模块的判断结果为是时，第一时刻记录子模块进一步用于更新接收到的日志获取请求的第一时刻，第一计时子模块进一步用于重启第一计时。

优选地，状态确定子模块具体包括：预定时长设置单元，用于设置预定时长；状态设置单元，用于在计时时长达到预定时长时，将会话队列的状态设置为失效，否则将会话队列的状态设置为有效。

优选地，本申请实施例四所示的日志服务器还包括：第二时刻记录模块，用于记录最近一次将所述日志内容存储至会话队列的第二时刻，并开始第二计时；会话关闭模块，用于在所述第二计时时长超过预定阈值时，关闭会话队列。

优选地，如果判断结果为否，则服务器还包括：创建模块，用于创建日志内容对应的会话队列。

优选地，本申请实施例四所示的日志服务器还包括：第二接收模块，用于接收来自Agent的日志内容；存储模块，用于将日志内容存储至相应的会话队列。

优选地，本申请实施例四所示的日志服务器还包括：第三接收模块，用于接收来自客户端的日志获取请求；日志内容确定模块，用于根据接收到日志获取请求的第一时刻和将日志获取请求对应的日志内容存储至会话队列的第二时刻，在会话队列中确定客户端请求的日志内容；第一发送模块，用于将确定的日志内容发送给客户端。

采用本申请实施例中的应用日志服务器，根据接收到日志获取请求的时刻来确定会话队列的状态，并将该状态反馈给Agent；从而使得Agent能够获知 停止收集日志的时机，避免Agent所在的计算机的资源浪费，提高计算机资源的利用率。

采用本申请实施例中的应用日志服务器，将来自Agent的日志内容存储在会话队列中，各客户端直接从日志服务器上获取日志内容，所以各Agent只需要向日志服务器发送一次日志内容即可，能够节约Agent所在的计算机的资源。

基于同一发明构思，本申请实施例中还提供了一种应用日志发送装置，该装置解决问题的原理与本申请实施例三所提供的应用日志发送方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

图7为本申请实施例六所示应用日志发送装置的结构示意图。

如图7所示，本申请实施例六所示应用日志发送装置700包括：第三接收模块702，用于接收来自客户端的日志获取请求，日志获取请求携带日志内容标识；查询模块704，用于根据日志内容标识查询日志服务器是否存在对应的会话队列；第二发送模块706，用于在存在时，将对应的会话队列中的日志内容发送给客户端。

优选地，本申请实施例六所示应用日志发送装置700还包括：创建模块，用于在不存在时，创建日志获取请求对应的会话队列。

优选地，日志内容标识为会话队列标识。

采用本申请实施例中的应用日志收集装置，根据接收到日志获取请求中的日志内容标识来确定相应的会话队列，并将该会话队列中的日志内容发送给客户端，在多个用户请求同一日志内容的情况下，各客户端能够直接从日志服务器中的存储该日志内容的会话队列中获取日志内容，所以各Agent只需要向日志服务器发送一次日志内容即可，能够节约Agent所在的计算机的资源。

基于同一发明构思，本申请实施例中还提供了一种应用日志收集系统，该系统解决问题的原理与本申请实施例中所提供的应用日志的收集、发送方法相 似，因此该系统的实施可以参见方法的实施，重复之处不再赘述。

图8为本申请实施例七所示应用日志收集系统的结构示意图。

如图8所示，本申请实施例七所示应用日志收集系统800包括：客户端802，向日志服务器发送日志获取请求，并从日志服务器接收日志内容；日志服务器600；应用日志发送装置700；包括日志收集装置500的Agent 804。

在具体实施时，客户端是用户用来查看日志文件的工具；用户可以通过客户端查看某台计算机上应用日志的列表、打开列表查看日志内容、或是设置应用日志收集配置等；客户端可以是浏览器或是定制的PC端软件。

在具体实施时，日志服务器从客户端接受日志获取请求，并将该请求转化为日志收集指令，并推送到Agent；日志服务器可以为每一个日志获取请求保存一个会话队列，Agent发送的日志内容都保存在会话队列中。日志服务器可以存储最新日志放入操作Put与最新日志获取操作Get的时间，并以Get时间为依据来判断会话队列是否失效；同时，还以Get时间和Put时间为依据来判断是否关闭会话队列。日志服务器还可以存储每一台计算机上应用日志的基本信息，例如，应用日志的名称、路径、大小等。

在具体实施时，Agent并不直接和客户端交互，而是从日志服务器接受日志收集指令，Agent在接收日志收集指令后，可以实时将日志内容发送给日志服务器。Agent可以周期性的查询日志服务器中会话队列的状态，当状态为失效(即没有客户端来拉取日志)时，Agent会停止收集日志。

在具体实施时，该应用日志发送装置700可以与日志服务器600合设。

在具体实施时，客户端与包括日志发送装置的日志服务器之间的交互流程如图9所示。

如图9所示，客户端与日志服务器之间的交互流程包括以下步骤：

S902，用户通过客户端发送日志获取请求给日志服务器，该请求可以包含日志所在计算机的唯一标示和日志文件路径；

S904，日志服务器判断是否已经有一个会话队列在存储该应用的日志内容； 如果否，则执行906；如果有，则执行908；

S906，日志服务器创建一个新的会话队列，并为该会话队列分配一个唯一的ID；该会话队列维护日志内容队列和日志操作时间。日志内容队列用于在内存中临时存储收集的日志内容，该队列只支持两种操作：get和put。Get用于从队列中根据位置获取日志内容，put用于将日志内容按照顺序放入队列。日志操作时间分为两种：get时间和put时间。Get时间用来保存最近一次日志获取的时间，Put时间用来标示最近一次日志放入的时间。日志服务器通过Get时间来判断是否有客户端仍然在查询会话队列的数据，以此判断会话队列的状态是否有效，通过Put时间来判断是否有新的日志内容放入队列。

S908，返回会话队列的ID；

S910，客户端使用会话队列ID查询是否有新的日志内容。

S912，日志服务器接收到请求后，更新Get时间；

S914，判断在会话队列中是否存在新的日志内容，如果存在，则执行716；如果不存在，则执行718；

S916，将日志内容返回给日志客户端；

S918，返回不存在新的日志内容；

S920，客户端接收到新的日志项后，显示在界面上。如果完成任务，用户可以直接关闭客户端，而不需要发送停止收集的指令。

在具体实施时，日志服务器与Agent之间的交互流程如图10所示。

如图10所示，日志服务器与Agent之间的交互流程包括以下步骤：

S1002，日志服务器在接收到来自客户端的日志获取请求后，判断相应的会话队列是否存在；如果不存在，则执行1004，如果存在，则发送相应的日志内容至客户端；

S1004，日志服务器创建新的会话队列，并生成相应的日志收集指令；

S1006，日志服务器将日志收集指令放入Agent的任务队列；该日志收集指令至少包括日志文件路径和日志收集配置(如日志文件扫描频率、日志级别、 初始日志行数等)；

S1008，Agent从自己的任务队列中获取日志收集指令，启动日志收集任务；

S1010，Agent开始监听日志文件；

S1012，根据日志收集配置发送若干已有日志内容和新的日志内容到日志服务器；

S1014，日志服务器接收到新的日志内容后，会将日志内容存入对应的会话队列，并更新日志Put时间；下一次日志客户端请求时，服务器会返回新的日志内容；

S1016，Agent周期性向日志服务器查询会话队列的状态；

S1018，日志服务器向Agent反馈会话队列的状态；

S1020，如果会话状态为失效，则Agent开始失效计数检测；如果会话状态为有效，则重复S1012-S1018；

S1022，在失效检测期间，Agent仍然将新收集到的日志内容发送给日志服务器；

S1024，在失效次数达到预先设定的阈值时，Agent停止收集日志内容，并停止日志推送工作；

S1026，日志服务器根据Get时间和Put时间来判断是否关闭会话队列；在根据Get时间判断会话队列失效后，进一步在Put时间超过预先设定的值后，日志服务器关闭该会话队列，并清除相关的数据。

采用本申请实施例中的应用日志收集系统，是否收集应用日志只依赖于客户端的Get操作和Agent的Put操作。即使Agent与日志服务器之间的通信通道出现问题，造成日志客户端无法获取到最新的日志数据，但是只要客户端的Get操作一直在进行，则该会话队列会一直保留在日志服务器中。待Agent与日志服务器之间的通信通道恢复后，客户端仍然能够得到新的日志内容。

采用本申请实施例中的应用日志收集系统，日志服务器将日志收集指令存入Agent的任务队列，Agent从自己的日志队列中提取指令；在推送日志数据 时，Agent将日志内容推送到日志服务器；所以不需要Agent开放任何端口，能够更好的适应安全性要求高的环境。

采用本申请实施例中的应用日志收集系统，在多个日志客户端请求查看同一个应用日志文件的场景下，客户端可以从日志服务器上获取内容，Agent只需要向日志服务器发送一次日志内容，能够很好的节约系统资源。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (29)

1.一种应用日志的收集方法，其特征在于，包括：

查询日志服务器中会话队列的状态，其中，所述会话队列中存储日志内容，所述会话队列的状态是日志服务器根据接收到来自客户端的日志获取请求的第一时刻确定的；

根据所述会话队列的状态触发代理端Agent收集或停止收集应用日志。

2.根据权利要求1所述的方法，其特征在于，根据所述会话队列的状态触发代理端Agent收集或停止收集应用日志，具体包括：

当所述会话队列的状态为有效时，触发代理端Agent收集应用日志；

当所述会话队列的状态为失效时，触发代理端Agent停止收集应用日志。

3.一种应用日志的收集方法，其特征在于，包括：

日志服务器根据接收到来自客户端的日志获取请求的第一时刻，确定会话队列的状态，其中，所述会话队列中存储：所述日志获取请求对应的日志内容；

接收Agent对所述会话队列的状态查询；

将所述会话队列的状态反馈给所述Agent。

4.根据权利要求3所述的方法，其特征在于，日志服务器根据接收到来自客户端的日志获取请求的第一时刻确定会话队列的状态，具体包括：

记录最近一次接收到所述日志获取请求的第一时刻，并开始第一计时；

根据所述第一时刻和第一计时时长确定所述会话队列的状态。

5.根据权利要求4所述的方法，其特征在于，所述会话队列为多个，所述日志获取请求中携带日志内容标识，在日志服务器接收来自客户端的日志获取请求之后，记录最近一次接收到所述日志获取请求的第一时刻，并开始第一计时之前，还包括：

根据所述日志内容标识判断所述会话队列是否已存在。

6.根据权利要求5所述的方法，其特征在于，如果判断结果为是，则记录最近一次接收到所述日志获取请求的第一时刻，并开始第一计时，具体包括：

更新接收到的所述日志获取请求的第一时刻，并重启第一计时。

7.根据权利要求4至6任一项所述的方法，其特征在于，根据所述第一时刻和第一计时时长确定会话队列的状态，具体包括：

在所述第一计时时长达到预定时长时，将所述会话队列的状态设置为失效，否则将所述会话队列的状态设置为有效。

8.根据权利要求7所述的方法，其特征在于，还包括：

记录最近一次将所述日志内容存储至会话队列的第二时刻，并开始第二计时；

在第二计时时长超过预定阈值时，关闭会话队列。

9.根据权利要求5所述的方法，其特征在于，如果判断结果为否，则在记录最近一次接收到所述日志获取请求的第一时刻，并开始第一计时之前，所述方法还包括：

创建所述日志内容对应的会话队列。

10.根据权利要求3所述的方法，其特征在于，还包括：

接收来自Agent的日志内容；

将所述日志内容存储至相应的会话队列。

11.根据权利要求8所述的方法，其特征在于，还包括：

接收来自客户端的日志获取请求；

根据接收到所述日志获取请求的第一时刻和将所述日志获取请求对应的日志内容存储至会话队列的第二时刻，在会话队列中确定所述客户端请求的日志内容；

将确定的日志内容发送给所述客户端。

12.一种应用日志的发送方法，其特征在于，包括：

接收来自客户端的日志获取请求，所述日志获取请求携带日志内容标识；

根据所述日志内容标识查询日志服务器是否存在对应的会话队列；

如果存在，则将对应的会话队列中的日志内容发送给所述客户端。

13.根据权利要求12所述的方法，其特征在于，如果不存在，则创建所述日志获取请求对应的会话队列。

14.根据权利要求12所述的方法，其特征在于，所述日志内容标识为会话队列标识。

15.一种应用日志收集装置，其特征在于，包括：

查询模块，用于查询日志服务器中会话队列的状态，其中，所述会话队列中存储日志内容，所述会话队列的状态是日志服务器根据接收到来自客户端的日志获取请求的第一时刻确定的；

确定模块，用于根据所述会话队列的状态触发代理端Agent收集或停止收集应用日志。

16.根据权利要求15所述的装置，其特征在于，确定模块具体包括：

第一触发子模块，用于在所述会话队列的状态为有效时，触发所述Agent收集应用日志；

第二触发子模块，用于在所述会话队列的状态为失效时，触发所述Agent停止收集应用日志。

17.一种日志服务器，其特征在于，包括：

会话队列状态确定模块，用于根据接收到来自客户端的日志获取请求的第一时刻，确定会话队列的状态，其中，所述会话队列中存储：所述日志获取请求对应的日志内容；

第一接收模块，用于接收Agent对所述会话队列的状态查询；

状态反馈模块，用于将所述会话队列的状态反馈给所述Agent。

18.根据权利要求17所述的服务器，其特征在于，所述会话队列状态确定模块具体包括：

第一时刻记录子模块，用于记录最近一次接收到所述日志获取请求的第一时刻；

第一计时子模块，用于开始第一计时；

状态确定子模块，用于根据所述第一时刻和第一计时时长确定所述会话队列的状态。

19.根据权利要求18所述的服务器，其特征在于，所述会话队列为多个，所述日志获取请求中携带日志内容标识，所述服务器还包括：

判断模块，用于根据所述日志内容标识判断所述会话队列是否已存在。

20.根据权利要求19所述的服务器，其特征在于，当所述判断模块的判断结果为是时，所述第一时刻记录子模块进一步用于更新接收到的所述日志获取请求的第一时刻，所述第一计时子模块进一步用于重启第一计时。

21.根据权利要求18至20中任一项所述的服务器，其特征在于，所述状态确定子模块具体包括：

预定时长设置单元，用于设置预定时长；

状态设置单元，用于在所述计时时长达到所述预定时长时，将所述会话队列的状态设置为失效，否则将所述会话队列的状态设置为有效。

22.根据权利要求21所述的服务器，其特征在于，还包括：

第二时刻记录模块，用于记录最近一次将所述日志内容存储至会话队列的第二时刻，并开始第二计时；

会话关闭模块，用于在第二计时时长超过预定阈值时，关闭会话队列。

23.根据权利要求21所述的服务器，其特征在于，如果判断结果为否，则所述服务器还包括：

创建模块，用于创建所述日志内容对应的会话队列。

24.根据权利要求17所述的服务器，其特征在于，还包括：

第二接收模块，用于接收来自Agent的日志内容；

存储模块，用于将所述日志内容存储至相应的会话队列。

25.根据权利要求19所述的服务器，其特征在于，还包括：

第三接收模块，用于接收来自客户端的日志获取请求；

日志内容确定模块，用于根据接收到所述日志获取请求的第一时刻和将所述日志获取请求对应的日志内容存储至会话队列的第二时刻，在会话队列中确定所述客户端请求的日志内容；

第一发送模块，用于将确定的日志内容发送给所述客户端。

26.一种应用日志发送装置，其特征在于，包括：

第三接收模块，用于接收来自客户端的日志获取请求，所述日志获取请求携带日志内容标识；

查询模块，用于根据所述日志内容标识查询日志服务器是否存在对应的会话队列；

第二发送模块，用于在存在时，将对应的会话队列中的日志内容发送给所述客户端。

27.根据权利要求26所述的装置，其特征在于，还包括：创建模块，用于在不存在时，创建所述日志获取请求对应的会话队列。

28.根据权利要求26所述的装置，其特征在于，所述日志内容标识为会话队列标识。

29.一种应用日志收集系统，其特征在于，包括：

客户端，向日志服务器发送日志获取请求，并从日志服务器接收日志内容；

如权利要求17-25中任一项所述的日志服务器；

如权利要求26-28中任一项所述的日志发送装置；

包括如权利要求15-16中任一项所述的日志收集装置的Agent。