CN112800017B - 分布式日志采集方法、装置、介质及电子设备 - Google Patents

Abstract

本公开的实施方式提供了一种分布式日志采集方法、装置、介质及电子设备，涉及数据处理技术领域。该方法应用于分布式代理服务器，包括：响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则；根据目标采集规则启动日志采集任务；确定日志采集任务针对的待采集日志文件的当前文件类型；根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。本公开通过检测规则更新状态获取日志采集规则以对各分布式代理服务器的规则进行配置，同时根据日志文件的当前文件类型动态采用对应的采集策略进行日志采集，可以有效兼顾日志采集时效性和资源占用率。

Description

分布式日志采集方法、装置、介质及电子设备

技术领域

本公开的实施方式涉及数据处理技术领域，更具体地，本公开的实施方式涉及分布式日志采集方法、分布式日志采集装置、计算机可读存储介质及电子设备。

背景技术

本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

日志采集是数据仓库建设中数据集成部分的一个重要环节，其目的是将散落在数以千计的应用服务器上的日志文件数据集中采集至消息队列或其他数据存储模块中，方便后续的日志数据处理与分析。

目前，常用的日志采集系统包括Flume和Filebeat、Fluentd等。Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统，支持在日志系统中定制各类数据发送方，用于收集数据，并写到各种数据接受方的能力。Filebeat、Fluentd也是市面上流行的日志采集Agent。Filebeat可由Kibana组件进行配置管理，但部署Filebeat仍需人工手动，使用定时扫描方式采集文件。

发明内容

而且，采用上述日志采集系统还存在下述问题：(1)传统的日志采集代理进程(Agent)默认只提供了单机部署与配置的使用方式。在实际的生产环境中，往往需要对大量的应用服务器进行日志采集工作，因此，现有的日志采集Agent往往无法实现大规模的Agent部署以及后续大规模采集规则的配置。(2)在实时数据仓库的场景下，为了满足用户对日志较高时效性要求所采用的单一采集策略，可能导致日志采集延迟或资源占用率过高的问题。(3)当日志采集Agent下游数据接收者出现故障或性能问题时，Agent需要暂时停止将数据发送至下游。基于数据缓存的下游故障处理策略可能造成Agent内存溢出或机器磁盘空间打满的问题。

由此，在现有技术中，缺乏一种可以实现有效管理分布式代理服务器中采集规则配置，能够兼顾日志采集时效性和Agent资源占用率，同时可以保障数据完整性的日志采集方案。

为此，非常需要一种改进的分布式日志采集方法，以使分布式代理服务器可以通过监测规则更新状态以获取对应的日志采集规则，并且可以根据待采集日志文件的当前文件类型调用相应的采集策略进行日志采集，以在日志采集时效性和Agent资源占用率之间达到平衡。

在本上下文中，本公开的实施方式期望提供一种分布式日志采集方法、分布式日志采集装置、计算机可读存储介质及电子设备。

在本公开实施方式的第一方面中，提供了一种分布式日志采集方法，应用于分布式代理服务器，包括：响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则；根据目标采集规则启动日志采集任务；确定日志采集任务针对的待采集日志文件的当前文件类型；根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。

在本公开的一个实施例中，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则，包括：确定与分布式代理服务器对应的规则节点；监测规则节点的节点状态；节点状态包含规则更新状态；如果规则更新状态存在状态更新变化，则根据规则节点从子域管理服务器获取目标采集规则；子域管理服务器用于与规则节点以及处于分布式代理服务器所在域之外的采集规则服务器进行通信。

在本公开的一个实施例中，根据规则节点从子域管理服务器获取目标采集规则，包括：从规则节点获取目标规则版本号；目标规则版本号由采集规则服务器通过子域管理服务器发送至规则节点；根据目标规则版本号从子域管理服务器获取目标采集规则。

在本公开的一个实施例中，根据目标规则版本号从子域管理服务器获取目标采集规则，包括：获取分布式代理服务器的生效采集规则，并确定生效采集规则对应的生效规则版本号；对比生效规则版本号和目标规则版本号；如果生效规则版本号小于目标规则版本号，则根据目标规则版本号从子域管理服务器中获取目标采集规则；将目标规则版本号确定为新的生效规则版本号，并将新的生效规则版本号同步至与分布式代理服务器对应的状态节点。

在本公开的一个实施例中，根据目标采集规则启动日志采集任务，包括：由子域管理服务器获取状态节点的状态节点信息；状态节点信息包含与日志采集任务对应的一个或多个分布式代理服务器的生效规则版本号；如果每个分布式代理服务器的生效规则版本号均大于目标规则版本号，则启动日志采集任务。

在本公开的一个实施例中，确定日志采集任务针对的待采集日志文件的当前文件类型，包括：确定待采集日志文件的文件内数据的当前生成速率；如果当前生成速率大于第一预设阈值，则将当前文件类型确定为快作业；如果当前生成速率小于等于第一预设阈值，则将当前文件类型确定为慢作业；如果待采集日志文件在第一时间阈值内未产生新的文件数据，则将当前文件类型确定为不活跃作业。

在本公开的一个实施例中，文件类型为快作业，根据当前文件类型所对应的采集策略进行日志采集操作，包括：确定待采集日志文件中包含的快作业集合；快作业集合包括一个或多个快作业；将一个或多个快作业推送至快作业队列；每隔第一预设时间从快作业队列中获取目标快作业，以对目标快作业进行日志采集操作。

在本公开的一个实施例中，文件类型为慢作业，根据当前文件类型所对应的采集策略进行日志采集操作，包括：监测慢作业的作业状态；如果慢作业的作业状态产生状态变化，则触发执行日志采集操作；获取待采集日志文件中未执行慢作业的慢作业数量；如果慢作业数量超过慢作业数量阈值，则根据慢作业数量和慢作业数量阈值确定待转换慢作业数量；将超过慢作业数量阈值的待转换慢作业转换为快作业。

在本公开的一个实施例中，文件类型为不活跃作业，根据当前文件类型所对应的采集策略进行日志采集操作，包括：每隔第二预设时间确定不活跃作业的总作业量，并确定不活跃作业的已采集作业量；如果不活跃作业的总作业量大于已采集作业量，则将不活跃作业转换为快作业，以进行日志采集操作。

在本公开的一个实施例中，在得到目标日志信息之后，上述方法还包括：确定接收目标日志信息的文件接收服务器，并获取文件接收服务器的缓冲区数值；根据缓冲区数值向文件接收服务器发送目标日志信息；根据文件接收服务器接收到的目标日志信息的数据量更新缓冲区数值。

在本公开的一个实施例中，上述方法还包括：监测文件接收服务器的服务器状态信息；如果服务器状态信息为服务器状态处于故障状态，则将待采集日志文件的文件状态确定为阻塞状态；如果文件状态处于阻塞状态，且服务器状态由故障状态切换为正常状态，则将文件状态由阻塞状态转换为采集状态，以进行日志采集操作。

在本公开实施方式的第二方面中，提供了一种分布式日志采集装置，应用于分布式代理服务器，包括：采集规则确定模块，用于响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则；任务启动模块，用于根据目标采集规则启动日志采集任务；文件类型确定模块，用于确定日志采集任务针对的待采集日志文件的当前文件类型；日志采集模块，用于根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。

在本公开的一个实施例中，采集规则确定模块包括采集规则确定单元，采集规则确定单元包括：规则节点确定单元，用于确定与分布式代理服务器对应的规则节点；节点状态监测单元，用于监测规则节点的节点状态；节点状态包含规则更新状态；规则获取单元，用于如果规则更新状态存在状态更新变化，则根据规则节点从子域管理服务器获取目标采集规则；子域管理服务器用于与规则节点以及处于分布式代理服务器所在域之外的采集规则服务器进行通信。

在本公开的一个实施例中，规则获取单元包括规则获取子单元，规则获取子单元包括：版本号获取子单元，用于从规则节点获取目标规则版本号；目标规则版本号由采集规则服务器通过子域管理服务器发送至规则节点；采集规则获取子单元，用于根据目标规则版本号从子域管理服务器获取目标采集规则。

在本公开的一个实施例中，采集规则获取子单元被配置为：获取分布式代理服务器的生效采集规则，并确定生效采集规则对应的生效规则版本号；对比生效规则版本号和目标规则版本号；如果生效规则版本号小于目标规则版本号，则根据目标规则版本号从子域管理服务器中获取目标采集规则；将目标规则版本号确定为新的生效规则版本号，并将新的生效规则版本号同步至与分布式代理服务器对应的状态节点。

在本公开的一个实施例中，任务启动模块包括任务启动单元，任务启动单元被配置为：由子域管理服务器获取状态节点的状态节点信息；状态节点信息包含与日志采集任务对应的一个或多个分布式代理服务器的生效规则版本号；如果每个分布式代理服务器的生效规则版本号均大于目标规则版本号，则启动日志采集任务。

在本公开的一个实施例中，文件类型确定模块包括文件类型确定单元，文件类型确定单元被配置为：确定待采集日志文件的文件内数据的当前生成速率；如果当前生成速率大于第一预设阈值，则将当前文件类型确定为快作业；如果当前生成速率小于等于第一预设阈值，则将当前文件类型确定为慢作业；如果待采集日志文件在第一时间阈值内未产生新的文件数据，则将当前文件类型确定为不活跃作业。

在本公开的一个实施例中，日志采集模块包括第一日志采集单元，第一日志采集单元被配置为：确定待采集日志文件中包含的快作业集合；快作业集合包括一个或多个快作业；将一个或多个快作业推送至快作业队列；每隔第一预设时间从快作业队列中获取目标快作业，以对目标快作业进行日志采集操作。

在本公开的一个实施例中，日志采集模块包括第二日志采集单元，第二日志采集单元被配置为：监测慢作业的作业状态；如果慢作业的作业状态产生状态变化，则触发执行日志采集操作；获取待采集日志文件中未执行慢作业的慢作业数量；如果慢作业数量超过慢作业数量阈值，则根据慢作业数量和慢作业数量阈值确定待转换慢作业数量；将超过慢作业数量阈值的待转换慢作业转换为快作业。

在本公开的一个实施例中，日志采集模块包括第三日志采集单元，第三日志采集单元被配置为：每隔第二预设时间确定不活跃作业的总作业量，并确定不活跃作业的已采集作业量；如果不活跃作业的总作业量大于已采集作业量，则将不活跃作业转换为快作业，以进行日志采集操作。

在本公开的一个实施例中，分布式日志采集装置还包括文件接收模块，文件接收模块被配置为：确定接收目标日志信息的文件接收服务器，并获取文件接收服务器的缓冲区数值；根据缓冲区数值向文件接收服务器发送目标日志信息；根据文件接收服务器接收到的目标日志信息的数据量更新缓冲区数值。

在本公开的一个实施例中，分布式日志采集装置还包括采集状态转换模块，采集状态转换模块被配置为：监测文件接收服务器的服务器状态信息；如果服务器状态信息为服务器状态处于故障状态，则将待采集日志文件的文件状态确定为阻塞状态；如果文件状态处于阻塞状态，且服务器状态由故障状态切换为正常状态，则将文件状态由阻塞状态转换为采集状态，以进行日志采集操作。

在本公开实施方式的第三方面中，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述所述的分布式日志采集方法。

在本公开实施方式的第四方面中，提供了一种电子设备，包括：处理器；以及存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如上述所述的分布式日志采集方法。

根据本公开实施方式的技术方案，响应于任务启动请求，通过监测采集规则的规则更新状态可以确定目标采集规则，并启动日志采集任务；根据待采集日志文件的当前文件类型可以确定出对应的采集策略，以进行日志采集操作。一方面，分布式代理服务器通过监测各采集规则的规则更新状态确定出与日志采集任务对应的目标采集规则，以实现在大规模部署了分布式代理服务器的情况下也可以进行对各分布式代理服务器的针对性管理。另一方面，根据确定出的当前文件类型调用对应的采集策略进行日志采集，可以避免像单一采集策略那样反复轮询采集日志文件最新内容所造成的过高资源占用，实现在日志采集时效性与分布式代理服务器资源占用率之间的平衡。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

图1示意性地示出了现有技术中Flume系统的示意框图；

图2示意性地示出了现有技术中Fluentd代理服务器的架构图；

图3示意性地示出了根据本公开的一些实施例的示例性应用场景的系统架构的示意框图；

图4示意性地示出了根据本公开的一些实施例的分布式日志采集方法的流程示意图；

图5示意性地示出了根据本公开的一些实施例的分布式代理服务器的采集规则配置的全链路时序图；

图6示意性地示出了根据本公开的一些实施例的待采集日志文件的分类示意图；

图7示意性地示出了根据本公开的一些实施例的不同作业类型的作业相互切换的流程图；

图8示意性地示出了根据本公开的一些实施例的文件接收服务器接收目标日志信息的工作原理图；

图9示意性地示出了根据本公开的一些实施例的分布式代理服务器的总体架构图；

图10示意性地示出了根据本公开的一些实施例的分布式日志采集装置的示意框图；

图11示意性地示出了根据本公开的示例实施例的存储介质的示意图；以及

图12示意性地示出了根据发明的示例实施例的电子设备的方框图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提出了一种分布式日志采集方法、分布式日志采集装置、介质和电子设备。

在本文中，需要理解的是，所涉及的术语，比如，Agent可以是部署在应用服务器上的日志采集代理进程，负责采集日志文件中的数据；另外，Agent还可以是进行日志采集的分布式代理服务器。Zookeeper是一种分布式一致性协调服务，它是Apache Hadoop的一个子项目，常用于统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。二阶段提交(Two-phase Commit，2PC)可以是为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。

发明概述

日志采集的目的是将散落在数以千计的应用服务器上的日志文件数据集中采集至消息队列或其他数据存储模块中，方便后续的日志数据处理与分析。

在一种技术方案中，可以采用Flume系统进行日志采集。参考图1，图1示意性地示出了现有技术中Flume系统的示意框图。Flume的数据流由事件(Event)表示，Event是Flume的基本数据单位，它携带包含了头信息的日志数据，Event由Agent的数据采集端(Source)生成，Source可以把Event发送至下游的数据隧道(Channel)中，它将保存Event直到汇聚结点(Sink)处理完该Event。

Flume部署和采集规则配置方式均为手工模式，需要用户在应用服务器上手动部署Agent，并配置采集规则。Flume提供了很多内置的Source，其中Taildir Source可实时监控一批文件，并记录每个文件最新消费位置，其实现原理是定时扫描，按时间间隔去判断文件是否有新数据，若没有新数据，则延迟一段时间后再进行检查。当Sink的下游出现故障或数据接收能力小于Source时，Channel负责对未处理的数据进行缓存，支持内存缓存或文件缓存模式。

在另一种技术方案中，将Filebeat、Fluentd等作为日志采集的分布式代理服务器。参考图2，图2示意性地示出了现有技术中Fluentd代理服务器的架构图。Filebeat可由Kibana组件进行配置管理，但部署Filebeat仍需人工手动，使用定时扫描方式采集文件。Fluentd的架构与Flume类似，由输入(Input)、缓冲区(Buffer)、输出(Output)组件构成。Input的in_tail插件同样使用了定时扫描策略对文件内容进行采集，同时Buffer模块支持对数据进行内存缓存或文件缓存。Fluentd同样只限于单机配置，没有集中的配置中心。

首先，上述两种日志采集Agent默认只提供了单机部署与配置的使用方式，用户需要下载软件包至目标应用服务器上进行部署，再根据采集需求配置采集规则。在实际的生产环境中，往往需要对大量的应用服务器进行日志采集工作，为了实现大规模采集规则配置，用户需要结合现有的分布式配置中心组件，并对Agent进行二次开发，例如可以使用Zookeeper集中管理Flume Agent的采集规则，采集规则内容配置在Znode中，Flume Agent监听Znode的状态变化，同步最新的采集规则。但由于Znode对节点数据存储容量存在限制，对于大量的采集规则并不适用这种方案。传统的日志采集Agent缺乏在分布式环境下的采集规则管理方案。

其次，在实时数据仓库的场景下，用户对日志采集的时效性有着非常高的需求。传统日志采集Agent使用的定时扫描策略对于日志采集的时效性少则秒级，多则达到分钟级，显然不能满足实时数据仓库的数据使用场景。有些用户对Agent采集策略进行了二次开发，使用线程轮询策略，即针对每个日志文件，都启动一个单独的线程反复轮询采集日志文件的最新内容，这种方式在日志文件数量较多的情况下，Agent需要占用大量的CPU资源，极端情况下甚至会影响到应用服务器上正常业务应用服务的稳定性。因此，采用单一的采集策略并不能在日志采集时效性和Agent资源占用率上做到很好的平衡。

再次，当日志采集Agent下游数据接收者出现故障或性能问题时，Agent需要暂时停止将数据发送至下游。Flume、Fluentd的处理策略都是由Agent自身进行缓存，例如，提供基于内存的数据缓存或基于本地磁盘持久化缓存，等待下游数据接收者恢复正常后，再继续发送缓存中的数据。在下游数据接收者长时间无法恢复，且上游数据产生量较大时，基于内存的数据缓存容易造成Agent服务自身的内存溢出，造成数据丢失。若使用基于本地磁盘持久化缓存策略，在该情况下Agent需要向本地磁盘写入大量日志数据，容易造成磁盘空间占用过高，当磁盘被打满时就会发生数据丢失现象。通过Agent自身的缓存策略并不能彻底解决数据完整性问题。

基于上述内容，本公开的基本思想在于，响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则；根据目标采集规则启动日志采集任务；确定日志采集任务针对的待采集日志文件的当前文件类型；根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。一方面，分布式代理服务器通过监测各采集规则的规则更新状态确定出与日志采集任务对应的目标采集规则，以实现在大规模部署了分布式代理服务器的情况下也可以进行对各分布式代理服务器的针对性管理。另一方面，根据确定出的当前文件类型调用对应的采集策略进行日志采集，可以避免像单一采集策略那样反复轮询采集日志文件最新内容所造成的过高资源占用，实现在日志采集时效性与分布式代理服务器资源占用率之间的平衡。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。

应用场景总览

首先参考图3，图3示出了可以应用本公开实施例的一种分布式日志采集方法及装置的示例性应用场景的系统架构的示意框图。

如图3所示，系统架构300可以包括终端设备301、302、303中的一个或多个，网络304和服务器305。网络304用以在终端设备301、302、303和服务器305之间提供通信链路的介质。网络304可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端设备301、302、303可以是具有显示屏的各种电子设备，包括但不限于台式计算机、便携式计算机、智能手机和平板电脑等等。服务器305可以是通过部署分布式日志采集进程以进行日志采集操作服务器。应该理解，图3中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器305可以是多个服务器组成的服务器集群等。

本公开实施例所提供的分布式日志采集方法一般由服务器305执行，相应地，分布式日志采集装置一般设置于服务器305中。但本领域技术人员容易理解的是，本公开实施例所提供的分布式日志采集方法也可以由终端设备101、102、103执行，相应的，分布式日志采集装置也可以设置于终端设备101、102、103中，通过部署相应的日志采集进程以进行分布式日志采集，本示例性实施例中对此不做特殊限定。本公开实施例可以让用户通过终端设备301、302、303架构和使用分布式计算平台。

举例而言，在一种示例性实施例中，可以服务器305通过部署的日志采集进程并采用对应的采集策略获取分布存储在终端设备301、302、303中的目标日志信息。通过本公开实施例所提供的分布式日志采集方法，通过部署有分布式日志采集进程的分布式代理服务器305监测采集规则的规则更新状态以获取目标采集规则，并根据目标采集规则启动日志采集任务；根据日志采集任务针对的待采集日志文件的当前文件类型确定对应的采集策略，并根据对应的日志采集策略在终端设备301、302、303等进行日志采集操作，以得到目标日志信息。

应该理解的是，图3所示的应用场景仅是本公开的实施例可以在其中得以实现的一个示例。本公开实施例的适用范围不受到该应用场景任何方面的限制。

示例性方法

下面结合图3的应用场景，参考图4来描述根据本公开示例性实施方式的分布式日志采集方法。需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。

本公开首先提供了一种分布式日志采集方法，该方法执行主体可以是终端设备，也可以是服务器，本公开对此不做特殊限定，本示例实施例中以分布式代理服务器执行该方法为例进行说明。

参照图4所示，在步骤S410中，响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则。

在一些示例实施例中，日志采集任务可以是进行分布式日志采集的任务。任务启动请求可以是启动分布式日志采集任务的请求。采集规则可以是用于确定日志采集任务中待采集日志文件的相关信息的规则。规则更新状态可以是分布式代理服务器中的采集规则的更新状态。目标采集规则可以是本次日志采集任务中特定的分布式代理服务器对应的日志采集规则。

分布式代理服务器在接收到日志采集任务的任务启动请求后，可以响应于任务启动请求，监测分布式代理服务器对应的采集规则的规则更新状态，通过监测各采集规则的规则更新状态规则更新状态，判断分布式代理服务器中的当前的日志采集规则是否需要更新。即确定出分布式代理服务器当前对应的日志采集规则，并判断当前的采集规则是否为与日志采集任务对应的采集规则。如果是，则将当前的日志采集规则作为目标采集规则；如果当前的日志采集规则不是与日志采集任务对应的日志采集规则，则获取目标采集规则，以根据目标采集规则确定日志采集任务对应的待采集日志文件。

在步骤S420中，根据目标采集规则启动日志采集任务。

在一些示例实施例中，由于日志采集任务可能通过一个或多个分布式代理服务器进行日志采集，因此，一个日志采集任务可能对应一个或多个分布式代理服务器。通过检测与日志采集任务对应的所有分布式代理服务器的采集规则的规则更新状态，如果所有分布式代理服务器中的日志采集规则均为与日志采集任务对应的最新日志采集规则，则启动日志采集任务。

在步骤S430中，确定日志采集任务针对的待采集日志文件的当前文件类型。

在一些示例实施例中，待采集日志文件可以是日志采集任务中待进行日志信息采集的日志文件。当前文件类型可以是待采集日志文件当前对应的文件类型。例如，文件类型可以包括快作业文件、慢作业文件和不活跃作业文件等类型。

在日志采集任务启动之后，由于日志采集任务中可以对应一个或多个待采集日志文件，因此，确定出日志采集任务所针对的待采集日志文件的当前文件类型，可以根据确定出的待采集日志文件的当前文件类型进行日志采集。

在步骤S440中，根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。

在一些示例实施例中，采集策略可以是根据待采集日志文件的当前文件类型确定出的进行日志采集的采集方式。日志采集操作可以是获取待采集日志文件的日志信息的操作。目标日志信息可以是待采集日志文件对应的日志信息，目标日志信息可以用于记录待采集日志文件的相关文件信息。

在确定出待采集日志文件对应的当前文件类型后，可以根据当前文件类型确定出对应的采集策略，以根据当前文件类型所对应的采集策略对待采集日志文件进行日志采集操作，得到目标日志信息。根据获取到的目标日志信息可以对日志文件进行分析和后续处理。

在本公开的一个实施例中，确定日志采集任务的目标采集规则可以通过下述步骤进行：确定与分布式代理服务器对应的规则节点；监测规则节点的节点状态；节点状态包含规则更新状态；如果规则更新状态存在状态更新变化，则根据规则节点从子域管理服务器获取目标采集规则；子域管理服务器用于与规则节点以及处于分布式代理服务器所在域之外的采集规则服务器进行通信。

其中，规则节点可以是用于存储目标采集规则对应的规则版本号的节点，规则节点可以是Zookeeper提供的节点。节点状态可以是规则节点的当前状态，节点状态包含规则更新状态。规则更新状态可以反映出日志采集规则是否存在更新，当规则更新状态存在状态更新变化时，可以表示分布式代理服务器对应的日志采集规则的状态发生变化。子域管理服务器可以用于负责与该子域内包含的Zookeeper和子域外的采集规则服务器进行通信。采集规则服务器可以是用于存储用户配置的采集规则的服务器。

分布式代理服务器在确定目标采集规则之前，可以确定与分布式代理服务器对应的规则节点，并监测规则节点的节点状态，节点状态中包括了日志采集规则的规则更新状态。如果监测到规则更新状态存在状态更新变化，则可以说明分布式代理服务器对应的采集规则产生了更新变化，此时，可以通过规则节点获取最新的日志采集规则的相关信息，以根据获取到的规则相关信息从子域管理服务器获取目标采集规则。

参考图5，图5示意性地示出了根据本公开的一些实施例的分布式代理服务器的采集规则配置的全链路时序图。用户可以通过与采集规则服务器520相连的客户端510进行规则配置操作，例如，用户可以通过客户端510按照任务维度配置采集规则，每个日志采集任务下可以配置若干个分布式代理服务器的采集规则。采集规则配置操作完成后，用户可以通过客户端510启动日志采集任务，并将配置完成的采集规则上传至采集规则服务器520。采集规则服务器520将按照Agent维度计算出日志采集任务所关联的Agent需要更新的日志采集规则和相关规则信息，并将确定出的日志采集规则及相关规则信息发送至子域管理服务器530。

由于分布式代理服务器处在不同的网络环境中，分布式代理服务器550无法直接与采集规则服务器通信，所以需要在每个网络子域内引入一个子域管理服务器530，由子域管理服务器530负责与一个子域内的分布式协调服务器540(Zookeeper)和域外的采集规则服务器通信。Zookeeper的命名空间内部拥有一个树状的内存模型，其中各节点被称为Zookeeper节点(Znode)。每个Znode包含一个路径和与之相关的元数据，以及该Znode下关联的子节点列表。子域管理服务器在接收到某个Agent的采集规则后，先将采集规则内容进行缓存，随后将采集规则的更新版本号同步至Zookeeper对应该Agent的规则节点541上，Zookeeper的规则节点的路径可以为/namespace/config/agent_id。另外，在本方案中，规则节点只保存日志采集任务对应的目标规则版本号，采集规则由子域管理服务器维护的方式可以解决Znode大小的限制约束(如1MB)导致大规模日志采集规则无法保存的问题。

因此，当用户启动日志采集任务后，分布式代理服务器550(Agent)将接收并响应于日志采集任务的任务启动请求，可以通过监测规则节点的节点状态，判断采集规则的规则更新状态是否发生变化。如果规则更新状态存在状态更新变化，则分布式代理服务器550可以通过状态节点从子域管理服务器获取与日志采集任务对应的目标采集规则。

在本公开的一个实施例中，根据规则节点从子域管理服务器获取目标采集规则的过程具体如下：从规则节点获取目标规则版本号；目标规则版本号由采集规则服务器通过子域管理服务器发送至规则节点；根据目标规则版本号从子域管理服务器获取目标采集规则。其中，目标规则版本号可以是目标采集规则对应的版本号。当用户配置采集规则时，每一个版本的日志采集规则均可以对应一个规则版本号。

具体的，参考图5，分布式代理服务器550可以通过Zookeeper的监测(Watch)机制监测规则节点的节点状态是否产生规则更新变化，如果规则节点产生规则更新变化，则分布式代理服务器550可以从规则节点中获取目标规则版本号。将获取到的目标规则版本号与分布式代理服务器550中的已生效规则版本号进行对比，以确定是否根据目标规则版本号从子域管理服务器获取目标采集规则。

在本公开的一个实施例中，根据目标规则版本号从子域管理服务器获取目标采集规则通过下述步骤进行：获取分布式代理服务器的生效采集规则，并确定生效采集规则对应的生效规则版本号；对比生效规则版本号和目标规则版本号；如果生效规则版本号小于目标规则版本号，则根据目标规则版本号从子域管理服务器中获取目标采集规则；将目标规则版本号确定为新的生效规则版本号，并将新的生效规则版本号同步至与分布式代理服务器对应的状态节点。

其中，生效采集规则可以是分布式代理服务器中当前已生效的日志采集规则。生效规则版本号可以是生效采集规则对应的版本号。状态节点可以是用于存储分布式代理服务器当前生效采集规则对应的生效规则版本号的节点。

参考图5，分布式代理服务器可以获取到该Agent当前的生效采集规则，并确定出生效采集规则对应的生效规则版本号，将生效规则版本号和目标规则版本号进行对比。如果分布式代理服务器550中当前的生效采集规则的生效规则版本号小于目标规则版本号，则说明分布式代理服务器550需要更新日志采集规则，则分布式代理服务器550可以主动向子域管理服务获取最新的采集规则(即目标采集规则)，分布式代理服务器550可以根据获取到的目标采集规则更新本地的采集规则，并更新生效规则版本号，即将目标规则版本号确定为新的生效规则版本号。同时将分布式代理服务器550的当前状态同步至对应的状态节点542，Zookeeper的状态节点的路径可以为/namespace/status/agent_id，状态节点内容包含了在分布式代理服务器550中最新的生效规则版本号。状态节点542可以向子域管理服务器530发送分布式代理服务器550中生效规则版本号的相关信息，向子域管理服务器530通知分布式代理服务器550中当前生效的采集规则的状态。

在本公开的一个实施例中，根据目标采集规则启动日志采集任务通过下述步骤进行：由子域管理服务器获取状态节点的状态节点信息；状态节点信息包含与日志采集任务对应的一个或多个分布式代理服务器的生效规则版本号；如果每个分布式代理服务器的生效规则版本号均大于目标规则版本号，则启动日志采集任务。其中，状态节点信息可以是状态节点包含的相关信息，如分布式代理服务器对应的生效规则版本号等。

具体的，子域管理服务器530可以通过监听Zookeeper路径/namespace/status下的所有状态节点的状态节点信息，将分布式代理服务器550的生效规则版本号发送至子域外的采集规则服务器520，采集规则服务器对于正在启动中的日志采集任务均维护一个待生效Agent集合和目标规则版本号，因为并发启动的多个任务可能涉及同一个Agent，由于目标规则版本号是全局递增生成的，所以当收到Agent的生效规则版本号大于等于目标规则版本号时，则可以认为Agent已经完成了采集规则的更新，因此，可以从待生效Agent集合中移除该Agent。直至待生效Agent集合为空时，表示所有Agent均已经更新完毕，将所有Agent采集规则更新完成的情况发送至用户，此时，日志采集任务启动成功。通过上述基于“Zookeeper+二级管理服务+2PC”的采集规则配置方案，可以有效解决在分布式异构网络环境下的大规模日志采集Agent配置管理问题。

在本公开的一个实施例中，确定日志采集任务针对的待采集日志文件的当前文件类型通过下述步骤进行：确定待采集日志文件的文件内数据的当前生成速率；如果当前生成速率大于第一预设阈值，则将当前文件类型确定为快作业；如果当前生成速率小于等于第一预设阈值，则将当前文件类型确定为慢作业；如果待采集日志文件在第一时间阈值内未产生新的文件数据，则将当前文件类型确定为不活跃作业。

其中，当前生成速率可以是待采集日志文件的文件内数据(文件内日志信息)在当前时刻的数据生成速率。第一预设阈值可以是预先设定的数据生成速率阈值，用于与待采集日志文件的文件内数据的当前生成速率进行对比。第一时间阈值可以是预先设定的时间段阈值。

日志文件在其生命周期内的数据生产不外乎4个阶段：高速写入时期，低速写入时期，不定期写入时期，不写入时期。一个日志文件可能在多个阶段中切换，也可能始终处于单一阶段。针对日志文件在不同阶段的特征，可以将文件映射为3种作业类型。参考图6，图6示意性地示出了根据本公开的一些实施例的待采集日志文件的分类示意图。根据待采集日志文件的文件内数据的当前生成速率与第一预设阈值的大小关系，可以确定出待采集日志文件所对应的当前文件类型。举例而言，可以将第一预设阈值确定为“1条/秒”，即每一秒生成一条新的日志数据。如果当前生成速率大于第一预设阈值，则可以将待采集日志文件的当前文件类型确定为快作业610。如果当前生成速率小于等于第一预设阈值，则可以将待采集日志文件的当前文件类型确定为慢作业620。另外，部分待采集日志文件可能阶段性的生成日志文件数据，可以将第一时间阈值确定为“5分钟”，当待采集日志文件在最近5分钟内没有新数据产生，则可以将该待采集日志文件的当前文件类型确定为不活跃作业630。

在本公开的一个实施例中，如果文件类型为快作业，则根据当前文件类型所对应的采集策略进行日志采集操作的过程可以通过下述步骤进行：确定待采集日志文件中包含的快作业集合；快作业集合包括一个或多个快作业；将一个或多个快作业推送至快作业队列；每隔第一预设时间从快作业队列中获取目标快作业，以对目标快作业进行日志采集操作。

其中，作业(Job)可以是待采集日志文件在Agent中对应的一个作业。快作业集合可以是由待采集日志文件中所有快作业组成的作业集合。快作业队列可以是用于存储待采集快作业的队列。第一预设时间可以是预先设定的时间段。目标快作业可以是当前进行日志采集处理的快作业。

根据不同待采集日志文件的当前文件类型，可以采用不同的日志采集策略进行日志采集操作。如果当前文件类型为快作业类型，则该待采集日志文件的文件实时写入的数据量较多，为了保证数据采集的时效性，可以先确定待采集日志文件中的所有快作业，形成快作业集合，并将快作业集合中的所有快作业推送至一个快作业队列中。采集线程可以每次从快作业队列的头部取出一个快作业作为目标快作业，并对目标快作业进行日志采集操作。为了防止其他快作业被饿死，采集线程可以每隔第一预设时间从快作业队列的头部取出一个目标快作业进行日志采集，当目标快作业采集一定的数据条数后，可以将其放回队列尾部，等待下次采集。

快作业的日志采集策略类似于中央处理器(Central Processing Unit，CPU)的时间分片原理，工作线程在不同的快作业中快速切换，队列中每个快作业的数据均可以被快速采集。同时，可以通过控制工作线程消费快作业队列的速率，从而达到限制采集速率的效果。

在本公开的一个实施例中，如果文件类型为慢作业，则根据当前文件类型所对应的采集策略进行日志采集操作的过程，可以通过下述步骤进行：监测慢作业的作业状态；如果慢作业的作业状态产生状态变化，则触发执行日志采集操作；获取待采集日志文件中未执行慢作业的慢作业数量；如果慢作业数量超过慢作业数量阈值，则根据慢作业数量和慢作业数量阈值确定待转换慢作业的数量；将超过慢作业数量阈值的待转换慢作业转换为快作业。

其中，作业状态可以是慢作业当前是否发生变化的状态。慢作业数量可以是待采集日志文件中当前还未被执行日志采集操作的慢作业的数量。慢作业数量阈值可以是与慢作业数量进行对比的数量阈值。待转换慢作业数量可以是待采集日志文件中待转换为快作业的慢作业的数量，即超出慢作业数量阈值的那部分慢作业的数量。

当待采集日志文件的当前文件类型为慢作业类型时，待采集日志文件的文件内数据产生的速率较慢，如果使用线程轮询方式，将导致线程无效工作时间升高。因此，在对慢作业进行日志采集操作时，可以通过Inotify机制进行。Inotify是一种文件变化通知机制，通过Intofity机制，能够对文件系统的变化进行监控，如对文件进行创建、删除、修改等操作，可以及时通知应用程序进行相关事件的处理。

对于慢作业的日志采集，可以开启对应的Inotify监控回调功能，当文件内容发生变化时，即慢作业的作业状态产生状态变化，则主动触发采集逻辑，进行日志采集操作。举例而言，操作系统允许一个用户开启文件Inotify watch最大数量默认为8192，因此，可以将慢作业数量阈值确定为8192，当未执行慢作业的慢作业数量超过该值时，可以将超出慢作业数量阈值的一部分慢作业自动转换为快作业类型，而后采用快作业对应的采集策略进行日志采集，避免超过Inotify watch数量限制。基于事件驱动的响应处理机制，避免了频繁的文件轮询操作，可以提高日志采集任务的处理效率。

在本公开的一个实施例中，如果文件类型为不活跃作业，则根据当前文件类型所对应的采集策略进行日志采集操作的过程，可以通过下述步骤进行：每隔第二预设时间确定不活跃作业的总作业量，并确定不活跃作业的已采集作业量；如果不活跃作业的总作业量大于已采集作业量，则将不活跃作业转换为快作业，以进行日志采集操作。

其中，第二预设时间可以是预先设定的时间段。不活跃作业的总作业量可以是待采集日志文件中不活跃作业的总数量。已采集作业量可以是待采集日志文件中当前记录的已进行日志采集操作的作业数量。

具体的，当文件类型为不活跃作业类型时，可以表示该待采集日志文件的文件内数据产生是不定期的，如果采用线程轮询将导致无效工作时间升高，如果采用响应处理机制将浪费Inotify watch资源。对于这些文件的数据采集，可以使用定时扫描策略，设置一个较长的检查周期(即第二预设时间)，例如30秒，每个检查周期内扫描所有的不活跃作业对应的文件，确定其文件大小，即不活跃作业的总作业量。将确定出的不活跃作业的总作业量与当前记录的已采集作业量，如果不活跃作业的总作业量大于已采集作业量，说明有新数据还未采集，此时可以将该不活跃作业转为快作业，并加入到快作业队里中等待采集，采用这种采集策略虽然牺牲了一些采集时效性，但大幅降低了资源占用率。

参考图7，图7示意性地示出了根据本公开的一些实施例的不同作业类型的作业相互切换的流程图。在步骤701中，创建新的待采集日志文件；在步骤702中，将待采集日志文件中当前生成速率大于第一预设阈值的文件，生成对应的快作业；在步骤703中，将生成的快作业推送至快作业队列中；在步骤704中，采用线程轮询采集的方式对快作业进行日志采集；在步骤705中，判断当前进行日志采集的快作业是否失速，如果该快作业未失速，则在采集周期结束后，可以将该快作业放回至快作业队列的队尾，并重新在队列头部获取一快作业进行日志采集；在步骤706中，如果检测到当前进行日志采集的快作业失速，则可以将快作业生成对应的慢作业；在步骤707中，采用Inotify机制针对慢作业进行日志采集；在步骤708中，可以进一步判断慢作业是否超速或失速，如果慢作业的当前生成速率与当前一致，则仍然采用Inotify机制进行日志采集；在步骤709中，如果检测到慢作业失速，则可以将慢作业转换为不活跃作业；在步骤710中，通过定期扫描检查不活跃作业是否有新的文件产生，如果检测到不活跃作业中有新的文件未采集，则可以将不活跃作业转换为快作业，采用快作业的采集策略进行日志采集操作；如果在第二预设时间内，没有新的文件数据产生，则该作业依然为不活跃作业。

采用上述采集策略，每个待采集日志文件均具有对应的采集速率监控器，根据不同的数据产生速率，一个文件在其生命周期内可以在多种作业类型中切换，文件的不同阶段采用各自最适合的采集策略，缓和了日志采集时效性与资源占用率之间的矛盾。举例而言，基于混合采集策略的Agent，在单机日志产生速率在5万条/秒(一条约为500字节)情况下，平均日志数据采集延迟为200毫秒，单核CPU占用为80％，在满足了实时数据仓库对数据高时效性需求的同时，对Agent的CPU资源也做合理控制，达到了采集时效性与资源占用率的平衡。

在本公开的一个实施例中，在得到目标日志信息之后，确定接收目标日志信息的文件接收服务器，并获取文件接收服务器的缓冲区数值；根据缓冲区数值向文件接收服务器发送目标日志信息；根据文件接收服务器接收到的目标日志信息的数据量更新缓冲区数值。其中，文件接收服务器可以是接收目标日志信息的服务器。缓冲区数值可以是文件接收服务器中可用的缓冲区大小的数值。

分布式代理服务器通过日志采集操作采集到的目标日志信息最终将发送到即文件接收服务器(下游服务器)中，基于信用的流量控制(credit-based flow control)是实现上下游流量控制的有效方式，常用于多层链路虚拟回路的流量控制。本公开中可以采用基于信用的流量控制方式将采集到的目标日志信息发送至对应的下游服务器。其具体的工作方式如下：在发送端通过连接发送数据之前，发送端需要接收接受端通过虚拟回路发送的信用值(credits)，在不同时期，接收端发送信用值到发送端，说明接收端可用的缓冲区大小。当接收到信用值后，发送端将按照信用值发送小于等于信用值量的数据到接收端，每次发送端发送数据后，相应的信用值减少，这样就可以避免发送端无限制的往接收端发送数据，造成网络阻塞。

参考图8，图8示意性地示出了根据本公开的一些实施例的文件接收服务器接收目标日志信息的工作原理图。Agent在向文件接收服务器发送目标日志信息时，可以先获取文件接收服务器的缓冲区数值，根据缓冲区数值向文件接收服务器发送小于缓冲区数值大于的目标日志信息。Agent每次向文件接收服务器发送目标日志信息后，则Agent获取到的文件接收服务器的缓冲区数值将相应减小。图8中的生产者容器810中具有对应的待发送的完整缓冲队列，生产者容器810中每个队列中均标示了每个通道的信用值(即文件接收服务器的缓冲区数值)，如四个队列对应的信用值分别为“2,2,3,1”。消费者容器820中示出了可用的接收缓冲区，每个队列示出了当前发送者的积压量，分别为“3,1,2,2”。

在本公开的一个实施例中，监测文件接收服务器的服务器状态信息；如果服务器状态信息为服务器状态处于故障状态，则将待采集日志文件的文件状态确定为阻塞状态；如果文件状态处于阻塞状态，且服务器状态由故障状态切换为正常状态，则将文件状态由阻塞状态转换为采集状态，以进行日志采集操作。

其中，服务器状态信息可以是表示文件接收服务器的当前状态的相关信息，通过服务器状态信息可以确定文件接收服务器是否处于故障状态。阻塞状态可以是待采集日志文件的一种文件状态，当待采集日志文件处于阻塞状态时，则暂停日志采集操作。

分布式代理服务器通过日志采集操作采集到的目标日志信息最终将发送到下游服务器(即文件接收服务器)中，当下游服务器出现故障或性能问题时，Agent则暂停继续向下游服务器发送数据。基于信用的流量控制可以实现Agent感知下游服务器的数据接收能力，当下游服务出现故障或性能问题时，则服务器状态信息表示服务器状态处于故障状态，下游服务器将接收压力信息通过信用值反馈给Agent，Agent接收到处于故障状态的服务器状态后将对应的文件采集作业标记为阻塞类型，对于此类作业，Agent将自动跳过采集，从而实现不再继续往下游服务发送数据。当文件状态处于阻塞状态时，如果下游服务恢复，则将服务器状态由故障状态切换为正常状态，同时文件接收服务器将解除反压的信息通过信用值反馈给Agent，这时Agent将对应阻塞类型的文件恢复为正常的采集状态，则可以继续进行日志采集操作。

通过基于反压的下游故障处理策略，使得Agent可以在下游出现故障或故障恢复时，对应用服务器上日志文件停止采集或启动采集，不仅避免了日志数据阻塞在网络中，也避免了Agent自身需要对未发送的日志数据进行缓存。

参考图9，图9示意性地示出了根据本公开的一些实施例的分布式代理服务器的总体架构图。用户通过客户端进行基于任务维度的采集规则配置操作，客户端模块将启动日志采集任务的请求发送至通信模块，通信模块可以通过域管理服务器获取与日志采集任务对应的目标采集规则，域管理服务器将目标采集规则发送至通信模块，通信模块可以将获取到的目标采集规则发送至采集规则模块，且可以将域管理服务器的地址、客户端地址和分布式代理服务器的标识发送至本地文件中进行存储。采集规则模块可以将采集规则发送至应用上下文中，确定出日志采集任务针对的待采集日志文件，以及待采集日志文件中的作业集合，包括快作业集合、慢作业集合和不活跃作业集合等。目录监听模块可以与应用上下文之间交互，互相发送规则和作业的相关信息。持久化模块将获取到的作业集合和规则集合等相关信息发送至本地文件中进行存储。在确定出待采集日志文件中的快作业、慢作业和不活跃作业后，可以分别采用对应的采集策略进行日志采集，并且不同作业类型的作业之间可以互相转换，监控模块用于监控不同作业类型之间的作业情况，并将相关信息发送至发送模块。慢作业模块和快作业模块可以将采集到的目标日志信息发送至发送模块，发送模块可以将接收到的目标日志信息发送至下游服务器中，以供下游服务器者使用。下游服务器可以将当前可用的缓冲区数值通过信用值发送至发送模块，以进行基于反压的下游故障处理策略。

综上所述，本公开的分布式日志采集方法，应用于分布式代理服务器，包括：响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则；根据目标采集规则启动日志采集任务；确定日志采集任务针对的待采集日志文件的当前文件类型；根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。一方面，分布式代理服务器通过监测各采集规则的规则更新状态确定出与日志采集任务对应的目标采集规则，以实现在大规模部署了分布式代理服务器的情况下也可以进行对各分布式代理服务器的针对性管理。另一方面，根据确定出的当前文件类型调用对应的采集策略进行日志采集，可以避免像单一采集策略那样反复轮询采集日志文件最新内容所造成的过高资源占用，实现在日志采集时效性与分布式代理服务器资源占用率之间的平衡。又一方面，通过采用基于反压的数据缓存策略，使得Agent在有限的内存使用条件下，避免造成由于数据缓存导致的内存溢出问题；也无需使用应用服务器的磁盘空间对数据做持久化缓存，从根本上解决了因为Agent数据缓存导致磁盘空间打满问题。

示例性装置

在介绍了本公开示例性实施方式的方法之后，接下来，参考图10对本公开示例性实施例的分布式日志采集装置进行说明。

在图10中，分布式日志采集装置1000可以包括采集规则确定模块1010、任务启动模块1020、文件类型确定模块1030以及日志采集模块1040。

其中，采集规则确定模块1010用于响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则；任务启动模块1020用于根据目标采集规则启动日志采集任务；文件类型确定模块1030用于确定日志采集任务针对的待采集日志文件的当前文件类型；日志采集模块1040用于根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。

在本公开的一些实施例中，在本公开的一个实施例中，采集规则确定模块包括采集规则确定单元，采集规则确定单元包括：规则节点确定单元，用于确定与分布式代理服务器对应的规则节点；节点状态监测单元，用于监测规则节点的节点状态；节点状态包含规则更新状态；规则获取单元，用于如果规则更新状态存在状态更新变化，则根据规则节点从子域管理服务器获取目标采集规则；子域管理服务器用于与规则节点以及处于分布式代理服务器所在域之外的采集规则服务器进行通信。

在本公开的一个实施例中，规则获取单元包括规则获取子单元，规则获取子单元包括：版本号获取子单元，用于从规则节点获取目标规则版本号；目标规则版本号由采集规则服务器通过子域管理服务器发送至规则节点；采集规则获取子单元，用于根据目标规则版本号从子域管理服务器获取目标采集规则。

在本公开的一个实施例中，采集规则获取子单元被配置为：获取分布式代理服务器的生效采集规则，并确定生效采集规则对应的生效规则版本号；对比生效规则版本号和目标规则版本号；如果生效规则版本号小于目标规则版本号，则根据目标规则版本号从子域管理服务器中获取目标采集规则；将目标规则版本号确定为新的生效规则版本号，并将新的生效规则版本号同步至与分布式代理服务器对应的状态节点。

在本公开的一个实施例中，任务启动模块包括任务启动单元，任务启动单元被配置为：由子域管理服务器获取状态节点的状态节点信息；状态节点信息包含与日志采集任务对应的一个或多个分布式代理服务器的生效规则版本号；如果每个分布式代理服务器的生效规则版本号均大于目标规则版本号，则启动日志采集任务。

在本公开的一个实施例中，文件类型确定模块包括文件类型确定单元，文件类型确定单元被配置为：确定待采集日志文件的文件内数据的当前生成速率；如果当前生成速率大于第一预设阈值，则将当前文件类型确定为快作业；如果当前生成速率小于等于第一预设阈值，则将当前文件类型确定为慢作业；如果待采集日志文件在第一时间阈值内未产生新的文件数据，则将当前文件类型确定为不活跃作业。

在本公开的一个实施例中，日志采集模块包括第一日志采集单元，第一日志采集单元被配置为：确定待采集日志文件中包含的快作业集合；快作业集合包括一个或多个快作业；将一个或多个快作业推送至快作业队列；每隔第一预设时间从快作业队列中获取目标快作业，以对目标快作业进行日志采集操作。

在本公开的一个实施例中，日志采集模块包括第二日志采集单元，第二日志采集单元被配置为：监测慢作业的作业状态；如果慢作业的作业状态产生状态变化，则触发执行日志采集操作；获取待采集日志文件中未执行慢作业的慢作业数量；如果慢作业数量超过慢作业数量阈值，则根据慢作业数量和慢作业数量阈值确定待转换慢作业数量；将超过慢作业数量阈值的待转换慢作业转换为快作业。

在本公开的一个实施例中，日志采集模块包括第三日志采集单元，第三日志采集单元被配置为：每隔第二预设时间确定不活跃作业的总作业量，并确定不活跃作业的已采集作业量；如果不活跃作业的总作业量大于已采集作业量，则将不活跃作业转换为快作业，以进行日志采集操作。

在本公开的一个实施例中，分布式日志采集装置还包括文件接收模块，文件接收模块被配置为：确定接收目标日志信息的文件接收服务器，并获取文件接收服务器的缓冲区数值；根据缓冲区数值向文件接收服务器发送目标日志信息；根据文件接收服务器接收到的目标日志信息的数据量更新缓冲区数值。

在本公开的一个实施例中，分布式日志采集装置还包括采集状态转换模块，采集状态转换模块被配置为：监测文件接收服务器的服务器状态信息；如果服务器状态信息为服务器状态处于故障状态，则将待采集日志文件的文件状态确定为阻塞状态；如果文件状态处于阻塞状态，且服务器状态由故障状态切换为正常状态，则将文件状态由阻塞状态转换为采集状态，以进行日志采集操作。

在本公开实施例的第三方面中，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的分布式日志采集方法。

示例性介质

在介绍了本公开示例性实施方式的装置之后，接下来，参考图11对本公开示例性实施例的存储介质进行说明。

在一些实施例中，本公开的各个方面还可以实现为一种介质，其上存储有程序代码，当所述程序代码被设备的处理器执行时用于实现本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的分布式日志采集方法中的步骤。

例如，所述设备的处理器执行所述程序代码时可以实现如图4中所述的步骤S410，响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则；步骤S420，根据目标采集规则启动日志采集任务；步骤S430，确定日志采集任务针对的待采集日志文件的当前文件类型；步骤S440，根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。

参考图11所示，描述了根据本公开的实施例的用于实现上述分布式日志采集方法或者实现上述分布式日志采集方法的程序产品1100，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备。

示例性计算设备

在介绍了本公开示例性实施方式的分布式日志采集方法、分布式日志采集装置以及存储介质之后，接下来，参考图12对本公开示例性实施方式的电子设备进行说明。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施例、完全的软件实施例(包括固件、微代码等)，或硬件和软件方面结合的实施例，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施例中，根据本公开的电子设备可以至少包括至少一个处理单元、以及至少一个存储单元。其中，所述存储单元存储有程序代码，当所述程序代码被所述处理单元执行时，使得所述处理单元执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的分布式日志采集方法中的步骤。例如，所述处理单元可以执行如图4中所述的步骤S410，响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定日志采集任务的目标采集规则；步骤S420，根据目标采集规则启动日志采集任务；步骤S430，确定日志采集任务针对的待采集日志文件的当前文件类型；步骤S440，根据当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息。

下面参照图12来描述根据本公开的示例实施例的电子设备1200。图12所示的电子设备1200仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图12所示，电子设备1200以通用计算设备的形式表现。电子设备1200的组件可以包括但不限于：上述至少一个处理单元1201、上述至少一个存储单元1202、连接不同系统组件(包括存储单元1202和处理单元1201)的总线1203、显示单元1207。

总线1203表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、图形加速端口、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储单元1202可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1221和/或高速缓存存储器1222，还可以进一步包括只读存储器(ROM)1223。

存储单元1202还可以包括具有一组(至少一个)程序模块1224的程序/实用工具1225，这样的程序模块1224包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

电子设备1200也可以与一个或多个外部设备1204(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与电子设备1200交互的设备通信，和/或与使得电子设备1200能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1205进行。并且，电子设备1200还可以通过网络适配器1206与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器1206通过总线1203与电子设备1200的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1200使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了分布式日志采集装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (22)

1.一种分布式日志采集方法，其特征在于，应用于分布式代理服务器，包括：

响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定所述日志采集任务的目标采集规则；所述目标采集规则基于所述分布式代理服务器对应的规则节点的规则更新状态确定；

根据所述目标采集规则启动所述日志采集任务；

确定所述日志采集任务针对的待采集日志文件的当前文件类型；所述当前文件类型基于所述待采集日志文件的文件内数据的当前生成速率确定；

根据所述当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息；

所述通过监测采集规则的规则更新状态，确定所述日志采集任务的目标采集规则，包括：如果所述规则更新状态存在状态更新变化，则根据所述规则节点从子域管理服务器获取所述目标采集规则；所述子域管理服务器用于与所述规则节点以及处于所述分布式代理服务器所在域之外的采集规则服务器进行通信；

所述确定所述日志采集任务针对的待采集日志文件的当前文件类型，包括：确定所述待采集日志文件的文件内数据的当前生成速率；如果所述当前生成速率大于第一预设阈值，则将所述当前文件类型确定为快作业；如果所述当前生成速率小于等于所述第一预设阈值，则将所述当前文件类型确定为慢作业；如果所述待采集日志文件在第一时间阈值内未产生新的文件数据，则将所述当前文件类型确定为不活跃作业。

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

确定与所述分布式代理服务器对应的规则节点；

监测所述规则节点的节点状态；所述节点状态包含所述规则更新状态。

3.根据权利要求2所述的方法，其特征在于，所述根据所述规则节点从子域管理服务器获取所述目标采集规则，包括：

从所述规则节点获取目标规则版本号；所述目标规则版本号由所述采集规则服务器通过所述子域管理服务器发送至所述规则节点；

根据所述目标规则版本号从所述子域管理服务器获取所述目标采集规则。

4.根据权利要求3所述的方法，其特征在于，所述根据所述目标规则版本号从所述子域管理服务器获取所述目标采集规则，包括：

获取所述分布式代理服务器的生效采集规则，并确定所述生效采集规则对应的生效规则版本号；

对比所述生效规则版本号和所述目标规则版本号；

如果所述生效规则版本号小于所述目标规则版本号，则根据所述目标规则版本号从所述子域管理服务器中获取所述目标采集规则；

将所述目标规则版本号确定为新的生效规则版本号，并将所述新的生效规则版本号同步至与所述分布式代理服务器对应的状态节点。

5.根据权利要求3所述的方法，其特征在于，所述根据所述目标采集规则启动所述日志采集任务，包括：

由所述子域管理服务器获取状态节点的状态节点信息；所述状态节点信息包含与所述日志采集任务对应的一个或多个分布式代理服务器的生效规则版本号；

如果每个所述分布式代理服务器的生效规则版本号均大于所述目标规则版本号，则启动所述日志采集任务。

6.根据权利要求1所述的方法，其特征在于，所述当前文件类型为快作业，所述根据所述当前文件类型所对应的采集策略进行日志采集操作，包括：

确定所述待采集日志文件中包含的快作业集合；所述快作业集合包括一个或多个所述快作业；

将一个或多个所述快作业推送至快作业队列；

每隔第一预设时间从所述快作业队列中获取目标快作业，以对所述目标快作业进行日志采集操作。

7.根据权利要求1所述的方法，其特征在于，所述当前文件类型为慢作业，所述根据所述当前文件类型所对应的采集策略进行日志采集操作，包括：

监测所述慢作业的作业状态；

如果所述慢作业的作业状态产生状态变化，则触发执行所述日志采集操作；

获取所述待采集日志文件中未执行慢作业的慢作业数量；

如果所述慢作业数量超过慢作业数量阈值，则根据所述慢作业数量和所述慢作业数量阈值确定待转换慢作业的数量；

将超过所述慢作业数量阈值的所述待转换慢作业转换为快作业。

8.根据权利要求1所述的方法，其特征在于，所述当前文件类型为不活跃作业，所述根据所述当前文件类型所对应的采集策略进行日志采集操作，包括：

每隔第二预设时间确定所述不活跃作业的总作业量，并确定所述不活跃作业的已采集作业量；

如果所述不活跃作业的总作业量大于所述已采集作业量，则将所述不活跃作业转换为快作业，以进行所述日志采集操作。

9.根据权利要求1所述的方法，其特征在于，在所述得到目标日志信息之后，所述方法还包括：

确定接收所述目标日志信息的文件接收服务器，并获取所述文件接收服务器的缓冲区数值；

根据所述缓冲区数值向所述文件接收服务器发送所述目标日志信息；

根据所述文件接收服务器接收到的目标日志信息的数据量更新所述缓冲区数值。

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

监测所述文件接收服务器的服务器状态信息；

如果所述服务器状态信息为服务器状态处于故障状态，则将所述待采集日志文件的文件状态确定为阻塞状态；

如果所述文件状态处于所述阻塞状态，且所述服务器状态由所述故障状态切换为正常状态，则将所述文件状态由所述阻塞状态转换为采集状态，以进行所述日志采集操作。

11.一种分布式日志采集装置，其特征在于，应用于分布式代理服务器，包括：

采集规则确定模块，用于响应于日志采集任务的任务启动请求，通过监测采集规则的规则更新状态，确定所述日志采集任务的目标采集规则；所述目标采集规则基于所述分布式代理服务器对应的规则节点的规则更新状态确定；

任务启动模块，用于根据所述目标采集规则启动所述日志采集任务；

文件类型确定模块，用于确定所述日志采集任务针对的待采集日志文件的当前文件类型；所述当前文件类型基于所述待采集日志文件的文件内数据的当前生成速率确定；

日志采集模块，用于根据所述当前文件类型所对应的采集策略进行日志采集操作，以得到目标日志信息；

采集规则确定模块还包括规则获取单元，用于如果所述规则更新状态存在状态更新变化，则根据所述规则节点从子域管理服务器获取所述目标采集规则；所述子域管理服务器用于与所述规则节点以及处于所述分布式代理服务器所在域之外的采集规则服务器进行通信；

所述文件类型确定模块包括文件类型确定单元，所述文件类型确定单元被配置为：确定所述待采集日志文件的文件内数据的当前生成速率；如果所述当前生成速率大于第一预设阈值，则将所述当前文件类型确定为快作业；如果所述当前生成速率小于等于所述第一预设阈值，则将所述当前文件类型确定为慢作业；如果所述待采集日志文件在第一时间阈值内未产生新的文件数据，则将所述当前文件类型确定为不活跃作业。

12.根据权利要求11所述的装置，其特征在于，所述采集规则确定模块包括采集规则确定单元，所述采集规则确定单元包括：

规则节点确定单元，用于确定与所述分布式代理服务器对应的规则节点；

节点状态监测单元，用于监测所述规则节点的节点状态；所述节点状态包含所述规则更新状态。

13.根据权利要求12所述的装置，其特征在于，所述规则获取单元包括规则获取子单元，所述规则获取子单元包括：

版本号获取子单元，用于从所述规则节点获取目标规则版本号；所述目标规则版本号由所述采集规则服务器通过所述子域管理服务器发送至所述规则节点；

采集规则获取子单元，用于根据所述目标规则版本号从所述子域管理服务器获取所述目标采集规则。

14.根据权利要求13所述的装置，其特征在于，所述采集规则获取子单元被配置为：

获取所述分布式代理服务器的生效采集规则，并确定所述生效采集规则对应的生效规则版本号；

对比所述生效规则版本号和所述目标规则版本号；

如果所述生效规则版本号小于所述目标规则版本号，则根据所述目标规则版本号从所述子域管理服务器中获取所述目标采集规则；

将所述目标规则版本号确定为新的生效规则版本号，并将所述新的生效规则版本号同步至与所述分布式代理服务器对应的状态节点。

15.根据权利要求13所述的装置，其特征在于，所述任务启动模块包括任务启动单元，所述任务启动单元被配置为：

由所述子域管理服务器获取状态节点的状态节点信息；所述状态节点信息包含与所述日志采集任务对应的一个或多个分布式代理服务器的生效规则版本号；

如果每个所述分布式代理服务器的生效规则版本号均大于所述目标规则版本号，则启动所述日志采集任务。

16.根据权利要求11所述的装置，其特征在于，所述日志采集模块包括第一日志采集单元，所述第一日志采集单元被配置为：

确定所述待采集日志文件中包含的快作业集合；所述快作业集合包括一个或多个所述快作业；

将一个或多个所述快作业推送至快作业队列；

每隔第一预设时间从所述快作业队列中获取目标快作业，以对所述目标快作业进行日志采集操作。

17.根据权利要求11所述的装置，其特征在于，所述日志采集模块包括第二日志采集单元，所述第二日志采集单元被配置为：

监测所述慢作业的作业状态；

如果所述慢作业的作业状态产生状态变化，则触发执行所述日志采集操作；

获取所述待采集日志文件中未执行慢作业的慢作业数量；

如果所述慢作业数量超过慢作业数量阈值，则根据所述慢作业数量和所述慢作业数量阈值确定待转换慢作业数量；

将超过所述慢作业数量阈值的所述待转换慢作业转换为所述快作业。

18.根据权利要求11所述的装置，其特征在于，所述日志采集模块包括第三日志采集单元，所述第三日志采集单元被配置为：

每隔第二预设时间确定所述不活跃作业的总作业量，并确定所述不活跃作业的已采集作业量；

如果所述不活跃作业的总作业量大于所述已采集作业量，则将所述不活跃作业转换为所述快作业，以进行所述日志采集操作。

19.根据权利要求11所述的装置，其特征在于，所述分布式日志采集装置还包括文件接收模块，所述文件接收模块被配置为：

确定接收所述目标日志信息的文件接收服务器，并获取所述文件接收服务器的缓冲区数值；

根据所述缓冲区数值向所述文件接收服务器发送所述目标日志信息；

根据所述文件接收服务器接收到的目标日志信息的数据量更新所述缓冲区数值。

20.根据权利要求19所述的装置，其特征在于，所述分布式日志采集装置还包括采集状态转换模块，所述采集状态转换模块被配置为：

监测所述文件接收服务器的服务器状态信息；

如果所述服务器状态信息为服务器状态处于故障状态，则将所述待采集日志文件的文件状态确定为阻塞状态；

如果所述文件状态处于所述阻塞状态，且所述服务器状态由所述故障状态切换为正常状态，则将所述文件状态由所述阻塞状态转换为采集状态，以进行所述日志采集操作。

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

处理器；以及

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如权利要求1至10中任意一项所述的分布式日志采集方法。

22.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至10中任意一项所述的分布式日志采集方法。

Images