摘要： 今天，日志服務再次更新Kubernetes（k8s）的日志解決方案。1分鐘内即可完成整個叢集部署，支援動态擴容，提供采集主控端日志、容器日志、容器stdout等所有資料源的一站式采集。
點此檢視原文：http://click.aliyun.com/m/42852/
背景
衆所周知，Docker很火，Docker中Kubernetes（簡稱k8s）最火。相對實體機、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的資料，曆經多次雙11、雙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個操作即可輕松上雲，讓廣大使用者真正體驗到一個字：爽，從此日志運維人員的生活品質大大提高。