2023年6月30日发(作者：)

关于k8s集群容器⽇志收集的总结容器⽇志存在形式⽬前容器⽇志有两种输出形式：1、 stdout,stderr标准输出这种形式的⽇志输出我们可以直接使⽤docker logs查看⽇志，k8s集群中同样集 群可以使⽤kubectl logs类似的形式查看⽇志。2、⽇志⽂件记录这种⽇志输出我们⽆法从以上⽅法查看⽇志内容，只能tail⽇志⽂件查看。在k8s官⽅⽂档中，对于以上两种形式的⽇志形式我们如果想收集并分析⽇志的话，官⽅推荐以下两种对策：对于第⼀种⽂档中这样说：When a cluster is created, the standard output and standard error output of each container can be ingested using aFluentd agent running on each node into either Google Cloud Logging or into Elasticsearch and viewed with a Kubernetes cluster is created with logging to Google Cloud Logging enabled, the system creates a pod calledfluentd-cloud-logging on each node of the cluster to collect Docker container logs. These pods were shown at the startof this blog article in the response to the first get pods command.就说说集群启动时会在每个机器启动⼀个Fluentd agent收集⽇志然后发送给Elasticsearch。

实现⽅式是每个agent挂载⽬录/var/lib/docker/containers使⽤fluentd的tail插件扫描每个容器⽇志⽂件，直接发送给Elasticsearch。对于第⼆种：1. A second container, using the /google_containers/fluentd-sidecar-es:1.2 image to send the logs toElasticsearch. We recommend attaching resource constraints of 100m CPU and 200Mi memory to this container,as in the example.2. A volume for the two containers to share. The emptyDir volume type is a good choice for this because we onlywant the volume to exist for the lifetime of the pod.3. Mount paths for the volume in each container. In your primary container, this should be the path that theapplications log files are written to. In the secondary container, this can be just about anything, so we put it under/mnt/log to keep it out of the way of the rest of the filesystem.4. The FILES_TO_COLLECT environment variable in the sidecar container, telling it which files to collect logs paths should always be in the mounted volume.其实跟第⼀种类似，但是是把Fluentd agent起在业务同⼀个pod中共享volume然后实现对⽇志⽂件的收集发送给Elasticsearchfluentd分析对于fluentd官⽅对其的定义是：统⼀⽇志层Fluentd通过在后端系统之间提供统⼀的⽇志记录层来从后端系统中解耦数据源。此层允许开发⼈员和数据分析⼈员在⽣成⽇志时使⽤多种类型的⽇志。统⼀的⽇志记录层可以让您和您的组织更好地使⽤数据，并更快地在您的软件上进⾏迭代。也就是说fluentd是⼀个⾯向多种数据来源以及⾯向多种数据出⼝的⽇志收集器。另外它附带了⽇志转发的功能。fluentd特点1. 部署简单灵活2. 开源3. 经过验证的可靠性和性能4. 社区⽀持，插件较多5. 使⽤json格式事件格式6. 可拔插的架构设计7. 低资源要求8. 内置⾼可靠性fluentd与Logstash引⽤⼀张图对⽐这两个⽇志收集⼯具。具体它们两个项⽬的对⽐请参考：fluentd与zeroMQ把这两个产品放在⼀起⽐较实属不怎么合适，因为它们属于不同的阵营，完成不同的功能需求。由于fluentd具有消息转发的功能，姑且将其与以zeroMQ为例的消息中间件的关系做个说明：在⼤型系统架构中，有使⽤zeroMQ进⾏⼤量的⽇志转发⼯作。在fluentd中有两个项⽬完成⽇志的中转路由的任务：golang编写的：和c写的那么是否意味着你需要做出选择呢？其实不然。着眼fluentd的定义和zeroMQ的定义。其实它们是⼀种合作关系。如果你是⼤型的架构系统，⽇志量很庞⼤。我推荐你使⽤fluentd进⾏⽇志收集，将zeroMQ作为fluentd的出⼝。就是说fluentd完成统⼀收集，zeroMQ完成⽇志传输。如果你的系统并不庞⼤，你就⽆需zeroMQ来传输了。因此你也⽆需关注这两个产品的性能⽐较。虽然它们都有⾼性能的定义。zeroMQ的性能测试结果：容器⽇志收集总结如上所描述的⼀样，⽆论你的业务容器⽇志呈现⽅式有什么不同，你都可以使⽤统⼀的⽇志收集器收集。以下简介三种情况下⽇志⼿机⽅式推荐：1. k8s集群

这种⽅式上⽂中已经提到了官⽅的解决⽅案，你只需要安装此⽅案部署即可。2. docker swarm集群

docker swarm⽬前暂时没有提供⽇志查看机制。但是docker cloud提供了与kubectrl logs类似的机制查看stdout的⽇志。⽬前还没有fluentd插件直接对服务进⾏⽇志收集，暂时考虑直接使⽤使⽤跟容器⼀样的机制收集。docker service create ⽀持--log-driver3. ⾃⼰部署的docker容器

从docker1.8内置了fluentd log driver。以如下的形式启动容器，容器stdout/stderr⽇志将发往配置的fluentd。如果配置后，docker logs将⽆法使⽤。另外默认模式下如果你配置得地址没有正常服务，容器⽆法启动。你也可以使⽤fluentd-async-connect形式启动，docker daemon则能在后台尝试连接并缓存⽇志。docker run --log-driver=fluentd --log-opt fluentd-address=:24224同样如果是⽇志⽂件，将⽂件暴露出来直接使⽤fluentd收集。好⾬云帮对kubernetes服务⽇志的统⼀处理⽅式需求是什么？云帮的公有云服务，平台上跑着有企业级应⽤和⼩型⽤户应⽤。我们怎么做到统⼀的⽇志收集和展⽰？⼜怎么做到⾯对企业级应⽤的⽇志输出和分析？

上⾯提到的⽅式不能完全解决我们的问题。实践⾸先⽬前kubernetes版本(v1.5.1)还不⽀持pod级别的⽇志log-driver设置，但是我们知道容器是可以设置log-driver的。也有关于这个问题的讨论。我们为了实现在⽤户⽹络(即pod容器⽹络)下的可配置⽇志转发⽅式。我们暂时修改了kubernetes源码使其⽀持设置容器的log-driver。默认情况下我们使⽤⾃⼰实现的zeroMQ-driver直接将容器⽇志通过0MQ发到⽇志统⼀处理中⼼。在处理中⼼统⼀完成下⼀步处理。如果平台⽤户需要将⽇志向外输出或者直接对接平台内⽇志分析应⽤，我们的处理是在应⽤pod中启动⽇志收集插件容器（封装扩展的fluentd）,根据⽤户的需要配置⽇志出⼝，实现应⽤级⽇志收集。这⾥你需要明确的是：容器⽇志⾸先是由docker-daemon收集到，再根据容器log-driver配置进⾏相应操作，也就是说如果你的宿主机⽹络与容器⽹络不通(k8s集群)，⽇志从宿主机到pod中的收集容器只有两种⽅式：⾛外层⽹络，⽂件挂载。我们采⽤⽂件挂载⽅式。本⽂转⾃开源中国-