全面提升，阿里雲Docker/Kubernetes(K8S) 日誌解決方案與選型對比

摘要： 今天，日誌服務再次升級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考驗。相關技術分享可以參見文章：多租戶隔離技術+雙十一實戰效果，Polling + Inotify 組合下的日誌保序採集方案。

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

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個操作即可輕鬆上雲，讓廣大用戶真正體驗到一個字：爽，從此日誌運維人員的生活質量大大提高。

目前Logtail除支持宿主機文件、容器文件、容器stdout採集外，還支持以下多種採集方式（這些方式k8s中均支持）：

1. syslog採集
2. Mysql binlog採集
3. JDBC採集
4. http採集

此外，Logtail即將推出Docker Event、Container Metric採集方式，敬請期待！

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎

推薦閱讀：