作者 | 元乙 阿里雲日志服務數據采集客戶端負責人，目前采集客戶端 logtail 在集團百萬規模部署，每天采集上萬應用數 PB 數據，經歷多次雙 11、雙 12 考驗。
導讀：隨着 K8s 不斷更新迭代，使用 K8s 日志系統建設的開發者，逐漸遇到了各種復雜的問題和挑戰。本篇文章中，作者結合自己多年經驗，分析 K8s 日志系統建設難點，期待為讀者提供有益參考。
在 Logging 這塊做了幾年，最近 1 年來越來越多的同學來咨詢如何為 Kubernetes 構建一個日志系統，或者是來求助在這過程中遇到一系列問題如何解決，授人以魚不如授人以漁，於是想把我們這些年積累的經驗以文章的形式發出來，讓看到這篇文章的同學能少走彎路。這個系列文章定位為長篇連載，內容偏向落地實操以及經驗分享，且內容會隨着技術的迭代而不定期更新。
前言
第一次聽到 Kubernetes 的名字是在 2016 年，那個時候 Kubernetes 還處於和 Docker Swarm、Mesos 方案的“三國鼎立時代”，Kubernetes 由於一系列優勢（可擴展、聲明式接口、雲友好）在這一競爭中嶄露頭角，最終獲得統治地位。
Kubernetes 作為 CNCF 最核心的項目（沒有之一），是 Cloud Native（雲原生）落地的底座，目前阿里已經全面基於 Kubernetes 在開展全站的雲原生改造，在 1-2 年內，阿里巴巴 100% 的業務都將跑在公有雲上。
CloudNative 在 CNCF 的定義的核心是：在公有雲、私有雲、混合雲等環境中，通過 Containers、Service Meshes、 MicroServices、Immutable Infrastructure、Declarative APIs 構建和運行可彈性擴展的且具有高容錯性、易於管理、可觀察、松耦合的應用系統。可觀察性是應用系統必不可少的一個部分，雲原生的設計理念中就有一條：面向診斷性設計（Diagnosability），包括集群級別的日志、Metric 和 Trace。
為何我們需要日志系統
通常一個線上問題的定位流程是：通過 Metric 發現問題，根據 Trace 定位到問題模塊，根據模塊具體的日志定位問題原因。在日志中包括了錯誤、關鍵變量、代碼運行路徑等信息，這些是問題排查的核心，因此日志永遠是線上問題排查的必經路徑。
在阿里的十多年中，日志系統伴隨着計算形態的發展在不斷演進，大致分為 3 個主要階段：
- 在單機時代，幾乎所有的應用都是單機部署，當服務壓力增大時，只能切換更高規格的 IBM 小型機。日志作為應用系統的一部分，主要用作程序 Debug，通常結合 grep 等 Linux 常見的文本命令進行分析；
- 隨着單機系統成為制約阿里業務發展的瓶頸，為了真正的 Scale out，飛天項目啟動：2013 年飛天 5K 項目正式上線。在這個階段各個業務開始了分布式改造，服務之間的調用也從本地變為分布式，為了更好的管理、調試、分析分布式應用，我們開發了 Trace（分布式鏈路追蹤）系統、各式各樣的監控系統，這些系統的統一特點是將所有的日志（包括 Metric 等）進行集中化的存儲；
- 為了支持更快的開發、迭代效率，近年來我們開始了容器化改造，並開始了擁抱 Kubernetes 生態、業務全量上雲、Serverless 等工作。在這階段，日志無論從規模、種類都呈現爆炸式的增長，對日志進行數字化、智能化分析的需求也越來越高，因此統一的日志平台應運而生。
可觀察性的終極解讀
在 CNCF 中，可觀察性的主要作用是問題的診斷，上升到公司整體層面，可觀察性（Observability）不僅僅包括 DevOps 領域，還包括業務、運營、BI、審計、安全等領域，可觀察性的最終的目標是實現公司各個方面的數字化、智能化。
在阿里，幾乎所有的業務角色都會涉及到各式各樣的日志數據，為了支撐各類應用場景，我們開發了非常多的工具和功能：日志實時分析、鏈路追蹤、監控、數據加工、流計算、離線計算、BI 系統、審計系統等等。日志系統主要專注於數據的實時采集、清洗、智能分析與監控以及對接各類各樣的流計算、離線系統。
Kubernetes 日志系統建設難點
單純日志系統的解決方案非常多，相對也比較成熟，這里就不再去贅述，我們此次只針對 Kubernetes 上的日志系統建設而論。Kubernetes 上的日志方案相比我們之前基於物理機、虛擬機場景的日志方案有很大不同，例如：
- 日志的形式變得更加復雜，不僅有物理機/虛擬機上的日志，還有容器的標准輸出、容器內的文件、容器事件、Kubernetes 事件等等信息需要采集；
- 環境的動態性變強，在 Kubernetes 中，機器的宕機、下線、上線、Pod銷毀、擴容/縮容等都是常態，這種情況下日志的存在是瞬時的（例如如果 Pod 銷毀后該 Pod 日志就不可見了），所以日志數據必須實時采集到服務端。同時還需要保證日志的采集能夠適應這種動態性極強的場景；
- 日志的種類變多，上圖是一個典型的 Kubernetes 架構，一個請求從客戶端需要經過 CDN、Ingress、Service Mesh、Pod 等多個組件，涉及多種基礎設施，其中的日志種類增加了很多，例如 K8s 各種系統組件日志、審計日志、ServiceMesh 日志、Ingress 等；
- 業務架構變化，現在越來越多的公司開始在 Kubernetes 上落地微服務架構，在微服務體系中，服務的開發更加復雜，服務之間的依賴以及服務底層產品的依賴越來越多，這時的問題排查將更加復雜，如果關聯各個維度的日志將是一個困難的問題；
- 日志方案集成困難，通常我們都會在 Kubernetes 上搭建一套 CICD 系統，這套 CICD 系統需要盡可能的自動化的完成業務的集成和部署，其中日志的采集、存儲、清洗等也需要集成到這套系統中，並和 K8s 的聲明式部署方式盡可能一致。而現有的日志系統通常都是較獨立的系統，集成到 CICD 中代價極大；
- 日志規模問題，通常在系統初期的時候我們會選擇自建開源的日志系統，這種方式在測試驗證階段或公司發展初期是沒有什么問題的，但當業務逐漸增長，日志量增長到一定規模時，自建的開源系統很多時候都會遇到各種各樣的問題，例如租戶隔離、查詢延遲、數據可靠性、系統可用性等。日志系統雖不是 IT 中最核心的路徑，但一旦關鍵時刻出現這些問題都將是非常可怕的影響，例如大促的時候出現緊急問題，排查時多個工程師並發查詢把日志系統打爆，導致故障恢復時間變長，大促收到影響。
相信在搞 K8s 日志系統建設的同學看到上面的難點分析都會深有感觸，后面我們會從落地角度出發，詳細介紹在阿里我們如何去搭建 K8s 的日志系統，敬請關注。
“ 阿里巴巴雲原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”