CN114546668B - 日志采集方法、装置、电子设备和计算机可读存储介质 - Google Patents

Abstract

本发明实施例提出一种日志采集方法、装置、电子设备和计算机可读存储介质，涉及计算机技术领域。该方法通过预先配置解析容器和采集容器，解析容器获取目标应用容器对应的日志采集配置信息，根据日志采集配置信息在第一容器组的第一指定目录下创建软链接，由于软链接指向目标应用容器的日志文件且解析容器和采集容器在一个容器组内可以共享目录，故采集容器通过读取第一指定目录下的软链接可以得到目标应用容器的日志文件。该方法通过配置的方式采集应用容器的日志文件，无需重启应用，也无需向应用Pod中注入边车容器，将应用日志的生命周期与应用的生命周期解耦，应用本身也无需增加额外资源消耗，最终实现应用日志数据的持久化存储和查询。

Description

日志采集方法、装置、电子设备和计算机可读存储介质

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种日志采集方法、装置、电子设备和计算机可读存储介质。

背景技术

Kubernetes，简称K8s，是Google开源的一个生产级别的容器编排系统。在容器中，容器日志有两大类，一类是标准输出日志，一类是文本日志，其中，文本日志指的是存在于容器内部并且没有被重定向到标准输出的日志，这类日志无法通过Kubernates或docker提供的命令或者API（Application Programming Interface，应用程序接口）获取，标准输出日志指的是需要向外界输出的日志。

传统应用在容器化转型的过程中，仍然习惯于将应用日志写入指定路径的日志文件中，这类日志文件不能按照标准输出日志的采集方式进行采集。现有技术中，如果需要采集应用容器内指定路径的日志文件，通常是采用边车容器的方式，通过向应用所在容器组（Pod）中加入边车容器，边车容器共享应用容器目录的方式读取应用容器的日志文件，这种方式的缺点在于不够通用，不同应用容器可能需要挂载不同的边车容器，且边车容器本身需要消耗一定资源，当集群规模较大时，会消耗大量资源。

发明内容

有鉴于此，本发明的目的在于提供一种日志采集方法、装置、电子设备和计算机可读存储介质，以解决现有技术中通过额外注入边车容器对应用容器进行日志采集存在的消耗大量资源的问题。

为了实现上述目的，本发明实施例采用的技术方案如下：

第一方面，本发明提供一种日志采集方法，应用于Kubernetes集群中的每个物理节点，所述物理节点上运行有第一容器组和至少一个第二容器组，所述第一容器组中运行有预先配置的解析容器和采集容器，所述第二容器组中运行有至少一个应用容器；所述解析容器和所述采集容器共享所述第一容器组的所有目录；所述方法包括：

通过所述解析容器获取目标应用容器对应的日志采集配置信息，根据所述日志采集配置信息在所述第一容器组的第一指定目录下创建软链接；所述软链接指向所述目标应用容器的日志文件；

通过所述采集容器读取所述第一容器组的第一指定目录下的软链接，得到所述目标应用容器的日志文件。

在可选的实施方式中，所述日志采集配置信息包括所述目标应用容器的名称、应用标签和所述目标应用容器的日志文件在所述目标应用容器内的路径；

所述根据所述日志采集配置信息在所述第一容器组的第一指定目录下创建软链接，包括：

根据所述应用标签获取所述目标应用容器所在目标容器组的名称、命名空间和所述目标应用容器的标识；

根据所述目标应用容器的日志文件在所述目标应用容器内的路径，确定所述目标应用容器的日志文件在所述第一容器组内的路径，并获取所述目标应用容器的日志文件的标识；

根据所述目标容器组的名称、命名空间、所述目标应用容器的名称、所述目标应用容器的标识和所述目标应用容器的日志文件的标识在所述第一指定目录下创建软链接，并将所述软链接与所述目标应用容器的日志文件在所述第一容器组内的路径进行关联。

在可选的实施方式中，所述物理节点的根目录挂载到所述第一容器组的第二指定目录下；

所述根据所述目标应用容器的日志文件在所述目标应用容器内的路径，确定所述目标应用容器的日志文件在所述第一容器组内的路径，包括：

根据所述目标应用容器的日志文件在所述目标应用容器内的路径，确定所述目标应用容器的日志文件在所述物理节点上的路径；

根据所述目标应用容器的日志文件在所述物理节点上的路径和所述第一容器组的第二指定目录，得到所述目标应用容器的日志文件在所述第一容器组内的路径。

在可选的实施方式中，所述方法还包括：

获取所述目标应用容器对应的元数据信息；

将所述元数据信息和采集的所述日志文件汇总后进行存储。

在可选的实施方式中，所述获取所述目标应用容器对应的元数据信息，包括：

通过所述采集容器读取所述第一指定目录下的软链接的名称，从所述软链接的名称中提取出所述目标应用容器对应的名称、标识、命名空间以及所述目标应用容器所在目标容器组的名称，并根据所述目标应用容器对应的名称、标识、命名空间以及所述目标容器组的名称获取所述目标应用容器对应的所有元数据信息。

在可选的实施方式中，每个所述第二容器组对应一个命名空间，所述解析容器用于监听所有命名空间下的应用容器对应的日志采集资源对象的创建、更新和删除事件；

所述通过所述解析容器获取目标应用容器对应的日志采集配置信息，包括：

在所述解析容器监听到目标应用容器对应的日志采集资源对象的创建事件后，通过所述解析容器从所述创建事件中解析出所述目标应用容器对应的日志采集配置信息。

第二方面，本发明提供一种日志采集装置，应用于Kubernetes集群中的每个物理节点，所述物理节点上运行有第一容器组和至少一个第二容器组，所述第一容器组中运行有预先配置的解析容器和采集容器，所述第二容器组中运行有至少一个应用容器；所述解析容器和所述采集容器共享所述第一容器组的所有目录；所述装置包括：

解析模块，用于通过所述解析容器获取目标应用容器对应的日志采集配置信息，根据所述日志采集配置信息在所述第一容器组的第一指定目录下创建软链接；所述软链接指向所述目标应用容器的日志文件；

采集模块，用于通过所述采集容器读取所述第一容器组的第一指定目录下的软链接，得到所述目标应用容器的日志文件。

在可选的实施方式中，所述日志采集配置信息包括所述目标应用容器的名称、应用标签和所述目标应用容器的日志文件在所述目标应用容器内的路径；

所述解析模块用于根据所述应用标签获取所述目标应用容器所在目标容器组的名称、命名空间和所述目标应用容器的标识；根据所述目标应用容器的日志文件在所述目标应用容器内的路径，确定所述目标应用容器的日志文件在所述第一容器组内的路径，并获取所述目标应用容器的日志文件的标识；根据所述目标容器组的名称、命名空间、所述目标应用容器的名称、所述目标应用容器的标识和所述目标应用容器的日志文件的标识在所述第一指定目录下创建软链接，并将所述软链接与所述目标应用容器的日志文件在所述第一容器组内的路径进行关联。

第三方面，本发明提供一种电子设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如前述实施方式中任一项所述的日志采集方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如前述实施方式中任一项所述的日志采集方法的步骤。

本发明实施例提供的日志采集方法、装置、电子设备和计算机可读存储介质，Kubernetes集群中的物理节点上运行有第一容器组和至少一个第二容器组，第一容器组中运行有预先配置的解析容器和采集容器，第二容器组中运行有至少一个应用容器，解析容器和采集容器共享第一容器组的所有目录；通过解析容器获取目标应用容器对应的日志采集配置信息，根据日志采集配置信息在第一容器组的第一指定目录下创建软链接；由于该软链接指向目标应用容器的日志文件且解析容器和采集容器在一个容器组内可以共享目录，故通过采集容器读取该第一指定目录下的软链接，即可获得目标应用容器的日志文件。如此，在不要求传统应用在容器化转型的过程中改变其通过写日志文件记录日志的方式情况下，通过配置的方式即可采集应用容器的日志文件，无需重启应用，也无需向应用Pod中注入边车容器，将应用日志的生命周期与应用的生命周期解耦，应用本身也无需增加额外资源消耗，最终实现应用日志数据的持久化存储和查询。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了现有日志采集方式中使用K8s原生的日志记录方式的一种示意图；

图2示出了现有日志采集方式中使用节点级日志代理的一种示意图；

图3示出了现有日志采集方式中使用边车容器的一种示意图；

图4示出了现有日志采集方式中使用边车容器的另一种示意图；

图5示出了现有日志采集方式中在应用中直接推送日志的一种示意图；

图6示出了适用于本发明实施例提供的日志采集方法的日志采集系统的一种示意图；

图7示出了本发明实施例提供的日志采集方法的一种流程示意图；

图8示出了用户添加LogCollector资源对象的一种示意图；

图9示出了本发明实施例提供的日志采集方法的另一种流程示意图；

图10示出了本发明实施例提供的日志采集装置的一种功能模块图；

图11示出了本发明实施例提供的电子设备的一种方框示意图。

图标：10-日志采集系统；100-物理节点；110-第二容器组；120-第一容器组；121-解析容器；122-采集容器；112-应用容器；600-日志采集装置；610-解析模块；620-采集模块；700-电子设备；710-存储器；720-处理器；730-通信模块。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

传统应用在容器化转型的过程中，仍然习惯于将应用日志写入指定路径的日志文件中，这种方式使得日志的可用性与应用的运行状态形成耦合。例如，在K8s中，如果发生应用容器崩溃、应用Pod被逐出或应用运行的K8s节点宕机等情况，可能无法进入应用查看日志。因此，应用日志应该具有独立的存储和生命周期，与K8s节点、Pod 或容器的生命周期相独立，需要一个独立的系统来实现日志的采集、清洗、存储、查询和分析。对此，K8s没有为容器日志数据提供原生的解决方案。下面介绍几种常见的采集和存储集群容器日志的方式。

第一种，K8s原生的日志记录方式，如图1所示，K8s原生的日志记录方式是将容器应用日志数据写入stdout（标准输出文件）和stderr（标准错误输出文件），这些数据会被容器引擎捕获并重定向到某个位置。例如，Docker容器引擎会将这两个输出流重定向到某个日志驱动（LoggingDriver），该日志驱动在Kubernetes中配置为以JSON格式写入文件。默认情况下，如果容器重启，kubelet（K8s部署在宿主机上的一个组件）会保留被终止的容器日志。 如果 Pod 在工作节点被驱逐，该 Pod 中所有的容器也会被驱逐，包括容器日志。

第二种，使用节点级日志代理，如图2所示，这种方式通常使用DaemonSet（服务守护进程）的形式在每个节点上运行日志代理，它可以监控该节点上所有应用容器的日志文件（stdout和stderr）的目录，并将日志数据统一采集存储至后端存储。

第三种，使用边车容器，可以采用以下两种方式：1、如图3所示，边车容器将应用程序日志发送到自己的标准输出，这种方式是通过在应用Pod中加入边车容器，这个边车容器可以从应用容器的文件、socket或 journald读取日志数据，并将这些数据输出到自己的stdout和stderr中，再借助K8s原生的日志记录方式写入到容器引擎日志文件，使得日志代理可以采集日志数据并存储到后端存储；2、如图4所示，边车容器运行一个日志代理，配置该日志代理以便从应用容器采集日志，这种方式是通过在应用Pod中加入具有日志代理功能的边车容器，直接读取应用容器的日志数据转发至后端存储。

第四种，在应用中直接推送日志，如图5所示，这种方式是在应用容器内主动将日志推送至后端存储。

然而，实际生产环境的日志采集需求，是既要能采集标准输出和标准错误流的日志数据，又要能采集应用容器内指定路径的日志文件数据，在实现这两个功能需求的基础上，还不能影响应用本身的正常运行，还应尽可能地消耗更少的资源。

对比分析上述列举的几种日志的采集和存储方式，K8S原生方式（图1）和使用节点级别代理（图2）这两种方式只能实现应用标准输出和标准错误流日志数据的采集。如果需要采集应用容器内指定路径的日志文件，通常是采用边车容器的方式，通过向应用Pod中加入边车容器，边车容器共享应用容器目录的方式读取应用容器的日志文件，这种方式的缺点在于不够通用，不同应用容器可能需要挂载不同的边车容器，且边车容器本身需要消耗一定资源，当集群规模较大时，会消耗大量资源。

基于此，本发明实施例提出一种日志采集方法、装置、电子设备和计算机可读存储介质，其在不要求传统应用在容器化转型的过程中改变其通过写日志文件记录日志的方式情况下，通过配置的方式即可采集应用容器的日志文件，无需重启应用，也无需向应用Pod中注入边车容器，将应用日志的生命周期与应用的生命周期解耦，应用本身也无需增加额外资源消耗，最终实现应用日志数据的持久化存储和查询。下面，先对适用于本发明实施例的一种应用场景进行说明。

请参照图6，本发明实施例提供的日志采集方法可以应用于如图6所示的日志采集系统10，该日志采集系统10包括多个物理节点100，物理节点100上运行有第一容器组120和至少一个第二容器组110，第一容器组120中运行有预先配置的解析容器121和采集容器122，第二容器组110中运行有至少一个应用容器112。

在本实施例中，每个物理节点100上安装了Kubernetes平台，该多个物理节点100构成Kubernetes集群，即Kubernetes集群中可以包括多个物理节点100，该物理节点100可以是服务器、物理机或者虚拟机等设备。

容器组是Kubernetes集群的最小调度单位，在Kubernetes集群中，容器组是所有业务类型的基础，一个容器组中运行的容器可以共享存储和命名空间。其中，容器组中运行的容器可以是Docker容器，当然，也可以是其他类型的容器。

每个应用容器112在运行过程中会产生日志文件，在每个物理节点100上以DaemonSet的方式部署解析容器（Logx）和采集容器（Fluentbit），Logx和Fluentbit组成一个pod（即第一容器组120），Logx和Fluentbit共享第一容器组的所有目录，对该第一容器组的目录下的所有文件拥有可读权限。解析容器121用于监听和解析所有调度到当前物理节点100的应用的Pod和LogCollector（日志采集）资源，并在第一容器组的指定目录下按规则创建软链接指向应用容器112的日志文件，采集容器122用于采集上述指定目录，获得日志文件，并可将日志文件转发至Fluentd（数据收集器，可以部署在任一个物理节点100上，或者在每个物理节点100上都部署），Fluentd将各个物理节点100的日志数据汇总并路由存储到不同的终端（日志收集终端）。用户只需要通过yaml（写配置文件的语言）的方式在应用容器112所在的命名空间内创建LogCollector资源来提交需要采集日志的应用信息，即可实现日志的采集。

应理解的是，为呈现更好的图示效果，图6仅在一个物理节点100上展示了第一容器组120、第二容器组110、解析容器121和采集容器122的部署情况，实际应用中，每个物理节点100上均会设置解析容器121和采集容器122。

下面，基于图6所示的日志采集系统10，对本发明实施例提供的日志采集方法进行详细说明。请参照图7，为本发明实施例提供的日志采集方法的一种流程示意图。需要说明的是，本发明实施例的日志采集方法并不以图7以及以下的具体顺序为限制，应当理解，在其他实施例中，本发明实施例的日志采集方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。该日志采集方法可以应用在Kubernetes集群中的每个物理节点100中，下面将对图7所示的具体流程进行详细阐述。

步骤S701，通过解析容器获取目标应用容器对应的日志采集配置信息，根据日志采集配置信息在第一容器组的第一指定目录下创建软链接；软链接指向目标应用容器的日志文件。

在本实施例中，该日志采集配置信息由用户创建，其可以与应用容器112同时创建，也可以在应用容器创建之后创建，当需要收集应用容器112的日志文件时，只需要用户针对该应用容器设置相应的日志采集配置信息。每个物理节点100中的解析容器121在获取需要采集日志的目标应用容器对应的日志采集配置信息后，根据日志采集配置信息在第一容器组的第一指定目录下创建指向该目标应用容器的日志文件的软链接。

其中，软链接类似于Windows系统中给文件创建快捷方式，即产生一个特殊的文件，该文件用来指向另一个目标文件，通过该软链接可以快速链接到其指向的目标文件。

步骤S702，通过采集容器读取第一容器组的第一指定目录下的软链接，得到目标应用容器的日志文件。

在本实施例中，由于解析容器和采集容器在一个容器组内可以共享目录，故解析容器在第一容器组的第一指定目录下创建的软链接，可以被采集容器读取到，即在解析容器根据日志采集配置信息在第一容器组的第一指定目录下创建软链接后，采集容器可以访问该第一容器组的第一指定目录下的软链接，而该软链接指向目标应用容器的日志文件，故采集容器对该软链接执行读取操作时，会对该软链接指向的目标应用容器的日志文件进行读取操作，实现了通过访问该软链接就可以迅速定位到软链接所指向的目标应用容器的日志文件。

可见，本发明实施例提供的日志采集方法，Kubernetes集群中的物理节点上运行有第一容器组和至少一个第二容器组，第一容器组中运行有预先配置的解析容器和采集容器，第二容器组中运行有至少一个应用容器，解析容器和采集容器共享第一容器组的所有目录；通过解析容器获取目标应用容器对应的日志采集配置信息，根据日志采集配置信息在第一容器组的第一指定目录下创建软链接；由于该软链接指向目标应用容器的日志文件且解析容器和采集容器在一个容器组内可以共享目录，故采集容器可以访问该第一容器组的第一指定目录下的软链接，采集容器对该软链接执行读取操作时，会对该软链接指向的目标应用容器的日志文件进行读取操作，实现了通过采集容器访问该软链接就可以迅速定位到软链接所指向的目标应用容器的日志文件。如此，在不要求传统应用在容器化转型的过程中改变其通过写日志文件记录日志的方式情况下，通过配置的方式即可采集应用容器的日志文件，无需重启应用，也无需向应用Pod中注入边车容器，将应用日志的生命周期与应用的生命周期解耦，应用本身也无需增加额外资源消耗，最终实现应用日志数据的持久化存储和查询。

在本实施例中，每个第二容器组110对应一个命名空间，解析容器121用于监听所有命名空间下的应用容器对应的日志采集资源对象的创建、更新和删除事件。应用容器112在K8s集群中创建并成功运行后，当需要收集应用容器112的日志文件时，用户只需在该应用容器112所在相同的命名空间下创建、更新或者删除LogCollector资源对象，该资源对象可以包括需要采集日志的目标应用容器的名称、日志文件在该目标应用容器内的路径、应用标签等，LogCollector通过标签选择器与目标应用容器进行绑定。

基于此，上述步骤S701中通过解析容器获取目标应用容器对应的日志采集配置信息，具体可以包括：

在解析容器监听到目标应用容器对应的日志采集资源对象的创建事件后，通过解析容器从创建事件中解析出目标应用容器对应的日志采集配置信息。

也即是说，每个物理节点100上部署的解析容器121会实时监听所有命名空间下的LogCollector资源对象的创建、更新和删除事件，当监听到自身所在物理节点上的某个目标应用容器相关的LogCollector资源对象的创建事件后，从中解析出目标应用容器对应的日志采集配置信息，例如需要采集日志的目标应用容器的名称、日志文件在该目标应用容器内的路径、应用标签等信息。

在一种实施方式中，日志采集配置信息包括目标应用容器的名称、应用标签和目标应用容器的日志文件在目标应用容器内的路径，解析容器121根据日志采集配置信息在第一容器组的第一指定目录下创建软链接，具体可以包括：

根据应用标签获取目标应用容器所在目标容器组的名称、命名空间和目标应用容器的标识；根据目标应用容器的日志文件在目标应用容器内的路径，确定目标应用容器的日志文件在第一容器组内的路径，并获取目标应用容器的日志文件的标识；根据目标容器组的名称、命名空间、目标应用容器的名称、目标应用容器的标识和目标应用容器的日志文件的标识在第一指定目录下创建软链接，并将软链接与目标应用容器的日志文件在第一容器组内的路径进行关联。

在本实施例中，目标应用容器所在目标容器组可以理解为目标应用容器所在的第二容器组110。

其中，解析容器121通过目标应用容器的应用标签，可以向API Server（K8s核心组件）请求获取目标应用容器所在目标容器组的详细信息，例如可以包括目标容器组的名称pod_name、命名空间namespace等信息，并从目标容器组的详细信息中提取目标应用容器的标识（Container ID），再通过Docker的SDK（软件开发工具包）获取该Container ID的详细信息。

在本实施例中，目标应用容器的日志文件在第一容器组内的路径也即是该日志文件在解析容器121和采集容器122内的路径，由于解析容器121和采集容器122共享第一容器组120内的目录，对该第一容器组120内的目录下的所有文件拥有可读权限，故解析容器121通过在第一容器组120的第一指定目录下创建软链接，并将软链接与目标应用容器的日志文件在第一容器组内的路径进行关联，使得该软链接与该目标应用容器的日志文件形成映射关系，实现软链接指向目标应用容器的日志文件，这样，采集容器122通过访问第一指定目录下的软链接，可以自动按照软链接关联的路径进行查找，最终获得软链接指向的目标应用容器的日志文件。

在本实施例中，每个文件都对应有一个唯一的标识，例如Inode（Index node，索引节点）号，解析容器121根据日志文件在目标应用容器内的路径中的最后一个条目，可以确定日志文件的文件名称，然后利用文件名称查找其对应的标识，最终得到目标应用容器的日志文件的标识。

解析容器121在获得目标容器组的名称pod_name、命名空间namespace、目标应用容器的名称Container name、目标应用容器的标识Container ID和目标应用容器的日志文件的Inode号后，可以按照预设规则创建一个软链接。

例如，该预设规则可以为<pod_name>_<namespace>_<container_name>-<container_id>.log.<inode>。当然，在实际应用中，还可以根据需求引入日志文件的文件名称log_file_name，此时该预设规则可以是<pod_name>_<namespace>_<container_name>-<container_id>.log.<inode>_<log_file_name>。

可见，本发明实施例提供的日志采集方法，解析容器根据目标容器组的名称、命名空间、目标应用容器的名称、目标应用容器的标识和目标应用容器的日志文件的标识在第一指定目录下创建软链接，并将软链接与目标应用容器的日志文件在第一容器组内的路径进行关联，这样，采集容器通过访问软链接，便可自动按照软链接关联的路径进行查找，最终获得目标应用容器的日志文件。

可选地，物理节点100的根目录挂载到第一容器组120的第二指定目录下，解析容器121和采集容器122对第二指定目录下的所有文件拥有可读权限，其中，第一指定目录和第二指定目录是第一容器组中的不同目录。基于此，解析容器121根据目标应用容器的日志文件在目标应用容器内的路径，确定目标应用容器的日志文件在第一容器组内的路径，具体可以包括：

根据目标应用容器的日志文件在目标应用容器内的路径，确定目标应用容器的日志文件在物理节点上的路径；根据目标应用容器的日志文件在物理节点上的路径和第一容器组的第二指定目录，得到目标应用容器的日志文件在第一容器组内的路径。

在本实施例中，假设名称为busybox-loop的目标应用容器正常运行在K8s集群的某台物理节点100上，该目标应用容器的日志文件路径（即目标应用容器的日志文件在目标应用容器内的路径）为/var/my.log，解析容器121根据目标应用容器的日志文件在目标应用容器内的路径，可从Mounts和GraphDriver（镜像管理驱动）获取需要采集的日志文件在宿主机文件系统中的真实路径，从而得到目标应用容器的日志文件在物理节点上的路径。

例如，根据该目标应用容器的日志文件在目标应用容器内的路径/var/my.log，可以得到该日志文件在当前物理节点100上的真实路径为/var/lib/docker/overlay2/deec294618dca3255f3f2ca3fd888c5c6690a3187d2df1e4f4153aaf7b662e7f/diff/var/my.log。

解析容器121和采集容器122所在的第一容器组120在物理节点100上启动时，需要把物理节点100的系统根目录（例如，图6中的FileSystem）挂载到第一容器组120的第二指定目录（例如自定义的/host目录）下，那么上述目标应用容器的日志文件在logx和fluentbit内的路径就变成了/host/var/lib/docker/overlay2/deec294618dca3255f3f2ca3fd888c5c6690a3187d2df1e4f4153aaf7b662e7f/diff/var/my.log，该路径即为目标应用容器的日志文件在第一容器组内的路径。

下面，以一个具体的示例对软链接的创建过程进行说明。用户在目标应用容器启动后添加图8所示的LogCollector资源对象，解析容器121就可以通过selector和containers的条件解析出目标应用容器的K8s元数据。具体地，解析容器121通过目标应用容器的应用标签，向API Server请求获取目标应用容器所在目标容器组的详细信息，包括目标容器组的名称pod_name、命名空间namespace等信息，并从目标容器组的详细信息中提取目标应用容器的标识（Container ID），再通过Docker的SDK获取该Container ID的详细信息；根据目标应用容器的日志文件在目标应用容器内的路径，从Mounts和GraphDriver获取目标应用容器的日志文件在物理节点上的路径，然后根据目标应用容器的日志文件在物理节点上的路径和第一容器组的第二指定目录，得到目标应用容器的日志文件在第一容器组内的路径；根据日志文件在目标应用容器内的路径中的最后一个条目，确定日志文件的文件名称，然后利用文件名称查找其对应的标识，即目标应用容器的日志文件的标识（Inode号）。

解析容器121在解析出目标应用容器的K8s元数据后，按照<pod_name>_<namespace>_<container_name>-<container_id>.log.<inode>_<log_file_name>的规则在第一容器组的第一指定目录（例如/logx/inputs目录）下创建一个名称为log-generator-675cc56ff4-dkmzq_orca-pdr7z_busybox-loop-3fc8f2915321050cf275dad2a308cf3434d34ed800875423edf48813d5da744e.log.23201005_my.log的软链接，该软链接指向路径/host/var/lib/docker/overlay2/deec294618dca3255f3f2ca3fd888c5c6690a3187d2df1e4f4153aaf7b662e7f/diff/var/my.log下的日志文件。

可以理解，在解析容器121视角下，目标应用容器内的软链接log-generator-675cc56ff4-dkmzq_orca-pdr7z_busybox-loop-3fc8f2915321050cf275dad2a308cf3434d34ed800875423edf48813d5da744e.log.23201005_my.log与路径/host/var/lib/docker/overlay2/deec294618dca3255f3f2ca3fd888c5c6690a3187d2df1e4f4153aaf7b662e7f/diff/var/my.log下的日志文件形成了映射关系。

在实际应用中，考虑到应用在运行过程中可能发生节点漂移，也可能会动态生成新的日志文件，针对这两种情况，可以设置每个物理节点100的解析容器周期性遍历所有命名空间下的LogCollector资源，实现创建、更新或删除每个物理节点100上的软链接文件。

在本实施例中，为了使采集的日志数据更加丰富，在进行应用容器日志文件数据采集的同时，还可以提取应用容器相关的K8s元数据信息。基于此，请参照图9，该方法还包括：

步骤S901，获取目标应用容器对应的元数据信息。

步骤S902，将元数据信息和采集的日志文件汇总后进行存储。

在一种实施方式中，可以通过采集容器122读取第一指定目录下的软链接的名称，从软链接的名称中提取出目标应用容器对应的名称、标识、命名空间以及目标应用容器所在目标容器组的名称，并根据目标应用容器对应的名称、标识、命名空间以及目标容器组的名称获取目标应用容器对应的所有元数据信息。

采集容器122获取到元数据信息后，可将元数据信息与采集到的日志文件进行封装后转发到一个数据收集器，由数据收集器对收到的数据进行汇总并进一步清晰、转发和存储，通过数据收集器可将不同物理节点100上的日志数据路由到不同的终端上存储。

例如，使用采集容器122的tail输入插件动态读取/logx/inputs目录下的软链接文件名，使用Kubernetes过滤器插件，通过自定义正则表达式从软链接文件名中提取目标应用容器的namespace（命名空间）、pod_name（目标应用容器所在目标容器组的名称）、container_name（目标应用容器对应的名称）、container_id（目标应用容器对应的标识）等，采集容器通过这些信息向API Server请求验证并获取真实应用所有的K8s元数据信息，并将这些元数据信息与日志数据一起封装成新的事件转发至Fluentd（数据收集器）。

可见，本发明实施例通过引入新的容器日志采集方式，对传统应用无任何侵入的情况下，只需通过创建日志采集配置的方式即可实现容器内日志文件数据的采集，同时提取应用相关的K8S元数据信息，丰富了日志的内容，为精准快速高效查询日志提供了有利条件，为大规模K8S集群海量日志采集提供了有效的方法。

为了执行上述实施例及各个可能的方式中的相应步骤，下面给出一种点云处理装置的实现方式。请参阅图10，为本发明实施例提供的日志采集装置600的一种功能模块图。需要说明的是，本实施例所提供的日志采集装置600，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。该日志采集装置600包括解析模块610和采集模块620。

解析模块610，用于通过解析容器获取目标应用容器对应的日志采集配置信息，根据日志采集配置信息在第一容器组的第一指定目录下创建软链接；软链接指向目标应用容器的日志文件。

可以理解，该解析模块610可以执行上述步骤S701。

采集模块620，用于通过采集容器读取第一容器组的第一指定目录下的软链接，得到目标应用容器的日志文件。

可以理解，该采集模块620可以执行上述步骤S702。

可选地，日志采集配置信息包括目标应用容器的名称、应用标签和目标应用容器的日志文件在目标应用容器内的路径。

解析模块610用于根据应用标签获取目标应用容器所在目标容器组的名称、命名空间和目标应用容器的标识；根据目标应用容器的日志文件在目标应用容器内的路径，确定目标应用容器的日志文件在第一容器组内的路径，并获取目标应用容器的日志文件的标识；根据目标容器组的名称、命名空间、目标应用容器的名称、目标应用容器的标识和目标应用容器的日志文件的标识在第一指定目录下创建软链接，并将软链接与目标应用容器的日志文件在第一容器组内的路径进行关联。

可选地，物理节点的根目录挂载到第一容器组的第二指定目录下，解析容器和采集容器对第二指定目录下的所有文件拥有可读权限。

解析模块610用于根据目标应用容器的日志文件在目标应用容器内的路径，确定目标应用容器的日志文件在物理节点上的路径；根据目标应用容器的日志文件在物理节点上的路径和第一容器组的第二指定目录，得到目标应用容器的日志文件在第一容器组内的路径。

可选地，每个第二容器组对应一个命名空间，解析容器用于监听所有命名空间下的应用容器对应的日志采集资源对象的创建、更新和删除事件。解析模块610用于在解析容器监听到目标应用容器对应的日志采集资源对象的创建事件后，通过解析容器从创建事件中解析出目标应用容器对应的日志采集配置信息。

可选地，该采集模块620还用于获取目标应用容器对应的元数据信息；将元数据信息和采集的日志文件汇总后进行存储。

其中，该采集模块620具体用于通过采集容器读取第一指定目录下的软链接的名称，从软链接的名称中提取出目标应用容器对应的名称、标识、命名空间以及目标应用容器所在目标容器组的名称，并根据目标应用容器对应的名称、标识、命名空间以及目标容器组的名称获取目标应用容器对应的所有元数据信息。

可以理解，该采集模块620还可以执行上述步骤S901、S902。

可见，本发明实施例提供的日志采集装置，应用于Kubernetes集群中的每个物理节点，物理节点上运行有第一容器组和至少一个第二容器组，第一容器组中运行有预先配置的解析容器和采集容器，第二容器组中运行有至少一个应用容器；解析容器和采集容器共享第一容器组的所有目录；该日志采集装置包括解析模块和采集模块，解析模块用于通过解析容器获取目标应用容器对应的日志采集配置信息，根据日志采集配置信息在第一容器组的第一指定目录下创建软链接；软链接指向目标应用容器的日志文件；采集模块用于通过采集容器读取第一容器组的第一指定目录下的软链接，得到目标应用容器的日志文件。由于该软链接指向目标应用容器的日志文件且解析容器和采集容器在一个容器组内可以共享目录，故通过采集容器读取该第一指定目录下的软链接，即可获得目标应用容器的日志文件。如此，在不要求传统应用在容器化转型的过程中改变其通过写日志文件记录日志的方式情况下，通过配置的方式即可采集应用容器的日志文件，无需重启应用，也无需向应用Pod中注入边车容器，将应用日志的生命周期与应用的生命周期解耦，应用本身也无需增加额外资源消耗，最终实现应用日志数据的持久化存储和查询。

请参照图11，为本发明实施例提供的电子设备700的一种方框示意图。该电子设备可以是上述Kubernetes集群中的任一个物理节点，例如可以是PC（Personal Computer，个人计算机）、服务器等设备，本实施例对此不做限制。电子设备700包括存储器710、处理器720及通信模块730。存储器710、处理器720以及通信模块730各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。

其中，存储器710用于存储程序或者数据。存储器710可以是，但不限于，随机存取存储器（Random Access Memory，RAM），只读存储器（Read Only Memory，ROM），可编程只读存储器（Programmable Read-Only Memory，PROM），可擦除只读存储器（ErasableProgrammable Read-Only Memory，EPROM），电可擦除只读存储器（Electric ErasableProgrammable Read-Only Memory，EEPROM）等。

处理器720用于读/写存储器710中存储的数据或程序，并执行相应地功能。例如，当存储器710中存储的计算机程序被处理器720执行时，可以实现上述各实施例所揭示的日志采集方法。

通信模块730用于通过网络建立电子设备700与其它通信终端之间的通信连接，并用于通过网络收发数据。

应当理解的是，图11所示的结构仅为电子设备700的结构示意图，电子设备700还可包括比图11中所示更多或者更少的组件，或者具有与图11所示不同的配置。图11中所示的各组件可以采用硬件、软件或其组合实现。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器720执行时实现上述各实施例所揭示的日志采集方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种日志采集方法，其特征在于，应用于Kubernetes集群中的每个物理节点，所述物理节点上运行有第一容器组和至少一个第二容器组，所述第一容器组中运行有预先配置的解析容器和采集容器，所述第二容器组中运行有至少一个应用容器；所述解析容器和所述采集容器共享所述第一容器组的所有目录；所述方法包括：

通过所述解析容器获取目标应用容器对应的日志采集配置信息，根据所述日志采集配置信息在所述第一容器组的第一指定目录下创建软链接；所述软链接指向所述目标应用容器的日志文件；所述日志采集配置信息由用户针对所述物理节点上的任一个需要收集日志文件的应用容器进行设置；

通过所述采集容器读取所述第一容器组的第一指定目录下的软链接，得到所述目标应用容器的日志文件。

2.根据权利要求1所述的方法，其特征在于，所述日志采集配置信息包括所述目标应用容器的名称、应用标签和所述目标应用容器的日志文件在所述目标应用容器内的路径；

所述根据所述日志采集配置信息在所述第一容器组的第一指定目录下创建软链接，包括：

根据所述应用标签获取所述目标应用容器所在目标容器组的名称、命名空间和所述目标应用容器的标识；

根据所述目标应用容器的日志文件在所述目标应用容器内的路径，确定所述目标应用容器的日志文件在所述第一容器组内的路径，并获取所述目标应用容器的日志文件的标识；

根据所述目标容器组的名称、命名空间、所述目标应用容器的名称、所述目标应用容器的标识和所述目标应用容器的日志文件的标识在所述第一指定目录下创建软链接，并将所述软链接与所述目标应用容器的日志文件在所述第一容器组内的路径进行关联。

3.根据权利要求2所述的方法，其特征在于，所述物理节点的根目录挂载到所述第一容器组的第二指定目录下；

所述根据所述目标应用容器的日志文件在所述目标应用容器内的路径，确定所述目标应用容器的日志文件在所述第一容器组内的路径，包括：

根据所述目标应用容器的日志文件在所述目标应用容器内的路径，确定所述目标应用容器的日志文件在所述物理节点上的路径；

根据所述目标应用容器的日志文件在所述物理节点上的路径和所述第一容器组的第二指定目录，得到所述目标应用容器的日志文件在所述第一容器组内的路径。

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

获取所述目标应用容器对应的元数据信息；

将所述元数据信息和采集的所述日志文件汇总后进行存储。

5.根据权利要求4所述的方法，其特征在于，所述获取所述目标应用容器对应的元数据信息，包括：

通过所述采集容器读取所述第一指定目录下的软链接的名称，从所述软链接的名称中提取出所述目标应用容器对应的名称、标识、命名空间以及所述目标应用容器所在目标容器组的名称，并根据所述目标应用容器对应的名称、标识、命名空间以及所述目标容器组的名称获取所述目标应用容器对应的所有元数据信息。

6.根据权利要求1所述的方法，其特征在于，每个所述第二容器组对应一个命名空间，所述解析容器用于监听所有命名空间下的应用容器对应的日志采集资源对象的创建、更新和删除事件；

所述通过所述解析容器获取目标应用容器对应的日志采集配置信息，包括：

在所述解析容器监听到目标应用容器对应的日志采集资源对象的创建事件后，通过所述解析容器从所述创建事件中解析出所述目标应用容器对应的日志采集配置信息。

7.一种日志采集装置，其特征在于，应用于Kubernetes集群中的每个物理节点，所述物理节点上运行有第一容器组和至少一个第二容器组，所述第一容器组中运行有预先配置的解析容器和采集容器，所述第二容器组中运行有至少一个应用容器；所述解析容器和所述采集容器共享所述第一容器组的所有目录；所述装置包括：

解析模块，用于通过所述解析容器获取目标应用容器对应的日志采集配置信息，根据所述日志采集配置信息在所述第一容器组的第一指定目录下创建软链接；所述软链接指向所述目标应用容器的日志文件；所述日志采集配置信息由用户针对所述物理节点上的任一个需要收集日志文件的应用容器进行设置；

采集模块，用于通过所述采集容器读取所述第一容器组的第一指定目录下的软链接，得到所述目标应用容器的日志文件。

8.根据权利要求7所述的装置，其特征在于，所述日志采集配置信息包括所述目标应用容器的名称、应用标签和所述目标应用容器的日志文件在所述目标应用容器内的路径；

所述解析模块用于根据所述应用标签获取所述目标应用容器所在目标容器组的名称、命名空间和所述目标应用容器的标识；根据所述目标应用容器的日志文件在所述目标应用容器内的路径，确定所述目标应用容器的日志文件在所述第一容器组内的路径，并获取所述目标应用容器的日志文件的标识；根据所述目标容器组的名称、命名空间、所述目标应用容器的名称、所述目标应用容器的标识和所述目标应用容器的日志文件的标识在所述第一指定目录下创建软链接，并将所述软链接与所述目标应用容器的日志文件在所述第一容器组内的路径进行关联。

9.一种电子设备，其特征在于，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1-6中任一项所述的日志采集方法的步骤。

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

Images