前言
阿里雲日誌服務是阿里集團針對日誌分析、處理的自研產品。Kubernetes 近兩年來發展十分迅速，已經成為容器編排領域的事實標準，但是 Kubernetes 中日誌採集相對困難，阿里雲日誌服務技術專家元乙即將在 QCon 北京 2019 分享Kubernetes 日誌平臺建設最佳實踐，藉此機會我們採訪了元乙老師阿里雲 Kubernetes 日誌平臺是如何建設的。
背景
阿里雲日誌服務是阿里集團針對日誌分析、處理的自研產品，最根本的目的是讓使用者專注在“分析”上，遠離瑣碎的工作。日誌服務整體功能分為 3 個部分：日誌採集、智慧查詢分析和資料分發。相比其他日誌系統，阿里雲日誌服務有以下幾個特點：
- 採集範圍廣，支援 30+ 種的資料採集通道，包括伺服器、交換機、容器、移動端、IOT 等各類裝置；支援全球加速、斷點續傳等功能，使全球化資料高可靠採整合為可能。
- 資料規模大，支援單使用者日 PB 級資料寫入，提供資料通道橫向自動擴充套件能力，可根據資料流量進行自動擴容。
- 查詢能力強，提供 SQL92 標準的分析語法，秒級即可分析 10 億條資料，同時提供豐富的資料圖表，提供所見即所得的資料分析能力。
- 下游渠道多，日誌服務支援對接各類下游的資料處理、分析系統，包括 Flink、Storm、Spark 等各類流計算系統，同時也支援 Hadoop、MaxCompute 等離線分析系統。
Kubernetes 日誌採集難點
Kubernetes 近兩年來發展十分迅速，已經成為容器編排領域的事實標準。Kubernetes 是一個大的生態系統，圍繞著 Kubernetes 我們需要去解決很多問題，例如 CI/CD、可擴充套件性、安全性、可觀察性等等。日誌是可觀察性中必不可少的一部分，而在 Kubernetes 中日誌採集相對更加困難，難點主要體現在：
- 採集目標多，Kubernetes 平臺執行著多種系統元件以及眾多應用，這些日誌由多種日誌格式（分隔符、json、Java、Nginx 等）和多種日誌形式（宿主機檔案、容器 stdout、容器檔案、syslog、journal 等）組成，通常主流的 Agent 很難支援各種資料的採集。
- 環境動態性強，在 Kubernetes 中，各類服務都會進行自動的縮擴容，應用也會進行動態遷移，日誌採集很難適應環境動態性強的系統，尤其是日誌的完整性很難得到保證。
- 使用負擔大，隨著叢集規模、使用人數、應用種類的逐漸增長，日誌採集的集中式管理、採集可靠性的監控等需求就顯得尤其重要。更進一步，如何基於 Kubernetes 的擴充套件能力讓日誌採集也能和 Kubernetes 資源一樣進行統一的管理？
阿里雲 Kubernetes 日誌平臺的整體功能和核心技術
阿里雲 Kubernetes 日誌平臺為 Kubernetes 日誌提供接入、查詢、分析、視覺化、下游對接等日誌分析整個生命週期的完整方案，並針對 Kubernetes 的元件日誌提供通用的解決方案，例如審計日誌、Ingress 日誌、系統元件日誌等。這裡的核心技術主要有以下幾點：
- 全方位日誌採集，能夠支援 Kubernetes 各類日誌的實時採集，併兼顧低資源消耗、高效能、高可靠性。同時基於 CRD 擴充套件，實現採集與 Kubernetes 的無縫整合。
- 超大規模資料量，Kubernetes 可輕鬆管理數萬臺機器的叢集，日資料量可能會達到數百 TB 甚至 PB 級，日誌平臺能夠支撐海量的資料規模，同時保證可擴充套件性和可靠性。
- 實時分析能力，日誌最常用的場景是監控和問題調查，因此實時的查詢 / 分析能力尤其重要，平臺能夠在秒級內實現對億級資料任意條件、任意維度組合的分析。
- 超高價效比，針對日誌特點進行鍼對性系統優化，降低海量資料的儲存、處理成本，最大化利用機器資源，在成本控制上對開源方案形成壓倒性優勢。
- 通用方案打通，基於日誌平臺的通用能力，對 Kubernetes 的通用方案進行整體封裝，並打通採集、儲存、分析、視覺化、告警等整個流程，實現通用方案的開箱即用。
平臺設計難點
阿里雲在通用日誌平臺的建設方面有著 10 年的經驗，針對 Kubernetes 場景平臺整體的複雜性增加很多，難點主要有：
- 支援各類採集需求，需支援採集多種日誌形式和日誌格式，不同的使用場景對日誌採集的需求不同，需要保證資料採集具備高可靠、高效能、低資源佔用、可監控的能力。
- Kubernetes 整合，日誌的採集和管理需要和 Kubernetes 平臺進行無縫相容，因此需要提供 CRD 的擴充套件方式，尤其在多種方式同時操作、叢集不可用等複雜場景下，CRD 與服務端的同步與協調關係較難維護。
- 多租戶隔離，Kubernetes 日誌平臺的使用方較多，平臺需保證從日誌採集、處理、查詢、消費等各個環節的多租戶隔離，不能讓部分使用者的大量請求或非法使用而導致整個叢集不可用。
- 超大流量壓力，在阿里內部，即使最大規格的 VIP 也無法承受所有日誌的流量，雙 11、春節紅包等流量高峰瞬間可能會打爆叢集，因此減少資料迴路、削峰填谷、降級方案、系統兜底方案等尤其重要。
日誌資料的使用
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 日誌平臺中可通過智慧分析的功能直接基於日誌發現、定位並診斷問題，大大減少問題調查時間。智慧分析的能力主要有：
- 日誌聚類，根據日誌的相似性進行智慧歸類，秒級即可實現億級資料自動歸類，快速掌握日誌整體狀態。
- 異常檢測，基於變點檢測、折點檢測、多週期檢測、時序聚類等機器學習方法，自動檢測時序中的異常。
- 日誌模式對比，通過前後兩個時間段 / 版本的日誌模式對比，快速發現當前時間 / 版本的日誌差異。
- 知識庫匹配，將問題調查經驗以知識庫形式儲存下來，將日誌與知識庫內容進行匹配，快速得到具體日誌對應的問題和解決方案。
阿里雲 Kubernetes 日誌平臺的借鑑意義
阿里雲 Kubernetes 日誌平臺建設過程中考慮的很多問題對於大家都有一定的借鑑意義，例如：
- 採集方案選擇，Kubernetes 中採集通常會使用 DaemonSet 和 Sidecar 兩種方式，日誌也會分為 stdout 和檔案兩種形式，檔案也分為容器內檔案和宿主機掛載檔案等不同方式，需根據業務場景特點選擇合適的日誌採集方案。
- 平臺高可用建設，隨著應用場景的逐漸擴充套件，對於日誌平臺的可用性要求也越來越高，我們在高可靠日誌採集、日誌平臺自監控、異常自動遮蔽與恢復、高效運維等方面積累了很多寶貴的經驗與教訓。
- 生態對接，平臺不可能實現日誌生命週期中所需的所有系統和功能，很大一部分功能需要上下游的生態來完成（例如流計算、離線計算、Trace 系統、告警系統等），因此生態的對接成為了日誌平臺能夠覆蓋所有日誌場景必不可少的一個部分。
- 效能與成本取捨，成本是每個公司都需要考慮的一點，通常日誌的開銷只佔 IT 支出的 1-3% 左右，日誌的採集、儲存、查詢等各個環節需儘可能的節省資源，同時還需保證整體效能在可接受範圍內。
本文為雲棲社群原創內容，未經允許不得轉載。