一文看懂 K8s 日志系統設計和實踐

作者 | 元乙  阿裡雲存儲服務技術專家

導讀：上一篇文章 《6 個 K8s 日志系統建設中的典型問題，你遇到過幾個？ 》 中我們介紹了為什麼需要一個日志系統、為什麼雲原生下的日志系統如此重要以及雲原生背景下日志系統的建設難點，相信 DevOps、SRE、運維等同學看了之後深有體會。本篇文章單刀直入，會直接跟大家分享一下如何在雲原生的場景下搭建一個靈活、功能強大、可靠、可擴容的日志系統。

需求驅動架構設計

技術架構，是将産品需求轉變為技術實作的過程。對于所有的架構師而言，能夠将産品需求分析透徹是非常基本也是非常重要的一點。很多系統剛建成沒多久就要被推翻，最根本的原因還是沒有解決好産品真正的需求。

我所在的日志服務團隊在日志這塊有近10年的經驗，幾乎服務阿裡内部所有的團隊，涉及電商、支付、物流、雲計算、遊戲、即時通訊、IoT等領域，多年來的産品功能的優化和疊代都是基于各個團隊的日志需求變化。

有幸我們最近幾年在阿裡雲上實作了産品化，服務了數以萬計的企業使用者，包括國内各大直播類、短視訊、新聞媒體、遊戲等行業Top1網際網路客戶。産品功能從服務一個公司到服務上萬家公司會有質的差别，上雲促使我們更加深入的去思考：究竟哪些功能是日志這個平台需要去為使用者去解決的，日志最核心的訴求是什麼，如何去滿足各行各業、各種不同業務角色的需求...

需求分解與功能設計

上一節中我們分析了公司内各個不同角色對于日志的相關需求，總結起來有以下幾點：

1. 支援各種日志格式、資料源的采集，包括非K8s
2. 能夠快速的查找/定位問題日志
3. 能夠将各種格式的半結構化/非結構化日志格式化，并支援快速的統計分析、可視化
4. 支援通過日志進行實時計算并獲得一些業務名額，并支援基于業務名額實時的告警（其實本質就是APM）
5. 支援對于超大規模的日志進行各種次元的關聯分析，可接受一定時間的延遲
6. 能夠便捷的對接各種外部系統或支援自定義的擷取資料，例如對接第三方審計系統
7. 能夠基于日志以及相關的時序資訊，實作智能的告警、預測、根因分析等，并能夠支援自定義的離線訓練方式以獲得更好的效果

為滿足上述這些功能需求，日志平台上必須具備的功能功能子產品有：

1. 全方位日志采集，支援DaemonSet、Sidecar各種采集方式以應對不同的采集需求，同時支援Web、移動端、IoT、實體機/虛拟機各種資料源的采集；
2. 日志實時通道，這個是為了對接上下遊所必備的功能，保證日志能夠被多種系統所便捷的使用；
3. 資料清洗（ETL: Extract，Transform，Load），對各種格式的日志進行清洗，支援過濾、富化、轉換、補漏、分裂、聚合等；
4. 日志展現與搜尋，這是所有日志平台必須具備的功能，能夠根據關鍵詞快速的定位到日志并檢視日志上下文，看似簡單的功能卻最難做好；
5. 實時分析，搜尋隻能完成一些定位到問題，而分析統計功能可以幫助快速分析問題的根因，同時可以用于快速的計算一些業務名額；
6. 流計算，通常我們都會使用流計算架構（Flink、Storm、Spark Stream等）來計算一些實時的名額或對資料進行一些自定義的清洗等；
7. 離線分析，營運、安全相關的需求都需要對大量的曆史日志進行各種次元的關聯計算，目前隻有T+1的離線分析引擎能夠完成；
8. 機器學習架構，能夠便捷、快速的将曆史的日志對接到機器學習架構進行離線訓練，并将訓練後的結果加載到線上實時的算法庫中。

開源方案設計

借助于強大的開源社群，我們可以很容易基于開源軟體的組合來實作這樣一套日志平台，上圖是一個非常典型的以ELK為核心的日志平台方案：

• 利用FileBeats、Fluentd等采集Agent實作容器上的資料統一收集。
• 為了提供更加豐富的上下遊以及緩沖能力，可以使用kafka作為資料采集的接收端。
• 采集到的原始資料還需要進一步的清洗，可以使用Logstash或者Flink訂閱Kafka中的資料，清洗完畢後再寫入kafka中。
• 清洗後的資料可以對接ElasticSearch來做實時的查詢檢索、對接Flink來計算實時的名額和告警、對接Hadoop來做離線的資料分析、對接TensorFlow來做離線模型訓練。
• 資料的可視化可以使用grafana、kibana等常用的可視化元件。

為什麼我們選擇自研

采用開源軟體的組合是非常高效的方案，得益于強大的開源社群以及龐大使用者群體的經驗積累，我們可以很快搭建出這樣一套系統，并且可以滿足我們絕大部分的需求。

當我們把這套系統部署好，能夠把日志從容器上采集上來、elasticsearch上能夠查到、Hadoop上能夠成功執行SQL、Grafana上能看到圖、告警短信能收到......完成上述流程打通後，加加班可能隻需要花費幾天的時間，當系統終于跑通的時候，這時候終于可以長舒一口氣，躺在辦公椅上放松放松。

然而理想很豐滿現實很骨感，當我們預發通了，測試完了上到生産，開始接入第一個應用，逐漸更多的應用接入，越來越多的人開始使用......這時候很多問題都可能暴露出來：

• 随着業務量的上漲，日志量也越來越大，Kakfa和ES要不斷擴容，同時同步Kafka到ES的Connector也需要擴容，最煩的是采集Agent，每台機器上部署的DaemonSet Fluentd根本沒辦法擴容，到了單Agent瓶頸就沒辦法了，隻能換Sidecar，換Sidecar工作量大不說，還會帶來一系列其他的問題，比如怎麼和CICD系統內建、資源消耗、配置規劃、stdout采集不支援等等。
• 從剛開始上的邊緣業務，慢慢更多的核心業務接入，對于日志的可靠性要求越來越高，經常有研發反應從ES上查不到資料、營運說統計出來的報表不準、安全說拿到的資料不是實時的......每次問題的排查都要經過采集、隊列、清洗、傳輸等等非常多的路徑，排查代價非常高。同時還要為日志系統搭建一套監控方案，能夠即時發現問題，而且這套方案還不能基于日志系統，不能自依賴。
• 當越來越多的開發開始用日志平台調查問題時，經常會出現因為某1-2個人送出一個大的查詢，導緻系統整體負載上升，其他人的查詢都會被Block，甚至出現Full GC等情況。這時候一些大能力的公司會對ES進行改造，來支援多租戶隔離；或者為不同的業務部門搭建不同的ES叢集，最後又要運維多個ES叢集，工作量還是很大。
• 當投入了很多人力，終于能夠把日志平台維持日常使用，這時候公司财務找過來了，說我們用了非常多的機器，成本太大。這時候開始要優化成本，但是思來想去就是需要這麼多台機器，每天大部分的機器水位都在20%-30%，但是高峰的水位可能到70%，是以不能撤，撤了高峰頂不住，這時候隻能搞搞削峰填谷，又是一堆工作量。

上述這些是一家中等規模的網際網路企業在日志平台建設中經常會遇到的問題，在阿裡這些問題會放大非常多倍：

• 比如面對雙十一的流量，市面上所有的開源軟體都無法滿足我們那麼大流量的需求。
• 面對阿裡内部上萬個業務應用，幾千名工程師同時使用，并發和多租戶隔離我們必須要做到極緻。
• 面對非常多核心的訂單、交易等場景，整個鍊路的穩定性必須要求3個9甚至4個9的可用性。
• 每天如此大的資料量，對于成本的優化顯得極為重要，10%的成本優化帶來的收益可能就有上億。

阿裡K8s日志方案

針對上述的一些問題，我們經過多年的時間，開發并打磨出這樣一套K8s日志方案：

1. 使用我們自研的日志采集Agent Logtail實作K8s全方位的資料采集，目前Logtail在集團内有數百萬的全量部署，性能、穩定性經過多次雙十一金融級考驗。
2. 化繁為簡，資料隊列、清洗加工、實時檢索、實時分析、AI算法等原生內建，而不是基于各種開源軟體搭積木的形式實，大大降低了資料鍊路長度，鍊路長度的降低也意味着出錯可能性的減少。
3. 隊列、清洗加工、檢索、分析、AI引擎等全部針對日志場景深度定制優化，滿足大吞吐、動态擴容、億級日志秒級可查、低成本、高可用性等需求。
4. 對于流式計算、離線分析場景這種通用需求，無論是開源還是阿裡内部都有非常成熟的産品，我們通過無縫對接的方式來支援，目前日志服務支援了數十種下遊的開源、雲上産品的對接。

這套系統目前支撐了整個阿裡集團、螞蟻集團、雲上上萬家企業的日志分析，每天寫入的資料量16PB+，開發、運維這樣一套系統問題和挑戰非常多，這裡就不再展開，有興趣的同學可以參考我們團隊的技術分享：

阿裡10PB/天日志系統設計和實作

。

總結

本篇主要從架構層面去介紹如何搭建一套K8s的日志分析平台，包括開源方案以及我們阿裡自研的一套方案。然而實際這套系統落地到生産環境并有效運作還有很多工作要做：

1. K8s上以什麼樣的姿勢來打日志？
2. K8s上的日志采集方案選擇，DaemonSet or Sidecar？
3. 日志方案如何與CICD去內建？
4. 微服務下各個應用的日志存儲如何劃分？
5. 如何基于K8s系統的日志去做K8s監控？
6. 如何去監控日志平台的可靠性？
7. 如何去對多個微服務/元件去做自動的巡檢？
8. 如何自動的監控多個站點并實作流量異常時的快速定位？

“ 阿裡巴巴雲原生微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”