本文介紹了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。

對於第二種：

1. 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.
2. 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.
3. 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.
4. 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特點

1. 部署簡單靈活
2. 開源
3. 經過驗證的可靠性和效能
4. 社群支援，外掛較多
5. 使用json格式事件格式
6. 可拔插的架構設計
7. 低資源要求
8. 內建高可靠性

fluentd與Logstash

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

fluentd與zeroMQ

把這兩個產品放在一起比較實屬不怎麼合適，因為它們屬於不同的陣營，完成不同的功能需求。由於fluentd具有訊息轉發的功能，姑且將其與以zeroMQ為例的訊息中介軟體的關係做個說明：

在大型系統架構中，有使用zeroMQ進行大量的日誌轉發工作。在fluentd中有兩個專案完成日誌的中轉路由的任務：golang編寫的：fluentd-forwarder 和c寫的fluent-bit

那麼是否意味著你需要做出選擇呢？其實不然。

著眼fluentd的定義和zeroMQ的定義。其實它們是一種合作關係。如果你是大型的架構系統，日誌量很龐大。我推薦你使用fluentd進行日誌收集，將zeroMQ作為fluentd的出口。就是說fluentd完成統一收集，zeroMQ完成日誌傳輸。如果你的系統並不龐大，你就無需zeroMQ來傳輸了。

因此你也無需關注這兩個產品的效能比較。雖然它們都有高效能的定義。

容器日誌收集總結

如上所描述的一樣，無論你的業務容器日誌呈現方式有什麼不同，你都可以使用統一的日誌收集器收集。以下簡介三種情況下日誌手機方式推薦：

1. k8s叢集
   這種方式上文中已經提到了官方的解決方案，你只需要安裝此方案部署即可。
2. docker swarm叢集
   docker swarm目前暫時沒有提供日誌檢視機制。但是docker cloud提供了與kubectrl logs類似的機制檢視stdout的日誌。目前還沒有fluentd外掛直接對服務進行日誌收集，暫時考慮直接使用使用跟容器一樣的機制收集。docker service create 支援–log-driver
3. 自己部署的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收集。

好雨雲幫對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中的收集容器只有兩種方式：走外層網路，檔案掛載。
我們採用檔案掛載方式。

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