Kubernetes日志收集的那些套路

标签: kubernetes 日志 套路 | 发表时间:2021-04-05 05:03 | 作者:老马
出处:http://weekly.dockone.io

准备

关于容器日志

Docker的日志分为两类,一类是Docker引擎日志;另一类是容器日志。引擎日志一般都交给了系统日志,不同的操作系统会放在不同的位置。本文主要介绍容器日志,容器日志可以理解是运行在容器内部的应用输出的日志,默认情况下,docker logs显示当前运行的容器的日志信息,内容包含 STOUT(标准输出)和STDERR(标准错误输出)。日志都会以json-file的格式存储于 /var/lib/docker/containers/<容器id>/<容器id>-json.log,不过这种方式并不适合放到生产环境中。
  • 默认方式下容器日志并不会限制日志文件的大小,容器会一直写日志,导致磁盘爆满,影响系统应用。(docker log-driver支持log文件的rotate)
  • Docker Daemon收集容器的标准输出,当日志量过大时会导致Docker Daemon成为日志收集的瓶颈,日志的收集速度受限。
  • 日志文件量过大时,利用docker logs -f查看时会直接将Docker Daemon阻塞住,造成docker ps等命令也不响应。


Docker提供了logging drivers配置,用户可以根据自己的需求去配置不同的log-driver,可参考官网 Configure logging drivers。但是上述配置的日志收集也是通过Docker Daemon收集,收集日志的速度依然是瓶颈。


log-driver 日志收集速度

syslog 14.9 MB/s

json-file 37.9 MB/s
能不能找到不通过Docker Daemon收集日志直接将日志内容重定向到文件并自动rotate的工具呢?答案是肯定的采用 S6基底镜像。

S6-log将CMD的标准输出重定向到/.../default/current,而不是发送到 Docker Daemon,这样就避免了Docker Daemon收集日志的性能瓶颈。本文就是采用 S6基底镜像构建应用镜像形成统一日志收集方案。

关于Kubernetes日志

Kubernetes日志收集方案分成三个级别:

应用(Pod)级别

Pod级别的日志,默认是输出到标准输出和标志输入,实际上跟Docker容器的一致。使用kubectl logs pod-name -n namespace查看,具体参考: https://kubernetes.io/docs/ref ... 3logs

节点级别

Node级别的日志 , 通过配置容器的 log-driver来进行管理,这种需要配合 logrotare来进行,日志超过最大限制,自动进行rotate操作。

集群级别

集群级别的日志收集,有三种。

节点代理方式,在Node级别进行日志收集。一般使用DaemonSet部署在每个Node中。这种方式优点是耗费资源少,因为只需部署在节点,且对应用无侵入。缺点是只适合容器内应用日志必须都是标准输出。

使用 sidecar container作为容器日志代理,也就是在Pod中跟随应用容器起一个日志处理容器,有两种形式:

一种是直接将应用容器的日志收集并输出到标准输出(叫做 Streaming sidecar container),但需要注意的是,这时候,宿主机上实际上会存在两份相同的日志文件:一份是应用自己写入的;另一份则是sidecar的stdout和stderr对应的JSON文件。这对磁盘是很大的浪费,所以说,除非万不得已或者应用容器完全不可能被修改。

另一种是每一个Pod中都起一个 日志收集agent(比如Logstash或Fluebtd)也就是相当于把方案一里的logging agent放在了Pod里。但是这种方案资源消耗(CPU,内存)较大,并且日志不会输出到标准输出,kubectl logs会看不到日志内容。

应用容器中直接将日志推到存储后端,这种方式就比较简单了,直接在应用里面将日志内容发送到日志收集服务后端。

日志架构

通过上文对Kubernetes日志收集方案的介绍,要想设计一个统一的日志收集系统,可以采用 节点代理方式收集每个节点上容器的日志,日志的整体架构如图所示:

解释如下:
  1. 所有应用容器都是基于S6基底镜像的,容器应用日志都会重定向到宿主机的某个目录文件下比如/data/logs/namespace/appname/podname/log/xxxx.log
  2. log-agent内部包含 Filebeat,Logrotate等工具,其中Filebeat是作为日志文件收集的agent
  3. 通过Filebeat将收集的日志发送到Kafka
  4. Kafka在讲日志发送的ES日志存储/kibana检索层
  5. Logstash作为中间工具主要用来在ES中创建index和消费Kafka的消息


整个流程很好理解,但是需要解决的是:
  1. 用户部署的新应用,如何动态更新Filebeat配置
  2. 如何保证每个日志文件都被正常的rotate
  3. 如果需要更多的功能则需要二次开发Filebeat,使Filebeat支持更多的自定义配置


付诸实践

解决上述问题,就需要开发一个log-agent应用以DaemonSet形式运行在Kubernetes集群的每个节点上,应用内部包含Filebeat,Logrotate和需要开发的功能组件。

第一个问题,如何动态更新Filebeat配置,可以利用 http://github.com/fsnotify/fsnotify工具包监听日志目录变化create、delete事件,利用模板渲染的方法更新Filebeat配置文件。

第二个问题,利用 http://github.com/robfig/cron工具包创建CronJob,定期rotate日志文件,注意应用日志文件所属用户,如果不是root用户所属,可以在配置中设置切换用户。
/var/log/xxxx/xxxxx.log {  
  su www-data www-data
  missingok
  notifempty
  size 1G
  copytruncate


第三个问题,关于二次开发filebeat,可以参考博文: https://www.jianshu.com/p/fe3ac68f4a7a

总结

本文只是对Kubernetes日志收集提供了一个简单的思路,关于日志收集可以根据公司的需求,因地制宜。

参考文献:


原文链接: https://zhuanlan.zhihu.com/p/70662744

相关 [kubernetes 日志 套路] 推荐:

Kubernetes日志收集的那些套路

- - DockOne.io
Docker的日志分为两类,一类是Docker引擎日志;另一类是容器日志. 引擎日志一般都交给了系统日志,不同的操作系统会放在不同的位置. 本文主要介绍容器日志,容器日志可以理解是运行在容器内部的应用输出的日志,默认情况下,docker logs显示当前运行的容器的日志信息,内容包含 STOUT(标准输出)和STDERR(标准错误输出).

Kubernetes 日志收集方案

- - IT瘾-dev
Kubernetes 中的基本日志. Kubernetes 日志收集. 以 sidecar 容器收集日志. 用 sidecar 容器重新输出日志. 使用 sidecar 运行日志采集 agent. 前面的课程中和大家一起学习了 Kubernetes 集群中监控系统的搭建,除了对集群的监控报警之外,还有一项运维工作是非常重要的,那就是日志的收集.

Kubernetes & Microservice

- - 午夜咖啡
这是前一段时间在一个微服务的 meetup 上的分享,整理成文章发布出来. 谈微服务之前,先澄清一下概念. 微服务这个词的准确定义很难,不同的人有不同的人的看法. 比如一个朋友是『微服务原教旨主义者』,坚持微服务一定是无状态的 http API 服务,其他的都是『邪魔歪道』,它和 SOA,RPC,分布式系统之间有明显的分界.

使用filebeat收集kubernetes中的应用日志 - 宋净超的博客|Cloud Native|云原生布道师

- -
本文已同步更新到Github仓库. kubernetes-handbook中. 使用Logstash收集Kubernetes的应用日志,发现logstash十分消耗内存(大约500M),经人提醒改用filebeat(大约消耗10几M内存),因此重写一篇使用filebeat收集kubernetes中的应用日志.

kubernetes移除Docker?

- -
两周前,Kubernetes在其最新的Changelog中宣布1.20之后将要弃用dockershime,也就说Kubernetes将不再使用Docker做为其容器运行时. 这一消息持续发酵,掀起了不小的波澜,毕竟Kubernetes+Docker的经典组合是被市场所认可的,大量企业都在使用. 看上去这个“弃用”的决定有点无厘头,那么为什么Kubernetes会做出这样的决定.

Kubernetes 完全教程

- - 午夜咖啡
经过一个阶段的准备,视频版本的 《Kubernetes 完全教程》出炉了. 课程一共分为七节,另外有一节 Docker 预备课,每节课大约一个多小时. 目标是让从没接触过 Kubernetes 的同学也能通过这个课程掌握 Kubernetes. 为什么要学习 Kubernetes. 在介绍课程之前,先说说为什么要学习 Kubernetes 以及什么人需要学习 Kubernetes.

Kubernetes 监控详解

- - DockOne.io
【编者的话】监控 Kubernetes 并不是件容易的事. 本文介绍了监控 Kubernetes 的难点、用例以及有关工具,希望可以帮助大家进一步了解监控 Kubernetes. 如果想要监控 Kubernetes,包括基础架构平台和正在运行的工作负载,传统的监控工具和流程可能还不够用. 就目前而言,监控 Kubernetes 并不是件容易的事.

喜大普奔:Spark on kubernetes

- - Zlatan Eevee
两个星期前(08/15/2017),spark社区提了一个新的SPIP(Spark Project Improvement Proposals): Spark on Kubernetes: Kubernetes as A Native Cluster Manager,即用k8s管理spark集群. 经过社区2个星期的投票,看上去很快要能合入了.

Kubernetes 会不会“杀死” DevOps?

- - InfoQ推荐
DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile). 传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求.

轻量级Kubernetes k3s初探

- - InfoQ推荐
1 k3s简介–5 less than K8s. k3s [1] 是rancher®开源的一个Kubernetes发行版,从名字上就可以看出k3s相对k8s做了很多裁剪和优化,二进制程序不足50MB,占用资源更少,只需要512MB内存即可运行. 而之所以称为k3s是因为相对k8s裁剪了如下5个部分:.