【做者barnett】本文介绍了k8s官方提供的日志收集方法,并介绍了Fluentd日志收集器并与其余产品作了比较。最后介绍了好雨云帮如何对k8s进行改造并使用ZeroMQ以消息的形式将日志传输到统一的日志处理中心。node
目前容器日志有两种输出形式:git
这种形式的日志输出咱们能够直接使用docker logs
查看日志,k8s集群中一样集群可使用kubectl logs
相似的形式查看日志。github
日志文件记录golang
这种日志输出咱们没法从以上方法查看日志内容,只能tail
日志文件查看。docker
在k8s官方文档中,对于以上两种形式的日志形式咱们若是想收集并分析日志的话,官方推荐如下两种对策: 对于第一种文档中这样说:json
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 vs. Logstash: A Comparison of Log Collectors
把这两个产品放在一块儿比较实属不怎么合适,由于它们属于不一样的阵营,完成不一样的功能需求。因为fluentd具备消息转发的功能,姑且将其与以zeroMQ为例的消息中间件的关系作个说明: 在大型系统架构中,有使用zeroMQ进行大量的日志转发工做。在fluentd中有两个项目完成日志的中转路由的任务:golang编写的:fluentd-forwarder 和c写的fluent-bit
那么是否意味着你须要作出选择呢?其实否则。 着眼fluentd的定义和zeroMQ的定义。其实它们是一种合做关系。若是你是大型的架构系统,日志量很庞大。我推荐你使用fluentd进行日志收集,将zeroMQ做为fluentd的出口。就是说fluentd完成统一收集,zeroMQ完成日志传输。若是你的系统并不庞大,你就无需zeroMQ来传输了。
所以你也无需关注这两个产品的性能比较。虽然它们都有高性能的定义。
zeroMQ的性能测试结果:zeroMQ 与JeroMQ性能对比
如上所描述的同样,不管你的业务容器日志呈现方式有什么不一样,你均可以使用统一的日志收集器收集。如下简介三种状况下日志手机方式推荐:
docker cloud
提供了与kubectrl logs
相似的机制查看stdout的日志。目前尚未fluentd插件直接对服务进行日志收集,暂时考虑直接使用使用跟容器同样的机制收集。docker service create
支持--log-driver
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收集。
云帮的公有云服务,平台上跑着有企业级应用和小型用户应用。咱们怎么作到统一的日志收集和展现?又怎么作到面对企业级应用的日志输出和分析?
上面提到的方式不能彻底解决咱们的问题。
首先目前kubernetes版本(v1.5.1)还不支持pod级别的日志log-driver设置,可是咱们知道容器是能够设置log-driver的。这里也有关于这个问题的讨论。咱们为了实如今用户网络(即pod容器网络)下的可配置日志转发方式。咱们暂时修改了kubernetes源码使其支持设置容器的log-driver。默认状况下咱们使用本身实现的zeroMQ-driver直接将容器日志经过0MQ发到日志统一处理中心。在处理中心统一完成下一步处理。若是平台用户须要将日志向外输出或者直接对接平台内日志分析应用,咱们的处理是在应用pod中启动日志收集插件容器(封装扩展的fluentd),根据用户的须要配置日志出口,实现应用级日志收集。这里你须要明确的是:容器日志首先是由docker-daemon收集到,再根据容器log-driver配置进行相应操做,也就是说若是你的宿主机网络与容器网络不通(k8s集群),日志从宿主机到pod中的收集容器只有两种方式:走外层网络,文件挂载。 咱们采用文件挂载方式。
若是您对本文提到的k8s官方收集、处理日志以及对好雨云帮的日志收集方式有疑问或问题,欢迎留言,做者会在第一时间解答。
云盟认证成员:barnett