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

時間 2019-12-05

原文原文鏈接

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

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

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

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

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

在單機時代，幾乎全部的應用都是單機部署，當服務壓力增大時，只能切換更高規格的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場景中，更須要一套高性能、智能分析的功能來幫助用戶快速定位問題，同時提供一系列簡單有效的可視化手段進行輔助。

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

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、存儲進行時序建模，進行更加智能的調度，讓總體利用率如絲般平滑；存儲團隊經過對磁盤空間的增加預測，提早制定預算並採購機器；在作部門/產品預算時，根據歷年帳單預測整年的消費，進行更優的成本控制。
稍微大一些的服務可能會有幾百、上千甚至上萬臺的機器，經過人肉很難發現每臺機器行爲（時序）的區別，而經過時序聚類就能夠快速獲得集羣的行爲分佈，定位出異常的機器；同時對於單條時序，能夠經過時序異常相關的檢測方法，自動定位異常點。

根因分析

時序相關的函數主要用來發現問題，而查找問題根源還須要模式分析相關的方法（根因分析，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：二次開發日誌管理平臺

在阿里有不少大的業務部門但願基於咱們標準的日誌平臺進行二次開發，來知足他們部門的一些特殊需求，例如：