作者 |? 元乙? 阿里云日志服務(wù)數(shù)據(jù)采集客戶(hù)端負(fù)責(zé)人，目前采集客戶(hù)端 logtail 在集團(tuán)百萬(wàn)規(guī)模部署，每天采集上萬(wàn)應(yīng)用數(shù) PB 數(shù)據(jù)，經(jīng)歷多次雙 11、雙 12 考驗(yàn)。

導(dǎo)讀：隨著 K8s 不斷更新迭代，使用?K8s 日志系統(tǒng)建設(shè)的開(kāi)發(fā)者，逐漸遇到了各種復(fù)雜的問(wèn)題和挑戰(zhàn)。本篇文章中，作者結(jié)合自己多年經(jīng)驗(yàn)，分析 K8s 日志系統(tǒng)建設(shè)難點(diǎn)，期待為讀者提供有益參考。

在 Logging 這塊做了幾年，最近 1 年來(lái)越來(lái)越多的同學(xué)來(lái)咨詢(xún)?nèi)绾螢?Kubernetes 構(gòu)建一個(gè)日志系統(tǒng)，或者是來(lái)求助在這過(guò)程中遇到一系列問(wèn)題如何解決，授人以魚(yú)不如授人以漁，于是想把我們這些年積累的經(jīng)驗(yàn)以文章的形式發(fā)出來(lái)，讓看到這篇文章的同學(xué)能少走彎路。這個(gè)系列文章定位為長(zhǎng)篇連載，內(nèi)容偏向落地實(shí)操以及經(jīng)驗(yàn)分享，且內(nèi)容會(huì)隨著技術(shù)的迭代而不定期更新。

前言

第一次聽(tīng)到 Kubernetes 的名字是在 2016 年，那個(gè)時(shí)候 Kubernetes 還處于和 Docker Swarm、Mesos 方案的“三國(guó)鼎立時(shí)代”，Kubernetes 由于一系列優(yōu)勢(shì)（可擴(kuò)展、聲明式接口、云友好）在這一競(jìng)爭(zhēng)中嶄露頭角，最終獲得統(tǒng)治地位。

Kubernetes 作為 CNCF 最核心的項(xiàng)目（沒(méi)有之一），是 Cloud Native（云原生）落地的底座，目前阿里已經(jīng)全面基于 Kubernetes 在開(kāi)展全站的云原生改造，在 1-2 年內(nèi)，阿里巴巴 100% 的業(yè)務(wù)都將跑在公有云上。

CloudNative 在?CNCF 的定義的核心是：在公有云、私有云、混合云等環(huán)境中，通過(guò) Containers、Service Meshes、 MicroServices、Immutable Infrastructure、Declarative APIs 構(gòu)建和運(yùn)行可彈性擴(kuò)展的且具有高容錯(cuò)性、易于管理、可觀察、松耦合的應(yīng)用系統(tǒng)。可觀察性是應(yīng)用系統(tǒng)必不可少的一個(gè)部分，云原生的設(shè)計(jì)理念中就有一條：面向診斷性設(shè)計(jì)（Diagnosability），包括集群級(jí)別的日志、Metric 和 Trace。

為何我們需要日志系統(tǒng)

通常一個(gè)線(xiàn)上問(wèn)題的定位流程是：通過(guò) Metric 發(fā)現(xiàn)問(wèn)題，根據(jù) Trace 定位到問(wèn)題模塊，根據(jù)模塊具體的日志定位問(wèn)題原因。在日志中包括了錯(cuò)誤、關(guān)鍵變量、代碼運(yùn)行路徑等信息，這些是問(wèn)題排查的核心，因此日志永遠(yuǎn)是線(xiàn)上問(wèn)題排查的必經(jīng)路徑。

在阿里的十多年中，日志系統(tǒng)伴隨著計(jì)算形態(tài)的發(fā)展在不斷演進(jìn)，大致分為 3 個(gè)主要階段：

在單機(jī)時(shí)代，幾乎所有的應(yīng)用都是單機(jī)部署，當(dāng)服務(wù)壓力增大時(shí)，只能切換更高規(guī)格的 IBM 小型機(jī)。日志作為應(yīng)用系統(tǒng)的一部分，主要用作程序 Debug，通常結(jié)合 grep 等 Linux 常見(jiàn)的文本命令進(jìn)行分析；

隨著單機(jī)系統(tǒng)成為制約阿里業(yè)務(wù)發(fā)展的瓶頸，為了真正的 Scale out，飛天項(xiàng)目啟動(dòng)：2013 年飛天 5K 項(xiàng)目正式上線(xiàn)。在這個(gè)階段各個(gè)業(yè)務(wù)開(kāi)始了分布式改造，服務(wù)之間的調(diào)用也從本地變?yōu)榉植际?#xff0c;為了更好的管理、調(diào)試、分析分布式應(yīng)用，我們開(kāi)發(fā)了 Trace（分布式鏈路追蹤）系統(tǒng)、各式各樣的監(jiān)控系統(tǒng)，這些系統(tǒng)的統(tǒng)一特點(diǎn)是將所有的日志（包括 Metric 等）進(jìn)行集中化的存儲(chǔ)；

為了支持更快的開(kāi)發(fā)、迭代效率，近年來(lái)我們開(kāi)始了容器化改造，并開(kāi)始了擁抱 Kubernetes 生態(tài)、業(yè)務(wù)全量上云、Serverless 等工作。在這階段，日志無(wú)論從規(guī)模、種類(lèi)都呈現(xiàn)爆炸式的增長(zhǎng)，對(duì)日志進(jìn)行數(shù)字化、智能化分析的需求也越來(lái)越高，因此統(tǒng)一的日志平臺(tái)應(yīng)運(yùn)而生。

可觀察性的終極解讀

在 CNCF 中，可觀察性的主要作用是問(wèn)題的診斷，上升到公司整體層面，可觀察性（Observability）不僅僅包括 DevOps 領(lǐng)域，還包括業(yè)務(wù)、運(yùn)營(yíng)、BI、審計(jì)、安全等領(lǐng)域，可觀察性的最終的目標(biāo)是實(shí)現(xiàn)公司各個(gè)方面的數(shù)字化、智能化。

在阿里，幾乎所有的業(yè)務(wù)角色都會(huì)涉及到各式各樣的日志數(shù)據(jù)，為了支撐各類(lèi)應(yīng)用場(chǎng)景，我們開(kāi)發(fā)了非常多的工具和功能：日志實(shí)時(shí)分析、鏈路追蹤、監(jiān)控、數(shù)據(jù)加工、流計(jì)算、離線(xiàn)計(jì)算、BI 系統(tǒng)、審計(jì)系統(tǒng)等等。日志系統(tǒng)主要專(zhuān)注于數(shù)據(jù)的實(shí)時(shí)采集、清洗、智能分析與監(jiān)控以及對(duì)接各類(lèi)各樣的流計(jì)算、離線(xiàn)系統(tǒng)。

Kubernetes 日志系統(tǒng)建設(shè)難點(diǎn)

單純?nèi)罩鞠到y(tǒng)的解決方案非常多，相對(duì)也比較成熟，這里就不再去贅述，我們此次只針對(duì) Kubernetes 上的日志系統(tǒng)建設(shè)而論。Kubernetes 上的日志方案相比我們之前基于物理機(jī)、虛擬機(jī)場(chǎng)景的日志方案有很大不同，例如：

日志的形式變得更加復(fù)雜，不僅有物理機(jī)/虛擬機(jī)上的日志，還有容器的標(biāo)準(zhǔn)輸出、容器內(nèi)的文件、容器事件、Kubernetes 事件等等信息需要采集；

環(huán)境的動(dòng)態(tài)性變強(qiáng)，在 Kubernetes 中，機(jī)器的宕機(jī)、下線(xiàn)、上線(xiàn)、Pod銷(xiāo)毀、擴(kuò)容/縮容等都是常態(tài)，這種情況下日志的存在是瞬時(shí)的（例如如果 Pod 銷(xiāo)毀后該 Pod 日志就不可見(jiàn)了），所以日志數(shù)據(jù)必須實(shí)時(shí)采集到服務(wù)端。同時(shí)還需要保證日志的采集能夠適應(yīng)這種動(dòng)態(tài)性極強(qiáng)的場(chǎng)景；

日志的種類(lèi)變多，上圖是一個(gè)典型的 Kubernetes 架構(gòu)，一個(gè)請(qǐng)求從客戶(hù)端需要經(jīng)過(guò) CDN、Ingress、Service Mesh、Pod 等多個(gè)組件，涉及多種基礎(chǔ)設(shè)施，其中的日志種類(lèi)增加了很多，例如 K8s 各種系統(tǒng)組件日志、審計(jì)日志、ServiceMesh 日志、Ingress 等；

業(yè)務(wù)架構(gòu)變化，現(xiàn)在越來(lái)越多的公司開(kāi)始在 Kubernetes 上落地微服務(wù)架構(gòu)，在微服務(wù)體系中，服務(wù)的開(kāi)發(fā)更加復(fù)雜，服務(wù)之間的依賴(lài)以及服務(wù)底層產(chǎn)品的依賴(lài)越來(lái)越多，這時(shí)的問(wèn)題排查將更加復(fù)雜，如果關(guān)聯(lián)各個(gè)維度的日志將是一個(gè)困難的問(wèn)題；

日志方案集成困難，通常我們都會(huì)在 Kubernetes 上搭建一套 CICD 系統(tǒng)，這套 CICD 系統(tǒng)需要盡可能的自動(dòng)化的完成業(yè)務(wù)的集成和部署，其中日志的采集、存儲(chǔ)、清洗等也需要集成到這套系統(tǒng)中，并和 K8s 的聲明式部署方式盡可能一致。而現(xiàn)有的日志系統(tǒng)通常都是較獨(dú)立的系統(tǒng)，集成到 CICD 中代價(jià)極大；

日志規(guī)模問(wèn)題，通常在系統(tǒng)初期的時(shí)候我們會(huì)選擇自建開(kāi)源的日志系統(tǒng)，這種方式在測(cè)試驗(yàn)證階段或公司發(fā)展初期是沒(méi)有什么問(wèn)題的，但當(dāng)業(yè)務(wù)逐漸增長(zhǎng)，日志量增長(zhǎng)到一定規(guī)模時(shí)，自建的開(kāi)源系統(tǒng)很多時(shí)候都會(huì)遇到各種各樣的問(wèn)題，例如租戶(hù)隔離、查詢(xún)延遲、數(shù)據(jù)可靠性、系統(tǒng)可用性等。日志系統(tǒng)雖不是 IT 中最核心的路徑，但一旦關(guān)鍵時(shí)刻出現(xiàn)這些問(wèn)題都將是非常可怕的影響，例如大促的時(shí)候出現(xiàn)緊急問(wèn)題，排查時(shí)多個(gè)工程師并發(fā)查詢(xún)把日志系統(tǒng)打爆，導(dǎo)致故障恢復(fù)時(shí)間變長(zhǎng)，大促收到影響。

相信在搞 K8s 日志系統(tǒng)建設(shè)的同學(xué)看到上面的難點(diǎn)分析都會(huì)深有感觸，后面我們會(huì)從落地角度出發(fā)，詳細(xì)介紹在阿里我們?nèi)绾稳ゴ罱?K8s 的日志系統(tǒng)，敬請(qǐng)關(guān)注。

“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的6 个 K8s 日志系统建设中的典型问题，你遇到过几个？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。