关于K8s集群器日志收集的总结

本文介绍了kubernetes官方提供的日志收集方法，并介绍了Fluentd日志收集器并与其他产品做了比较。最后介绍了好雨云帮如何对k8s进行改造并使用ZeroMQ以消息的形式将日志传输到统一的日志处理中心。

容器日志存在形式

目前容器日志有两种输出形式：

stdout,stderr标准输出

这种形式的日志输出我们可以直接使用docker logs查看日志，k8s集群中同样集群可以使用kubectl logs类似的形式查看日志。

日志文件记录

这种日志输出我们无法从以上方法查看日志内容，只能tail日志文件查看。

在k8s官方文档中，对于以上两种形式的日志形式我们如果想收集并分析日志的话，官方推荐以下两种对策：

对于第一种文档中这样说：

When a cluster is created, the standard output and standard error output of each container can be ingested using a Fluentd agent running on each node into either Google Cloud Logging or into Elasticsearch and viewed with Kibana.

When a Kubernetes cluster is created with logging to Google Cloud Logging enabled, the system creates a pod called fluentd-cloud-logging on each node of the cluster to collect Docker container logs. These pods were shown at the start of this blog article in the response to the first get pods command.

就是说集群启动时会在每个机器启动一个Fluentd agent收集日志然后发送给Elasticsearch。

实现方式是每个agent挂载目录/var/lib/docker/containers使用fluentd的tail插件扫描每个容器日志文件，直接发送给Elasticsearch。

对于第二种：

A second container, using the gcr.io/google_containers/fluentd-sidecar-es:1.2 image to send the logs to Elasticsearch. We recommend attaching resource constraints of 100m CPU and 200Mi memory to this container, as in the example.

A volume for the two containers to share. The emptyDir volume type is a good choice for this because we only want the volume to exist for the lifetime of the pod.

Mount paths for the volume in each container. In your primary container, this should be the path that the applications 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.

The FILES_TO_COLLECT environment variable in the sidecar container, telling it which files to collect logs from. These paths should always be in the mounted volume.

其实跟第一种类似，但是是把Fluentd agent起在业务同一个pod中共享volume然后实现对日志文件的收集发送给Elasticsearch

fluentd分析

对于fluentd官方对其的定义是：

统一日志层

Fluentd通过在后端系统之间提供统一的日志记录层来从后端系统中解耦数据源。
此层允许开发人员和数据分析人员在生成日志时使用多种类型的日志。
统一的日志记录层可以让您和您的组织更好地使用数据，并更快地在您的软件上进行迭代。
也就是说fluentd是一个面向多种数据来源以及面向多种数据出口的日志收集器。另外它附带了日志转发的功能。

fluentd特点

部署简单灵活
开源
经过验证的可靠性和性能
社区支持，插件较多
使用json格式事件格式
可拔插的架构设计
低资源要求
内置高可靠性

fluentd与Logstash

引用一张图对比这两个日志收集工具。具体它们两个项目的对比请参考：

Fluentd vs. Logstash: A Comparison of Log Collectors

fluentd与zeroMQ

把这两个产品放在一起比较实属不怎么合适，因为它们属于不同的阵营，完成不同的功能需求。由于fluentd具有消息转发的功能，姑且将其与以zeroMQ为例的消息中间件的关系做个说明：

在大型系统架构中，有使用zeroMQ进行大量的日志转发工作。在fluentd中有两个项目完成日志的中转路由的任务：golang编写的：fluentd-forwarder 和c写的fluent-bit

那么是否意味着你需要做出选择呢？其实不然。

着眼fluentd的定义和zeroMQ的定义。其实它们是一种合作关系。如果你是大型的架构系统，日志量很庞大。我推荐你使用fluentd进行日志收集，将zeroMQ作为fluentd的出口。就是说fluentd完成统一收集，zeroMQ完成日志传输。如果你的系统并不庞大，你就无需zeroMQ来传输了。

因此你也无需关注这两个产品的性能比较。虽然它们都有高性能的定义。

zeroMQ的性能测试结果：zeroMQ 与JeroMQ性能对比

容器日志收集总结

如上所描述的一样，无论你的业务容器日志呈现方式有什么不同，你都可以使用统一的日志收集器收集。以下简介三种情况下日志手机方式推荐：

k8s集群
这种方式上文中已经提到了官方的解决方案，你只需要安装此方案部署即可。
docker swarm集群
docker swarm目前暂时没有提供日志查看机制。但是docker cloud提供了与kubectrl logs类似的机制查看stdout的日志。目前还没有fluentd插件直接对服务进行日志收集，暂时考虑直接使用使用跟容器一样的机制收集。docker service create 支持–log-driver
自己部署的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=myhost.local:24224
```
同样如果是日志文件，将文件暴露出来直接使用fluentd收集。