摘要：我推薦你使用進(jìn)行日志收集，將作為的出口。集群目前暫時(shí)沒有提供日志查看機(jī)制。以如下的形式啟動(dòng)容器，容器日志將發(fā)往配置的。

【作者barnett】本文介紹了k8s官方提供的日志收集方法，并介紹了Fluentd日志收集器并與其他產(chǎn)品做了比較。最后介紹了好雨云幫如何對(duì)k8s進(jìn)行改造并使用ZeroMQ以消息的形式將日志傳輸?shù)浇y(tǒng)一的日志處理中心。

目前容器日志有兩種輸出形式：

stdout,stderr標(biāo)準(zhǔn)輸出

這種形式的日志輸出我們可以直接使用docker logs查看日志，k8s集群中同樣集群可以使用kubectl logs類似的形式查看日志。

日志文件記錄

這種日志輸出我們無法從以上方法查看日志內(nèi)容，只能tail日志文件查看。

在k8s官方文檔中，對(duì)于以上兩種形式的日志形式我們?nèi)绻胧占⒎治鋈罩镜脑?，官方推薦以下兩種對(duì)策：
對(duì)于第一種文檔中這樣說：

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.

就說說集群?jiǎn)?dòng)時(shí)會(huì)在每個(gè)機(jī)器啟動(dòng)一個(gè)Fluentd agent收集日志然后發(fā)送給
Elasticsearch。
實(shí)現(xiàn)方式是每個(gè)agent掛載目錄/var/lib/docker/containers使用fluentd的tail插件掃描每個(gè)容器日志文件，直接發(fā)送給Elasticsearch。

對(duì)于第二種：

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.

其實(shí)跟第一種類似，但是是把Fluentd agent起在業(yè)務(wù)同一個(gè)pod中共享volume然后實(shí)現(xiàn)對(duì)日志文件的收集發(fā)送給Elasticsearch

對(duì)于fluentd官方對(duì)其的定義是：

#### 統(tǒng)一日志層
Fluentd通過在后端系統(tǒng)之間提供統(tǒng)一的日志記錄層來從后端系統(tǒng)中解耦數(shù)據(jù)源。
此層允許開發(fā)人員和數(shù)據(jù)分析人員在生成日志時(shí)使用多種類型的日志。
統(tǒng)一的日志記錄層可以讓您和您的組織更好地使用數(shù)據(jù)，并更快地在您的軟件上進(jìn)行迭代。
也就是說fluentd是一個(gè)面向多種數(shù)據(jù)來源以及面向多種數(shù)據(jù)出口的日志收集器。另外它附帶了日志轉(zhuǎn)發(fā)的功能。

部署簡(jiǎn)單靈活

開源

經(jīng)過驗(yàn)證的可靠性和性能

社區(qū)支持，插件較多

使用json格式事件格式

可拔插的架構(gòu)設(shè)計(jì)

低資源要求

內(nèi)置高可靠性

引用一張圖對(duì)比這兩個(gè)日志收集工具。具體它們兩個(gè)項(xiàng)目的對(duì)比請(qǐng)參考：

Fluentd vs. Logstash: A Comparison of Log Collectors

把這兩個(gè)產(chǎn)品放在一起比較實(shí)屬不怎么合適，因?yàn)樗鼈儗儆诓煌年嚑I(yíng)，完成不同的功能需求。由于fluentd具有消息轉(zhuǎn)發(fā)的功能，姑且將其與以zeroMQ為例的消息中間件的關(guān)系做個(gè)說明：
在大型系統(tǒng)架構(gòu)中，有使用zeroMQ進(jìn)行大量的日志轉(zhuǎn)發(fā)工作。在fluentd中有兩個(gè)項(xiàng)目完成日志的中轉(zhuǎn)路由的任務(wù)：golang編寫的：fluentd-forwarder 和c寫的fluent-bit

那么是否意味著你需要做出選擇呢？其實(shí)不然。
著眼fluentd的定義和zeroMQ的定義。其實(shí)它們是一種合作關(guān)系。如果你是大型的架構(gòu)系統(tǒng)，日志量很龐大。我推薦你使用fluentd進(jìn)行日志收集，將zeroMQ作為fluentd的出口。就是說fluentd完成統(tǒng)一收集，zeroMQ完成日志傳輸。如果你的系統(tǒng)并不龐大，你就無需zeroMQ來傳輸了。

因此你也無需關(guān)注這兩個(gè)產(chǎn)品的性能比較。雖然它們都有高性能的定義。

zeroMQ的性能測(cè)試結(jié)果：zeroMQ 與JeroMQ性能對(duì)比

如上所描述的一樣，無論你的業(yè)務(wù)容器日志呈現(xiàn)方式有什么不同，你都可以使用統(tǒng)一的日志收集器收集。以下簡(jiǎn)介三種情況下日志手機(jī)方式推薦：

k8s集群
這種方式上文中已經(jīng)提到了官方的解決方案，你只需要安裝此方案部署即可。

docker swarm集群
docker swarm目前暫時(shí)沒有提供日志查看機(jī)制。但是docker cloud提供了與kubectrl logs類似的機(jī)制查看stdout的日志。目前還沒有fluentd插件直接對(duì)服務(wù)進(jìn)行日志收集，暫時(shí)考慮直接使用使用跟容器一樣的機(jī)制收集。docker service create 支持--log-driver

自己部署的docker容器
從docker1.8內(nèi)置了fluentd log driver。以如下的形式啟動(dòng)容器，容器stdout/stderr日志將發(fā)往配置的fluentd。如果配置后，docker logs將無法使用。另外默認(rèn)模式下如果你配置得地址沒有正常服務(wù)，容器無法啟動(dòng)。你也可以使用fluentd-async-connect形式啟動(dòng)，docker daemon則能在后臺(tái)嘗試連接并緩存日志。

docker run --log-driver=fluentd --log-opt fluentd-address=myhost.local:24224

同樣如果是日志文件，將文件暴露出來直接使用fluentd收集。

云幫的公有云服務(wù)，平臺(tái)上跑著有企業(yè)級(jí)應(yīng)用和小型用戶應(yīng)用。我們?cè)趺醋龅浇y(tǒng)一的日志收集和展示？又怎么做到面對(duì)企業(yè)級(jí)應(yīng)用的日志輸出和分析？
上面提到的方式不能完全解決我們的問題。

首先目前kubernetes版本(v1.5.1)還不支持pod級(jí)別的日志log-driver設(shè)置，但是我們知道容器是可以設(shè)置log-driver的。這里也有關(guān)于這個(gè)問題的討論。我們?yōu)榱藢?shí)現(xiàn)在用戶網(wǎng)絡(luò)(即pod容器網(wǎng)絡(luò))下的可配置日志轉(zhuǎn)發(fā)方式。我們暫時(shí)修改了kubernetes源碼使其支持設(shè)置容器的log-driver。默認(rèn)情況下我們使用自己實(shí)現(xiàn)的zeroMQ-driver直接將容器日志通過0MQ發(fā)到日志統(tǒng)一處理中心。在處理中心統(tǒng)一完成下一步處理。如果平臺(tái)用戶需要將日志向外輸出或者直接對(duì)接平臺(tái)內(nèi)日志分析應(yīng)用，我們的處理是在應(yīng)用pod中啟動(dòng)日志收集插件容器（封裝擴(kuò)展的fluentd）,根據(jù)用戶的需要配置日志出口，實(shí)現(xiàn)應(yīng)用級(jí)日志收集。這里你需要明確的是：容器日志首先是由docker-daemon收集到，再根據(jù)容器log-driver配置進(jìn)行相應(yīng)操作，也就是說如果你的宿主機(jī)網(wǎng)絡(luò)與容器網(wǎng)絡(luò)不通(k8s集群)，日志從宿主機(jī)到pod中的收集容器只有兩種方式：走外層網(wǎng)絡(luò)，文件掛載。
我們采用文件掛載方式。

如果您對(duì)本文提到的k8s官方收集、處理日志以及對(duì)好雨云幫的日志收集方式有疑問或問題，歡迎留言，作者會(huì)在第一時(shí)間解答。

云盟認(rèn)證成員：barnett