h5棋牌源碼分享《全面提高，阿里雲Docker/Kubernetes(K8S) 日誌解決方案與選型對比》

背景

衆所周知，Docker很火，Docker中Kubernetes（簡稱k8s）最火。h5棋牌源碼(h5.hxforum.com)聯繫方式 17061863533 企鵝 2952777280相對物理機、VM，Docker提供了更加簡單、輕量、高性價比的部署與運維方法；而k8s在Docker之上，更進一步提供了對管理基礎設施的抽象，造成了真正意義上的一站式部署與運維方案。

k8s提供了強有力工做調度、水平擴展、健康監測、維護高可用性等能力，同時提供了網絡、文件系統的抽象與管理，因此對於已有應用上k8s或者基於k8s部署應用十分便捷。但這裏有一部分令開發和運維人員比較頭疼–日誌採集。

難點分析

基於VM或者物理機部署的應用，日誌採集相關技術都比較完善，有比較健全的Logstash、Fluentd、FileBeats等。但在Docker中，尤爲在k8s中，日誌採集並無很好的解決方案，主要緣由以下：

1.採集目標多：須要採集宿主機日誌、容器內日誌、容器stdout。針對每種數據源都有對應的採集軟件，但缺少一站式解決方案。 
2.彈性伸縮難：k8s是一個分佈式的集羣，服務、環境的彈性伸縮對於日誌採集帶來了很大的困難，採集的動態性以及數據完整性是很是大的挑戰。 
3.運維成本大：現有的方案只能使用多種軟件組合採集，各個軟件組裝起來的系統穩定性難以保障，且缺少中心化的管理、配置、監控手段，運維負擔巨大。 
4.侵入性高：Docker Driver擴展須要修改底層引擎；一個Container對應一個採集Agent又會產生資源競爭和浪費。 
5.採集性能低：正常狀況下一個Docker Engine會運行數十個甚至數百個Container，此時開源Agent日誌採集性能以及資源消耗十分堪憂。

基於阿里巴巴多年來容器服務日誌採集的經驗積累，並結合阿里雲Kubernetes內測以來廣大用戶的反饋與訴求，今天，日誌服務爲k8s帶來真正意義上的一站式日誌解決方案。

方案介紹

方案簡介 

如上圖所示，咱們只須要在Kubernetes集羣中的每一個節點上部署一個Logtail的容器，便可實現該節點上宿主機日誌、容器日誌、容器stdout等全部數據源的一站式採集。咱們針對k8s提供了DaemonSet部署模板，1分鐘內便可完成整個集羣部署，而且後續集羣動態伸縮無需對採集作任何二次部署。具體請參見使用方式章節。

日誌服務客戶端Logtail目前已有百萬級部署，天天採集上萬應用、數PB的數據，歷經屢次雙十一、雙12考驗。

依託阿里雲日誌服務強大的功能，對於採集到的日誌數據，咱們提供：

1.上下文查詢，從茫茫數據中快速定位異常數據，並支持定位異常所在Container/Pod的上下文日誌 
2.實時的海量數據分析，1秒便可完成1億條數據的統計分析 
3.自帶報表、告警功能，老闆、開發、運維全搞定 
4.流計算對接：storm、flink、blink、spark streaming等等都支持 
5.外接可視化：Grafana、DataV輕鬆對接 
6.日誌歸檔投遞：支持投遞OSS歸檔存儲，也支持投遞MaxCompute進行離線分析

採集方案優點

關於日誌服務總體的優點這裏再也不贅述，本文主要探討日誌服務Kubernetes採集方案的相關優點。這裏咱們主要總結了如下幾點： 

方案對比

相對Logstash、Fluentd主流日誌採集方式，對好比下： 

使用方式 

部署k8s的日誌採集只需分爲3個步驟，1分鐘內便可完成集羣部署（詳細幫助文檔參見 k8s採集幫助），這多是你見過的最簡單的k8s日誌採集部署方案：

1.部署Logtail的DaemonSet。體力消耗：一條wget名，vi 修改3個參數，執行一條kubectl命令 
2.日誌服務控制檯建立自定義標識機器組(後續集羣動態伸縮無需額外操做)。體力消耗：web控制檯點擊幾回，輸入一個ID 
3.日誌服務控制檯建立採集配置(全部採集均爲服務端配置，無需本地運維)。體力消耗：stdout採集 web控制檯點擊幾回；文件採集 web控制檯點擊幾回，輸入2個path

除k8s外，日誌服務還支持標準docker不熟方式

核心技術簡介

自定義標識機器組

日誌採集支持k8s彈性伸縮的關鍵就是Logtail的自定義標識機器組。一般採集Agent遠程管理的方案都以IP或者hostname做爲標識，此方案在集羣規模較小以及環境變化性不強的狀況下較爲適用，當機器規模擴大、彈性伸縮成爲常態時運維成本承指數級升高。

基於集團內數年來的Agent運維經驗總結，咱們設計了一種靈活性更高、使用更加便捷、耦合度更低的配置&機器管理方式：

1.機器組除支持靜態ip設置外，也支持自定義標識的方式：全部Logtail只要定義了該標識則自動關聯到對應的機器組。 
2.一個Logtail可屬於多個機器組，一個機器組可包含多個Logtail，實現Logtail與機器組的解耦。 
3.一個採集配置可應用到多個機器組，一個機器組可關聯多個採集配置，實現機器組與採集配置的解耦。

以上概念映射到k8s中，可實現各類靈活的配置：

1.一個k8s集羣對應一個自定義標識的機器組。同一集羣的Logtail使用相同配置，k8s集羣伸縮時對應Logtail的DaemonSet自動伸縮，Logtail啓動後當即就會獲取和該機器組關聯的全部配置。 
2.一個k8s集羣中配置多種不一樣採集配置。根據不一樣Pod需求設置對應的採集配置，全部涉及容器採集的配置均支持IncludeLabel、ExcluseLabel過濾 
3.同一配置可應用到多個k8s集羣。若是您有多個的k8s集羣，若其中有部分服務日誌採集邏輯相同，您能夠將同一配置應用到多個集羣，無需額外配置。

容器自動發現

Logtail和不少軟件（Logspout、MetricBeats、Telegraf等）同樣內置了容器的自動發現機制。當前開源的容器自動發現均採用一次掃描+事件監聽的方式，即：初次運行時獲取當前全部的容器信息，後續監聽docker engine的事件信息，增量更新信息。

此種方式效率相對最高，但有必定機率遺漏部分信息：

1.獲取全部容器信息到docker engine事件監聽創建期間的這部分的增量信息會丟失 
2.事件監聽可能會由於某些異常狀況而終止，終止後到監聽從新創建期間的增量信息會丟失 

考慮以上問題，Logtail採用了事件監聽與按期全量掃描的方式實現容器的自動發現：

1.首先註冊監聽事件，其次再全量掃描 
2.每隔一段時間執行一次全量掃描，全量更新meta信息（時間間隔高到對docker engine壓力無影響）

容器文件自動渲染

容器日誌採集只須要配置容器內的文件路徑，而且支持各類採集模式：極簡、Nginx模板、正則、分隔符、JSON等。相對傳統的絕對路徑採集，容器內日誌採集動態性極強，爲此咱們專門實現了一套容器路徑的自動匹配與配置渲染方案：

1.Logtail會根據配置的容器路徑，查找容器對應路徑在宿主機上的映射關係 
2.根據宿主機路徑以及容器的元數據信息（container name、pod、namespace…）渲染出正常的採集配置 
3.Logtail文件採集模塊加載渲染的配置並採集數據 
4.當容器銷燬時刪除相應渲染的配置

可靠性保證

日誌採集中的可靠性保證是很是重要也很是困難的工做。在Logtail的設計中，進程退出、異常終止、程序升級被認爲是常態，在這些狀況發生時Logtail需儘量保證數據的可靠性。針對容器數據採集的動態特色，Logtail在以前可靠性保證的基礎上，新增了容器標準輸出以及容器文件的checkpoint維護機制

容器標準輸出checkpoint管理

1.容器stdout和stderr的checkpoint獨立保存 
2.checkpoint保存策略：按期dump全部容器當前的checkpoint；配置更新/進程退出時強制保存 
3.配置加載時，默認從checkpoint處開始採集，若無checkpoint，則從5秒前採集 
4.考慮到配置刪除時並不會刪除checkpoint，後臺按期清除無效checkpoint

容器文件checkpoint管理

1.除文件採集的checkpoint需保存外，還需保存容器meta的映射關係 
2.checkpoint加載前需提早加載容器與文件之間的映射關係 
3.考慮到中止期間沒法感知容器狀態變化，因此每次啓動時會渲染全部當前的配置。Logtail保證屢次加載同一容器配置的冪等性。

總結

阿里雲日誌服務提供的解決方案完美地解決了k8s上日誌採集難的問題，從以前須要多個軟件、幾十個部署流程精簡到1款軟件、3個操做便可輕鬆上雲，讓廣大用戶真正體驗到一個字：爽，今後日誌運維人員的生活質量大大提升。