如何進行關于K8s集群器日志收集的總結

如何進行關于K8s集群器日志收集的總結，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

下面介紹了k8s官方提供的日志收集方法，并介紹了Fluentd日志收集器并與其他產品做了比較。最后介紹了如何對k8s進行改造并使用ZeroMQ以消息的形式將日志傳輸到統一的日志處理中心。

容器日志存在形式

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

1. stdout,stderr標準輸出

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

2. 日志文件記錄

   這種日志輸出我們無法從以上方法查看日志內容，只能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 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性能對比

容器日志收集總結

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

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收集。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。