kubernetes日志收集方案有几种方案,都适用于什么场景?本文对k8s常用日志采集方案做了详细介绍。
Docker的日志分为两类,一类是 Docker引擎日志;另一类是容器日志。
引擎日志一般都交给了系统日志,不同的操作系统会放在不同的位置。本文主要介绍容器日志,容器日志可以理解是运行在容器内部的应用输出的日志,默认情况下,docker logs 显示当前运行的容器的日志信息,内容包含 STOUT(标准输出) 和 STDERR(标准错误输出)。日志都会以 json-file 的格式存储于 /var/lib/docker/containers/<容器id>/<容器id>-json.log ,不过这种方式并不适合放到生产环境中。
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-log 将 CMD 的标准输出重定向到/.../default/current,而不是发送到 Docker Daemon,这样就避免了 Docker Daemon 收集日志的性能瓶颈。本文就是采用基底镜像构建应用镜像形成统一日志收集方案。
k8s日志收集方案分成三个级别:
Pod级别的日志 , 默认是输出到标准输出和标志输入,实际上跟docker 容器的一致。使用
kubectl logs pod-name -n namespace
查看。
Node级别的日志 , 通过配置容器的log-driver来进行管理 , 这种需要配合logrotare来进行 , 日志超过最大限制 , 自动进行rotate操作。
集群级别的日志收集 , 有三种
节点代理方式,在node级别进行日志收集。一般使用DaemonSet部署在每个node中。这种方式优点是耗费资源少,因为只需部署在节点,且对应用无侵入。缺点是只适合容器内应用日志必须都是标准输出。
使用sidecar container作为容器日志代理,也就是在pod中跟随应用容器起一个日志处理容器,有两种形式:
通过上文对k8s日志收集方案的介绍,要想设计一个统一的日志收集系统,可以采用节点代理方式收集每个节点上容器的日志,日志的整体架构如图所示。
解释如下:
整个流程很好理解,但是需要解决的是
解决上述问题,就需要开发一个log-agent应用以daemonset形式运行在k8s集群的每个节点上,应用内部包含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
}
本文只是对k8s日志收集提供了一个简单的思路,关于日志收集可以根据公司的需求,因地制宜。