阿里雲 PB 級 Kubernetes 日誌平臺建設實踐

前言

阿里雲日誌服務是阿里集團針對日誌分析、處理的自研產品。Kubernetes 近兩年來發展十分迅速，已經成爲容器編排領域的事實標準，可是 Kubernetes 中日誌採集相對困難，阿里雲日誌服務技術專家元乙即將在 QCon 北京 2019 分享Kubernetes 日誌平臺建設最佳實踐，藉此機會咱們採訪了元乙老師阿里雲 Kubernetes 日誌平臺是如何建設的。

背景

阿里雲日誌服務是阿里集團針對日誌分析、處理的自研產品，最根本的目的是讓用戶專一在「分析」上，遠離瑣碎的工做。日誌服務總體功能分爲 3 個部分：日誌採集、智能查詢分析和數據分發。相比其餘日誌系統，阿里雲日誌服務有如下幾個特色：

1. 採集範圍廣，支持 30+ 種的數據採集通道，包括服務器、交換機、容器、移動端、IOT 等各種設備；支持全球加速、斷點續傳等功能，使全球化數據高可靠採集成爲可能。
2. 數據規模大，支持單用戶日 PB 級數據寫入，提供數據通道橫向自動擴展能力，可根據數據流量進行自動擴容。
3. 查詢能力強，提供 SQL92 標準的分析語法，秒級便可分析 10 億條數據，同時提供豐富的數據圖表，提供所見即所得的數據分析能力。
4. 下游渠道多，日誌服務支持對接各種下游的數據處理、分析系統，包括 Flink、Storm、Spark 等各種流計算系統，同時也支持 Hadoop、MaxCompute 等離線分析系統。

Kubernetes 日誌採集難點 ​

Kubernetes 近兩年來發展十分迅速，已經成爲容器編排領域的事實標準。Kubernetes 是一個大的生態系統，圍繞着 Kubernetes 咱們須要去解決不少問題，例如 CI/CD、可擴展性、安全性、可觀察性等等。日誌是可觀察性中必不可少的一部分，而在 Kubernetes 中日誌採集相對更加困難，難點主要體如今：

1. 採集目標多，Kubernetes 平臺運行着多種系統組件以及衆多應用，這些日誌由多種日誌格式（分隔符、json、Java、Nginx 等）和多種日誌形式（宿主機文件、容器 stdout、容器文件、syslog、journal 等）組成，一般主流的 Agent 很難支持各類數據的採集。
2. 環境動態性強，在 Kubernetes 中，各種服務都會進行自動的縮擴容，應用也會進行動態遷移，日誌採集很難適應環境動態性強的系統，尤爲是日誌的完整性很可貴到保證。
3. 使用負擔大，隨着集羣規模、使用人數、應用種類的逐漸增加，日誌採集的集中式管理、採集可靠性的監控等需求就顯得尤爲重要。更進一步，如何基於 Kubernetes 的擴展能力讓日誌採集也能和 Kubernetes 資源同樣進行統一的管理？

阿里雲 Kubernetes 日誌平臺的總體功能和核心技術

 ​ 
阿里雲 Kubernetes 日誌平臺爲 Kubernetes 日誌提供接入、查詢、分析、可視化、下游對接等日誌分析整個生命週期的完整方案，並針對 Kubernetes 的組件日誌提供通用的解決方案，例如審計日誌、Ingress 日誌、系統組件日誌等。這裏的核心技術主要有如下幾點：

1. 全方位日誌採集，可以支持 Kubernetes 各種日誌的實時採集，併兼顧低資源消耗、高性能、高可靠性。同時基於 CRD 擴展，實現採集與 Kubernetes 的無縫集成。
2. 超大規模數據量，Kubernetes 可輕鬆管理數萬臺機器的集羣，日數據量可能會達到數百 TB 甚至 PB 級，日誌平臺可以支撐海量的數據規模，同時保證可擴展性和可靠性。
3. 實時分析能力，日誌最經常使用的場景是監控和問題調查，所以實時的查詢 / 分析能力尤爲重要，平臺可以在秒級內實現對億級數據任意條件、任意維度組合的分析。
4. 超高性價比，針對日誌特色進行鍼對性系統優化，下降海量數據的存儲、處理成本，最大化利用機器資源，在成本控制上對開源方案造成壓倒性優點。
5. 通用方案打通，基於日誌平臺的通用能力，對 Kubernetes 的通用方案進行總體封裝，並打通採集、存儲、分析、可視化、告警等整個流程，實現通用方案的開箱即用。

平臺設計難點

阿里雲在通用日誌平臺的建設方面有着 10 年的經驗，針對 Kubernetes 場景平臺總體的複雜性增長不少，難點主要有：

1. 支持各種採集需求，需支持採集多種日誌形式和日誌格式，不一樣的使用場景對日誌採集的需求不一樣，須要保證數據採集具有高可靠、高性能、低資源佔用、可監控的能力。
2. Kubernetes 集成，日誌的採集和管理須要和 Kubernetes 平臺進行無縫兼容，所以須要提供 CRD 的擴展方式，尤爲在多種方式同時操做、集羣不可用等複雜場景下，CRD 與服務端的同步與協調關係較難維護。
3. 多租戶隔離，Kubernetes 日誌平臺的使用方較多，平臺需保證從日誌採集、處理、查詢、消費等各個環節的多租戶隔離，不能讓部分用戶的大量請求或非法使用而致使整個集羣不可用。
4. 超大流量壓力，在阿里內部，即便最大規格的 VIP 也沒法承受全部日誌的流量，雙 十一、春節紅包等流量高峯瞬間可能會打爆集羣，所以減小數據迴路、削峯填谷、降級方案、系統兜底方案等尤爲重要。

日誌數據的使用

Kubernetes 中存在各類日誌，包括內核日誌、系統組件日誌、Ingress、ServiceMesh、中間件、應用日誌等，每種日誌都會有不一樣人員在不一樣的場景中應用。例如 APIServer 的審計（Audit）日誌，安全同窗會用來作入侵檢測、帳號操做審計等，運維同窗會基於審計日誌作變動管理、核心組件監控、節點監控等，開發同窗會使用審計日誌檢查變動是否生效；例如 Ingress 的訪問日誌，運營同窗會用來作用戶行爲分析、業務走勢分析、運營檢測等；運維同窗會用來作集羣 / 服務監控；開發同窗會基於 Ingress 訪問日誌進行發佈先後的指標對比…

從日誌平臺角度來看，平臺須要爲不一樣的業務角色、不一樣的使用場景提供通用的數據處理 / 分析能力，包括但不限於：智能分析、鏈路跟蹤、監控、數據清洗、流計算、數據倉庫、安全分析、BI 分析等。 
 ​

Kubernetes 日誌平臺與可觀察性的關係

「可觀察性」（Observability）從電氣角度上的解釋是：「若全部的內部狀態均可以輸出到輸出信號，此係統即有可觀察性」。CNCF-Landscape 首次將「可觀察性」（Observability）引入到了 IT 領域。可觀察性相關的工具主要包括 Logging、Metric、Tracing 三大類，這三者之間有不少重疊部分，從表現力上來看，Metrics 最弱、Tracing 其次、Logging 最強。Metric 主要記錄了一些聚合的指標信息，例如 CPU/Mem 利用率、請求成功率、請求延遲等；Tracing 記錄從請求發起到響應完畢的整個流程；而日誌相對範疇最大，日誌記錄了系統運行期間全部的信息，而從日誌的字段中能夠聚合出 Metric、從日誌的 RequestID 中能夠提取出整個 Tracing 鏈路。

在 Kubernetes 中，一般經過 Metric 發現問題，而後經過 Tracing 定位問題模塊，最後根據日誌中的詳細信息診斷錯誤。而在阿里雲 Kubernetes 日誌平臺中可經過智能分析的功能直接基於日誌發現、定位並診斷問題，大大減小問題調查時間。智能分析的能力主要有：

1. 日誌聚類，根據日誌的類似性進行智能歸類，秒級便可實現億級數據自動歸類，快速掌握日誌總體狀態。
2. 異常檢測，基於變點檢測、折點檢測、多週期檢測、時序聚類等機器學習方法，自動檢測時序中的異常。
3. 日誌模式對比，經過先後兩個時間段 / 版本的日誌模式對比，快速發現當前時間 / 版本的日誌差別。
4. 知識庫匹配，將問題調查經驗以知識庫形式保存下來，將日誌與知識庫內容進行匹配，快速獲得具體日誌對應的問題和解決方案。

 ​

阿里雲 Kubernetes 日誌平臺的借鑑意義

阿里雲 Kubernetes 日誌平臺建設過程當中考慮的不少問題對於你們都有必定的借鑑意義，例如：

1. 採集方案選擇，Kubernetes 中採集一般會使用 DaemonSet 和 Sidecar 兩種方式，日誌也會分爲 stdout 和文件兩種形式，文件也分爲容器內文件和宿主機掛載文件等不一樣方式，需根據業務場景特色選擇合適的日誌採集方案。
2. 平臺高可用建設，隨着應用場景的逐漸擴展，對於日誌平臺的可用性要求也愈來愈高，咱們在高可靠日誌採集、日誌平臺自監控、異常自動屏蔽與恢復、高效運維等方面積累了不少寶貴的經驗與教訓。
3. 生態對接，平臺不可能實現日誌生命週期中所需的全部系統和功能，很大一部分功能須要上下游的生態來完成（例如流計算、離線計算、Trace 系統、告警系統等），所以生態的對接成爲了日誌平臺可以覆蓋全部日誌場景必不可少的一個部分。
4. 性能與成本取捨，成本是每一個公司都須要考慮的一點，一般日誌的開銷只佔 IT 支出的 1-3% 左右，日誌的採集、存儲、查詢等各個環節需儘量的節省資源，同時還需保證總體性能在可接受範圍內。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。