阿裡PB級Kubernetes日志平台建設實踐

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

計算形态的發展與日志系統的演進

在阿裡的十多年中，日志系統伴随着計算形态的發展在不斷演進，大緻分為3個主要階段：

阿裡PB級Kubernetes日志平台建設實踐阿裡PB級Kubernetes日志平台建設實踐計算形态的發展與日志系統的演進日志平台的重要性與建設目标阿裡日志平台現狀為何選擇自建 Kubernetes日志平台建設難點阿裡PB級Kubernetes日志平台建設實踐優秀應用案例分析未來工作展望

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

日志平台的重要性與建設目标

日志不僅僅是伺服器、容器、應用的Debug日志，也包括各類通路日志、中間件日志、使用者點選、IoT/移動端日志、資料庫Binlog等等。這些日志随着時效性的不同而應用在不同的場景：

準實時級别：這類日志主要用于準實時（秒級延遲）的線上監控、日志檢視、運維資料支撐、問題診斷等場景，最近兩年也出現了準實時的業務洞察，也是基于這類準實時的日志實作。
小時/天級别：當資料積累到小時/天級别的時候，這時一些T+1的分析工作就可以開始了，例如使用者留存分析、廣告投放效果分析、反欺詐、營運監測、使用者行為分析等。
季度/年級别：在阿裡，資料是我們最重要的資産，是以非常多的日志都是儲存一年以上或永久儲存，這類日志主要用于歸檔、審計、攻擊溯源、業務走勢分析、資料挖掘等。

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

阿裡日志平台現狀

目前阿裡的日志平台覆寫幾乎所有的産品線和産品，同時我們的産品也在雲上對外提供服務，已經服務了上萬家的企業。每天寫入流量16PB以上，對應日志行數40萬億+條，采集用戶端200萬，服務數千Kubernetes叢集，是國内最大的日志平台之一。

為何選擇自建

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

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

Kubernetes日志平台建設難點

圍繞着Kubernetes場景的需求，日志平台建設的難點主要有以下幾點：

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

Kubernetes日志資料采集

無論是在ITOM還是在未來的AIOps場景中，日志擷取都是其中必不可少的一個部分，資料源直接決定了後續應用的形态和功能。在十多年中，我們積累了一套實體機、虛拟機的日志采集經驗，但在Kubernetes中不能完全适用，這裡我們以問題的形式展開：

問題1：DaemonSet or Sidecar

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

DaemonSet方式：在K8S的每個node上部署日志agent，由agent采集所有容器的日志到服務端。
Sidecar方式：一個POD中運作一個sidecar的日志agent容器，用于采集該POD主容器産生的日志。

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

DaemonSet方式	Sidecar方式
采集日志類型	标準輸出+部分檔案	檔案
部署運維	一般，需維護DaemonSet	較高，每個需要采集日志的POD都需要部署sidecar容器
日志分類存儲	一般，可通過容器/路徑等映射	每個POD可單獨配置，靈活性高
多租戶隔離	一般，隻能通過配置間隔離	強，通過容器進行隔離，可單獨配置設定資源
支援叢集規模	中小型規模，業務數最多支援百級别	無限制
資源占用	較低，每個節點運作一個容器	較高，每個POD運作一個容器
查詢便捷性	較高，可進行自定義的查詢、統計	高，可根據業務特點進行定制
可定制性	低	高，每個POD單獨配置
适用場景	功能單一型的叢集	大型、混合型、PAAS型叢集

在阿裡内部，對于大型的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采集到服務端。這種采集的好處有：

實體機無需為容器提供日志盤，真正實作日志無盤化。
應用程式視角看到的還是普通的檔案系統，無需做任何額外改造。
資料采集繞過磁盤，直接從記憶體中将資料采集到服務端。
所有的資料都存在服務端，服務端支援橫向擴充，對于應用來說他們看到的日志盤具有無線存儲空間。

問題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個主要過程：

百規模：在好幾年前，Logtail剛開始部署時，也就在幾百台實體機上運作，這個時期的Logtail和其他主流的Agent一樣，主要完成資料采集的功能，主要流程為資料輸入、處理、聚合、發送，這個時期的管理基本靠手，采集出現問題的時候人工登入機器去看問題。
萬規模：當越來越多的應用方接入，每台機器上可能會有多個應用方采集不同類型的資料，手動配置的接入過程也越來越難以維護。是以我們重點在多租戶隔離以及中心化的配置管理，同時增加了很多控制相關的手段，比如限流、降級等。
百萬規模：當部署量打到百萬級别的時候，異常發生已經成為常态，我們更需要的是靠一系列的監控、可靠性保證機制、自動化的運維管理工具，讓這些機制、工具來自動完成Agent安裝、監控、自恢複等一系列工作，真正做到甩手掌櫃。

Kubernetes日志平台架構

上圖是阿裡Kubernetes日志平台的整體架構，從底到上分為日志接入層、平台核心層以及方案整合層：

平台提供了非常多的手段用來接入各種類型的日志資料。不僅僅隻有Kubernetes中的日志，同時還包括和Kubernetes業務相關的所有日志，例如移動端日志、Web端應用點選日志、IoT日志等等。所有資料支援主動Push、被動Agent采集，Agent不僅支援我們自研的Logtail，也支援使用開源Agent（Logstash、Fluentd、Filebeats等）。
日志首先會到達平台提供的實時隊列中，類似于Kafka的consumer group，我們提供實時資料訂閱的功能，使用者可以基于該功能實作ETL的相關需求。平台最核心的功能包括：
1. 實時搜尋：類似于搜尋引擎的方式，支援從所有日志中根據關鍵詞查找，支援超大規模（PB級）。
2. 實時分析：基于SQL92文法提供互動式的日志分析方法。
3. 機器學習：提供時序預測、時序聚類、根因分析、日志聚合等智能分析方法。
4. 流計算：對接各類流計算引擎，例如：Flink、Spark Stream、Storm等。
5. 離線分析：對接離線分析引擎，例如Hadoop、Max Compute等。
基于全方位的資料源以及平台提供的核心功能，并結合Kubernetes日志特點以及應用場景，向上建構Kubernetes日志的通用解決方案，例如：審計日志、Ingress日志分析、ServiceMesh日志等等。同時對于有特定需求的應用方/使用者，可直接基于平台提供的OpenAPI建構上層方案，例如Trace系統、性能分析系統等。

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

PB級日志查詢

排查問題的最佳手段是查日志，大部分人腦海中最先想到的是用

grep

指令查找日志中的一些關鍵錯誤資訊，

grep

是Linux程式員最受歡迎的指令之一，對于簡單的問題排查場景也非常實用。如果應用部署在多台機器，那還會配合使用pgm、pssh等指令。然而這些指令對于Kubernetes這種動态、大規模的場景并不适用，主要問題有：

查詢不夠靈活，grep指令很難實作各種邏輯條件的組合。
grep是針對純文字的分析手段，很難将日志格式化成對應的類型，例如Long、Double甚至JSON類型。
grep指令的前提條件是日志存儲在磁盤上。而在Kubernetes中，應用的本地日志空間都很小，并且服務也會動态的遷移、伸縮，本地的資料源很可能會不存在。
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标準實作，在此基礎上擴充了很多針對日志分析場景的進階函數，例如：

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

智能日志分析

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

時序分析

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

阿裡PB級Kubernetes日志平台建設實踐阿裡PB級Kubernetes日志平台建設實踐計算形态的發展與日志系統的演進日志平台的重要性與建設目标阿裡日志平台現狀為何選擇自建 Kubernetes日志平台建設難點阿裡PB級Kubernetes日志平台建設實踐優秀應用案例分析未來工作展望

根因分析

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

按照Service去Group，檢視Service之間的錯誤率有無差别
沒有差别，然後排查URL
還沒有，按照浏覽器
浏覽器有點關系，繼續看移動端、PC端
移動端錯誤率比較高，看看是Android還是IOS
...

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

為了更加精确的定位問題，我們還支援對比兩個模式的差異，例如今天發生異常時，和昨天正常的模式進行對比，快速找到問題的原因；在釋出時進行藍綠對比以及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日志平台在内外部已經有非常多的應用，未來我們還将繼續打磨平台，為應用方/使用者提供更加完美的方案，後續工作主要集中在以下幾點：

資料采集進一步精細化，持續優化可靠性和資源消耗，做到極緻化的多租戶隔離，争取在PAAS平台使用DaemonSet采集所有應用的日志。
提供更加便捷、智能的資料清洗服務，在平台内部就可以完成異構資料的清洗、規整等工作。
建構面向Ops領域的、可自動更新的、支援異構資料的知識圖譜，讓問題排查的經驗可以積累在知識庫中，實作異常搜尋與推理。
提供互動式的訓練平台，建構更加智能的Automation能力，真正實作Ops的閉環。