CN116610443A - 日志采集方法、设备及可读存储介质 - Google Patents

Abstract

本申请公开了一种日志采集方法、设备及可读存储介质，中心集群根据来自控制台的、携带日志采集规则的采集请求，生成与至少一个容器绑定的第一CRD，并将第一CRD发送给至少一个容器中各容器所在的边缘集群。边缘集群接收到第一CRD后，确定出节点集群，节点集合中的每个工作节点上具有至少一个容器中的容器。之后，边缘集群针对每个工作节点，生成第二CRD，并根据工作节点对应的第二CRD采集日志。采用该种方案，无需一一登录各个容器，通过一次配置即可采集和查询海量边缘容器日志，方便快捷配置采集目标，耗时短，便于容器化应用的及时维护，确保容器化应用正常运行。

Description

日志采集方法、设备及可读存储介质

技术领域

本申请实施例涉及容器技术领域，特别涉及一种日志采集方法、设备及可读存储介质。

背景技术

随着云原生时代的到来，越来越多的传统应用逐渐容器化。应用的日常维护中，日志是排查问题的一个关键环节。

云边协同的边缘计算场景下，每个边缘集群(cluster)上部署多个容器，部署在边缘节点上的容器又称作边缘容器。需要采集日志时，运维人员远程登录每个边缘容器，采集日志并排查问题。

然而，云边协同场景下，边缘集群数量庞大。相应的，边缘容器也是海量的，远程登录一个个容器查看日志，耗时长，导致无法及时维护容器化的应用，导致容器化应用容易出现故障。

发明内容

本申请的目的在于提供一种日志采集方法、设备及可读存储介质，通过一次配置即可采集和查询海量边缘容器日志，耗时短，便于容器化应用的及时维护，确保容器化应用正常运行。

第一方面，本申请实施例提供一种日志采集方法，应用于边缘集群，所述方法包括：

接收来自中心集群的第一自定义资源CRD，所述第一CRD指示至少一个容器，所述边缘集群包括多个工作节点，每个工作节点上部署多个容器；

从所述多个工作节点中确定出节点集合，所述节点集合中的每个工作节点上具有所述至少一个容器中的容器；

针对所述节点集合中的每个工作节点，生成所述工作节点对应的第二CRD；

对于所述节点集合中的每个工作节点，根据所述工作节点对应的第二CRD采集日志。

第二方面，本申请实施例提供一种日志采集方法，应用于中心集群，所述方法包括：

接收来自控制台的、携带日志采集规则的采集请求；

响应所述采集请求，生成第一自定义资源CRD，所述第一CRD与至少一个容器绑定，所述至少一个容器是所述日志采集规则指示的容器；

向所述至少一个容器中各容器所在的边缘集群发送所述第一CRD。

第三方面，本申请实施例提供一种电子设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时使得所述电子设备实现如上第一方面各种可能的实现方式所述的方法。

第四方面，本申请实施例提供一种电子设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时使得所述电子设备实现如上第二方面各种可能的实现方式所述的方法。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令在被处理器执行时用于实现如上第一方面各种可能的实现方式所述的方法。

第六方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令在被处理器执行时用于实现如上第二方面各种可能的实现方式所述的方法。

本申请实施例提供的日志采集方法、设备及可读存储介质，中心集群根据来自控制台的、携带日志采集规则的采集请求，生成与至少一个容器绑定的第一CRD，并将第一CRD发送给至少一个容器中各容器所在的边缘集群。边缘集群接收到第一CRD后，确定出节点集群，节点集合中的每个工作节点上具有至少一个容器中的容器。之后，边缘集群针对每个工作节点，生成第二CRD，并根据工作节点对应的第二CRD采集日志。采用该种方案，无需一一登录各个容器，通过一次配置即可采集和查询海量边缘容器日志，方便快捷配置采集目标，耗时短，便于容器化应用的及时维护，确保容器化应用正常运行。

附图说明

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

图1是本申请实施例提供的日志采集方法所适用的一个网络架构示意图；

图2是本申请实施例提供的日志采集方法的另一个网络架构示意图；

图3是本申请实施例提供的日志采集方法的流程图；

图4是本申请实施例提供的日志采集方法中日志采集规则的配置界面示意图；

图5是本申请实施例提供的日志采集方法中节点集合的示意图；

图6是本申请实施例提供的日志采集方法中边缘集群的流程图；

图7为本申请实施例提供的一种日志采集装置的示意图；

图8为本申请实施例提供的另一种日志采集装置的示意图；

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

具体实施方式

容器技术作为一种虚拟化技术，是一种被大家广泛认可的服务器资源共享方式。随着越来越多应用的容器化，应用日常维护中，经常利用日志排查问题，日志是应用日常维护中排查问题的一个关键环节。因此，应用容器化过程中，如何方便快捷、高效地自动发现日志和采集应用的日志，如何与日志存储系统协同来高效存储和搜索应用日志，成为容器化应用需要解决的关键问题。

目前，为了利用日志排查容器化应用的问题，运维人员远程登录容器，通过登录一个个容器来查看容器日志。

然而，基于云边协同的边缘计算场景下，容器往往部署在边缘集群上，而边缘集群分布广泛、数量庞大，因此，容器的分布范围也很广、数量也很庞大。另外，容器还具有弹性伸缩、故障恢复等特点。鉴于云边协同场景下容器的这些特征，若一个个登录容器查看日志，则极大程度上增加了排查问题的时长。而且，目前的日志采集方式还有其他弊端。

例如，缺乏动态配置的能力。

目前的日志采集方式中，采集人员事先手动配置好日志采集方式和路径等信息，无法自动感知到容器的生命周期变化，无法自动感知容器的动态漂移。

再如，容易发生重复采集日志或丢失日志的情况。

现有的采集工具基本都是通过tail的方式采集日志。该方式存在两个问题：一个是日志丢失问题。比如，采集工具重启过程中，应用依然在写日志，导致这个窗口期的日志丢失。为了避免日志丢失，保守的做法是：默认往前多采集1M或2M的日志。但是，这又可能会引起重复采集日志的问题。

又如，未标记日志源。

一个应用可能有多个容器，多个容器输出的日志是一样的。当所有日志存储到后端时，搜索日志的时候，无法明确一条日志是哪个工作节点上的哪个应用容器产生的。

又如，采集延迟。

通常情况下，基于轮询的方式采集日志，即通过定期检测日志文件有无更新来进行日志采集，采集延迟以及资源消耗高。云边协同场景中，边缘集群上的容器的日志规模较大，轮询一次的时间较长，采集延迟高。

又如，难以确定日志上下文。

为了方便定位，需要查询原始日志的上下几行日志。现有的一些工具基本是按时间去锁定一段日志，然后进行查找，加大通过日志排查问题的时长。

又如，难以实现多租户隔离。

日志采集并不是单一用户/应用要完成的工作，每个应用可能会有不同类的日志，比如访问日志、调试(debug)日志、资源类日志、监控类日志等。假设一个边缘集群的一个工作节点上有50个容器(docker)，每个容器预估采集3-6种日志，那么，单机就会有300左右的配置。因此，保证多租户的隔离性和公平性至关重要。

为此，要求各采集工作之间互不影响，部分采集配置阻塞不影响其他正常采集。同时，保证各个阶段多个采集工作之间的公平性，不能因为某个采集工作对应的日志写入量大，而导致其他采集工作被处理的概率降低。其中，各个阶段包括日志读取阶段、处理阶段和发送阶段等。

目前，每个采集工作对应一个配置，为每个配置分配一个协程，从而保证各采集工作的隔离。然而，随着采集工作的增多，配置数量增长，相应的，协程数和配置呈等比上升。当采集工作增多时，配置也增多，导致资源难以控制。而且，由于各协程完全依赖操作系统、运行库(go Running)等底层的调度，当CPU资源无法全部满足时，写入量大的日志对应的采集事件会占用较多的时间，和资源，导致其他采集事件获得资源的概率降低。

基于此，本申请实施例提供一种日志采集方法、设备及可读存储介质，通过一次配置即可采集和查询海量边缘集群上容器的日志，耗时短，便于容器化应用的及时维护，确保容器化应用正常运行。

图1是本申请实施例提供的日志采集方法所适用的一个网络架构示意图。请参照图1，该网络架构包括中心集群(cluster)11、边缘集群12、控制台13和云存储14。中心集群11和边缘集群12之间、中心集群11和控制台13之间、中心集群11和云存储14之间建立网络连接。各边缘集群12与云存储14之间建立网络连接，图中未示意出。

中心集群11可以是硬件也可以是软件。当中心集群11为硬件时，该中心集群11为单个服务器或多个服务器组成的分布式服务器集群。当中心集群11为软件时，可以为多个软件模块或单个软件模块等，本申请实施例并不限制。

中心集群11用于管理多个边缘集群12，一个边缘集群12上具有多个工作节点(work node)121，每个工作节点121上具有多个容器1211。应用容器化的过程中，有的应用具有一个容器，有的应用具有多个容器。

图1所示网络架构的适用场景包括但不限于内容分发网络(Content DeliveryNetwork，CDN)、分布式集群等。可以是一个机房组成一个边缘集群12，也可以跨机房组成一个边缘集群12，本申请实施例并不限制。

控制台13例如为采集人员的笔记本电脑、台式电脑、手机、平板电脑等终端设备，采集人员在控制台13配置日志采集规则等，并向中心集群11发送携带日志采集规则的采集请求。中心集群11接收到采集请求后，触发边缘集群12采集日志并将采集到的日志存储至云存储14等。后续需求查询日志时，采集人员通过控制台13向云存储14发送查询请求，从而进行日志查询。

应当理解的是，图1中中心集群11、边缘集群12、控制台13和云存储14的数量仅仅是示意性的。实际实现中，根据实际需求部署任意数量的中心集群11、边缘集群12、控制台13和云存储14。

图2是本申请实施例提供的日志采集方法的另一个网络架构示意图。请参照图2，该网络架构包括中心集群21、边缘集群22、控制台23和云存储24。中心集群21和边缘集群22之间、中心集群21和控制台23之间、中心集群21和云存储24之间建立网络连接。各边缘集群22与云存储24之间建立网络连接，图中未示意出。

请参照图2，采用Kubernetes技术管理大规模的边缘集群22。Kubernetes，也被称为K8S或Kube，是容器编排器的一种，支持Docker、rkt等容器的运行环境(Runtime)。可以将Kubernetes视为一个分布式机器，包括中心集群21和多个边缘集群22，中心集群21又称作管理节点等。中心集群21主要运行着应用程序编程接口服务器(application programminginterface server，API server)、调度器(scheduler)、控制器(controller manager)、存储器(etcd)、微服务等核心组件。其中，微服务例如为benthos微服务等。从所有边缘集群22的角度来看，中心集群21相当于一个主节点，用于管理所有的边缘集群22。

API server是中心集群21的统一入口以及中心集群21中各组件的协调中心，管理员以及用户均通过API server接入K8S。所有对象资源的增删、修改、查找以及监听操作都可以由API server处理后再提交给etcd存储。其它组件需要通过API server查询或修改数据，只有API server有权直接操作etcd。

控制器(controller manager)是K8S中资源对象的自动化控制中心，用于维护管理集群的状态，例如，故障检测，自动扩展、更新等。

调度器(Scheduler)：负责K8S中的资源调度，例如，按照预定的调度策略将pod调度到相应的边缘集群22中。

etcd:分布式键值数据库，用于保存整个集群的状态数据。例如pod、服务(service)等对象信息。

边缘集群22上具有一个主节点和多个工作节点，每个工作节点上具有多个容器。每个边缘集群22上的主节点用于管理所有工作节点。由此可见：边缘集群22上的主节点和中心集群21管理的范围不同。边缘集群22上的主节点的组成部分可参见中心集群21的描述，此处不再赘述。

Kubernetes技术中，服务单元(pod)代表正在运行的一个进程，包含至少一个容器。也就是说，pod是Kubernetes创建或部署的最小、最简单的基本单位，是Kubernetes的基本调度单元，是Kubernetes中的一个应用实例，属于一个pod的容器部署在一个工作节点上。Kubernetes中的每个pod都被分配一个唯一的IP地址，使得应用使用同一个端口，避免发生冲突等。

请参照图2，每个边缘集群22上还运行一个日志控制器。每个工作节点上除了容器外，还具有采集组件。

日志采集过程中，采集人员在控制台23上配置日志采集规则，并向中心集群21发送携带日志采集规则的采集请求。中心集群21中的微服务接收到采集请求后，生成第一自定义资源(Custom Resource Define，CRD)，并将第一CRD发送至API server。API sever接收到第一CRD后，对第一CRD进行规范检查等，并存储至etcd中。控制器用于从中心集群21管理的边缘集群22中，确定出需要向哪些边缘集群22发送第一CRD并发送。

边缘集群22上的API sever接收到第一CRD后，将其存储在边缘集群22的etcd上。边缘集群22上的日志控制器确定哪些工作节点上存在需要采集日志的容器得到节点集合，对节点集合中的每个工作节点生成第二CRD。节点集合中的各工作节点上的采集组件根据第二CRD进行日志采集。

采集组件采集好日志后，根据采集到的日志生成报告(report)，并将报告上报给云存储24。后续当用户需求查询日志时，通过控制台23向中心集群21发送查询请求，中心集群23从云存储24获取日志并反馈给控制台23。

下面，基于图1和图2所示网络架构，对本申请实施例提供的日志采集方法进行详细说明。示例性的，请参照图3。

图3是本申请实施例提供的日志采集方法的流程图。本实施例是从边缘集群和中心集群交互的角度进行说明。本实施例包括：

301、控制台向中心集群发送携带日志采集规则的采集请求。

相应的，中心集群接收来自控制台的、携带日志采集规则的采集请求。

示例性的，当需求采集日志时，采集人员通过控制台提供的界面配置日志采集规则，日志采集规则包括基础信息、日志源和日志解析方式等。其中，基础信息包括日志采集规则的名称、存储日志的日志集的名称等；日志源用于指示采集哪些容器等；日志解析方式用于指示如何解析日志，包括单行文本解析方式等。图4是本申请实施例提供的日志采集方法中日志采集规则的配置界面示意图。

请参照图4，带*的是必填项。基础信息中，必填项包括日志采集规则的名称、日志集等。日志采集规则的名称例如是采集人员自定义的名称。日志集可以是已有日志集中的某个日志集，也可以是新建日志集。日志集位于云存储，用于存储边缘集群根据日志采集规则采集到的日志。

日志源用于配置要采集哪些容器的日志。日志源上具有两个可选的控件，一个是指定工作负载，一个是指定pod标签(labels)，无论选中哪个控件，最终都是为了配置待采集日志的容器。假设采集人员选中指定工作负载，如图中灰色填充所示，则采集人员通过下拉菜单依次选择命名空间(namespace)、工作负载类型、工作负载和容器，从而配置好待采集日志的容器。其中，工作负载类型包括Deployment、ReplicaSet等，工作负载是根据需求创建的。

图4中，一个命名空间、工作负载类型、工作负载和容器的组合就是一个日志源。若需要增加第二个日志源，则点击添加数据按钮，继续配置命名空间、工作负载类型、工作负载和容器，从而得到第二个日志源。

日志解析方式用于指示如何解析日志，包括单行文本解析方式、正则表达式、json、分隔符等。

302、响应所述采集请求，生成第一自定义资源CRD。

其中，所述第一CRD与至少一个容器绑定，所述至少一个容器是所述日志采集规则指示的容器。

请参照图2，中心集群上设置有微服务，微服务会生成第一CRD，并下发给中心集群的API server。中心集群管理各个边缘集群，所有的日志采集配置，即第一CRD都通过中心集群下发。中心集群的API server接收到第一CRD后，将该第一CRD存储在etcd上。

请继续参照图4，一个日志源具有对应的命名空间、工作负载类型、工作负载和容器。针对每个日志源，中心集群的微服务生成第一CRD，第一CRD的数量和日志源的个数相同。一个第一CRD指示至少一个容器，该至少一个容器是需要进行日志采集的容器。

303、向所述至少一个容器中各容器所在的边缘集群发送所述第一CRD。

相应的，各边缘集群接收来自中心集群的第一CRD。

本申请实施例中，一个日志源指示多个待采集日志的容器，这些容器很有可能分布在不同的边缘集群上。例如，中心集群管理300个边缘集群，日志源指示100个容器，这100个容器分布在10个边缘节点上。因此，中心集群向10个边缘集群发送第一CRD。这10个边缘集群是中心集群管理的300个边缘集群中的集群，且每个边缘集群中具有日志源指示的容器。比如，每个边缘集群的容器中，有10个容器是日志源指示的100个容器中的容器。

304、从所述多个工作节点中确定出节点集合。

其中，所述节点集合中的每个工作节点上具有所述至少一个容器中的容器。

本申请实施例中，一个边缘集群上有多个工作节点，每个工作节点上有多个容器。边缘集群接收到第一CRD后，从本地的多个工作节点上确定出节点集合，节点集合中的任意一个工作节点上具有至少一个容器中的容器。示例性的，请参照图5。

图5是本申请实施例提供的日志采集方法中节点集合的示意图。请参照图5，第一CRD与100个容器绑定，即待采集日志的容器共100个。这100个容器中，有10个容器位于边缘集群甲上。边缘集群甲上有4个工作节点，即work node1～work node 4，每个工作节点上具有5个容器。其中，work node1上的容器a～容器e、work node2上的容器f和容器g、worknode3上的容器l、容器m和容器n是上述的10个容器。因此，边缘集群确定出节点集合包括work node1、work node2和work node3。

请参照图2，边缘集群的API server接收到第一CRD后，将该第一CRD存储在边缘集群的etcd上。边缘集群上的日志控制器根据需采集日志的容器所在的工作节点，确定出节点集合。

305、针对所述节点集合中的每个工作节点，生成所述工作节点对应的第二CRD。

本申请实施例中，边缘集群根据待采集日志的容器所在的工作节点，智能归类日志采集规则以得到工作节点对应的第二CRD，能够动态发现日志。

继续沿用上述的例子，边缘集群为work node1、work node2和work node3分别生成第二CRD。第二CRD用于指示一个工作节点需要采集的容器的日志采集规则。

306、对于所述节点集合中的每个工作节点，根据所述工作节点对应的第二CRD采集日志。

生成第二CRD后，边缘节点为对节点集合中的每个工作节点，根据对应的第二CRD采集日志。

请参照图2，每个工作节点上具有采集组件，采集组件监听到本工作节点的第二CRD后，执行采集任务，将采集到的日志上报给云存储。

由于采集人员配置日志采集规则的时候，主要是配置需要对哪些容器进行日志采集，并不关乎容器的具体位置。中心集群能够确定出需要向哪些边缘节点发送第一CRD。而边缘节点是知道容器位于哪个工作节点上的，例如，假设图5中容器f原本位于work node1，但是由于容器漂移，容器f漂移到work node2上。由于边缘集群能够根据第二CRD感知容器漂移等动态变化，因此，本案的日志采集方法能够应对容器漂移等动态场景。

本申请实施例提供的日志采集方法，中心集群根据来自控制台的、携带日志采集规则的采集请求，生成与至少一个容器绑定的第一CRD，并将第一CRD发送给至少一个容器中各容器所在的边缘集群。边缘集群接收到第一CRD后，确定出节点集群，节点集合中的每个工作节点上具有至少一个容器中的容器。之后，边缘集群针对每个工作节点，生成第二CRD，并根据工作节点对应的第二CRD采集日志。采用该种方案，无需一一登录各个容器，通过一次配置即可采集和查询海量边缘容器日志，方便快捷配置采集目标，耗时短，便于容器化应用的及时维护，确保容器化应用正常运行。

可选的，上述实施例中，边缘集群的日志采集流程包括三个主要步骤：日志采集规则发现和容器服务发现、日志发现、采集任务执行。通过该日志采集流程，保证日志采集的可靠性、高效性、多租户隔离和顺序性。其中，可靠性指不漏采、不重采；高效性指减少采集延迟。多租户隔离指：日志采集场景下的多租户隔离，保证各个采集工作互不影响。顺序性是指能够快速查找到上下文。下面，对该三个步骤分别进行详细说明。

首先，日志采集规则发现和容器服务发现。

图6是本申请实施例提供的日志采集方法中边缘集群的流程图。请参照图6，边缘集群监听两个内容：一个是第二CRD，一个是容器事件(containerd event)。这是因为：有时候采集人员先下发配置，边缘集群先生成第二CRD，而容器在配置下发后才启动；而另外一些时候容器先启动，采集人员的配置后下发。

对于每个工作节点，边缘集群监听过程中，通过API server接收第一CRD，根据第一CRD生成本工作节点的第二CRD。根据第二CRD确定需要采集的容器所在的pod，即目标pod。本申请实施例中，工作节点上的容器对应至少一个pod，所述至少一个pod包含所述目标pod，所述目标pod包含的容器中存在目标容器，所述目标容器是所述至少一个容器中的容器。

确定出目标pod后，边缘集群监听到目标pod中的容器启动后，生成目标容器的采集事件并存储至事件队列。一个采集事件对应一个目标容器。其中，pod队列例如是边缘集群的所有pod，比如3000个。之后，边缘集群执行第二个主要步骤。

采用该种方案，边缘集群动态发现采集规则并执行采集任务，无需采集人员多次登录每个容器，提高日志采集效率，进而提高容器化应用的问题排查效率。

其次、日志发现。

经过上述的第一个主要步骤，边缘集群将容器的采集事件存储在采集事件队列中。日志发现过程中，边缘集群从采集事件队列中获取要执行的采集事件。对于每个采集事件，确定待采集的目标日志。由于一个采集事件对应一个容器，而一个容器可能会产生多种日志，如访问日志、调试(debug)日志、资源类日志、监控日志等，因此，对于每个采集事件，可能对应多个目标日志。之后，边缘集群根据目标日志生成采集任务并存储至任务队列。后续采集任务执行过程中，每次并发执行任务池中预设数量的采集任务。

本申请实施例中，边缘集群为每个具有目标容器的工作节点生成第二CRD。一个工作节点上具有多个容器，第二CRD指示需要采集多个容器中哪些容器的日志。由于采集人员可根据需求配置第二CRD，比如，上次配置采集多个容器中的4个容器的日志，本次配置采集3个容器的日志，因此，本申请实施例提供的日志采集方法能够动态的发现目标日志，能方便采集人员灵活的配置需要采集日志的容器、速度快、灵活度高。

本申请实施例中，从配置(第一CRD)下发到日志采集，再到存储采集到的日志，每一条链路都会产生时延。从采集组件的角度而言，要保证第二CRD的及时发现，以及日志的快速采集。边缘集群通过轮询所有待采集容器以及监听容器的采集事件，以确保快速发现第二CRD。同时，针对日志轮转情况也加上监听，保证目标日志更快被发现，采集日志时使用多租户隔离方案，保障所有目标日志可以公平采集，时效一致。

采用该种方案，边缘集群根据采集事件对应的容器确定目标日志，生成采集任务并执行，具有采集配置便利性，可动态发现目标日志，智能采集日志，保证容器化应用日常运维过程中，能根据需求采集日志。

可选的，上实施例中，采集人员可通过图4所示界面配置不同的日志采集规则。另外，对于同一条日志采集规则，也可以根据需求灵活的进行修改。因此，边缘集群每次生成采集事件后，还需要确定事件类型，判断采集事件是新增采集还是删除采集，根据判断结果确定目标日志。

边缘集群从采集事件队列中取出一件采集事件后，根据所述采集事件对应的第二CRD，确定所述采集事件的事件类型。判断过程中，边缘集群对比本次针对该工作节点生成的第二CRD，以及上次生成的第二CRD。倘若之前从未针对该工作节点生成第二CRD，则采集事件是新增采集事件。若之前生成过第二CRD，则比较相邻两次，即本次和上次各自生成的第二CRD。

例如，工作节点上有容器a～容器e五个容器，本次生成的第二CRD指示采集容器b、容器c和容器d产生的日志，上次生成的第二CRD指示采集容器a、容器b、容器c、容器d和容器e产生的日志，新增对容器a和容器e产生的日志的采集，因此是新增采集事件。

再如，工作节点上有容器a～容器e五个容器，本次生成的第二CRD指示容器a、容器b、容器c、容器d和容器e产生的日志，上次生成的第二CRD指示采集容器a、容器b、容器c产生的日志，删除对容器d和容器e产生的日志的采集，因此是删除采集事件。

判断出采集事件的事件类型后，当采集事件是新增采集时，边缘集群确定新增容器，将新增容器产生的日志作为目标日志，并添加到已有的目标日志中。例如，之前仅采集容器a、容器b、容器c产生的日志，本次接收到的第二CRD指示采集容器a、容器b、容器c、容器d和容器e产生的日志，则这5个容器产生的日志均为目标日志。对于新增采集事件，边缘集群需要自动添加定期扫描、监听文件、读取文件等。

当采集事件是删除采集事件时，边缘集群从容器集合中确定出需停止采集日志的容器，将剩余容器产生的日志作为目标日志，所述容器集合中的容器是本次接收到所述第二CRD之前需采集日志的容器。例如，之前采集容器a、容器b、容器c、容器d和容器e产生的日志，本次接收到的第二CRD仅指示采集容器a、容器b、容器c产生的日志，则停止对容器d和容器e产生的日志的采集。对于删除采集事件，边缘集群需对停止日志采集的容器删除定期扫描、删除文件监听、停止日志读取等。

采用该种方案，边缘集群判断每一个采集事件的事件类型，根据事件类型确定需要增加对哪些日志的采集、删除对哪些日志的采集，从而动态发现目标日志，方便采集人员的配置的同时，提高日志采集效率。另外，通过文件轮询和事件监听方式，可有效降低采集延迟。

最后，采集任务执行。

本步骤中，边缘集群以固定协程数并发执行采集任务池中的采集任务，记录偏移量，落盘文件，由文件发送器把落盘后的文件发送给云存储。

边缘集群从任务队列中取出待读取的目标日志得到采集任务，将采集任务放入任务池(task pool)，以固定协程数并发执行采集任务。例如，固定协程数为10个，每次并发执行10个采集任务。

并发执行采集任务的过程中，每个协程每次读取固定大小的数据，以缓冲固定大小的日志，保证每次采集任务可以快速执行完，以便其他任务能均衡的放入任务池。例如，每个协程每次读取数据时，读取16K的数据。

传统的日志采集方法中，采集工作是通过一个配置一个协程来保证隔离，如果日志的数据量比较大，则协程一直占用资源，不会释放资源。而本申请实施例中，若一个日志比较大，容器一直在往日志中写数据，则这个日志在读事件队列(read event queue)中出现的次数比较多，但是必须监听或扫描到，才会出现在读事件队列中，不会一直占用CPU等资源。

采用该种方案，通过事件监听机制和轮询机制把待采集任务入任务池，保证多租户之间的配置和采集工作互不影响，实现多租户隔离，保证公平性。

可选的，上述实施例中，边缘集群并发执行采集任务的过程中，对于所述并发执行的每个采集任务，判断是否满足落盘条件。当满足采集任务满足所述落盘条件时，根据已采集的日志数据生成子文件；记录所述子文件在所述目标日志中的偏移位置。若采集任务不满足落盘条件，则继续执行采集任务，以采集更多的日志数据。其中，落盘条件包括下述条件中的至少一个：距离上次落盘大于或等于预设时长、已读取的行数大于或等于预设行数、已采集的日志数据的数据量大于或等于预设数据量。

示例性的，假设预设时长为3秒、预设行数为2000行、预设数据流为20M，则对于并发执行的每个采集任务，每次读取数据后，比如读取16K的数据后，边缘集群判断该采集任务是否满足落盘条件。落盘是指将采集到的日志存储在云存储中。

由于容器化应用的维护过程中，有时候对日志的实时性要求比较高，因此，如果距离上次落盘时长超过3秒，则无论当前已经采集到多少日志数据，均要落盘。例如，有些日志吞吐比较大，经过3秒后不会采集到20M的日志数据或2000行的日志数据，比如仅采集了1000行的日志数据，此时，需要将已采集到的日志数据落盘。

当满足落盘条件时，边缘集群根据已采集的日志数据生成子文件，通过文件发送器将子文件上传给云存储。同时，对子文件进行记录所述子文件在所述目标日志中的偏移位置。

采用该种方案，每次满足落盘条件后，记录子文件的偏移位置，将偏移位置存储在本地数据库。当采集组件不可用或升级时，可保证恢复使用的采集组件能够从上一次采集的位置继续采集日志，通过偏移量机制保证不漏采、不重采、提高日志采集的可靠性。

可选的，上述实施例中，当所述采集任务满足所述落盘条件时，边缘集群根据已采集的日志数据生成子文件之后，还根据各子文件在所述目标日志中的位置，按顺序为每个子文件分配唯一标识，并为每个子文件的每行内容分配独立索引。之后，存储所述子文件、所述子文件的位移标识、所述子文件中每行内容的独立索引。例如，将子文件、子文件的位移标识、子文件中每行内容的独立索引存储在云存储中。

示例性的，为了保证拆分后的子文件上报后，能有序查出原始日志的上下文，边缘集群对拆分出的每个子文件打上唯一标识，如唯一单调递增的标识。同时，在分散的每个子文件里对每行日志加上独立的递增索引，将唯一标识、独立索引与子文件一起存储至云存储。这样一来，日志查询过程中，查询人员通过唯一标识和独立索引即可查询到原始日志的上下文。例如，查询人员通过控制台输入唯一标识就能找到子文件，输入独立索引后，能进一步的查找到子文件的某一行的内容。

采用该种方案，通过为子文件添加唯一标识，为每行内容增加独立索引，便于确定原始日志的上下文，降低容器化应用过程中，通过日志排查问题的时长，即提高排查效率。

可选的，上述实施例中，边缘集群还为所述目标日志分配标签，所述标签用于指示产生所述目标日志的容器所在的工作节点和所述工作节点归属的边缘集群。

边缘集群对读取数据后，进行富化处理，为目标日志打上标签，以标注该日志是哪个边缘集群中的那个工作节点上的哪个容器产生的，方便日志分析。

采用该种方案，通过富化处理，为每一条目标日志打上标签，以标记产生目标日志的容器所在的工作节点和工作节点归属的边缘集群，便于分析日志时，快速确定目标日志的来源，提高日志分析效率，进而提高通过日志排查问题的效率。

可选的，上述实施例中，中心集群还接收来自所述控制台的、携带查询条件的查询请求。之后，中心集群响应该查询请求，根据查询条件获取日志并反馈给所述控制台。其中，查询条件包括日志集的标识、日志内容标识、容器标识、pod标识或边缘集群标识等。

示例性的，日志集例如为图4基础信息中的日志集，是一条日志采集规则对应的日志集。倘若查询人员不配置其他过滤条件，如日志内容标识、容器标识等，则表示查询人员想要查询日志采集规则下的所有日志。

采用该种方案，通过将采集的日志存储在云存储中，通过控制台即智能查询日志，保证日常运维能随时查到需要分析的日志，提供容器化应用问题排查的效率。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图7为本申请实施例提供的一种日志采集装置的示意图。该日志采集装置700包括：收发模块71、确定模块72、生成模块73和处理模块74。

收发模块71，用于接收来自中心集群的第一自定义资源CRD，所述第一CRD指示至少一个容器，所述边缘集群包括多个工作节点，每个工作节点上部署多个容器；

确定模块72，用于从所述多个工作节点中确定出节点集合，所述节点集合中的每个工作节点上具有所述至少一个容器中的容器；

生成模块73，用于针对所述节点集合中的每个工作节点，生成所述工作节点对应的第二CRD；

处理模块74，用于对于所述节点集合中的每个工作节点，根据所述工作节点对应的第二CRD采集日志。

一种可行的实现方式中，所述处理模块74，用于根据所述第二CRD确定目标服务单元pod，所述工作节点上的容器对应至少一个pod，所述pod中包含所述目标pod，所述目标pod包含的容器中存在目标容器；轮询包含所述目标pod的pod列表并监听容器事件，以确定所述目标容器；所述目标容器启动后，针对所述目标容器生成采集事件并存储至事件队列；执行所述事件队列中的采集事件以采集日志。

一种可行的实现方式中，所述处理模块74执行所述事件队列中的采集事件以采集日志时，用于对于所述事件队列中的每个采集事件，确定待采集的目标日志；根据所述目标日志生成采集任务并存储至任务池；每次并发执行所述任务池中预设数量的采集任务。

一种可行的实现方式中，所述处理模块74，还用于对于所述并发执行的每个采集任务，判断是否满足落盘条件，所述落盘条件包括下述条件中的至少一个：距离上次落盘大于或等于预设时长、已读取的行数大于或等于预设行数、已采集的日志数据的数据量大于或等于预设数据量；当所述采集任务满足所述落盘条件时，根据已采集的日志数据生成子文件；记录所述子文件在所述目标日志中的偏移位置。

一种可行的实现方式中，所述处理模块74根据已采集的日志数据生成子文件之后，还用于根据各子文件在所述目标日志中的位置，为每个子文件分配唯一标识，并为每个子文件的每行内容分配独立索引；存储所述子文件、所述子文件的位移标识、所述子文件中每行内容的独立索引。

一种可行的实现方式中，所述处理模块74，还用于为所述目标日志分配标签，所述标签用于指示产生所述目标日志的容器所在的工作节点和所述工作节点归属的边缘集群。

一种可行的实现方式中，所述处理模块74，用于根据所述采集事件对应的第二CRD，确定所述采集事件的事件类型，所述事件类型包括新增采集事件或删除采集事件；

当所述采集事件是新增采集事件时，确定新增容器，将所述新增容器产生的日志作为待采集的目标日志；当所述采集事件是删除采集事件时，从容器集合中确定出需停止采集日志的容器。

本申请实施例提供的日志采集装置，可以执行上述实施例中边缘集群的动作，其实现原理和技术效果类似，在此不再赘述。

图8为本申请实施例提供的另一种日志采集装置的示意图。该日志采集装置800包括：接收模块81、处理模块82和发送模块83。

接收模块81，用于接收来自控制台的、携带日志采集规则的采集请求；

处理模块82，用于响应所述采集请求，生成第一自定义资源CRD，所述第一CRD与至少一个容器绑定，所述至少一个容器是所述日志采集规则指示的容器；

发送模块83，用于向所述至少一个容器中各容器所在的边缘集群发送所述第一CRD。

一种可行的实现方式中，所述接收模块81，还用于接收来自所述控制台的、携带查询条件的查询请求，所述查询条件包括下述条件中的至少一个：日志集的标识、日志内容标识、容器标识、pod标识或边缘集群标识；

所述处理模块82，还用于响应所述查询请求，根据所述查询条件获取日志；

所述发送模块83，还用于向控制台反馈获取到的日志。

本申请实施例提供的日志采集装置，可以执行上述实施例中中心集群的动作，其实现原理和技术效果类似，在此不再赘述。

图9为本申请实施例提供的一种电子设备的结构示意图。该电子设备900例如为上述的边缘集群或中心集群，该电子设备900包括：

处理器91和存储器92；

所述存储器92存储计算机指令；

所述处理器91执行所述存储器92存储的计算机指令，使得所述处理器91执行如上边缘集群或中心集群实施的日志采集方法。

处理器91的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

可选地，该电子设备900还包括通信部件93。其中，处理器91、存储器92以及通信部件93可以通过总线94连接。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现如上边缘集群或中心集群实施的日志采集方法。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包含计算机程序，计算机程序被处理器执行时实现如上边缘集群或中心集群实施的日志采集方法。

本领域技术人员在考虑说明书及实践这里公开的申请后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (11)

1.一种日志采集方法，其特征在于，应用于边缘集群，所述方法包括：

接收来自中心集群的第一自定义资源CRD，所述第一CRD指示至少一个容器，所述边缘集群包括多个工作节点，每个工作节点上部署多个容器；

从所述多个工作节点中确定出节点集合，所述节点集合中的每个工作节点上具有所述至少一个容器中的容器；

针对所述节点集合中的每个工作节点，生成所述工作节点对应的第二CRD；

对于所述节点集合中的每个工作节点，根据所述工作节点对应的第二CRD采集日志。

2.根据权利要求1所述的方法，其特征在于，所述对于所述节点集合中的每个工作节点，根据所述工作节点对应的第二CRD采集日志，包括：

根据所述第二CRD确定目标服务单元pod，所述工作节点上的容器对应至少一个pod，所述pod中包含所述目标pod，所述目标pod包含的容器中存在目标容器；

轮询包含所述目标pod的pod列表并监听容器事件，以确定所述目标容器；

当所述目标容器启动后，针对所述目标容器生成采集事件并存储至事件队列；

执行所述事件队列中的采集事件以采集日志。

3.根据权利要求2所述的方法，其特征在于，所述执行所述事件队列中的采集事件以采集日志，包括：

对于所述事件队列中的每个采集事件，确定待采集的目标日志；

根据所述目标日志生成采集任务并存储至任务池；

每次并发执行所述任务池中预设数量的采集任务。

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

对于所述并发执行的每个采集任务，判断是否满足落盘条件，所述落盘条件包括下述条件中的至少一个：距离上次落盘大于或等于预设时长、已读取的行数大于或等于预设行数、已采集的日志数据的数据量大于或等于预设数据量；

当所述采集任务满足所述落盘条件时，根据已采集的日志数据生成子文件；

记录所述子文件在所述目标日志中的偏移位置。

5.根据权利要求4所述的方法，其特征在于，所述当所述采集任务满足所述落盘条件时，根据已采集的日志数据生成子文件之后，还包括：

根据各子文件在所述目标日志中的位置，为每个子文件分配唯一标识，并为每个子文件的每行内容分配独立索引；

存储所述子文件、所述子文件的位移标识、所述子文件中每行内容的独立索引。

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

为所述目标日志分配标签，所述标签用于指示产生所述目标日志的容器所在的工作节点和所述工作节点归属的边缘集群。

7.根据权利要求3所述的方法，其特征在于，所述对于所述事件队列中的每个采集事件，确定待采集的目标日志，包括：

根据所述采集事件对应的第二CRD，确定所述采集事件的事件类型，所述事件类型包括新增采集事件或删除采集事件；

当所述采集事件是新增采集事件时，确定新增容器，将所述新增容器产生的日志作为待采集的目标日志；

当所述采集事件是删除采集事件时，从容器集合中确定出需停止采集日志的容器。

8.一种日志采集方法，其特征在于，应用于中心集群，所述方法包括：

接收来自控制台的、携带日志采集规则的采集请求；

响应所述采集请求，生成第一自定义资源CRD，所述第一CRD与至少一个容器绑定，所述至少一个容器是所述日志采集规则指示的容器；

向所述至少一个容器中各容器所在的边缘集群发送所述第一CRD。

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

接收来自所述控制台的、携带查询条件的查询请求，所述查询条件包括下述条件中的至少一个：日志集的标识、日志内容标识、容器标识、pod标识或边缘集群标识；

响应所述查询请求，根据所述查询条件获取日志并反馈给所述控制台。

10.一种电子设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时使得所述电子设备实现如权利要求1至9任一所述的方法。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至9任一所述的方法。