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

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

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

stdout,stderr標準輸出

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

日志文件記錄

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

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

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收集日志然后發(fā)送給
Elasticsearch。
實現(xiàn)方式是每個agent掛載目錄/var/lib/docker/containers使用fluentd的tail插件掃描每個容器日志文件，直接發(fā)送給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起在業(yè)務(wù)同一個pod中共享volume然后實現(xiàn)對日志文件的收集發(fā)送給Elasticsearch

對于fluentd官方對其的定義是：

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

部署簡單靈活

開源

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

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

使用json格式事件格式

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

低資源要求

內(nèi)置高可靠性

引用一張圖對比這兩個日志收集工具。具體它們兩個項目的對比請參考：

Fluentd vs. Logstash: A Comparison of Log Collectors

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

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

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

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

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

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

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

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

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

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

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

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

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

云盟認證成員：barnett