QCon是由InfoQ主辦的綜合性技術盛會,每年在倫敦、北京、紐約、聖保羅、上海、舊金山召開。有幸參加這次QCon10週年大會,作為分享嘉賓在劉宇老師的運維專場發表了《阿里PB級Kubernetes日誌平臺建設實踐》,現將PPT和文字稿整理下來,希望和更多的愛好者分享。
在阿里的十多年中,日誌系統伴隨著計算形態的發展在不斷演進,大致分為3個主要階段:
日誌不僅僅是伺服器、容器、應用的Debug日誌,也包括各類訪問日誌、中間件日誌、用戶點擊、IoT/移動端日誌、資料庫Binlog等等。這些日誌隨著時效性的不同而應用在不同的場景:
在阿里,幾乎所有的業務角色都會涉及到各式各樣的日誌數據,為了支撐各類應用場景,我們開發了非常多的工具和功能:日誌實時分析、鏈路追蹤、監控、數據清洗、流計算、離線計算、BI系統、審計系統等等。其中很多系統都非常成熟,日誌平臺主要專註於智能分析、監控等實時的場景,其他功能通常打通的形式支持。
日誌系統存在了十多年,目前也有非常多的開源的方案,例如最典型的ELK(Elastic Search、Logstash、Kibana),通常一個日誌系統具備以下功能:日誌收集/解析、查詢與檢索、日誌分析、可視化/告警等,這些功能通過開源軟體的組合都可以實現,但最終我們選擇自建,主要有幾下幾點考慮:
圍繞著Kubernetes場景的需求,日誌平臺建設的難點主要有以下幾點:
無論是在ITOM還是在未來的AIOps場景中,日誌獲取都是其中必不可少的一個部分,數據源直接決定了後續應用的形態和功能。在十多年中,我們積累了一套物理機、虛擬機的日誌採集經驗,但在Kubernetes中不能完全適用,這裡我們以問題的形式展開:
每種採集方式都有其對應的優缺點,這裡簡單總結如下:
| | DaemonSet方式 | Sidecar方式 | | --- | --- | --- | | 採集日誌類型 | 標準輸出+部分文件 | 文件 | | 部署運維 | 一般,需維護DaemonSet | 較高,每個需要採集日誌的POD都需要部署sidecar容器 | | 日誌分類存儲 | 一般,可通過容器/路徑等映射 | 每個POD可單獨配置,靈活性高 | | 多租戶隔離 | 一般,只能通過配置間隔離 | 強,通過容器進行隔離,可單獨分配資源 | | 支持集羣規模 | 中小型規模,業務數最多支持百級別 | 無限制 | | 資源佔用 | 較低,每個節點運行一個容器 | 較高,每個POD運行一個容器 | | 查詢便捷性 | 較高,可進行自定義的查詢、統計 | 高,可根據業務特點進行定製 | | 可定製性 | 低 | 高,每個POD單獨配置 | | 適用場景 | 功能單一型的集羣 | 大型、混合型、PAAS型集羣 |
在阿里內部,對於大型的PAAS集羣,主要使用Sidecar方式採集數據,相對隔離性、靈活性最好;而對與功能比較單一(部門內部/產品自建)的集羣,基本都採用DaemonSet的方式,資源佔用最低。
我們數據採集Agent使用的是自研的Logtail,Logtail用C++/Go編寫,相對開源Agent在資源消耗上具有非常大的優勢,但我們還一直在壓榨數據採集的資源消耗,尤其在容器場景。通常,為了提高打日誌和採集的性能,我們都使用本地SSD盤作為日誌盤。這裡我們可以做個簡答的計算:假設每個容器掛載1GB的SSD盤,1個物理機運行40個容器,那每臺物理機需要40GB的SSD作為日誌存儲,那5W物理機則會佔用2PB的SSD盤。
下面我們從問題排查的角度來具體展開平臺提供的核心功能。
排查問題的最佳手段是查日誌,大部分人腦海中最先想到的是用 grep 命令查找日誌中的一些關鍵錯誤信息, grep 是Linux程序員最受歡迎的命令之一,對於簡單的問題排查場景也非常實用。如果應用部署在多臺機器,那還會配合使用pgm、pssh等命令。然而這些命令對於Kubernetes這種動態、大規模的場景並不適用,主要問題有:
grep
我們在2009年開始在飛天平臺研發過程中,為夠解決大規模(例如5000臺)下的研發效率、問題診斷等問題,開始研支持超大規模的日誌查詢平臺,其中最主要的目標是「快」,對於幾十億的數據也能夠輕鬆在秒級完成。
在Kubernetes的場景中,每個容器的標準輸出(stdout)、文件都有對應的組合方式構成一個上下文分區,例如Namesapce+Pod+ContainerID+FileName/Stdout。
在日誌平臺上,應用方/用戶可以通過日誌接入、查詢、分析、可視化、告警等功能可以完成異常監控、問題調查與定位。但隨著計算形態、應用形態以及開發人員職責的不斷演變,尤其在近兩年Kubernetes、ServiceMesh、Serverless等技術的興起,問題的複雜度不斷上升,常規手段已經很難適用。於是我們開始嘗試向AIOps領域發展,例如時序分析、根因分析、日誌聚類等。
時序相關的函數主要用來發現問題,而查找問題根源還需要模式分析相關的方法(根因分析,Root Cause Analysis)。例如K8s集羣整體Ingress錯誤率(5XX比例)突然上升時,如何排查是因為某個服務問題、某個用戶引起、某個URL引起、某個瀏覽器引起、某些地域網路問題、某個節點異常還是整體性的問題?通常這種問題都需要人工從各個維度去排查,例如:
這種問題的排查在維度越多時複雜度越高,排查時間也越久,可能等到發現問題的時候影響面已經全面擴大了。因此我們開發了根因分析相關的函數,可以直接從多維數據中定位對目標(例如延遲、失敗率等)影響最大的一組(幾組)維度組合。
上面我們通過智能時序函數發現問題、通過根因分析定位到關鍵的維度組合,但涉及到最終的代碼問題排查,還是離不開日誌。當日誌的數據量很大時,一次次的手動過濾太過耗時,我們希望可以通過智能聚類的方式,把相似的日誌聚類到一起,最終可以通過聚類後的日誌快速掌握系統的運行狀態。
用戶最終選擇使用阿里雲Kubernetes日誌平臺的方案,使用Logtail的方案解決採集可靠性問題,通過公網、專線、全球加速的配合解決網路問題,由系統管理員使用DaemonSet統一採集所有系統組件級別的日誌,應用方只需使用CRD採集自己的業務日誌。對於平臺側,系統管理員可以訪問所有系統級別日誌,並進行統一的監控和告警;對於應用側,應用方不僅可以查到自己的業務日誌,還能訪問到和業務相關的中間件、Ingress、系統組件日誌,進行全鏈路的分析。
這些需求可以基於我們提供的OpenAPI以及各語言的SDK快速的實現,同時為了減少前端的工作量,平臺還提供Iframe嵌入的功能,支持直接將部分界面(例如查詢框、Dashboard)直接嵌入到業務部門自己的系統中。
推薦閱讀: