資訊專欄INFORMATION COLUMN
摘要：我推薦你使用進行日志收集，將作為的出口。集群目前暫時沒有提供日志查看機制。以如下的形式啟動容器，容器日志將發往配置的。
【作者barnett】本文介紹了k8s官方提供的日志收集方法，并介紹了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。
對于第二種：
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是一個面向多種數據來源以及面向多種數據出口的日志收集器。另外它附帶了日志轉發的功能。
部署簡單靈活
開源
經過驗證的可靠性和性能
社區支持，插件較多
使用json格式事件格式
可拔插的架構設計
低資源要求
內置高可靠性
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性能對比
容器日志收集總結如上所描述的一樣，無論你的業務容器日志呈現方式有什么不同，你都可以使用統一的日志收集器收集。以下簡介三種情況下日志手機方式推薦：
k8s集群
這種方式上文中已經提到了官方的解決方案，你只需要安裝此方案部署即可。
docker swarm集群
docker swarm目前暫時沒有提供日志查看機制。但是docker cloud提供了與kubectrl logs類似的機制查看stdout的日志。目前還沒有fluentd插件直接對服務進行日志收集，暫時考慮直接使用使用跟容器一樣的機制收集。docker service create 支持--log-driver
自己部署的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官方收集、處理日志以及對好雨云幫的日志收集方式有疑問或問題，歡迎留言，作者會在第一時間解答。
云盟認證成員：barnett
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/27986.html
摘要：我推薦你使用進行日志收集，將作為的出口。集群目前暫時沒有提供日志查看機制。以如下的形式啟動容器，容器日志將發往配置的。 【作者barnett】本文介紹了k8s官方提供的日志收集方法，并介紹了Fluentd日志收集器并與其他產品做了比較。最后介紹了好雨云幫如何對k8s進行改造并使用ZeroMQ以消息的形式將日志傳輸到統一的日志處理中心。 容器日志存在形式 目前容器日志有兩種輸出形式： ...
摘要：宋體本文從拉勾網的業務架構日志采集監控服務暴露調用等方面介紹了其基于的容器化改造實踐。宋體此外，拉勾網還有一套自研的環境的業務發布系統，不過這套發布系統未適配容器環境。寫在前面 拉勾網于 2019 年 3 月份開始嘗試將生產環境的業務從 UHost 遷移到 UK8S，截至 2019 年 9 月份，QA 環境的大部分業務模塊已經完成容器化改造，生產環境中，后臺管理服務已全部遷移到 UK8...
摘要：基于年底或年初沒有推廣的現狀，唯品會部門目前已經做了兩年的時間。唯品會現狀唯品會目前線上有一千多個域，每個域之間相互的依賴比較復雜，每次的部署發布困難。這是唯品會的架構，主要包含持續集成和持續部署。 數人云上海&深圳兩地容器之Mesos/K8S/Swarm三國演義的嘉賓精彩實錄第三更來啦。唯品會是數人云Meetup的老朋友，去年曾做過RPC服務框架和Mesos容器化的分享。本次分享中，...
摘要：參與者流量來自于內部系統和外部流量，其中大部分來自于外部流量。水平擴容服務的水平擴容重要性不言而喻。 背景 目前微店中臺團隊為了滿足公司大部分產品、運營以及部分后端開發人員的嘗鮮和試錯的需求，提供了一套基于圖形化搭建的服務端接口交付方案，利用該方案及提供的系統可生成一副包含運行時環境定義可立即運行的工程代碼，最后，通過 某種serverless平臺 實現生成后代碼的部署、CI、運行、反...
摘要：詳細請見產品價格產品概念使用須知名詞解釋漏洞修復記錄集群節點配置推薦模式選擇產品價格操作指南集群創建需要注意的幾點分別是使用必讀講解使用需要賦予的權限模式切換的切換等。UK8S概覽UK8S是一項基于Kubernetes的容器管理服務，你可以在UK8S上部署、管理、擴展你的容器化應用，而無需關心Kubernetes集群自身的搭建及維護等運維類工作。了解使用UK8S為了讓您更快上手使用，享受UK...
閱讀 1311·2023-04-26 03:05
閱讀 761·2021-10-19 11:43
閱讀 3206·2021-09-26 09:55
閱讀 825·2019-08-30 15:56
閱讀 979·2019-08-30 15:44
閱讀 1228·2019-08-30 15:44
閱讀 2717·2019-08-30 14:23
閱讀 3233·2019-08-30 13:13
