本发明专利技术涉及云计算领域,具体提供了一种应用日志收集与管理方法,应用于云原生场景下部署在Kubernetes集群中基于sidecar容器的应用日志收集与管理,具有如下步骤:S1、在应用中按照指定标准,将日志分别输出到特定的文件中,可将文件路径可设定为应用Pod上挂载的内存类型的临时目录上;S2、使用kubectl logs查看应用pod日志,通过一个sidecar容器把这些日志文件重新输出到sidecar的stdout和stderr上;S3、通过一个sidecar容器来运行一个logging agent,把应用的日志文件发送到远程存储里。与现有技术相比,本发明专利技术可以用cluster
【技术实现步骤摘要】
一种应用日志收集与管理方法及系统
[0001]本专利技术涉及云计算领域,具体提供一种应用日志收集与管理方法及系统。
技术介绍
[0002]上云成为企业持续发展的必然选择,全面使用云服务构建软件服务的时代已经到来。云原生架构与传统架构相比较,从业务代码中剥离了大量非功能性特性到Iaas和Paas中,从而减少业务代码开发人员的技术关注范围,通过云服务提升应用的非功能性能力。
[0003]Kubernetes集群中对Pod及其容器日志的处理系统,与容器、Pod以及Node的生命周期应该是完全解耦的。这种设计保证了无论是容器异常、Pod被删除或驱逐,甚至集群节点宕机的时候,应用的日志依然可以被正常获取到。但Kubernetes本身,实际上是不会为用户做容器日志收集工作的,所以为了实现上述cluster
‑
level
‑
logging,用户需要在部署集群的时候,提前对具体的日志方案进行规划。
技术实现思路
[0004]本专利技术是针对上述现有技术的不足,提供一种实用性强的应用日志收集与管理方法。
[0005]本专利技术进一步的技术任务是提供一种设计合理,安全适用的应用日志收集与管理装置。
[0006]本专利技术解决其技术问题所采用的技术方案是:
[0007]一种应用日志收集与管理方法,应用于云原生场景下部署在Kubernetes集群中基于sidecar容器的应用日志收集与管理,具有如下步骤:
[0008]S1、在应用中按照指定标准,将日志分别输出到特定的文件中,可将文件路径可设定为应用Pod上挂载的内存类型的临时目录上;
[0009]S2、使用kubectl logs查看应用pod日志,通过一个sidecar容器把这些日志文件重新输出到sidecar的stdout和stderr上;
[0010]S3、通过一个sidecar容器来运行一个logging agent,把应用的日志文件发送到远程存储里。
[0011]进一步的,在步骤S1中,所述制定标准为Info和ERROR,count
‑
test容器为实际的应用容器,该容器中,将ERROR等级的日志输出到Pod上的挂载的临时卷上的ERROR.log文件中,将Info等级的日志输出到Pod上的挂载的临时卷上的Info.log文件中。
[0012]进一步的,在步骤S2中,临时卷生命周期与Pod相同,当Pod被删除时,该临时卷也会被清除,采用内存类型的临时目录,消耗Pod内存资源配额。
[0013]进一步的,容器count
‑
test
‑
log
‑
1和count
‑
test
‑
log
‑
2分别将存储了Error级别日志的ERROR.log文件及存储了Info级别日志的INFO.log文件内容重新以stdout和stderr的方式输出出来,用户使用kubectl logs命令查看应用日志。
[0014]进一步的,在步骤S3中,容器count
‑
test
‑
agent直接把应用的日志文件发送到远
程存储里面去,对应的配置文件fluentd
‑
config以ConfigMap的形式挂载到Pod中供容器使用。
[0015]一种应用日志收集与管理装置,应用于云原生场景下部署在Kubernetes集群中基于sidecar容器的应用日志收集与管理;
[0016]首先在应用中按照指定标准,将日志分别输出到特定的文件中,可将文件路径可设定为应用Pod上挂载的内存类型的临时目录上;
[0017]同时,如果仍想使用kubectl logs查看应用pod日志,可以通过一个sidecar容器把这些日志文件重新输出到sidecar的stdout和stderr上;
[0018]最后实现应用的cluster
‑
level
‑
logging,通过一个sidecar容器来运行一个logging agent,把应用的日志文件发送到远程存储里。
[0019]进一步的,所述制定标准为Info和ERROR,count
‑
test容器为实际的应用容器,该容器中,将ERROR等级的日志输出到Pod上的挂载的临时卷上的ERROR.log文件中,将Info等级的日志输出到Pod上的挂载的临时卷上的Info.log文件中。
[0020]进一步的,临时卷生命周期与Pod相同,当Pod被删除时,该临时卷也会被清除,采用内存类型的临时目录,消耗Pod内存资源配额。
[0021]进一步的,容器count
‑
test
‑
log
‑
1和count
‑
test
‑
log
‑
2分别将存储了Error级别日志的ERROR.log文件及存储了Info级别日志的INFO.log文件内容重新以stdout和stderr的方式输出出来,用户使用kubectl logs命令查看应用日志。
[0022]进一步的,容器count
‑
test
‑
agent直接把应用的日志文件发送到远程存储里面去,对应的配置文件fluentd
‑
config以ConfigMap的形式挂载到Pod中供容器使用。
[0023]本专利技术的一种应用日志收集与管理方法及系统和现有技术相比,具有以下突出的有益效果:
[0024]本专利技术可以用cluster
‑
level
‑
logging的方式收集与管理在k8s集群上运行的指定应用的日志,具有部署简单,灵活性高的优点。
附图说明
[0025]为了更清楚地说明本专利技术实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本专利技术的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
[0026]附图1是一种应用日志收集与管理方法的流程示意图。
具体实施方式
[0027]为了使本
的人员更好的理解本专利技术的方案,下面结合具体的实施方式对本专利技术作进一步的详细说明。显然,所描述的实施例仅仅是本专利技术一部分实施例,而不是全部的实施例。基于本专利技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例都属于本专利技术保护的范围。
[0028]下面给出一个最佳实施例:
[0029]如图1所示,本实施例中的一种应用日志收集与管理方法,具有如下步骤:
[0030]S1、在应用中按照指定标准(如Info,ERROR等),将日志分别输出到特定的文件中,为了拥有更好的性能,可将文件路径可设本文档来自技高网...
【技术保护点】
【技术特征摘要】
1.一种应用日志收集与管理方法,其特征在于,应用于云原生场景下部署在Kubernetes集群中基于sidecar容器的应用日志收集与管理,具有如下步骤:S1、在应用中按照指定标准,将日志分别输出到特定的文件中,可将文件路径可设定为应用Pod上挂载的内存类型的临时目录上;S2、使用kubectl logs查看应用pod日志,通过一个sidecar容器把这些日志文件重新输出到sidecar的stdout和stderr上;S3、通过一个sidecar容器来运行一个logging agent,把应用的日志文件发送到远程存储里。2.根据权利要求1所述的一种应用日志收集与管理方法,其特征在于,在步骤S1中,所述制定标准为Info和ERROR,count
‑
test容器为实际的应用容器,该容器中,将ERROR等级的日志输出到Pod上的挂载的临时卷上的ERROR.log文件中,将Info等级的日志输出到Pod上的挂载的临时卷上的Info.log文件中。3.根据权利要求2所述的一种应用日志收集与管理方法,其特征在于,在步骤S2中,临时卷生命周期与Pod相同,当Pod被删除时,该临时卷也会被清除,采用内存类型的临时目录,消耗Pod内存资源配额。4.根据权利要求3所述的一种应用日志收集与管理方法,其特征在于,容器count
‑
test
‑
log
‑
1和count
‑
test
‑
log
‑
2分别将存储了Error级别日志的ERROR.log文件及存储了Info级别日志的INFO.log文件内容重新以stdout和stderr的方式输出出来,用户使用kubectl logs命令查看应用日志。5.根据权利要求4所述的一种应用日志收集与管理方法,其特征在于,在步骤S3中,容器count
‑
test
‑
agent直接把应用的日志文件发送到远程存储里面去,对应的配置文件fluentd
‑
config以ConfigMap的形式挂载到Pod中供容器使用。6.一种应用日志收集与管理装置,其特征在于,应...
【专利技术属性】
技术研发人员:孔令航,徐军,张东海,王刚,
申请(专利权)人:浪潮云信息技术股份公司,
类型:发明
国别省市:
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。