日志自动采集的方法、设备及存储介质与流程

1.本发明实施例涉及但不限于容器技术领域，尤其涉及一种日志自动采集的方法、设备及存储介质。


背景技术：

2.传统日志工具的运作模式，一般分为独立远程日志服务器，或者本地日志服务；前者一般以商业日志软件为主，需要独立部署日志服务器，实现日志配置和管理，通过在源端和目标端布置的客户端实现日志服务；后者多为开源工具，部署在源端或者日志端。以上两种方式的运维需要依赖人力进行维护，同时其并不能很好的适应容器编排器(如kubernetes环境)的日志需求，现有的容器编排器自带的日志采集服务要么依赖于平台自带的采集工具，即采集工具与采集服务强相关，无法适配定制化的采集需求；而另一些容器编排器中日志采集服务虽然可以需要根据实际的应用创建服务实现定制化需求，但是采集服务的部署较难，因此，基于现有的容器编排器的日志采集的方式很难对多种应用场景进行快速部署和采集需求的适配。


技术实现要素：

3.以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
4.本发明实施例提供了一种日志自动采集的方法、设备及存储介质，能适配多种应用场景的日志采集需求且能快速部署。
5.第一方面，本发明实施例提供了一种日志自动采集的方法，应用于容器编排器，包括：
6.将预设的日志抽象文件作为自定义资源进行存储；
7.获取预设的日志采集通用参数以及预设的日志逻辑文件，其中，所述日志采集通用参数包括日志工具信息；
8.将所述日志采集通用参数作为所述日志抽象文件的参数，并根据所述日志抽象文件的参数创建日志服务对象；
9.根据所述日志服务对象和所述日志逻辑文件，创建日志采集服务；
10.根据所述日志逻辑文件中的日志采集逻辑，通过所述日志采集服务调用所述日志工具信息对应的日志工具进行日志采集。
11.根据本发明第一方面的一些实施例，所述日志采集通用参数包括配置文件，所述配置文件用于存储采集目标，所述日志抽象文件包括目标服务器；
12.所述根据所述日志逻辑文件中的日志采集逻辑，通过所述日志采集服务调用所述日志工具信息对应的日志工具进行日志采集，包括：
13.通过所述日志采集服务从所述日志服务对象中提取所述配置文件并从所述配置文件中确定第一日志采集目录；
14.通过所述日志采集服务从所述日志服务对象中确定所述目标服务器；
15.通过所述日志采集服务调用所述日志工具，采集所述目标服务器下所述第一日志采集目录下的日志文件。
16.根据本发明第一方面的一些实施例，所述日志采集通用参数还包括日志监控目录；
17.所述根据所述日志逻辑文件中的日志采集逻辑，通过所述日志采集服务调用所述日志工具信息对应的日志工具进行日志采集，还包括：
18.通过所述日志采集服务从所述日志服务对象中提取日志监控目录；
19.按照预设周期从所述日志监控目录提取第二日志采集目录；
20.将当前提取的所述第二日志采集目录与所述第一日志采集目录进行比较；
21.当所述第二日志采集目录相对于所述第一日志采集目录有新增路径，通过所述日志采集服务将所述新增路径添加至所述配置文件，使得所述第一日志采集目录被更新；
22.重启所述日志采集服务，使得所述日志工具根据所述配置文件中已更新的所述第一日志采集目录进行日志采集。
23.根据本发明第一方面的一些实施例，所述根据所述日志逻辑文件中的日志采集逻辑，通过所述日志采集服务调用所述日志工具信息对应的日志工具进行日志采集，还包括：
24.当所述新增路径表示有新增的应用，通过所述日志采集服务将所述新增的应用添加至所述配置文件。
25.根据本发明第一方面的一些实施例，所述通过所述日志采集服务将所述新增的应用添加至所述存储采集目标，包括：
26.通过所述日志采集服务从所述新增路径中提取出所述新增的应用的应用名称；
27.将所述应用名称作为所述容器编排器的服务提取接口的参数，得到应用信息；
28.通过所述日志采集服务将所述应用信息添加至所述配置文件。
29.根据本发明第一方面的一些实施例，在进行日志采集之前，所述方法还包括：
30.通过所述日志采集服务调用所述日志工具，得到校验日志；
31.对所述校验日志进行模式解析，得到第一日志模式；
32.将所述第一日志模式与所述容器编排器预设的第二日志模型进行比较；
33.将比较结果更新至所述日志服务对象的资源状态参数中，使得所述容器编排器根据所述资源状态参数监控所述日志服务对象的采集状态。
34.根据本发明第一方面的一些实施例，在进行日志采集之后，所述方法还包括：
35.统计所述日志采集占用的网络流量；
36.将所述网络流量与预设的门限值进行比较；
37.当所述网络流量大于所述门限值，按照预设的调整算法减少所述日志工具的并发量。
38.第二方面，本发明提供一种具备日志自动采集功能的设备，包括：
39.资源定义模块，用于将预设的日志抽象文件作为自定义资源进行存储；
40.获取模块，用于获取预设的日志采集通用参数以及预设的日志逻辑文件，其中，所述日志采集通用参数包括日志工具信息；
41.对象创建模块，用于将所述日志采集通用参数作为所述日志抽象文件的参数，并
根据所述日志抽象文件的参数创建日志服务对象；
42.服务创建模块，用于根据所述日志服务对象和所述日志逻辑文件，创建日志采集服务；
43.运行模块，用于根据所述日志逻辑文件中的日志采集逻辑，通过所述日志采集服务调用所述日志工具信息对应的日志工具进行日志采集。
44.第三方面，本发明实施例还提供了一种电子设备，包括：至少一个处理器，以及，与至少一个处理器通信连接的存储器；其中，存储器存储有指令，指令被至少一个处理器执行，以使至少一个处理器执行指令时实现如第一方面任意一项所述的日志自动采集的方法。
45.第四方面，本发明实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行第一方面任意一项所述的日志自动采集的方法。
46.本发明上述实施例至少具有如下有益效果：通过将日志抽象文件作为自定义资源进行部署，进而可以将实际应用场景所需的日志工具等作为日志采集通用参数并结合日志抽象文件进行实例化，得到日志服务对象，同时通过自定义日志逻辑文件管理日志服务对象的操作，实现日志采集服务与日志工具和部署的解耦。此时，当应用场景或者采集工具发生变化时，仅需调整采集通用参数以及日志采集逻辑即可实现日志采集服务的创建，日志采集服务的部署更为简单和通用化且能满足不同采集需求的设置，因此，本发明实施例的日志自动采集的方法、设备及存储介质，能适配多种应用场景的日志采集需求且能快速部署。
47.本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
48.附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。
49.图1是本发明实施例的日志自动采集的方法的流程示意图；
50.图2是本发明实施例的日志抽象文件的示例；
51.图3是本发明实施例的日志服务对象的示例；
52.图4是本发明实施例的日志自动采集的方法中维护采集目标的流程示意图；
53.图5是本发明实施例的日志自动采集的方法中日志模式自动识别的流程示意图；
54.图6是本发明实施例的具备日志自动采集功能的设备的模块示意图；
55.图7是本发明实施例的应用日志自动采集的方法的电子设备的硬件示意图。
具体实施方式
56.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
57.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的
技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
58.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。
59.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
60.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
61.下面是对本发明中用到的一些术语的解释。
62.容器编排器，可以工作在使用容器的任何环境。它可以帮助你在多个环境中部署相同的程序，而不需要重新编写它。
63.kubernetes，也被称为k8s或kube，是容器编排器的一种。用于自动化部署、扩展和管理容器化应用的开源容器编排器技术；它通过在集群之上形成一个抽象层来使得部署和管理微服务架构应用程序变得很简单。
64.operator，基于kubernetes中的两个概念结合而成：自定义资源和自定义控制器。它让工程师可以根据应用独有的领域逻辑为应用编写自定义的控制器。其中，自定义资源就是不由kubernetes原生提供的资源对象。
65.crd，全称为customresourcedefinition，crd自定义资源二次开发能力能扩展kubernetes api，通过crd我们可以向kubernetes api中增加新资源类型，而不需要修改kubernetes源码或创建自定义的api server。
66.efk,为目前最为流行的分布式日志框架,主要实现了日志的收集,存储,分析等,它可以与docker容器进行结合,来收集docker的控制台日志。
67.传统日志工具的运作模式，一般分为独立远程日志服务器，或者本地日志服务；前者一般以商业日志软件为主，需要独立部署日志服务器，实现日志配置和管理，通过在源端和目标端布置的客户端实现日志服务；后者多为开源工具，部署在源端或者日志端。以上两种方式的运维需要依赖人力进行维护，且随着技术的发展，云原生服务由于其能为平台用户提供容器编排、自愈、部署管理功能，被广泛使用，但是当前的日志采集服务的方式并不能很好的适应,以kubernetes环境为例，前用户使用k8s的主要由两种模式，第一种是托管模式，即是向云服务商购买现成的k8s服务，将整个k8s平台托管给云服务商维护，自身仅仅作为应用算力使用者；第二种是自托管模式，是自行在裸金属服务器，或者由云服务商提供的计算资源上维护自己的k8s平台，而前者的日志采集的方式虽然无需日志采集工具的部署，但是日志采集服务的完全依赖于平台自身支持的日志工具，并无法适用各种应用场景。而后者则更适合于企业构建自身的私有云原生服务，优势在于能构建适用于自身应用特点的云服务、同时具有私有云的优点，缺点则在于应用到生产环境所必须的辅助服务，比如日
志等，部分或全部需要自行构建，在容器编排器中部署较为困难。因此，后一种部署难度较大，因此，现有的日志采集的方法。因此，现有适用于容器很难对多种应用场景进行快速部署和采集需求的适配。基于此，本发明实施例提供了一种日志自动采集的方法、设备及存储介质，能适配多种应用场景的日志采集需求且能快速部署。
68.第一方面，参照图1所示，根据本发明实施例提供的一种日志自动采集的方法，应用于容器编排器，包括：
69.步骤s100、将预设的日志抽象文件作为自定义资源进行存储。
70.需说明的是，将日志抽象文件存储在自定义资源的目录下后，即可作为自定义资源被容器编排器使用，以供后续服务对象的实例化。
71.需说明的是，日志抽象文件是根据日志采集行为抽象得到的，包括有备份软件的信息、备份类别，备份资源，其中，备份资源分别对应本地以及k8s api-resource资源。其中，备份软件和备份资源为日志抽象文件对应的自定义资源的必选参数。备份资源的确定方式可以通过配置文件或者直接参数的方式确定，对此，本发明实施例不做限制。
72.示例性的，参照图2所示，以k8s平台为例，在k8s平台上基于crd创建日志抽象文件loghavstdef.yaml，其中，“haevest”对应备份软件的信息，“watchpath”为日志监控目录的信息，用于监控采集日志的目录的变化状态，“configfile”为日志工具的配置信息，如日志路径等。“remoteserver”为待采集日志所在的服务器，可以设置一个或者多个；“netlimit”为日志工具的流量上限参数。其中，“haevest”、“watchpath”、“configfile”为日志抽象文件的必选参数，其余参数为可选参数。
73.示例性的，在另一些实施例中，日志抽象文件loghavstdef.yaml中的配置文件也可以替换为待采集的日志目录。优选的，本发明实施例采用配置文件的方式进行自定义资源的设置。
74.步骤s200、获取预设的日志采集通用参数以及预设的日志逻辑文件，其中，日志采集通用参数包括日志工具信息。
75.需说明的是，日志逻辑文件用于管理日志采集过程中的日志工具操作行为，如什么时候进行日志采集，哪些日志需要采集，或者流量限定等。
76.步骤s300、将日志采集通用参数作为日志抽象文件的参数，并根据日志抽象文件的参数创建日志服务对象。
77.需说明的是，以图2为例，在loghavstdef.yaml创建在集群上之后，便可以创建实际执行采集的服务loghavest，根据loghavstdef中预定支持的备份工具，制作支持的工具镜像，后续k8s将根据自定义资源的信息，在对应operator的控制下使用镜像创建服务容器，得到日志服务对象。示例性的，以图3为例，创建得到日志服务对象filebeat。
78.步骤s400、根据日志服务对象和日志逻辑文件，创建日志采集服务。
79.需说明的是，在根据备份逻辑编写日志逻辑文件loghavest-operator后，容器编排器的插件如operator会根据日志服务对象中的日志采集通用参数创建日志采集服务，使得日志采集服务能根据备份逻辑运行。
80.步骤s500、根据日志逻辑文件中的日志采集逻辑，通过日志采集服务调用日志工具信息对应的日志工具进行日志采集。
81.需说明的是，日志采集逻辑用于设定日志采集服务调用日志工具进行日志采集的
操作行为。
82.因此，通过将日志抽象文件作为自定义资源进行部署，进而可以将实际应用场景所需的日志工具等作为日志采集通用参数并结合日志抽象文件进行实例化，得到日志服务对象，同时通过自定义日志逻辑文件管理日志服务对象的操作，实现日志采集服务与日志工具和部署的解耦。此时，当应用场景或者采集工具发生变化时，仅需调整采集通用参数以及日志采集逻辑即可实现日志采集服务的创建，日志采集服务的部署更为简单和通用化且能满足不同采集需求的设置，因此，本发明实施例的日志自动采集的方法、设备及存储介质，能适配多种应用场景的日志采集需求且能快速部署。
83.需说明的是，日志采集服务和日志服务对象是一一对应的，在一些实施例中，会实例化多个日志服务对象，多个日志服务对象可以共享同一日志采集逻辑，也可以分别设定一一对应的日志采集逻辑，本领域技术人员可以根据实际的需求，进行任意组合和设置，对此，本发明实施例不做限制。
84.可理解的是，日志采集通用参数包括配置文件，配置文件用于存储采集目标，日志抽象文件包括目标服务器。
85.参照图4所示，步骤s500、根据日志逻辑文件中的日志采集逻辑，通过日志采集服务调用日志工具信息对应的日志工具进行日志采集，包括：
86.步骤s510、通过日志采集服务从日志服务对象中提取配置文件并从配置文件中确定第一日志采集目录。
87.需说明的是，通过配置文件的方式记录待采集文件的第一日志采集目录，进而可以在具有多个采集对象时，能更加高效的进行日志采集目录的管理。相对于直接在通用参数中输入日志路径的方式或采用通配符等直接输入采集路径的方式，采用配置文件的方式更加灵活且当待采集目录被更改时，可以无需重新创建日志采集服务即可实现新的日志采集。因此，通过这种方式，使得日志采集更加灵活，可以更好的适配更多的应用场景。
88.需说明的是，日志采集通用参数与日志抽象文件中输入参数的设置一一对应，日志采集通用参数中至少包括日志抽象文件中的必选参数，实际应用中，用户可以根据需要在日志采集通用参数中输入日志抽象文件中的可选参数的值进行个性化日志采集的设置，可选参数如图2所示的，网络流量上限，目标服务器等。
89.步骤s520、通过日志采集服务从日志服务对象中确定目标服务器。
90.需说明的是，日志服务对象时根据日志采集通用参数进行实例化得到，因此，在日志服务对象中能提取出目标服务器。
91.步骤s530、通过日志采集服务调用日志工具，采集目标服务器的第一日志采集目录下的日志文件。
92.需说明的是，对于同一个日志采集服务，目标服务器可以是多个或者是一个，对此，本发明实施例不做限制。示例性的，参照图3所示，在创建日志服务对象时，目标服务器设置有两个，分别为kafka01和kafka02，则在日志采集时，会分别从kafka01和kafka02的第一日志采集目录进行日志文件的采集。
93.可理解的是，日志采集通用参数还包括日志监控目录；参照图4所示，步骤s500、根据日志逻辑文件中的日志采集逻辑，通过日志采集服务调用日志工具信息对应的日志工具进行日志采集，还包括：
94.步骤s540、通过日志采集服务从日志服务对象中提取日志监控目录。
95.步骤s550、按照预设周期从日志监控目录提取第二日志采集目录。
96.需说明的是，日志监控目录周期性的获取，可以如以天或者月等为周期。在一些实施例中，还可以通过应用程序进行部署变更时，触发步骤s550进行主动日志监控目录的提取，并结合周期进行第二日志采集目录的提取，以确保日志监控目录下每一路径的变更均能被监测到。对此，本发明实施例不做限制。具体的，本领域技术人员可以根据实际的应用场景设置相关的规则。
97.步骤s560、将当前提取的第二日志采集目录与第一日志采集目录进行比较。
98.步骤s570、当第二日志采集目录相对于第一日志采集目录有新增路径，通过日志采集服务将新增路径添加至配置文件，使得第一日志采集目录被更新。
99.需说明的是，在一些实施例中，当第一日志采集目录中存在第二日志采集目录中没有的路径，则可以将该没有的路径在配置文件中删除，以提升对配置文件路径解析的效率。对此，本发明实施例不做限制，优选的，在本发明实施例中，仅对新增路径进行操作。
100.步骤s580、重启日志采集服务，使得日志工具根据配置文件中已更新的第一日志采集目录进行日志采集。
101.需说明的是，在日志采集服务重启后，再次运行日志采集服务时，日志采集服务会调用日志工具并重新读取配置文件中记录的第一日志采集目录，进而可以实现自动采集新增日志。
102.示例性的，以k8s和operator组合应用日志采集服务为例，operator根据loghavest01应用的配置文件首先取日志服务对象loghavest01的spec.configfile读取预先存在configmap中的filebeat配置文件harvest01.yaml,根据步骤s560中扫描到的日志路径更新harvest01.yaml中的log-path(在一些实施例中还会更新路径下对应的应用的标签)，然后在k8s上启动demonset类型的filebeat采集器应用，后续定时比对是否有新增采集路径，如有，按以上逻辑更新configmap并重启filebeat应用；减少经常手工维护采集目标的概率。
103.需说明的是，由于采用日志监控目录的方式进行采集目标的收集，因此，在构建k8s的时候或者接入的时候约定日志生成子目录模式为watchpath/[应用名：systemname]/根据watchpath下的应用名(此处是指k8s语境下的应用，对应集群上的某个deployment\statefulset等部署类型资源实例)，此时，能通过日志监控目录提取到systemname和日志路径，并将其存储在数据库中，并最终更新到配置文件中。
[0104]
可理解的是，s500、根据日志逻辑文件中的日志采集逻辑，通过日志采集服务调用日志工具信息对应的日志工具进行日志采集，还包括：当新增路径表示有新增的应用，通过日志采集服务将新增的应用添加至配置文件。
[0105]
需说明的是，在一些实施例中，由于容器编排器中部署的应用中应用模块会随着版本迭代进行新增，因此，对应应用的目录下会新增应用模块对应的路径，即有新增路径。在另一些实施例中，在容器编排器中部署有新增的应用，因此，会创建与该应用相关的目录。通过将应用记录在配置文件，能够使得日志采集时根据应用类别为单位进行日志的采集，实现日志的更优管理。
[0106]
可理解的是，通过日志采集服务将新增的应用添加至存储采集目标，包括；通过日
志采集服务从新增路径中提取出新增的应用的应用名称；将应用名称作为容器编排器的服务提取接口的参数，得到应用信息；通过日志采集服务将应用信息添加至配置文件。
[0107]
需说明的是，由于容器编排器能管理部署于其上的所有应用，因此，能通过容器编排器提取出应用信息。示例性的，以k8s为例，以应用名为参数请求k8s api-server获取应用数据，并提取应用数据对应的应用中间件类型，进而得到应用标签作为应用信息存储在配置文件中。
[0108]
可理解的是，在容器编排器中，因为efk要求日志模式(日志的格式)和efk配置的识别模式一致，因此上线前需要人工复核，保证模式识别成功。基于此，增加识别功能，当扫描接入采集时，先取部分日志和预先储存的识别模式匹配。因此，在进行日志采集之前，参照图5所示，方法还包括：
[0109]
步骤s610、通过日志采集服务调用日志工具，得到校验日志。
[0110]
需说明的是，校验日志时用于提取待采集文件的日志格式的，在进行日志采集之前，可以通过日志采集工具对每一应用下的路径下采集少量日志，进行格式校验。
[0111]
步骤s620、对校验日志进行模式解析，得到第一日志模式。
[0112]
步骤s630、将第一日志模式与容器编排器预设的第二日志模型进行比较。
[0113]
需说明的是，第二日志模式为efk默认支持的日志格式。
[0114]
步骤s640、将比较结果更新至日志服务对象的资源状态参数中，使得容器编排器根据资源状态参数监控日志服务对象的采集状态。
[0115]
需说明的是，通过将比较结果更新到资源状态参数中，后续便可以通过监控loghavest资源状态，实现自动检查。如，资源状态参数中显示不匹配，则表示第一日志模式和第二日志模式不匹配，此时可以通过比较结果中的第一日志模式和第二日志模式进行人工干预。
[0116]
可理解的是，在进行日志采集之后，方法还包括：统计日志采集占用的网络流量；将网络流量与预设的门限值进行比较；当网络流量大于门限值，按照预设的调整算法减少日志工具的并发量。
[0117]
需说明的是，并发量的多少会影响网络流量，因此，可以通过调整并发量进而改变日志采集时占用的流量。
[0118]
需说明的是，门限值的设置可以根据历史的流量占用情况实时估算一个具体的至进行设置。也可以简单设置为流量上限的某一百分比，对此，本发明实施例不做限制。
[0119]
示例性的，operator通过k8s的metrics server检查读取宿主机的网络流量，如果网络流量超过70％，则调整filebeat配置harvest01.yaml中的采集器并发数bulk_max_size,woker,来控制采集器的并发量，降低因日志流量影响应用的概率。
[0120]
本发明的方法可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计
算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
[0121]
下面，参照图1至图5，以k8s平台为例，日志采集的方法如下：
[0122]
operator监听loghavest01的创建，从中读取sepc.watchpath,和spec.configmap指定的filebeat01.yaml；定时扫描spec.watchpath下的目录(其中，watchpath目录为在构建k8s的时候或者接入的时候约定日志生成子目录模式，其具体的模式为watchpath/[应用名：systemname]/)。
[0123]
根据watchpath下的应用名(此处是指k8s语境下的应用，对应集群上的某个deployment\statefulset等部署类型资源实例)，提取systemname和日志路径，并将其存储在数据库中；并以应用名为参数请求k8s api-server获取应用数据，从应用数据中提取应用中间件类型，得到应用标签；operator根据loghavest01应用的配置文件首先取loghavest01的spec.configfile读取预先存在configmap中的filebeat配置文件harvest01.yaml,根据前述中扫描到的日志路径更新harvest01.yaml中的log-path，以及应用标签，然后在k8s上启动demonset类型的filebeat采集器应用，后续定时比对是否有新增采集路径，如有，按以上逻辑更新configmap并重启filebeat应用；降低经常手工维护采集目标的概率；同时，为保证efk要求日志模式(日志的格式)和efk配置的识别模式一致，降低人工复核的次数，在operator中增加识别功能，当扫描接入采集时，先取部分日志进行模式识别得到第一日志模式，并和预先储存的第二日志模式匹配，如果失败则operator更新loghavest01的unmach字段，后续便可以通过监控loghavest资源状态(对应unmach字段)，实现自动检查；进一步，operator通过k8s的metrics server检查读取宿主机的网络流量，如果网络流量超过70％，则调整filebeat配置harvest01.yaml中的采集器并发数bulk_max_size,woker,来控制日志工具中采集器的并发量，减少因日志流量影响应用本身的概率。
[0124]
因此，基于上述实施例中采用cdr+oprerator方式将备份服务托管给k8s集群，能实现日志工具自托管，同时采用k8s官方支持的平台插件开发模式，将日志采集服务与具体的日志采集工具和部署解耦，用户根据日志分析平台选择自己需要的工具与日志的内容和目的服务器即可，对用户能具有如下有益效果：1.减轻了使用成本和学习负担；2.对日志采集服务与具体实现进行了解耦，方便后续替换迁移；同时，对服务维护方具有如下有益效果:1，备份服务容器化，方便升级、迁移；2，一次构建，重复使用，降低维护成本；3.简单的日常运维操作，如故障重启，流量限速，维护采集对象等，可以由k8s自动完成；对平台，享受容器编排带来的低成本优势。
[0125]
第二方面，参照图6所示，根据本发明提供的一种具备日志自动采集功能的设备，包括：
[0126]
资源定义模块100，用于将预设的日志抽象文件作为自定义资源进行存储；
[0127]
获取模块200，用于获取预设的日志采集通用参数以及预设的日志逻辑文件，其中，日志采集通用参数包括日志工具；
[0128]
对象创建模块300，用于将日志采集通用参数作为日志抽象文件的参数，并根据日志抽象文件的参数创建日志服务对象；
[0129]
服务创建模块400，用于根据日志服务对象和日志逻辑文件，创建日志采集服务；
[0130]
运行模块500，用于根据日志逻辑文件中的日志采集逻辑，通过日志采集服务调用
日志工具信息对应的日志工具进行日志采集。
[0131]
需说明的是，在一些实施例中，具备日志自动采集功能的设备还包括采集目标维护模块600，采集目标维护模块600用于周期性从日志服务对象中设定的日志监控目录中进行日志采集路径的比较，以识别出该日志监控目录下是否有新增的文件路径，并将新增的文件路径保存在日志服务对象中用于存储采集目标路径的配置文件中。
[0132]
需说明的是，在一些实施例中，具备日志自动采集功能的设备还包括模式识别模块，模式识别模块用于对待采集的日志文件进行模式的自动识别，判断其格式是否与默认的日志框架中的格式一致，并将比较结果更新在日志服务对象中，进而可以在日志采集服务被自动托管时，托管平台能够通过实时监控该比较结果进行预警，提升日志部署的效率。
[0133]
需说明的是，在一些实施例中，具备日志自动采集功能的设备还包括流量监测模块，通过监测日志采集过程中占用的网络流量和预设的流量门限值进行比较，在超出流量门限值时，减少日志采集器的并发数，使得日志采集占用的网络流量降低。在当前网络流量远小于预设的流量门限值时，通过增大日志采集器的并发数，进而快速提升日志采集的下来。因此，通过根据比较结果进行当前网络流量的调整，在不影响应用正常运行的前提下，能使得带宽被充分使用。
[0134]
第三方面，根据本发明实施例提供的一种电子设备，包括：
[0135]
至少一个处理器，以及，
[0136]
与至少一个处理器通信连接的存储器；其中，
[0137]
存储器存储有指令，指令被至少一个处理器执行，以使至少一个处理器执行指令时实现如本发明实施例上述实施例的日志自动采集的方法。
[0138]
需说明的是，由于第三方面的电子设备执行第一方面日志自动采集的方法中的步骤，因此，具有第一方面的所有有益效果。
[0139]
下面结合图7对计算机设备的硬件结构进行详细说明。该电子设备包括：处理器710、存储器720、输入/输出接口730、通信接口740和总线750。
[0140]
处理器710，可以采用通用的cpu(central processin unit，中央处理器)、微处理器、应用专用集成电路(application specific integrated circuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本公开实施例所提供的技术方案；
[0141]
存储器720，可以采用rom(read only memory，只读存储器)、静态存储设备、动态存储设备或者ram(random access memory，随机存取存储器)等形式实现。存储器720可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器720中，并由处理器710来调用执行本公开实施例的模型的训练方法；
[0142]
输入/输出接口730，用于实现信息输入及输出；
[0143]
通信接口740，用于实现本设备与其他设备的通信交互，可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信；和总线750，在设备的各个组件(例如处理器710、存储器720、输入/输出接口730和通信接口740)之间传输信息；
[0144]
其中，处理器710、存储器720、输入/输出接口730和通信接口740通过总线750实现彼此之间在设备内部的通信连接。
可以表示：只存在a，只存在b以及同时存在a和b三种情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
[0154]
以上是对本发明的较佳实施进行了具体说明，但本发明并不局限于上述实施方式，熟悉本领域的技术人员在不违背本发明精神的前提下还可作出种种的等同变形或替换，这些等同的变形或替换均包含在本发明权利要求所限定的范围内。