摘要： 今天，日誌服務再次升級Kubernetes（k8s）的日誌解決方案。1分鐘內即可完成整個叢集部署，支援動態擴容，提供採集宿主機日誌、容器日誌、容器stdout等所有資料來源的一站式採集。

背景

眾所周知，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彈性伸縮的關鍵就是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個操作即可輕鬆上雲，讓廣大使用者真正體驗到一個字：爽，從此日誌運維人員的生活質量大大提高。