CN111046011A - 日志收集方法、***、节点、电子设备及可读存储介质 - Google Patents

Abstract

本申请提供一种日志收集方法、***、节点、电子设备及可读存储介质，涉及计算机技术领域。该方法包括：通过日志收集组件采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod中的每个容器产生的日志文件；通过所述日志收集组件将采集的所述日志文件传输至日志存储***。该方案中，通过在节点中部署日志收集组件，使得可以通过日志收集组件在日志存储路径下收集其存储的节点内的所有容器产生的日志文件，然后将日志文件传输至日志存储***，由此可轻松实现对节点内的每个pod内的容器产生的日志文件的收集。

Description

日志收集方法、***、节点、电子设备及可读存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种日志收集方法、***、节点、电子设备及可读存储介质。

背景技术

随着以Docker和Kubernetes为代表的容器生态***的不断完善，越来越多的开发者将他们的应用及其所依赖的环境打包到容器中运行，并采用Kubernetes进行部署运行、资源调度、服务发现和动态扩缩等一系列的容器编排操作，提高了大规模容器集群管理的便捷性。

但是应用容器化带来了管理上的高复杂度，其中一点便是应用日志的收集和管理，在大规模的容器集群中，一个微服务会存在多个副本并随机分配到不同主机节点上，导致难以收集这些节点中的多个容器产生的日志数据。

发明内容

本申请实施例的目的在于提供一种日志收集方法、***、节点、电子设备及可读存储介质，用以改善现有技术中日志数据收集比较困难的问题。

第一方面，本申请实施例提供了一种日志收集方法，应用于集群中的节点，所述方法包括：

通过日志收集组件采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod中的每个容器产生的日志文件；

通过所述日志收集组件将采集的所述日志文件传输至日志存储***。

在上述实现过程中，通过在节点中部署日志收集组件，使得可以通过日志收集组件在日志存储路径下收集其存储的节点内的所有容器产生的日志文件，然后将日志文件传输至日志存储***，由此可轻松实现对节点内的每个pod内的容器产生的日志文件的收集。

可选地，所述通过日志收集组件采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件，包括：

通过日志收集组件对所述至少一个pod的日志存储路径下存储的日志文件进行内容检测；

通过日志收集组件在检测到所述日志存储路径下存储的日志文件存在更新时，采集更新的日志文件。

在上述实现过程中，通过日志收集组件对日志存储路径下存储的日志文件进行检测，由此可确保日志收集组件可以及时采集到日志存储路径下存储的日志文件。

可选地，所述方法还包括：

通过日志处理组件从所述日志文件中的每条日志信息中获取每条日志信息所属的容器的标识，并根据所述容器的标识查找每条日志信息所属的pod的元数据，将每条日志信息所属的pod的元数据添加到对应的日志信息中。

在上述实现过程中，通过节点中部署的日志处理组件来查找获得日志信息所属的pod的元数据，从而实现在日志信息中添加对应的pod的元数据，使得后续可以根据pod的元数据对日志文件进行分析处理。

可选地，所述方法还包括：

通过每个pod中的容器将所述容器的标识添加到所述容器产生的每条日志信息中。

可选地，所述通过所述日志收集组件将采集的所述日志文件传输至日志存储***，包括：

通过所述日志收集组件将采集的所述日志文件传输至消息队列服务器，以通过所述消息队列服务器将所述日志文件传输至所述日志存储***。

可选地，所述消息队列服务器为Kafka。

在上述实现过程中，Kafka可以对接收到的日志文件进行缓存，从而对于高并发场景下进行流量消峰，在一定程度上可以保护日志存储***的具体存储服务。

可选地，所述日志收集组件为Filebeat，所述日志存储***为Elasticserach。

可选地，所述日志收集组件通过Linux***中的守护进程来运行，从而使得日志收集组件在运行过程中不会轻易失败重启。

第二方面，本申请实施例提供了一种节点，所述节点包括：

日志收集组件，用于采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod中的每个容器产生的日志文件；

所述日志收集组件，还用于将采集的所述日志文件传输至所述日志存储***。

可选地，所述日志收集组件，还用于对所述至少一个pod的日志存储路径下存储的日志文件进行内容检测；

所述日志收集组件，还用于在检测到所述日志存储路径下存储的日志文件存在更新时，采集更新的日志文件。

可选地，所述节点还包括：

日志处理组件，用于从所述日志文件中的每条日志信息中获取每条日志信息所属的容器的标识，并根据所述容器的标识查找每条日志信息所属的pod的元数据，将每条日志信息所属的pod的元数据添加到对应的日志信息中。

可选地，所述节点还包括：

容器，用于将所述容器的标识添加到所述容器产生的每条日志信息中。

可选地，所述日志收集组件，还用于将采集的所述日志文件传输至消息队列服务器，以通过所述消息队列服务器将所述日志文件传输至所述日志存储***。

可选地，所述消息队列服务器为Kafka。

可选地，所述日志收集组件为Filebeat，所述日志存储***为Elasticserach。

可选地，所述日志收集组件通过Linux***中的守护进程来运行。

第三方面，本申请实施例提供了一种日志收集***，包括多个节点以及运行日志存储***的服务器：

所述节点，用于通过日志收集组件采集所述至少一个pod的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod中的每个容器产生的日志文件；

所述节点，还用于将采集的所述日志文件发送至所述服务器；

所述服务器，用于通过所述日志存储***对所述日志文件进行异常分析。

第四方面，本申请实施例提供一种电子设备，包括处理器以及存储器，所述存储器存储有计算机可读取指令，当所述计算机可读取指令由所述处理器执行时，运行如上述第一方面提供的所述方法中的步骤。

第五方面，本申请实施例提供一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时运行如上述第一方面提供的所述方法中的步骤。

本申请的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请实施例了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

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

图1为本申请实施例提供的一种日志收集***的结构示意图；

图2为本申请实施例提供的一种日志收集方法的流程图；

图3为本申请实施例提供的另一种日志收集***的结构示意图；

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

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

发明人在研究中发现，现有技术中对节点中的容器产生的日志数据进行收集一般采用日志收集工具来收集，但是日志收集工具一般部署于节点中运行的每个pod中，即每个节点内的每个pod内均运行有一个日志收集工具，这使得有多少个pod就需要有多少个日志收集工具，每个日志收集工具只针对其所属的pod内的容器的日志数据进行收集，在节点内运行的pod的数量较多时，也需要运行大量的日志收集工具，导致节点资源消耗较大以及空间占用较多。

而且，当日志收集工具以容器运行时，需要给每个容器配置相应的可读探针和就绪探针，以便于检测其容器是否可用，当Kubernetes集群规模较大时，其探针监测到失败后从失败恢复的世界就会增加，在发现故障到故障恢复的时间内，该容器内的服务无法正常运行，从而导致日志输出的实时性下降。

另外，当集群内需要升级日志收集工具的版本或者回滚版本时，需要对每个日志收集工具分别进行操作，由于日志收集工具的数量较多，从而增加了操作上的不便和管理上的复杂度。

以上现有技术中的方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本发明实施例针对上述问题所提出的解决方案，都应该是发明人在本发明过程中对本发明做出的贡献。

为了解决上述问题，本申请实施例提供一种日志收集方法，通过在每个节点内部署日志收集组件，然后每个pod内的容器产生的日志存储于日志存储路径下，使得日志收集组件可以通过日志存储路径采集容器产生的日志文件，由此可轻松实现对节点内的容器的日志数据的采集。

并且，该日志收集组件部署于每个pod外，使得每个节点内只需要部署一个日志收集组件即可，大大减少了节点内日志收集组件的数量，进而减少了节点的资源消耗和空间占用。由于日志收集组件的数量减少，使得需要对日志收集组件进行升级版本或者回滚版本时，可以对较少数量的日志收集组件进行操作即可，提高了操作的便利以及减少了管理的复杂度。

下面结合附图对本申请实施例提供的日志收集方法进行详细介绍。

本申请实施例提供的日志收集方法应用于如图1中所示的日志收集***200，该日志收集***200包括多个节点100以及运行日志存储***132的服务器130，该节点100中运行有日志收集组件110，节点100中除所述日志收集组件110外还运行有至少一个pod120，每个pod120中运行有至少一个容器122。

所述节点100，用于通过日志收集组件110采集所述至少一个pod120的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod120中的每个容器122产生的日志文件。

所述节点100，还用于通过日志收集组件110将采集的所述日志文件发送至所述服务器130。

所述服务器130，用于通过日志存储***132对所述日志文件进行异常分析。

其中，节点100是指kubernetes集群中的节点，kubernetes是自动化容器122操作的开源平台，kubernetes集群是指一组节点100，即在kubernetes集群中可以包含有多个节点100，这些节点100可以是物理服务器、物理机或者虚拟机等设备，这些节点100上安装了kubernetes平台。

每个节点100在运行过程中会产生日志，为了获取这些节点100产生的日志文件，可以在每个节点100中部署日志收集组件110，即每个节点100中可以运行有日志收集组件110，日志收集组件110用于收集节点100内的容器122产生的日志文件。

该节点100中除日志收集组件110外还运行有至少一个pod120，每个pod120中运行有至少一个容器122。pod120是指kubernetes集群的最小调度单位，在kubernetes集群中，pod120是所有业务类型的基础，是一个或多个容器122的组合，这些容器122共享存储、存储和命名空间，以及如何运行的规范。在pod120中，所有容器122都被统一安排和调度，并运行在共享的上下文中，pod120的上下文可以了理解成多个Linux命名空间的联合。对于具体应用而言，pod120是容器122的逻辑主机，pod120中可包含业务相关的多个应用容器122。

每个pod120都会被分配一个唯一的IP地址，在pod120中的每一个容器122共享网络命名空间，包括IP地址和网络端口。在同一个pod120中的容器122可以通过localhost相互通信。

这些容器122可以是指Docker容器122，当然，kubernetes集群不只是支持Docker容器122，也可以支持其他容器122。

需要说明的是，日志收集组件110部署于节点100中的pod120外，用于收集节点100内所有pod120内的容器122产生的日志文件，从而使得日志收集组件110无需部署于pod120内部，而每个节点100内部只需部署一个日志收集组件110即可采集所有容器122的日志文件，以此可减少节点100的资源消耗。

下面结合方法实施例对上述的日志收集***200进行说明，请参照图2，图2为本申请实施例提供的一种日志收集方法的流程图，该方法包括如下步骤：

步骤S110：通过日志收集组件采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件。

由于同一个pod120内的所有容器共享存储空间，所以，这些容器所产生的日志文件均存储在一个固定的存储空间中，这个存储空间可通过日志存储路径访问获得。即日志存储路径下存储有每个pod120中的每个容器产生的日志文件。

若其容器采用Docker容器，由于Docker容器机制，使得容器内对于标准输出所打印的日志信息，都在一个固定的路径下面以文件的形式暂存起来，即其日志文件均存储在日志存储路径下，而日志收集组件110可以通过日志存储路径访问到存储的日志文件，进行采集。

其中，日志存储路径可以根据实际需求自定义存储路径，或者将默认的存储日志文件的存储空间所在的路径作为日志存储路径。

另外，可以自定义日志收集组件110采集日志文件的时间，如日志收集组件110可以周期性或者实时采集日志存储路径下暂存的日志文件。

步骤S120：通过所述日志收集组件将采集的所述日志文件传输至日志存储***。

为了将后续可以对日志文件进行分析，日志收集组件110还需要将采集的日志文件传输至日志存储***132。

其中，日志存储***132不在节点100内，其可以部署于节点100外的另一服务器130上，即在实际应用中，会通过另外一服务器130来部署日志存储***132，然后节点100通过日志收集组件110将日志文件传输给服务器上的日志存储***132。

在上述实现过程中，在节点100中部署日志收集组件110，使得可以通过日志收集组件110在日志存储路径下收集其存储的节点100内的所有容器产生的日志文件，然后将日志文件传输至日志存储***132，由此可轻松实现对节点100内的每个pod120内的容器产生的日志文件的收集。

作为一种示例，日志收集组件110可以为Filebeat或Logstash，Filebeat是一种轻量的日志收集工具，Logstash是一种功能强大的日志收集管理工具。由于Filebeat部署在节点100中，其所占节点100资源较少，不会造成节点100较大的资源负载。

通过Filebeat采集日志文件时，其可以启动一个或多个查找器，查看日志存储路径，对于查找器找出的每一个日志文件，Filebeat会启动收割进程，每一个收割进程读取一个日志文件的新内容，并发送这些新的日志数据到处理程序，处理程序会集合这些信息，然后将这些信息作为采集获得的日志文件输出给日志存储***132。

为了确保日志收集组件110在运行过程不会轻易失败重启，则日志收集组件110可以通过Linux***中的守护进程来运行。守护进程是Linux的后台服务进程，其是一个生存期较长的进程，其可以独立于控制终端并且周期性地执行某种任务或等待处理某些发送的事件。

另外，为了确保日志收集组件110可以及时采集到日志存储路径下存储的日志文件，节点100可以通过日志收集组件110对至少一个pod120的日志存储路径下存储的日志文件进行内容检测，在检测到日志存储路径下存储的日志文件存在更新时，采集更新的日志文件。

可以理解地，日志收集组件110可以对日志存储路径进行实时监测，即日志收集组件110在上一次采集完日志存储路径下存储的所有日志文件后其日志存储路径下存储的信息为空，若监测到志存储路径下存储的信息为空时，则日志收集组件110不执行采集操作，若监测到日志存储路径下存储的信息不为空时，表示产生了新的日志文件，则日志收集组件110执行采集动作，以采集新的日志文件。

在上述实现过程中，通过日志收集组件110对日志存储路径下存储的日志文件进行检测，由此可确保日志收集组件110可以及时采集到日志存储路径下存储的日志文件。

作为一种示例，为了便于后续日志存储***132对日志文件进行处理和收集提供数据支撑，日志文件中包括至少一条日志信息，每条日志信息中包括该日志信息所属的pod120的元数据。

可以理解地，可以将每条日志信息与Kubernetes中对应的pod120进行关联，pod120的元数据包括有pod120标识、用户标识、客户端标识等信息，在创建pod120时，可以将这些信息添加到pod120的元数据中，从而后续日志存储***132对日志文件进行分析过滤后，可以对具体的用户和客户端做针对性的推送。

上述日志信息中包含的pod120的元数据可以通过节点100中部署的日志处理组件来添加，即节点100中还运行有日志处理组件，该通过日志处理组件从每条日志信息中获取每条日志信息所属的容器的标识，并根据容器的标识查找每条日志信息所属的pod120的元数据，然后将每条日志信息所属的pod120的元数据添加到对应的日志信息中。

其中，每个容器在产生对应的日志信息时，每条日志信息会携带有其所属容器的标识，即通过容器每个pod中的容器将该容器的标识添加到该容器产生的每条日志信息中。例如，在pod1201中包含有三个容器，分别是容器1、容器2和容器3，容器1产生的日志信息会携带该容器1的标识，如为1，容器2产生的日志信息会携带该容器2的标识2，容器3产生的日志信息会携带该容器3的标识3，由此，日志处理组件可从每条日志信息中获取对应的容器的标识。在kubernetes平台中存储有各个pod120与其包含的各个容器之间的对应关系，如pod1201与容器1、容器2和容器3的对应关系，所以可以根据容器的标识查找到对应的pod120，进而可从kubernetes平台中获取对应pod120的元数据，然后添加到日志信息中，由此使得每条日志信息中携带有对应pod120的元数据。

如此，可以通过日志处理组件将每条日志信息添加对应的pod120的元数据，从而使得后续可以根据pod120的元数据对日志文件进行分析处理。

作为一种示例，如图3所示，日志收集***200还可包括消息队列服务器140，日志收集组件110还可以将采集的日志文件传输至消息队列服务器140，然后通过消息队列服务器140将日志文件传输至日志存储***132。

本申请实施例中，消息队列服务器140中可以部署Kafka，Kafka是一个分布式消息队列处理平台，Kafka可以对接收到的日志文件进行缓存，从而对于高并发场景下进行流量消峰，在一定程度上可以保护日志存储***132的具体存储服务。

另外，消息队列服务器140可以将日志文件按照时间来存储，则日志存储***132可以根据时间顺序获取日志文件，从而可以按照时间顺序来对日志文件进行处理。

另外，日志存储***132可以为Elasticserach，Elasticserach是一个分布式可扩展的实时搜索和分析引擎，其可以分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。

日志存储***132可用于对日志文件进行异常分析，如可以通过关键词对获得的日志文件进行过滤，从而可以确定出日志文件中的异常信息进行告警，然后可通过告警服务或邮件服务通知对应的***管理员。例如，一个支付业务，某个容器找那个发现某用户频繁支付密码失败，这个发现信息会记录在日志信息中，日志信息中还会记录用户的标识、用户登录的应用的IP地址等信息，那么在日志存储***132中可以通过将用户登录的应用的IP地址或者用户的标识作为关键词搜索日志文件，然后可将这些日志信息进行告警。由于其日志信息中记录有其所属的pod120的元数据，所以***管理员可及时知晓哪些pod120有异常，进而定位到对应的出现异常的容器。

另外，结合上述方法实施例，本申请实施例还提供一种节点100，所述节点100包括：

日志收集组件110，用于采集所述节点中运行的至少一个pod120的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod120中的每个容器产生的日志文件；

所述日志收集组件110，还用于将采集的所述日志文件传输至所述日志存储***132。

可选地，所述日志收集组件110通过Linux***中的守护进程来运行。

可选地，所述日志收集组件110，还用于对所述至少一个pod120的日志存储路径下存储的日志文件进行内容检测；在检测到所述日志存储路径下存储的日志文件存在更新时，采集更新的日志文件。

可选地，所述节点100还包括：

日志处理组件，用于从每条日志信息中获取每条日志信息所属的容器122的标识，并根据所述容器122的标识查找每条日志信息所属的pod120的元数据，将每条日志信息所属的pod120的元数据添加到对应的日志信息中。

可选地，所述节点还包括：

容器122，用于将所述容器122的标识添加到所述容器122产生的每条日志信息中。

可选地，所述日志收集组件110，还用于将采集的所述日志文件传输至所述消息队列服务器140；以通过所述消息队列服务器140将所述日志文件传输至所述日志存储***132。

可选地，所述消息队列服务器140为Kafka。

可选地，所述日志收集组件110为Filebeat，所述日志存储***132为Elasticserach。

请参照图4，图4为本申请实施例提供的一种电子设备的结构示意图，上述的日志收集组件和日志处理组件可以是电子设备上的模块、程序段或代码。所述电子设备可以包括：至少一个处理器310，例如CPU，至少一个通信接口320，至少一个存储器330和至少一个通信总线340。其中，通信总线340用于实现这些组件直接的连接通信。其中，本申请实施例中设备的通信接口320用于与其他节点设备进行信令或数据的通信。存储器330可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器330可选的还可以是至少一个位于远离前述处理器的存储装置。存储器330中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器310执行时，电子设备执行上述图2所示方法过程。其中，存储器330可用于存储日志存储路径下的日志文件，处理器310可以调用日志收集组件实现日志文件的收集以及传输。

本申请实施例提供一种可读存储介质，所述计算机程序被处理器执行时，执行如图2所示方法实施例中电子设备所执行的方法过程。

本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如，包括：通过日志收集组件采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod中的每个容器产生的日志文件；通过所述日志收集组件将采集的所述日志文件传输至日志存储***。

综上所述，本申请实施例提供一种日志收集方法、***、节点、电子设备及可读存储介质，该方案中，通过在节点中部署日志收集组件，使得可以通过日志收集组件在日志存储路径下收集其存储的节点内的所有容器产生的日志文件，然后将日志文件传输至日志存储***，由此可轻松实现对节点内的每个pod内的容器产生的日志文件的收集。

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

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

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

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

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

Claims (10)

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

通过日志收集组件采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod中的每个容器产生的日志文件；

通过所述日志收集组件将采集的所述日志文件传输至日志存储***。

2.根据权利要求1所述的方法，其特征在于，所述通过日志收集组件采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件，包括：

通过日志收集组件对所述至少一个pod的日志存储路径下存储的日志文件进行内容检测；

通过日志收集组件在检测到所述日志存储路径下存储的日志文件存在更新时，采集更新的日志文件。

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

通过日志处理组件从所述日志文件中的每条日志信息中获取每条日志信息所属的容器的标识，并根据所述容器的标识查找每条日志信息所属的pod的元数据，将每条日志信息所属的pod的元数据添加到对应的日志信息中。

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

通过每个pod中的容器将所述容器的标识添加到所述容器产生的每条日志信息中。

5.根据权利要求1所述的方法，其特征在于，所述通过所述日志收集组件将采集的所述日志文件传输至日志存储***，包括：

通过所述日志收集组件将采集的所述日志文件传输至消息队列服务器，以通过所述消息队列服务器将所述日志文件传输至所述日志存储***。

6.根据权利要求1所述的方法，其特征在于，所述日志收集组件通过Linux***中的守护进程来运行。

7.一种节点，其特征在于，所述节点包括：

日志收集组件，用于采集所述节点中运行的至少一个pod的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod中的每个容器产生的日志文件；

所述日志收集组件，还用于将采集的所述日志文件传输至日志存储***。

8.一种日志收集***，其特征在于，包括多个节点以及运行日志存储***的服务器：

所述节点，用于通过日志收集组件采集至少一个pod的日志存储路径下存储的日志文件，其中，在所述日志存储路径下存储有每个pod中的每个容器产生的日志文件；

所述节点，还用于将采集的所述日志文件发送至所述服务器；

所述服务器，用于通过所述日志存储***对所述日志文件进行异常分析。

9.一种电子设备，其特征在于，包括处理器以及存储器，所述存储器存储有计算机可读取指令，当所述计算机可读取指令由所述处理器执行时，运行如权利要求1-6任一所述的方法。

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

Images