一种容器云日志收集资源控制方法及系统与流程

文档序号:27338266发布日期:2021-11-10 02:36阅读:92来源:国知局
一种容器云日志收集资源控制方法及系统与流程

1.本发明属于云计算领域,尤其涉及一种容器云日志收集资源控制方法及系统。


背景技术:

2.本部分的陈述仅仅是提供了与本发明相关的背景技术信息,不必然构成在先技术。
3.随着云计算的普及,为了快速解决应用中出现各种问题,日志分析成为了必不可少的主要手段,日志收集、存储和检索则成为了关键技术。传统日志处理的方式是日志写到本机磁盘上,通常仅用于排查线上问题,很少用于数据分析,需要时登录到机器上用命令行查看。容器及部署在其中的应用日志,尤其是使用过容器编排系统的容器,日志在哪台机器的哪个容器,一个应用多个容器实例时业务发生在哪个容器应用上,都不能确定,这无疑加大了日志分析的困难。
4.为此业界基于容器云的事实标准开源项目kubernetes(以下简称k8s),研发出相关的解决方案和技术。目前容器日志有两种输出形式,stdout和stderr标准输出和日志文件记录。kubernetes不做容器日志收集工作,但提供了三种相关方案:第一种是守护程序(daemonset)方式,第二种是边车(sidecar)方式,第三种是一种混合模式采用第二种方式,将应用日志拷贝到节点目录下,然后再由第一种方式收集,这会出现节点存储两份日志的情况。
5.在第二种边车(sidecar)方式中:一个pod中运行一个sidecar容器,用于采集该pod主容器产生的日志,sidecar优先于主容器启动,适用于应用日志的收集,不侵入应用所在容器,但侵入应用所在pod。第三种原生方式:使用kubectl logs直接在查看本地保留的日志,或者通过容器引擎的log driver把日志重定向到文件、syslog、fluentd等系统中,需要直接侵入应用容器。其中,pod是一个或一个以上的容器(例如docker容器)组成的,且具有共享存储/网络/uts/pid的能力,以及运行容器的规范。并且在kubernetes中,pod是最小的可被调度的原子单位。
6.发明人发现,虽然第二种sidecar模式是业界标准方案,但如果多个sidecar容器满负荷并发工作,就会出现资源消耗过大的问题,严重占用节点资源,影响主容器业务,甚至导致容器崩溃的严重后果。


技术实现要素:

7.为了解决上述背景技术中存在的容器云边车模式下,应用日志的收集资源消耗大的技术问题,本发明提供一种容器云日志收集资源控制方法及系统,其能够充分降低日志功能对机器资源的消耗,并兼顾日志收集的时效性。
8.为了实现上述目的,本发明采用如下技术方案:
9.本发明的第一个方面提供一种容器云日志收集资源控制方法,其包括:
10.配置日志容器的扫描频率、日志优先级及流量控制阈值;
11.根据配置的日志优先级来初始化日志容器的限定资源,由日志容器引擎来控制日志容器运行时的资源上限;
12.基于配置的扫描频率来扫描日志容器内的日志文件;
13.监控日志容器网络出口瞬时流量,并与流量控制阈值实时比较来调整日志容器的发送因子,根据发送因子来调控发送的每包字节数和发送速度。
14.进一步地,日志容器的扫描频率、日志优先级及流量控制阈值这三个配置项存放在etcd服务中。
15.进一步地,日志容器的扫描频率配置项的配置单位秒。
16.进一步地,当日志容器的扫描频率配置项配置0s为准实时,不做频率控制。
17.进一步地,当日志容器的日志优先级配置项配置0为不设定优先级,不参与优先级控制。
18.进一步地,日志容器的流量控制阈值配置项的配置单位mb/秒。
19.进一步地,在基于配置的扫描频率来扫描日志容器内的日志文件时采用令牌桶算法以控制日志输出流量控制。
20.本发明的第二个方面提供一种容器云日志收集资源控制系统,其包括:
21.参数配置模块,其用于配置日志容器的扫描频率、日志优先级及流量控制阈值;
22.优先级控制模块,其用于根据配置的日志优先级来初始化日志容器的限定资源,由日志容器引擎来控制日志容器运行时的资源上限;
23.日志扫描模块,其用于基于配置的扫描频率来扫描日志容器内的日志文件;
24.流量控制模块,其用于监控日志容器网络出口瞬时流量,并与流量控制阈值实时比较来调整日志容器的发送因子,根据发送因子来调控发送的每包字节数和发送速度。
25.本发明的第三个方面提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如上述所述的容器云日志收集资源控制方法中的步骤。
26.本发明的第四个方面提供一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如上述所述的容器云日志收集资源控制方法中的步骤。
27.与现有技术相比,本发明的有益效果是:
28.本发明将多应用容器日志输出量大时的资源消耗峰值进行有效的分摊,分摊到后续时间窗口,即整体提升了节点运行效率,又达到了保护主容器应用的持续运行的目的。
29.本发明附加方面的优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本发明的实践了解到。
附图说明
30.构成本发明的一部分的说明书附图用来提供对本发明的进一步理解,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。
31.图1是本发明实施例的边车模式图;
32.图2是本发明实施例的容器云日志收集资源控制逻辑流程图;
33.图3是本发明实施例的令牌桶算法。
具体实施方式
34.下面结合附图与实施例对本发明作进一步说明。
35.应该指出,以下详细说明都是例示性的,旨在对本发明提供进一步的说明。除非另有指明,本文使用的所有技术和科学术语具有与本发明所属技术领域的普通技术人员通常理解的相同含义。
36.需要注意的是,这里所使用的术语仅是为了描述具体实施方式,而非意图限制根据本发明的示例性实施方式。如在这里所使用的,除非上下文另外明确指出,否则单数形式也意图包括复数形式,此外,还应当理解的是,当在本说明书中使用术语“包含”和/或“包括”时,其指明存在特征、步骤、操作、器件、组件和/或它们的组合。
37.实施例一
38.根据背景技术可知,日志收集的边车方式,如图1所示,就是通过边车(sidecar)容器,直接读取应用的日志文件发送到远程存储里面去的方案。也就是将日志代理放到应用所在的pod中,而不是节点上。这种方式下,当应用容器部署到k8s上时,业务容器将日志写在一个volume里面,如/var/logs目录下。而由于volume在pod里面是被共享的,所以边车容器(日志容器)一定可以通过共享该volume,直接把日志文件读出来,然后通过fluentd日志组件转发到集中的elasticsearch存储中,然后建立索引,方便后续检索。该方案的优点是不会对应用容器有侵入性,而且不要求应用日志模块进行改造。既适用于大部分容器应用日志场景,又可以灵活的进行sidecar容器的管理。这种方案部署简单,多租户隔离性较强,对宿主机也非常友好,所以成为一种主要的日志收集方案。日志收集的边车方式的缺点是这种方式并不适合节点上多个应用容器持续产生大量日志记录的场景。例如,多个sidecar容器满负荷并发工作,就会出现资源消耗过大的问题,严重占用节点资源(内存和网络),影响主容器业务,甚至会拖垮整个pod。
39.如图2所示,为了解决上述问题,本实施例提供了一种容器云日志收集资源控制方法,其具体包括如下步骤:
40.步骤1:配置日志容器的扫描频率、日志优先级及流量控制阈值。
41.由边车模式的设计原理得知,边车容器本身运行不会产生过大的cpu,内存和网络消耗,而频繁的日志扫描和日志读取,日志满负荷发送才会产生大量资源消耗。所以新方案沿用每个pod里存在一个日志代理的设计,但增加一套新的控制模块,在日志扫描频率,日志读取和发送的流控和优先级这三个关键点上,进行预先配置,期望达到运行时根据配置动态调控日志收集的节奏的目标。
42.在具体实施中,在日志容器的创建时,增加三个配置项扫描频率、日志优先级及流量控制阈值,分别表示为scanningfrequency,logsendingpriority,logflowcontrol,这三个配置项存放在etcd服务中。
43.其中,etcd是一个分布式、可靠的key

value存储的分布式系统,用于存储分布式系统中的关键数据;它不仅仅用于存储,还提供配置共享及服务发现;基于go语言实现。
44.scanningfrequency:日志容器的扫描频率配置项的配置单位秒。如10s,每10s扫描一次。
45.当日志容器的扫描频率配置项配置0s为准实时,不做频率控制。
46.logsendingpriority:
47.例如:日志容器的日志优先级分为0

10等级,1优先级最高,10优先级最低。当日志容器的日志优先级配置项配置0为不设定优先级,不参与优先级控制。
48.需要说明的是,本领域技术人员可根据实际情况来具体设置日志优先级。
49.logflowcontrol:日志容器的流量控制阈值配置项的配置单位mb/秒。如配置30mb/秒,低于此值不做限流,配置0为不做流控。
50.步骤2:根据配置的日志优先级来初始化日志容器的限定资源,由日志容器引擎来控制日志容器运行时的资源上限。
51.步骤3:基于配置的扫描频率来扫描日志容器内的日志文件。
52.在具体实施中,在基于配置的扫描频率来扫描日志容器内的日志文件时采用令牌桶算法以控制日志输出流量控制。
53.如图3所示,令牌桶算法(token bucket):
54.随着时间流逝,系统会按恒定1/qps时间间隔(如果qps=100,则间隔是10ms)往桶里加入token,如果桶已经满了就不再加了。新请求来临时,会各自拿走一个token,如果没有token可拿了就阻塞或者拒绝服务。令牌桶的另外一个好处是可以方便的改变速度。一旦需要提高速率,则按需提高放入桶中的令牌的速率。一般会定时(比如100毫秒)往桶中增加一定数量的令牌,有些变种算法则实时的计算应该增加的令牌的数量。
55.步骤4:监控日志容器网络出口瞬时流量,并与流量控制阈值实时比较来调整日志容器的发送因子,根据发送因子来调控发送的每包字节数和发送速度。
56.为了调整在日志容器中的fluentd的采集的精细化控制,上述步骤在fluentd的采集插件中实现。
57.本实施例的该方法降低了容器云日志收集资源消耗,解决了容器云边车模式下,应用日志的收集资源消耗大的问题,充分降低了日志功能对机器资源的消耗,并兼顾日志收集的时效性。
58.本实施例主要涉及在边车模式下,日志采集时增加一套资源控制机制,通过日志扫描频率,日志读取和发送的流控和优先级这三个关键点进行控制;本实施例充分利用了容器云原有的资源隔离和限制,容器流量监控,容器定时器(job)等底层技术做支撑,最精简的实现了一套完整的资源控制机制。
59.实施例二
60.本实施例提供了一种容器云日志收集资源控制系统,其具体包括如下模块:
61.参数配置模块,其用于配置日志容器的扫描频率、日志优先级及流量控制阈值;
62.优先级控制模块,其用于根据配置的日志优先级来初始化日志容器的限定资源,由日志容器引擎来控制日志容器运行时的资源上限;
63.日志扫描模块,其用于基于配置的扫描频率来扫描日志容器内的日志文件;
64.流量控制模块,其用于监控日志容器网络出口瞬时流量,并与流量控制阈值实时比较来调整日志容器的发送因子,根据发送因子来调控发送的每包字节数和发送速度。
65.此处需要说明的是,本实施例的各个模块,与实施例一中的各个步骤一一对应,其具体实施过程相同,此处不再累述。
66.实施例三
67.本实施例提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处
理器执行时实现如上述所述的容器云日志收集资源控制方法中的步骤。
68.实施例四
69.本实施例提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如上述所述的容器云日志收集资源控制方法中的步骤。
70.本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
71.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
72.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
73.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
74.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(read

only memory,rom)或随机存储记忆体(random accessmemory,ram)等。
75.以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1