摘要： 將在QCon上分享的《阿里PB級Kubernetes日誌平臺建設實踐》整理出來，分享給大家。

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

QCon是由InfoQ主辦的綜合性技術盛會，每年在倫敦、北京、紐約、聖保羅、上海、舊金山召開。有幸參加這次QCon10週年大會，作為分享嘉賓在劉宇老師的運維專場發表了《阿里PB級Kubernetes日誌平臺建設實踐》，現將PPT和文字稿整理下來，希望和更多的愛好者分享。

計算形態的發展與日誌系統的演進

在阿里的十多年中，日誌系統伴隨著計算形態的發展在不斷演進，大致分為3個主要階段：

  1. 在單機時代，幾乎所有的應用都是單機部署，當服務壓力增大時，只能切換更高規格的IBM小型機。日誌作為應用系統的一部分，主要用作程序Debug，通常結合grep等Linux常見的文本命令進行分析。
  2. 隨著單機系統成為制約阿里業務發展的瓶頸，為了真正的Scale out，飛天項目啟動：2009年開始了飛天的第一行代碼，2013年飛天5K項目正式上線。在這個階段各個業務開始了分散式改造，服務之間的調用也從本地變為分散式，為了更好的管理、調試、分析分散式應用，我們開發了Trace（分散式鏈路追蹤）系統、各式各樣的監控系統，這些系統的統一特點是將所有的日誌（包括Metric等）進行集中化的存儲。
  3. 為了支持更快的開發、迭代效率，近年來我們開始了容器化改造，並開始了擁抱Kubernetes生態、業務全量上雲、Serverless等工作。要實現這些改造，一個非常重要的部分是可觀察性的工作，而日誌是作為分析系統運行過程的最佳方式。在這階段，日誌無論從規模、種類都呈現爆炸式的增長，對日誌進行數字化、智能化分析的需求也越來越高，因此統一的日誌平臺應運而生。

日誌平臺的重要性與建設目標

日誌不僅僅是伺服器、容器、應用的Debug日誌，也包括各類訪問日誌、中間件日誌、用戶點擊、IoT/移動端日誌、資料庫Binlog等等。這些日誌隨著時效性的不同而應用在不同的場景：
  1. 準實時級別：這類日誌主要用於準實時（秒級延遲）的線上監控、日誌查看、運維數據支撐、問題診斷等場景，最近兩年也出現了準實時的業務洞察，也是基於這類準實時的日誌實現。
  2. 小時/天級別：當數據積累到小時/天級別的時候，這時一些T+1的分析工作就可以開始了，例如用戶留存分析、廣告投放效果分析、反欺詐、運營監測、用戶行為分析等。
  3. 季度/年級別：在阿里，數據是我們最重要的資產，因此非常多的日誌都是保存一年以上或永久保存，這類日誌主要用於歸檔、審計、攻擊溯源、業務走勢分析、數據挖掘等。

在阿里，幾乎所有的業務角色都會涉及到各式各樣的日誌數據，為了支撐各類應用場景，我們開發了非常多的工具和功能：日誌實時分析、鏈路追蹤、監控、數據清洗、流計算、離線計算、BI系統、審計系統等等。其中很多系統都非常成熟，日誌平臺主要專註於智能分析、監控等實時的場景，其他功能通常打通的形式支持。

阿里日誌平臺現狀

目前阿里的日誌平臺覆蓋幾乎所有的產品線和產品，同時我們的產品也在雲上對外提供服務，已經服務了上萬家的企業。每天寫入流量16PB以上，對應日誌行數40萬億+條，採集客戶端200萬，服務數千Kubernetes集羣，是國內最大的日誌平臺之一。

為何選擇自建

日誌系統存在了十多年，目前也有非常多的開源的方案，例如最典型的ELK(Elastic Search、Logstash、Kibana)，通常一個日誌系統具備以下功能：日誌收集/解析、查詢與檢索、日誌分析、可視化/告警等，這些功能通過開源軟體的組合都可以實現，但最終我們選擇自建，主要有幾下幾點考慮：

  1. 數據規模：這些開源日誌系統可以很好的支持小規模的場景，但很難支持阿里這種超大規模（PB級）的場景。
  2. 資源消耗：我們擁有百萬規模的伺服器/容器，同時日誌平臺的集羣規模也很大，我們需要減少對於採集以及平臺自身的資源消耗。
  3. 多租戶隔離：開源軟體搭建的系統大部分都不是為了多租戶而設計的，當非常多的業務 / 系統使用日誌平臺時，很容易因為部分用戶的大流量 / 不恰當使用而導致打爆整個集羣。
  4. 運維複雜度：在阿里內部有一套非常完整的服務部署和管理系統，基於內部組件實現會具備非常好的運維複雜度。
  5. 高級分析需求：日誌系統的功能幾乎全部來源與對應的場景需求，有很多特殊場景的高級分析需求開源軟體沒辦法很好的支持，例如：上下文、智能分析、日誌類特殊分析函數等等。

Kubernetes日誌平臺建設難點

圍繞著Kubernetes場景的需求，日誌平臺建設的難點主要有以下幾點：

  1. 日誌採集：採集在Kubernetes中極其關鍵和複雜，主要因為Kubernetes是一個高度複雜的場景，K8s中有各式各樣的子系統，上層業務支持各種語言和框架，同時日誌採集需要儘可能的和Kubernetes系統打通，用K8的形式來完成數據採集。
  2. 資源消耗：在K8s中，服務通常都會拆的很小，因此數據採集對於服務自身的資源消耗要儘可能的少。這裡我們簡單的做一個計算，假設有100W個服務實例，沒個採集Agent減少1M的內存、1%的CPU開銷，那整體會減少1TB的內存和10000個CPU核心。
  3. 運維代價：運維一套日誌平臺的代價相當之大，因此我們不希望每個用戶搭建一個Kubernetes集羣時還需再運維一個獨立的日誌平臺系統。因此日誌平臺一定是要SaaS化的，應用方/用戶只需要簡單的操作Web頁面就能完成數據採集、分析的一整套流程。
  4. 便捷使用：日誌系統最核心的功能是問題排查，問題排查的速度直接決定了工作效率、損失大小，在K8s場景中，更需要一套高性能、智能分析的功能來幫助用戶快速定位問題，同時提供一系列簡單有效的可視化手段進行輔助。

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

Kubernetes日誌數據採集

無論是在ITOM還是在未來的AIOps場景中，日誌獲取都是其中必不可少的一個部分，數據源直接決定了後續應用的形態和功能。在十多年中，我們積累了一套物理機、虛擬機的日誌採集經驗，但在Kubernetes中不能完全適用，這裡我們以問題的形式展開：

問題1：DaemonSet or Sidecar

日誌最主要的採集工具是Agent，在Kubernetes場景下，通常會分為兩種採集方式：

  1. DaemonSet方式：在K8S的每個node上部署日誌agent，由agent採集所有容器的日誌到服務端。
  2. Sidecar方式：一個POD中運行一個sidecar的日誌agent容器，用於採集該POD主容器產生的日誌。

每種採集方式都有其對應的優缺點，這裡簡單總結如下：

在阿里內部，對於大型的PAAS集羣，主要使用Sidecar方式採集數據，相對隔離性、靈活性最好；而對與功能比較單一（部門內部/產品自建）的集羣，基本都採用DaemonSet的方式，資源佔用最低。

問題2：如何降低資源消耗

我們數據採集Agent使用的是自研的Logtail，Logtail用C++/Go編寫，相對開源Agent在資源消耗上具有非常大的優勢，但我們還一直在壓榨數據採集的資源消耗，尤其在容器場景。通常，為了提高打日誌和採集的性能，我們都使用本地SSD盤作為日誌盤。這裡我們可以做個簡答的計算：假設每個容器掛載1GB的SSD盤，1個物理機運行40個容器，那每臺物理機需要40GB的SSD作為日誌存儲，那5W物理機則會佔用2PB的SSD盤。

為了降低這部分資源消耗，我們和螞蟻金服團隊的同學們一起開發了FUSE的日誌採集方式，使用FUSE（Filesystem in Userspace，用戶態文件系統）虛擬化出日誌盤，應用直接將日誌寫入到虛擬的日誌盤中，最終數據將直接從內存中被Logtail採集到服務端。這種採集的好處有：

  1. 物理機無需為容器提供日誌盤，真正實現日誌無盤化。
  2. 應用程序視角看到的還是普通的文件系統，無需做任何額外改造。
  3. 數據採集繞過磁碟，直接從內存中將數據採集到服務端。
  4. 所有的數據都存在服務端，服務端支持橫向擴展，對於應用來說他們看到的日誌盤具有無線存儲空間。

問題3：如何與Kubernetes無縫集成

Kubernetes一個非常大的突破是使用聲明式的API來完成服務部署、集羣管理等工作。但在K8s集羣環境下，業務應用/服務/組件的持續集成和自動發布已經成為常態，使用控制檯或SDK操作採集配置的方式很難與各類CI、編排框架集成，導致業務應用發布後用戶只能通過控制檯手動配置的方式部署與之對應的日誌採集配置。因此我們基於Kubernetes的CRD（CustomResourceDefinition）擴展實現了採集配置的Operator，用戶可以直接使用K8s API、Yaml、kubectl、Helm等方式直接配置採集方式，真正把日誌採集融入到Kubernetes系統中，實現無縫集成。

問題4：如何管理百萬級Logtail

對於人才管理有個經典的原則：10個人要用心良苦，100個人要殺伐果斷，1000個人要甩手掌櫃。而同樣對於Logtail這款日誌採集Agent的管理也是如此，這裡我們分為3個主要過程：
  1. 百規模：在好幾年前，Logtail剛開始部署時，也就在幾百臺物理機上運行，這個時期的Logtail和其他主流的Agent一樣，主要完成數據採集的功能，主要流程為數據輸入、處理、聚合、發送，這個時期的管理基本靠手，採集出現問題的時候人工登錄機器去看問題。
  2. 萬規模：當越來越多的應用方接入，每臺機器上可能會有多個應用方採集不同類型的數據，手動配置的接入過程也越來越難以維護。因此我們重點在多租戶隔離以及中心化的配置管理，同時增加了很多控制相關的手段，比如限流、降級等。
  3. 百萬規模：當部署量打到百萬級別的時候，異常發生已經成為常態，我們更需要的是靠一系列的監控、可靠性保證機制、自動化的運維管理工具，讓這些機制、工具來自動完成Agent安裝、監控、自恢復等一系列工作，真正做到甩手掌櫃。

Kubernetes日誌平臺架構

上圖是阿里Kubernetes日誌平臺的整體架構，從底到上分為日誌接入層、平臺核心層以及方案整合層：
  1. 平臺提供了非常多的手段用來接入各種類型的日誌數據。不僅僅只有Kubernetes中的日誌，同時還包括和Kubernetes業務相關的所有日誌，例如移動端日誌、Web端應用點擊日誌、IoT日誌等等。所有數據支持主動Push、被動Agent採集，Agent不僅支持我們自研的Logtail，也支持使用開源Agent（Logstash、Fluentd、Filebeats等）。
  2. 日誌首先會到達平臺提供的實時隊列中，類似於Kafka的consumer group，我們提供實時數據訂閱的功能，用戶可以基於該功能實現ETL的相關需求。平臺最核心的功能包括：

    1. 實時搜索：類似於搜索引擎的方式，支持從所有日誌中根據關鍵詞查找，支持超大規模（PB級）。
    2. 實時分析：基於SQL92語法提供互動式的日誌分析方法。
    3. 機器學習：提供時序預測、時序聚類、根因分析、日誌聚合等智能分析方法。
    4. 流計算：對接各類流計算引擎，例如：Flink、Spark Stream、Storm等。
    5. 離線分析：對接離線分析引擎，例如Hadoop、Max Compute等。

  1. 基於全方位的數據源以及平臺提供的核心功能，並結合Kubernetes日誌特點以及應用場景，向上構建Kubernetes日誌的通用解決方案，例如：審計日誌、Ingress日誌分析、ServiceMesh日誌等等。同時對於有特定需求的應用方/用戶，可直接基於平臺提供的OpenAPI構建上層方案，例如Trace系統、性能分析系統等。

下面我們從問題排查的角度來具體展開平臺提供的核心功能。

PB級日誌查詢

排查問題的最佳手段是查日誌，大部分人腦海中最先想到的是用 grep 命令查找日誌中的一些關鍵錯誤信息， grep 是Linux程序員最受歡迎的命令之一，對於簡單的問題排查場景也非常實用。如果應用部署在多臺機器，那還會配合使用pgm、pssh等命令。然而這些命令對於Kubernetes這種動態、大規模的場景並不適用，主要問題有：
  1. 查詢不夠靈活，grep命令很難實現各種邏輯條件的組合。
  2. grep是針對純文本的分析手段，很難將日誌格式化成對應的類型，例如Long、Double甚至JSON類型。
  3. grep命令的前提條件是日誌存儲在磁碟上。而在Kubernetes中，應用的本地日誌空間都很小，並且服務也會動態的遷移、伸縮，本地的數據源很可能會不存在。
  4. grep是典型的全量掃描方式，如果數據量在1GB以內，查詢時間還可以接受，但當數據量上升到TB甚至PB時，必須依賴搜索引擎的技術才能工作。

我們在2009年開始在飛天平臺研發過程中，為夠解決大規模（例如5000臺）下的研發效率、問題診斷等問題，開始研支持超大規模的日誌查詢平臺，其中最主要的目標是「快」，對於幾十億的數據也能夠輕鬆在秒級完成。

日誌上下文

當我們通過查詢的方式定位到關鍵的日誌後，需要分析當時系統的行為，並還原出當時的現場情況。而現場其實就是當時的日誌上下文，例如：
  • 一個錯誤，同一個日誌文件中的前後數據
  • 一行LogAppender中輸出，同一個進程順序輸出到日誌模塊前後順序
  • 一次請求，同一個Session組合
  • 一次跨服務請求，同一個TraceId組合

在Kubernetes的場景中，每個容器的標準輸出（stdout）、文件都有對應的組合方式構成一個上下文分區，例如Namesapce+Pod+ContainerID+FileName/Stdout。

為支持上下文，我們在採集協議中對每個最小區分單元會帶上一個全局唯一併且單調遞增的遊標，這個遊標對單機日誌、Docker、K8S以及移動端SDK、Log4J/LogBack等輸出中有不一樣的形式。

為日誌而生的分析引擎

在一些複雜的場景中，我們需要對日誌中的數據進行統計來發現其中規律。例如根據ClientIP進行聚合來查找攻擊源IP、將數據聚合計算P99/P9999延遲、從多個維度組合分析等。傳統的方式需要配合流計算或離線計算的引擎進行聚合計算，再對接可視化系統進行圖形化展示或對接告警系統。這種方式用戶需要維護多套系統，數據實時性變差，並且各個系統間的銜接很容易出現問題。

因此我們平臺原生集成了日誌分析、可視化、告警等相關的功能，儘可能減少用戶配置鏈路。通過多年的實踐，我們發現用戶最容易接受的還是SQL的分析方式，因此我們分析基於SQL92標準實現，在此基礎上擴展了很多針對日誌分析場景的高級函數，例如：

  1. 同比環比：前後數據對比是日誌分析中最常用的方式之一，我們提供了同比/環比函數，一個函數即可計算今日PV同比昨日、上週的增幅。
  2. IP地理函數：基於淘寶高精度IP地理庫，提供IP到國家、省、市、運營商、經緯度等的轉換，例如常見的Nginx訪問日誌、K8s Ingress訪問日誌中的remote-ip可以直接用來分析地理位置分佈。
  3. Join外部數據源：將日誌和 MySQL、CSV等做Join分析，例如根據ID從資料庫中查找用戶對應的信息、和CMDB中的網路架構數據做關聯等。
  4. 安全函數：支持日誌安全分析中的常見方式，例如高危IP庫查找、SQL注入分析、高危SQL檢測等。

智能日誌分析

在日誌平臺上，應用方/用戶可以通過日誌接入、查詢、分析、可視化、告警等功能可以完成異常監控、問題調查與定位。但隨著計算形態、應用形態以及開發人員職責的不斷演變，尤其在近兩年Kubernetes、ServiceMesh、Serverless等技術的興起，問題的複雜度不斷上升，常規手段已經很難適用。於是我們開始嘗試向AIOps領域發展，例如時序分析、根因分析、日誌聚類等。

時序分析

  • 通過時序預測相關方法，我們可以對CPU、存儲進行時序建模，進行更加智能的調度，讓整體利用率如絲般平滑；存儲團隊通過對磁碟空間的增長預測，提前制定預算並採購機器；在做部門/產品預算時，根據歷年賬單預測全年的消費，進行更優的成本控制。
  • 稍微大一些的服務可能會有幾百、上千甚至上萬臺的機器，通過人肉很難發現每臺機器行為（時序）的區別，而通過時序聚類就可以快速得到集羣的行為分佈，定位出異常的機器；同時對於單條時序，可以通過時序異常相關的檢測方法，自動定位異常點。

根因分析

時序相關的函數主要用來發現問題，而查找問題根源還需要模式分析相關的方法（根因分析，Root Cause Analysis）。例如K8s集羣整體Ingress錯誤率（5XX比例）突然上升時，如何排查是因為某個服務問題、某個用戶引起、某個URL引起、某個瀏覽器引起、某些地域網路問題、某個節點異常還是整體性的問題？通常這種問題都需要人工從各個維度去排查，例如：

  1. 按照Service去Group，查看Service之間的錯誤率有無差別
  2. 沒有差別，然後排查URL
  3. 還沒有，按照瀏覽器
  4. 瀏覽器有點關係，繼續看移動端、PC端
  5. 移動端錯誤率比較高，看看是Android還是IOS
  6. ...

這種問題的排查在維度越多時複雜度越高，排查時間也越久，可能等到發現問題的時候影響面已經全面擴大了。因此我們開發了根因分析相關的函數，可以直接從多維數據中定位對目標（例如延遲、失敗率等）影響最大的一組（幾組）維度組合。

為了更加精確的定位問題，我們還支持對比兩個模式的差異，例如今天發生異常時，和昨天正常的模式進行對比，快速找到問題的原因；在發布時進行藍綠對比以及A/B Test。

智能日誌聚類

上面我們通過智能時序函數發現問題、通過根因分析定位到關鍵的維度組合，但涉及到最終的代碼問題排查，還是離不開日誌。當日誌的數據量很大時，一次次的手動過濾太過耗時，我們希望可以通過智能聚類的方式，把相似的日誌聚類到一起，最終可以通過聚類後的日誌快速掌握系統的運行狀態。

上下游生態對接

Kubernetes日誌平臺主要的目標在解決DevOps、Net/Site Ops、Sec Ops等問題上，然而這些並不能滿足所有用戶對於日誌的所有需求，例如超大規模的日誌分析、BI分析、極其龐大的安全規則過濾等。平臺的強大更多的是生態的強大，我們通過對接上下游廣泛的生態來滿足用戶越來越多的日誌需求和場景。

優秀應用案例分析

案例1：混合雲PAAS平臺日誌管理

某大型遊戲公司在進行技術架構升級，大部分業務會遷移到基於Kubernetes搭建的PAAS平臺上，為提高平臺整體的可用性，用戶採集混合雲架構，對於日誌的統一建設與管理存在很大困難：
  • 眾多內部應用方：不希望應用方過多的接觸日誌採集、存儲等細節，並且能夠為應用方提供全鏈路的日誌；
  • 1000+微服務：需要支持大規模的日誌採集方式；
  • 多雲+線下IDC：希望多個雲廠商以及線下IDC採用的是同一套採集方案；
  • 應用週期短：部分應用的運行生命週期極短，需要能夠及時將數據採集到服務端；
  • 海外數據回國：海外節點的日誌回國分析，需儘可能保證傳輸穩定性和可靠性。

用戶最終選擇使用阿里雲Kubernetes日誌平臺的方案，使用Logtail的方案解決採集可靠性問題，通過公網、專線、全球加速的配合解決網路問題，由系統管理員使用DaemonSet統一採集所有系統組件級別的日誌，應用方只需使用CRD採集自己的業務日誌。對於平臺側，系統管理員可以訪問所有系統級別日誌，並進行統一的監控和告警；對於應用側，應用方不僅可以查到自己的業務日誌，還能訪問到和業務相關的中間件、Ingress、系統組件日誌，進行全鏈路的分析。

案例2：二次開發日誌管理平臺

在阿里有很多大的業務部門希望基於我們標準的日誌平臺進行二次開發，來滿足他們部門的一些特殊需求，例如：
  • 通過各類規則以及介面限制規範數據接入。
  • 通過TraceID將整個調用鏈串聯，構建Trace平臺。
  • 部門內部多用戶的許可權細化管理。
  • 部門內部各個子部門的成本結算。
  • 與一內部些管控、運維繫統打通。

這些需求可以基於我們提供的OpenAPI以及各語言的SDK快速的實現，同時為了減少前端的工作量，平臺還提供Iframe嵌入的功能，支持直接將部分界面（例如查詢框、Dashboard）直接嵌入到業務部門自己的系統中。

未來工作展望

目前阿里Kubernetes日誌平臺在內外部已經有非常多的應用，未來我們還將繼續打磨平臺，為應用方/用戶提供更加完美的方案，後續工作主要集中在以下幾點：
  1. 數據採集進一步精細化，持續優化可靠性和資源消耗，做到極致化的多租戶隔離，爭取在PAAS平臺使用DaemonSet採集所有應用的日誌。
  2. 提供更加便捷、智能的數據清洗服務，在平臺內部就可以完成異構數據的清洗、規整等工作。
  3. 構建面向Ops領域的、可自動更新的、支持異構數據的知識圖譜，讓問題排查的經驗可以積累在知識庫中，實現異常搜索與推理。
  4. 提供互動式的訓練平臺，構建更加智能的Automation能力，真正實現Ops的閉環。

相關工作與參考
  • 阿里雲日誌服務 aliyun.com/product/sls
  • 阿里雲Kubernetes : aliyun.com/product/kube
  • Kubernetes 審計日誌方案 : yq.aliyun.com/articles/
  • Kubernetes Ingress日誌方案 : yq.aliyun.com/articles/
  • 數據採集全球加速 : yq.aliyun.com/articles/
  • 日誌採集CRD配置： yq.aliyun.com/articles/

本文作者：元乙

原文鏈接

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

本文為雲棲社區原創內容，未經允許不得轉載。


推薦閱讀：
相關文章