概述

对于容器日志

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[1]。然而上述配置的日志收集也是通过Docker Daemon收集，收集日志的速度仍然是瓶颈。

log-driver 日志收集速度syslog 14.9 MB/sjson-file 37.9 MB/s

能不能找到不通过Docker Daemon收集日志间接将日志内容重定向到文件并主动rotate的工具呢？答案是必定的采纳S6[2]基底镜像。

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/reference/generated/kubectl/kubectl-commands#logs。

节点级别

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日志收集提供了一个简略的思路，对于日志收集能够依据公司的需要，就地取材。

写在最初

欢送大家关注我的公众号【惊涛骇浪如码】，海量Java相干文章，学习材料都会在外面更新，整顿的材料也会放在外面。

感觉写的还不错的就点个赞，加个关注呗！点关注，不迷路，继续更新！！！