CN114461503A - 基于Kubernetes集群的日志收集方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请涉及数据处理技术领域，本申请提供了一种基于Kubernetes集群的日志收集方法、装置、电子设备及存储介质。该方法包括：通过独立构建的信息收集容器中的代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息以生成并执行运行配置文件，然后动态监听工作节点中的目标容器的运行事件以生成对应的日志收集配置文件，该日志收集配置文件包括容器名称、目标容器和日志信息之间的关联关系，接着根据日志收集配置文件从内存中搜集目标日志信息并发送至日志服务集群。本申请在搜集目标日志信息的过程中考虑了目标日志信息和容器名称、目标容器之间的关联关系，克服了相关技术中Filebeat无法获知容器日志和容器之间的关系的问题，提高了容器日志的收集准确性。

Description

基于Kubernetes集群的日志收集方法、装置、电子设备及存储 介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种基于Kubernetes集群的日志收集方法、装置、电子设备及存储介质。

背景技术

日志收集分析是Kubernetes集群系统工作中的重要依据，业界许多日志系统都会选择在节点上部署Filebeat来采集Kubernetes集群中的容器日志，但是，Filebeat无法获知容器日志文件和容器之间的关系，不便于后续用户对特定容器的日志查询，而且，由于很多时候均需要利用容器的日志来定位问题，因此容器日志的准确性和重要性不言而喻。如何更高效准确的解决Kubernetes集群中容器的日志收集问题，成为一个亟待解决的问题。

发明内容

本申请实施例的主要目的在于提出一种基于Kubernetes集群的日志收集方法、装置、电子设备及存储介质，旨在提高Kubernetes集群中容器日志的收集准确性。

为实现上述目的，本申请实施例的第一方面提出了一种基于Kubernetes集群的日志收集方法，应用于所述Kubernetes集群中的工作节点，所述日志收集方法包括：

构建独立的信息收集容器，其中，所述信息收集容器包括用于收集日志信息的代理应用；

启动所述信息收集容器中的所述代理应用，通过所述代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，根据所述日志配置信息生成用于执行日志收集功能的运行配置文件，并控制所述代理应用执行所述运行配置文件；

通过所述代理应用动态监听所述工作节点中的目标容器的运行事件；

当监听到所述运行事件，生成与所述目标容器对应的日志收集配置文件，其中，所述日志收集配置文件包括容器名称、所述目标容器和所述目标容器所生成的日志信息之间的关联关系；

通过所述代理应用对所述工作节点的目标文件目录进行扫描，将所述目标文件目录中的由所述目标容器生成的目标日志信息加载进内存；

根据所述日志收集配置文件从所述内存中搜集所述目标日志信息，将所述目标日志信息发送至日志服务集群。

根据本申请一些实施例提供的日志收集方法，所述构建独立的信息收集容器之后，所述日志收集方法还包括：

设置所述信息收集容器的内存容量小于或等于预设容量，以及设置所述信息收集容器的中央处理器的核数小于或等于预设数量；

将所述工作节点的根路径映射到所述信息收集容器内部的目标路径。

根据本申请一些实施例提供的日志收集方法，所述通过所述代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，包括：

通过所述代理应用采用超文本传输协议访问所述Kubernetes集群的主节点上的接口服务器以请求集群级别的日志配置信息；

通过所述代理应用接收所述接口服务器发送的所述集群级别的日志配置信息。

根据本申请一些实施例提供的日志收集方法，所述通过所述代理应用动态监听所述工作节点中的目标容器的运行事件，包括：

通过所述代理应用动态监听所述工作节点中Docker守护进程中的目标容器的运行事件；

其中，所述运行事件包括启动事件、停运事件或重启事件中的任意一种。

根据本申请一些实施例提供的日志收集方法，所述生成与所述目标容器对应的日志收集配置文件之后，所述日志收集方法还包括：

当监听到所述目标容器的更新事件时，根据所述更新事件对与所述目标容器对应的日志收集配置文件进行更新处理；

或者，

当监听到所述目标容器的删除事件时，根据所述删除事件对与所述目标容器对应的日志收集配置文件进行删除处理。

根据本申请一些实施例提供的日志收集方法，所述通过所述代理应用对所述工作节点的目标文件目录进行扫描，将所述目标文件目录中的由所述目标容器生成的目标日志信息加载进内存，包括：

通过所述代理应用每间隔预设时间对所述工作节点的目标文件目录进行扫描；

当在所述目标文件目录中扫描到由所述目标容器生成的目标日志信息，将所述目标文件目录中的所述目标日志信息动态加载进内存。

根据本申请一些实施例提供的日志收集方法，所述根据所述日志收集配置文件从所述内存中搜集所述目标日志信息，将所述目标日志信息发送至日志服务集群，包括：

根据所述日志收集配置文件从所述内存中搜集所述目标日志信息；

根据所述目标容器、所述目标容器对应的命名空间、所述目标容器对应的容器名称和所述目标容器对应的Kubernetes集群，对所述目标日志信息进行结构化处理；

将经过结构化处理的所述目标日志信息发送至日志服务集群。

为实现上述目的，本申请实施例的第二方面提出了一种基于Kubernetes集群的日志收集装置，所述日志收集装置包括：

容器构建模块，用于构建独立的信息收集容器，其中，所述信息收集容器包括用于收集日志信息的代理应用；

容器运行模块，用于启动所述信息收集容器中的所述代理应用，通过所述代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，根据所述日志配置信息生成用于执行日志收集功能的运行配置文件，并控制所述代理应用执行所述运行配置文件；

事件监听模块，用于通过所述代理应用动态监听工作节点中的目标容器的运行事件；

文件生成模块，用于当监听到所述运行事件，生成与所述目标容器对应的日志收集配置文件，其中，所述日志收集配置文件包括容器名称、所述目标容器和所述目标容器所生成的日志信息之间的关联关系；

信息加载模块，用于通过所述代理应用对所述工作节点的目标文件目录进行扫描，将所述目标文件目录中的由所述目标容器生成的目标日志信息加载进内存；

信息发送模块，用于根据所述日志收集配置文件从所述内存中搜集所述目标日志信息，将所述目标日志信息发送至日志服务集群。

为实现上述目的，本申请实施例的第三方面提出了一种电子设备，所述电子设备包括存储器、处理器、存储在所述存储器上并可在所述处理器上运行的程序，所述程序被所述处理器执行时实现上述第一方面所述的日志收集方法。

为实现上述目的，本申请实施例的第四方面提出了一种存储介质，所述存储介质为计算机可读存储介质，用于计算机可读存储，所述存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述第一方面所述的日志收集方法。

本申请提出一种基于Kubernetes集群的日志收集方法、装置、电子设备及存储介质，通过独立构建的信息收集容器中的代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息以生成并执行运行配置文件，然后动态监听工作节点中的目标容器的运行事件以生成与目标容器对应的日志收集配置文件，其中，日志收集配置文件包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系，接着根据日志收集配置文件从内存中搜集目标日志信息，并将目标日志信息发送至日志服务集群。通过上述方法得到的发给日志服务集群的目标日志信息，是与容器名称以及目标容器相关联的，克服了相关技术中Filebeat无法获知容器日志和容器之间的关系的问题，提高了Kubernetes集群中容器日志的收集准确性。

附图说明

图1是本申请实施例提供的用于执行基于Kubernetes集群的日志收集方法的实施环境的示意图；

图2是本申请实施例提供的一种基于Kubernetes集群的日志收集方法的流程图；

图3是本申请另一个实施例提供的一种基于Kubernetes集群的日志收集方法的流程图；

图4是图2中步骤S120的一种具体方法流程图；

图5是图2中步骤S150的一种具体方法流程图；

图6是图2中步骤S160的一种具体方法流程图；

图7是本申请实施例提供的基于Kubernetes集群的日志收集装置的结构示意图；

图8是本申请实施例提供的电子设备的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

需要说明的是，除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

首先，对本申请中涉及的若干名词进行解析：

Kubernetes集群：Kubernetes可以简称为K8s，是一个能用于管理云平台中多个主机上的容器化的应用。Kubernetes提供了应用部署，规划，更新，维护的一种机制。Kubernetes中应用部署是通过部署容器方式实现的，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。在Kubernetes集群环境下，所部署的业务以容器(Pod)的形式运行在节点上面，其中，每个Pod中至少设置有一个业务容器。

Filebeat：是用于转发和集中日志数据的轻量级传送工具。Filebeat监视所指定的日志文件或位置，收集日志事件，并将它们转发到Elasticsearch或Logstash进行索引。Filebeat的工作方式如下：启动Filebeat时，Filebeat会启动一个或多个输入，这些输入会在指定的位置中查找日志数据。对于Filebeat所找到的每个日志，Filebeat都会启动收集器，每个收集器都读取单个日志以获取新内容，并将新日志数据发送到Libbeat，Libbeat会对这些日志数据进行聚集，并将聚集的日志数据发送到为Filebeat配置的输出。

Elasticsearch：是一个分布式、高扩展、高实时的搜索与数据分析引擎。Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索，具有接近实时的搜索，并支持多租户。Elasticsearch是分布式的，这意味着索引可以被分成分片，每个分片可以有0个或多个副本。每个节点托管一个或多个分片，并充当协调器将操作委托给正确的分片。相关数据通常存储在同一个索引中，该索引由一个或多个主分片和零个或多个复制分片组成。一旦创建了索引，就不能更改主分片的数量。Elasticsearch的实现原理主要分为以下几个步骤：首先用户将数据提交到Elasticsearch数据库中，再通过分词控制器去将对应的语句分词，将其权重和分词结果一并存入数据，当用户搜索数据时候，再根据权重将结果排名，打分，再将返回结果呈现给用户。

Docker：是一个应用容器引擎，其本身并不是容器，Docker是创建容器的工具。Docker的整体架构主要由三个部分构成：Client(客户端)、Docker daemon(Docker守护进程)和Registry(注册器)，其中Docker daemon作为关键一环起到了承上启下的作用，上接Registry，下联Client。其中，Docker daemon能够接收Docker Client发送的操作指令并执行，另外，Docker daemon还能够管理Docker的对象，如镜像、容器、数据卷、网络。Dockerdaemon可以与其它Docker daemon通信以管理容器的服务。Docker Client提供了一组人机接口(可以是命令行，也可以是SDK)，使用户可以向Docker发送操作指令并接受执行结果。一个Docker Client可以与多个Docker Host建立连接。Docker Client可以与Docker Host安装在一台主机上也可以安装在不同的主机上。Docker Registry提供了保存镜像的能力。使用docker pull或者docker search等命令的时候，实际上就是在查询镜像仓库。

目前，业界的许多日志系统中，都选择在Kubernetes集群的节点上的已部署容器中进一步部署Filebeat来采集Kubernetes集群中的容器日志，但是，这会存在一些问题：首先，这种部署Filebeat的方式，会导致Filebeat对宿主机的CPU和内存等资源的占用无法得到有效限制，从而会对Kubernetes集群的安全使用产生影响；其次，Filebeat无法获知容器日志文件和容器之间的关系，不便于后续用户对特定容器的日志查询。然而，由于很多时候均需要利用容器的日志来定位问题，因此，如果获取到的容器日志文件无法与容器相关联，则会影响对问题的定位的便捷性和准确性，从而无法对问题进行快速定位。

为了能够提高Kubernetes集群中容器日志的收集准确性以便于后续能够对问题进行快速定位，本申请提出一种基于Kubernetes集群的日志收集方法、装置、电子设备及存储介质，通过独立构建的信息收集容器中的代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息以生成并执行运行配置文件，然后动态监听工作节点中的目标容器的运行事件以生成与目标容器对应的日志收集配置文件，其中，日志收集配置文件包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系，接着根据日志收集配置文件从内存中搜集目标日志信息，并将目标日志信息发送至日志服务集群。通过上述方法得到的发给日志服务集群的目标日志信息，是与容器名称以及目标容器相关联的，克服了相关技术中Filebeat无法获知容器日志和容器之间的关系的问题，从而提高了Kubernetes集群中容器日志的收集准确性，使得后续能够对问题进行快速定位。

图1是本申请实施例提供的用于执行基于Kubernetes集群的日志收集方法的实施环境的示意图。参照图1，该Kubernetes集群包括主节点110以及工作节点120，工作节点120的数量可以为多个。主节点110中设置有接口服务器(Kube-apiserver)111，通过主节点110中的Kube-apiserver111可以对Kubernetes集群进行操作，此外，主节点110中还包括有控制器112，通过控制器112可以实现针对工作节点120的多种配置。工作节点120中包括有多个Pod121，Pod121是Kubernetes集群的最小可部署单元，一个Pod121代表了集群中运行的一个工作负载，可以包括一个或多个Docker容器、挂载需要的存储，并拥有唯一的IP地址，Pod121中的多个容器将始终在同一个节点上运行。

需要说明的是，主节点110和工作节点120均可以例如为数据中心中的物理机器，还可以例如为云供应商上的虚拟机等，本实施例对此并不作具体限定。

图2是本申请实施例提供的一种基于Kubernetes集群的日志收集方法的流程图。如图2所示，该基于Kubernetes集群的日志收集方法，包括但不限于如下步骤S110至步骤S160。需要说明的是，该方法可以由Kubernetes集群中的工作节点执行，例如可以由如图1所示实施例中的工作节点120执行。

S110：构建独立的信息收集容器，其中，信息收集容器包括用于收集日志信息的代理应用。

可以理解的是，在执行基于Kubernetes集群的日志收集方法时，可以先利用Kubernetes中特有的资源对象DaemonSet的特点，在每个工作节点上分别构建一个独立的信息收集容器，并且该信息收集容器包括有用于收集日志信息的代理应用。由于该信息收集容器是独立构建的，和工作节点中的其他容器相互隔离，因此可以针对该信息收集容器进行独立的CPU资源和内存资源的设置，所以，可以很方便的限制该信息收集容器的CPU资源和内存资源，从而降低对Kubernetes集群的安全使用的影响。

需要说明的是，可以通过kubectl在Kubernetes集群的每一个工作节点上单独构建独立的信息收集容器，并且在每一个工作节点上独立构建的该信息收集容器，都包括有用于收集日志信息的代理应用。

需要说明的是，kubectl是操作Kubernetes集群的命令行工具，可以安装在Kubernetes的主节点上，通过kubectl可以实现对Kubernetes集群中各种资源的增删改查等操作。

S120：启动信息收集容器中的代理应用，通过代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，根据日志配置信息生成用于执行日志收集功能的运行配置文件，并控制代理应用执行运行配置文件。

本步骤中，由于在步骤S110构建了独立的信息收集容器，并且该信息收集容器包括有用于收集日志信息的代理应用，因此可以启动该信息收集容器中的代理应用，通过该代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，根据日志配置信息生成用于执行日志收集功能的运行配置文件，并控制代理应用执行运行配置文件，以便于在后续步骤中可以根据该运行配置文件搜集工作节点的日志信息。

需要说明的是，在一些可行的实施方式中，在启动信息收集容器中的代理应用之后，可以通过该代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息(即logconfig配置)，然后根据该logconfig配置生成用于执行日志收集功能的运行配置文件(即filebeat.yml文件)，接着控制代理应用执行该filebeat.yml文件，运行Filebeat的日志信息搜集功能。

本步骤中，由于代理应用从Kubernetes集群的主节点中获取到的日志配置信息为集群级别的配置信息，所以后续步骤中根据该日志配置信息而生成的用于执行日志收集功能的运行配置文件，是与整个Kubernetes集群有关联关系的，因此在执行该运行配置文件之后，每个工作节点中的代理应用在执行Filebeat的日志信息搜集功能时，能够基于集群级别的角度搜集日志信息，从而与整个Kubernetes集群相适配。此外，由于运行配置文件是在启动代理应用之后，由代理应用自动从Kubernetes集群的主节点中获取集群级别的日志配置信息并根据该日志配置信息而生成的，即是说，用于执行日志收集功能的运行配置文件是自动生成的，不需要用户手动编写，从而能够提高了处理效率；而且，由于运行配置文件是根据集群级别的日志配置信息而自动生成的，因此能够与Kubernetes集群相适配，节省了由于手动编写配置文件而需要适配执行的编译调试处理，进而能够进一步提高处理效率，增加了容器的使用价值。

S130：通过代理应用动态监听工作节点中的目标容器的运行事件。

需要说明的是，由于在步骤S120中控制代理应用执行了运行配置文件，因此代理应用能够执行日志收集功能(例如执行Filebeat的日志搜集功能)，但是，这只是实现了相关技术中例如Filebeat的常规的日志收集功能，仍然存在无法获知容器日志文件和容器之间的关系，为了解决这个问题，本步骤中，先通过代理应用动态监听工作节点中的目标容器的运行事件，以便于后续步骤可以根据目标容器的运行事件而生成包括容器日志文件与容器之间的关联关系的日志收集配置文件，从而解决相关技术中Filebeat无法获知容器日志和容器之间的关系的问题。

需要说明的是，目标容器的运行事件，例如可以包括启动事件、停运事件或重启事件等，可以根据实际应用情况而进行适当的选择，此处不作具体限定。

S140：当监听到运行事件，生成与目标容器对应的日志收集配置文件，其中，日志收集配置文件包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系。

本步骤中，由于在步骤S130中通过代理应用动态监听了工作节点中的目标容器的运行事件，因此，当监听到运行事件，可以生成与目标容器对应的日志收集配置文件，其中，该日志收集配置文件包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系，所以，当后续步骤根据该日志收集配置文件获取目标容器所生成的日志信息时，能够获得日志信息与容器名称、目标容器之间的关联关系，从而解决了相关技术中Filebeat无法获知容器日志和容器之间的关系的问题，达到更高效准确的保存Kubernetes集群中容器的日志收集的目的。

S150：通过代理应用对工作节点的目标文件目录进行扫描，将目标文件目录中的由目标容器生成的目标日志信息加载进内存。

需要说明的是，当工作节点中的目标容器启动之后，随着目标容器的运行，工作节点会将目标容器在运行过程中产生的日志信息保存到对应的文件目录(例如/var/log/container/目录)中。基于此，本步骤中，由于信息收集容器的启动时间早于目标容器的启动时间，并且在步骤S120中控制代理应用执行了运行配置文件以运行日志收集功能，因此可以通过代理应用对工作节点的目标文件目录进行扫描，将目标文件目录中的由目标容器生成的目标日志信息加载进内存，以便于后续步骤能够从内存中获取与容器名称和目标容器相关联的目标日志信息，为后续用户针对特定容器的日志查询提供准确的数据基础。

S160：根据日志收集配置文件从内存中搜集目标日志信息，将目标日志信息发送至日志服务集群。

本步骤中，由于在步骤S140中生成了包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系的日志收集配置文件，并且在步骤S150中将目标文件目录中的由目标容器生成的目标日志信息加载进了内存，因此可以根据该日志收集配置文件从内存中搜集目标日志信息，并将目标日志信息发送至日志服务集群，使得日志服务集群对目标日志信息进行保存，以便于用户能够通过日志服务集群针对特定容器进行准确的日志查询。

在一些可行的实施方式中，日志服务集群可以为Elasticsearch集群，可以根据实际应用情况而进行适当的选择，此处不作具体限定。

本实施例中，通过包括前面步骤S110至步骤S160的基于Kubernetes集群的日志收集方法，通过独立构建的信息收集容器中的代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息以生成并执行运行配置文件，然后动态监听工作节点中的目标容器的运行事件以生成与目标容器对应的日志收集配置文件，其中，日志收集配置文件包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系，接着根据日志收集配置文件从内存中搜集目标日志信息，并将目标日志信息发送至日志服务集群。通过上述方法得到的发给日志服务集群的目标日志信息，是与容器名称以及目标容器相关联的，克服了相关技术中Filebeat无法获知容器日志和容器之间的关系的问题，提高了Kubernetes集群中容器日志的收集准确性。

参照图3所示，本申请的一个实施例，对该日志收集方法进行进一步的说明，在执行步骤S110之后，该日志收集方法还可以包括但不限于步骤S111和步骤S112。

步骤S111：设置信息收集容器的内存容量小于或等于预设容量，以及设置信息收集容器的中央处理器的核数小于或等于预设数量。

本步骤中，由于在步骤S110中构建了独立的信息收集容器，因此可以针对该信息收集容器进行独立的CPU资源和内存资源的设置，所以，可以设置该信息收集容器的内存容量小于或等于预设容量，并且设置该信息收集容器的中央处理器的核数小于或等于预设数量，使得该信息收集容器不会过多的占用工作节点中的CPU资源和内存资源，从而降低对Kubernetes集群的安全使用的影响。

需要说明的是，预设容量可以根据实际应用情况而进行适当的选择，此处不作具体限定，例如，预设容量可以设置为200M。

需要说明的是，预设数量可以根据实际应用情况而进行适当的选择，此处不作具体限定，例如，预设数量可以设置为1个。

步骤S112：将工作节点的根路径映射到信息收集容器内部的目标路径。

可以理解的是，通过将工作节点的根路径映射到信息收集容器内部的目标路径，能够使得在信息收集容器启动的时候，可以对工作节点中与根路径对应的文件目录进行操作，以便于后续步骤可以对该文件目录中的日志信息进行扫描及收集。

在一可行的实施方式中，可以将工作节点的根路径映射到信息收集容器内部的目标路径/host，使得在信息收集容器启动的时候，可以对工作节点中的文件目录/var/log/进行操作，以获取保存在该文件目录/var/log/中的日志信息。

参照图4所示，本申请的一个实施例，对步骤S120中的“通过代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息”进行进一步的说明，步骤S120中的“通过代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息”，可以包括但不限于步骤S121和步骤S122。

步骤S121：通过代理应用采用超文本传输协议访问Kubernetes集群的主节点上的接口服务器以请求集群级别的日志配置信息。

本步骤中，在启动信息收集容器中的代理应用之后，可以通过代理应用采用超文本传输协议访问Kubernetes集群的主节点上的接口服务器(Kube-apiserver)，从而请求集群级别的日志配置信息，以便于后续步骤中可以根据该日志配置信息生成用于执行日志收集功能的运行配置文件以及控制代理应用执行该运行配置文件，实现搜集工作节点的日志信息的目的。

需要说明的是，Kube-apiserver相当于是Kubernetes集群的一个入口，不论是通过kubectl还是使用remote api对Kubernetes集群进行控制，都要经过Kube-apiserver对指定的端口进行监听以及控制。Kube-apiserver是Kubernetes系统中所有对象的增删查改盯的http/restful式服务端，其中，“盯”是指watch操作(例如监听操作)。需要说明的是，Kube-apiserver本身是无状态的，其提供了数据访问的认证鉴权、缓存、api版本适配转换等一系列的功能。

步骤S122：通过代理应用接收接口服务器发送的集群级别的日志配置信息。

本步骤中，由于在步骤S121中访问了Kubernetes集群的主节点上的接口服务器(Kube-apiserver)以请求集群级别的日志配置信息，因此可以通过代理应用接收Kube-apiserver发送的集群级别的日志配置信息，以便于可以根据该日志配置信息生成用于执行日志收集功能的运行配置文件以及控制代理应用执行该运行配置文件，从而实现搜集工作节点的日志信息的目的。

另外，本申请的一个实施例，对步骤S130进行进一步的说明，步骤S130可以包括但不限于以下步骤：

通过代理应用动态监听工作节点中Docker守护进程(Docker daemon)中的目标容器的运行事件。

需要说明的是，本步骤中，目标容器的运行事件包括启动事件、停运事件或重启事件中的任意一种，此处不作具体限定。

需要说明的是，Docker daemon是Docker的守护进程，可以通过在Docker Client中进行命令行的输入，实现Docker Client与Docker Damon的通信，从而完成对Docker的相关操作。由于Docker是用于创建容器的工具，因此通过Docker daemon可以对多个容器进行管理，也就是说，通过Docker daemon能够实现对目标容器的例如启动事件、停运事件或重启事件等的管理，因此，通过代理应用动态监听工作节点中Docker daemon中的目标容器的运行事件，可以捕捉目标容器的各种运行情况，以便于后续步骤可以根据目标容器的具体运行情况生成对应的日志收集配置文件，进而可以使得后续步骤根据该日志收集配置文件获取目标容器所生成的日志信息时，能够获得日志信息与容器名称、目标容器之间的关联关系，从而解决了相关技术中Filebeat无法获知容器日志和容器之间的关系的问题，达到更高效准确的保存Kubernetes集群中容器的日志收集的目的。

另外，本申请的一个实施例，对该日志收集方法进行进一步的说明，在执行步骤S140之后，该日志收集方法还可以包括但不限于以下步骤：

当监听到目标容器的更新事件时，根据更新事件对与目标容器对应的日志收集配置文件进行更新处理。

需要说明的是，由于Docker daemon可以对多个容器进行管理，因此Dockerdaemon能够实现目标容器在工作节点中的自动化部署，当监听到目标容器的更新事件时，说明目标容器发生了更新改变，由于日志收集配置文件是与目标容器相对应的，因此在目标容器发生了更新改变时，需要同步对日志收集配置文件进行更新处理，具体地，可以根据更新事件对与目标容器对应的日志收集配置文件进行更新处理。

另外，本申请的一个实施例，对该日志收集方法进行进一步的说明，在执行步骤S140之后，该日志收集方法还可以包括但不限于以下步骤：

当监听到目标容器的删除事件时，根据删除事件对与目标容器对应的日志收集配置文件进行删除处理。

需要说明的是，本实施例是与上述监听到目标容器的更新事件而对日志收集配置文件进行更新处理的实施例相并列的实施例。

需要说明的是，由于Docker daemon可以对多个容器进行管理，因此Dockerdaemon能够实现目标容器在工作节点中的自动化部署，当监听到目标容器的删除事件时，说明目标容器从工作节点中删除了，由于日志收集配置文件是与目标容器相对应的，因此在目标容器从工作节点中删除时，需要同步对日志收集配置文件进行删除处理，具体地，可以根据删除事件对与目标容器对应的日志收集配置文件进行删除处理。

参照图5所示，本申请的一个实施例，对步骤S150进行进一步的说明，步骤S150可以包括但不限于步骤S151和步骤S152。

步骤S151：通过代理应用每间隔预设时间对工作节点的目标文件目录进行扫描。

需要说明的是，当通过代理应用对工作节点的目标文件目录进行扫描时，具体可以是通过代理应用每间隔预设时间对工作节点的目标文件目录进行扫描，以便于后续步骤可以每间隔预设时间将目标文件目录中的由目标容器生成的目标日志信息增量加载进内存，从而能够降低把目标日志信息加载进内存的处理压力，提高系统的鲁棒性。

需要说明的是，预设时间可以根据实际应用情况而进行适当的选择，此处并不作具体限定。例如，在一可行的实施方式中，可以通过代理应用每间隔5秒对工作节点的目标文件目录进行扫描。

步骤S152：当在目标文件目录中扫描到由目标容器生成的目标日志信息，将目标文件目录中的目标日志信息动态加载进内存。

本步骤中，由于在步骤S151中每间隔预设时间对工作节点的目标文件目录进行扫描，因此当在目标文件目录中扫描到由目标容器生成的目标日志信息时，可以将目标文件目录中的目标日志信息动态加载进内存，以便于后续步骤能够从内存中获取与容器名称和目标容器相关联的目标日志信息，为后续用户针对特定容器的日志查询提供准确的数据基础。

本步骤中，由于是将目标文件目录中的目标日志信息动态加载进内存，因此能够将目标日志信息增量加载进内存，从而能够降低把目标日志信息加载进内存的处理压力，提高系统的鲁棒性。

参照图6所示，本申请的一个实施例，对步骤S160进行进一步的说明，步骤S160可以包括但不限于步骤S161至步骤S163。

步骤S161：根据日志收集配置文件从内存中搜集目标日志信息。

本步骤中，由于在步骤S140中生成了包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系的日志收集配置文件，并且在步骤S150中将目标文件目录中的由目标容器生成的目标日志信息加载进了内存，因此可以根据该日志收集配置文件从内存中搜集目标日志信息，以便于后续步骤可以将目标日志信息发送至日志服务集群进行保存。

需要说明的是，由于日志收集配置文件包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系，因此在根据日志收集配置文件从内存中搜集目标日志信息时，能够同时获得目标日志信息与容器名称、目标容器之间的关联关系，以便于后续步骤可以根据该关联关系对目标日志信息进行结构优化处理，从而达到便于保存以及检索目标日志信息的目的。

步骤S162：根据目标容器、目标容器对应的命名空间、目标容器对应的容器名称和目标容器对应的Kubernetes集群，对目标日志信息进行结构化处理。

本步骤中，由于在步骤S161中根据日志收集配置文件从内存中搜集了目标日志信息，因此可以根据目标容器、目标容器对应的命名空间、目标容器对应的容器名称和目标容器对应的Kubernetes集群，对目标日志信息进行结构化处理，以便于后续步骤能够将进行结构化处理之后目标日志信息发送至日志服务集群进行保存。

需要说明的是，对目标日志信息进行结构化处理，具体是指将目标日志信息与目标容器、目标容器对应的命名空间、目标容器对应的容器名称和目标容器对应的Kubernetes集群进行结构化关联，例如，对于经过结构化处理的目标日志信息，可以通过Kubernetes集群、容器名称、命名空间和目标容器的层级关系逐步查找到对应的目标日志信息。

步骤S163：将经过结构化处理的目标日志信息发送至日志服务集群。

本步骤中，由于在步骤S162中根据目标容器、目标容器对应的命名空间、目标容器对应的容器名称和目标容器对应的Kubernetes集群对目标日志信息进行了结构化处理，因此可以将经过结构化处理的目标日志信息发送至日志服务集群以进行保存，以便于用户能够通过日志服务集群针对特定容器进行准确的日志查询。

需要说明的是，由于保存到日志服务集群中的目标日志信息是经过结构化处理的，因此能够实现对目标日志信息的更高效准确的保存。

需要说明的是，在一可行的实施方式中，当将经过结构化处理的目标日志信息发送至日志服务集群之后，日志服务集群中的检索服务单元可以向用户提供操作界面，用户可以通过日志服务集群所提供的操作界面，设置搜索目标日志信息的条件，例如设置目标容器、命名空间、容器名称、Kubernetes等条件，从日志服务集群中的大量容器日志信息中快速查找到所需要的很细粒度的日志信息，从而能够大大降低容器日志信息的查看和寻找的难度，降低了用户的查看成本，提升了用户的使用体验，节约了用户的查找时间，提高了效率，进而增加了容器的使用价值。

参照图7所示，本申请实施例还公开了一种基于Kubernetes集群的日志收集装置，该日志收集装置200可以设置于Kubernetes集群中的工作节点，或者该日志收集装置200可以为Kubernetes集群中的工作节点，能够实现如前面实施例的基于Kubernetes集群的日志收集方法，该日志收集装置200包括：

容器构建模块210，用于构建独立的信息收集容器，其中，信息收集容器包括用于收集日志信息的代理应用；

容器运行模块220，用于启动信息收集容器中的代理应用，通过代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，根据日志配置信息生成用于执行日志收集功能的运行配置文件，并控制代理应用执行运行配置文件；

事件监听模块230，用于通过代理应用动态监听工作节点中的目标容器的运行事件；

文件生成模块240，用于当监听到运行事件，生成与目标容器对应的日志收集配置文件，其中，日志收集配置文件包括容器名称、目标容器和目标容器所生成的日志信息之间的关联关系；

信息加载模块250，用于通过代理应用对工作节点的目标文件目录进行扫描，将目标文件目录中的由目标容器生成的目标日志信息加载进内存；

信息发送模块260，用于根据日志收集配置文件从内存中搜集目标日志信息，将目标日志信息发送至日志服务集群。

在一实施例中，该日志收集装置200还包括：

资源设置模块，用于设置信息收集容器的内存容量小于或等于预设容量，以及设置信息收集容器的中央处理器的核数小于或等于预设数量；

路径映射模块，用于将工作节点的根路径映射到信息收集容器内部的目标路径。

在一实施例中，容器运行模块220包括：

信息请求模块，用于通过代理应用采用超文本传输协议访问Kubernetes集群的主节点上的接口服务器以请求集群级别的日志配置信息；

信息接收模块，用于通过代理应用接收接口服务器发送的集群级别的日志配置信息。

在一实施例中，事件监听模块230包括：

信息监听模块，用于通过代理应用动态监听工作节点中Docker守护进程中的目标容器的运行事件；其中，运行事件包括启动事件、停运事件或重启事件中的任意一种。

在一实施例中，该日志收集装置200还包括：

信息更新模块，用于当监听到目标容器的更新事件时，根据更新事件对与目标容器对应的日志收集配置文件进行更新处理；

或者，

信息删除模块，用于当监听到目标容器的删除事件时，根据删除事件对与目标容器对应的日志收集配置文件进行删除处理。

在一实施例中，信息加载模块250包括：

信息扫描模块，用于通过代理应用每间隔预设时间对工作节点的目标文件目录进行扫描；

信息加载子模块，用于当在目标文件目录中扫描到由目标容器生成的目标日志信息，将目标文件目录中的目标日志信息动态加载进内存。

在一实施例中，信息发送模块260包括：

信息搜集模块，用于根据日志收集配置文件从内存中搜集目标日志信息；

结构化处理模块，用于根据目标容器、目标容器对应的命名空间、目标容器对应的容器名称和目标容器对应的Kubernetes集群，对目标日志信息进行结构化处理；

信息发送子模块，用于将经过结构化处理的目标日志信息发送至日志服务集群。

参照图8所示，图8示出了本申请一个实施例提供的电子设备的硬件结构示意图，该电子设备包括：

处理器310，可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集合成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集合成电路等方式实现，用于执行相关程序，以实现本申请实施例所提供的技术方案；

存储器320，可以采用只读存储器(Read Only Memory，ROM)、静态存储设备、动态存储设备或者随机存取存储器(Random Access Memory，RAM)等形式实现。存储器320可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器320中，并由处理器310来调用执行本申请实施例的日志收集方法；

输入/输出接口330，用于实现信息输入及输出；

通信接口340，用于实现本设备与其他设备的通信交互，可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信；和

总线350，在设备的每个组件(例如处理器310、存储器320、输入/输出接口330和通信接口340)之间传输信息；

其中，处理器310、存储器320、输入/输出接口330和通信接口340通过总线350实现彼此之间在设备内部的通信连接。

本申请实施例还提供了一种存储介质，存储介质为计算机可读存储介质，用于计算机可读存储，存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现上述日志收集方法。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例描述的实施例是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

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

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

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

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

另外，在本申请每个实施例中的各功能单元可以集合成在一个处理单元中，也可以是每个单元单独物理存在，也可以两个或两个以上单元集合成在一个单元中。上述集合成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上参照附图说明了本申请实施例的优选实施例，并非因此局限本申请实施例的权利范围。本领域技术人员不脱离本申请实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本申请实施例的权利范围之内。

Claims (10)

1.一种基于Kubernetes集群的日志收集方法，其特征在于，应用于所述Kubernetes集群中的工作节点，所述日志收集方法包括：

构建独立的信息收集容器，其中，所述信息收集容器包括用于收集日志信息的代理应用；

启动所述信息收集容器中的所述代理应用，通过所述代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，根据所述日志配置信息生成用于执行日志收集功能的运行配置文件，并控制所述代理应用执行所述运行配置文件；

通过所述代理应用动态监听所述工作节点中的目标容器的运行事件；

当监听到所述运行事件，生成与所述目标容器对应的日志收集配置文件，其中，所述日志收集配置文件包括容器名称、所述目标容器和所述目标容器所生成的日志信息之间的关联关系；

通过所述代理应用对所述工作节点的目标文件目录进行扫描，将所述目标文件目录中的由所述目标容器生成的目标日志信息加载进内存；

根据所述日志收集配置文件从所述内存中搜集所述目标日志信息，将所述目标日志信息发送至日志服务集群。

2.根据权利要求1所述的日志收集方法，其特征在于，所述构建独立的信息收集容器之后，所述日志收集方法还包括：

设置所述信息收集容器的内存容量小于或等于预设容量，以及设置所述信息收集容器的中央处理器的核数小于或等于预设数量；

将所述工作节点的根路径映射到所述信息收集容器内部的目标路径。

3.根据权利要求1所述的日志收集方法，其特征在于，所述通过所述代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，包括：

通过所述代理应用采用超文本传输协议访问所述Kubernetes集群的主节点上的接口服务器以请求集群级别的日志配置信息；

通过所述代理应用接收所述接口服务器发送的所述集群级别的日志配置信息。

4.根据权利要求1所述的日志收集方法，其特征在于，所述通过所述代理应用动态监听所述工作节点中的目标容器的运行事件，包括：

通过所述代理应用动态监听所述工作节点中Docker守护进程中的目标容器的运行事件；

其中，所述运行事件包括启动事件、停运事件或重启事件中的任意一种。

5.根据权利要求1所述的日志收集方法，其特征在于，所述生成与所述目标容器对应的日志收集配置文件之后，所述日志收集方法还包括：

当监听到所述目标容器的更新事件时，根据所述更新事件对与所述目标容器对应的日志收集配置文件进行更新处理；

或者，

当监听到所述目标容器的删除事件时，根据所述删除事件对与所述目标容器对应的日志收集配置文件进行删除处理。

6.根据权利要求1所述的日志收集方法，其特征在于，所述通过所述代理应用对所述工作节点的目标文件目录进行扫描，将所述目标文件目录中的由所述目标容器生成的目标日志信息加载进内存，包括：

通过所述代理应用每间隔预设时间对所述工作节点的目标文件目录进行扫描；

当在所述目标文件目录中扫描到由所述目标容器生成的目标日志信息，将所述目标文件目录中的所述目标日志信息动态加载进内存。

7.根据权利要求1所述的日志收集方法，其特征在于，所述根据所述日志收集配置文件从所述内存中搜集所述目标日志信息，将所述目标日志信息发送至日志服务集群，包括：

根据所述日志收集配置文件从所述内存中搜集所述目标日志信息；

根据所述目标容器、所述目标容器对应的命名空间、所述目标容器对应的容器名称和所述目标容器对应的Kubernetes集群，对所述目标日志信息进行结构化处理；

将经过结构化处理的所述目标日志信息发送至日志服务集群。

8.一种基于Kubernetes集群的日志收集装置，其特征在于，包括：

容器构建模块，用于构建独立的信息收集容器，其中，所述信息收集容器包括用于收集日志信息的代理应用；

容器运行模块，用于启动所述信息收集容器中的所述代理应用，通过所述代理应用从Kubernetes集群的主节点中获取集群级别的日志配置信息，根据所述日志配置信息生成用于执行日志收集功能的运行配置文件，并控制所述代理应用执行所述运行配置文件；

事件监听模块，用于通过所述代理应用动态监听工作节点中的目标容器的运行事件；

文件生成模块，用于当监听到所述运行事件，生成与所述目标容器对应的日志收集配置文件，其中，所述日志收集配置文件包括容器名称、所述目标容器和所述目标容器所生成的日志信息之间的关联关系；

信息加载模块，用于通过所述代理应用对所述工作节点的目标文件目录进行扫描，将所述目标文件目录中的由所述目标容器生成的目标日志信息加载进内存；

信息发送模块，用于根据所述日志收集配置文件从所述内存中搜集所述目标日志信息，将所述目标日志信息发送至日志服务集群。

9.一种电子设备，其特征在于，所述电子设备包括存储器、处理器、存储在所述存储器上并可在所述处理器上运行的程序，所述程序被所述处理器执行时实现如权利要求1至7任一项所述的基于Kubernetes集群的日志收集方法的步骤。

10.一种存储介质，所述存储介质为计算机可读存储介质，用于计算机可读存储，其特征在于，所述存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现权利要求1至7中任一项所述的基于Kubernetes集群的日志收集方法的步骤。

Images