嘉賓 | 元乙

隨著近兩年的發(fā)展，Kubernetes 早已成為容器編排領(lǐng)域的標(biāo)準(zhǔn)，現(xiàn)在非常多的企業(yè)基于 Kubernetes 構(gòu)建整個(gè)微服務(wù)的開(kāi)發(fā)、運(yùn)維平臺(tái)，而日志是其中必不可少的核心功能。本文整理自阿里云日志服務(wù)技術(shù)專家元乙在 QCon 全球軟件開(kāi)發(fā)大會(huì)（北京站）2019 上的演講，他的分享主要介紹了阿里超大規(guī)模下 Kubernetes 日志平臺(tái)的架構(gòu)實(shí)踐，通過(guò)日志采集、處理、分析、監(jiān)控、異常診斷等全方位技術(shù)，實(shí)現(xiàn) Kubernetes 以及業(yè)務(wù)應(yīng)用真正意義上的可觀察性。

QCon 是由 InfoQ 主辦的綜合性技術(shù)盛會(huì)，每年在倫敦、北京、紐約、圣保羅、上海、舊金山召開(kāi)。我有幸在 QCon 10 周年之際，作為分享嘉賓在 QCon 全球軟件開(kāi)發(fā)大會(huì)（北京站）2019 中劉宇老師的運(yùn)維專場(chǎng)發(fā)表了《Kubernetes 日志平臺(tái)建設(shè)最佳實(shí)踐》，現(xiàn)將 PPT 和文字稿整理下來(lái)，希望和更多的愛(ài)好者分享。

計(jì)算形態(tài)的發(fā)展與日志系統(tǒng)的演進(jìn)

在阿里的十多年中，日志系統(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)：2009 年開(kāi)始了飛天的第一行代碼，2013 年飛天 5K 項(xiàng)目正式上線。在這個(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 等工作。要實(shí)現(xiàn)這些改造，一個(gè)非常重要的部分是可觀察性的工作，而日志是作為分析系統(tǒng)運(yùn)行過(guò)程的最佳方式。在這階段，日志無(wú)論從規(guī)模、種類都呈現(xiàn)爆炸式的增長(zhǎng)，對(duì)日志進(jìn)行數(shù)字化、智能化分析的需求也越來(lái)越高，因此統(tǒng)一的日志平臺(tái)應(yīng)運(yùn)而生。

日志平臺(tái)的重要性與建設(shè)目標(biāo)

日志不僅僅是服務(wù)器、容器、應(yīng)用的 Debug 日志，也包括各類訪問(wèn)日志、中間件日志、用戶點(diǎn)擊、IoT/ 移動(dòng)端日志、數(shù)據(jù)庫(kù) Binlog 等等。這些日志隨著時(shí)效性的不同而應(yīng)用在不同的場(chǎng)景：

• 準(zhǔn)實(shí)時(shí)級(jí)別：這類日志主要用于準(zhǔn)實(shí)時(shí)（秒級(jí)延遲）的線上監(jiān)控、日志查看、運(yùn)維數(shù)據(jù)支撐、問(wèn)題診斷等場(chǎng)景，最近兩年也出現(xiàn)了準(zhǔn)實(shí)時(shí)的業(yè)務(wù)洞察，也是基于這類準(zhǔn)實(shí)時(shí)的日志實(shí)現(xiàn)。

• 小時(shí) / 天級(jí)別：當(dāng)數(shù)據(jù)積累到小時(shí) / 天級(jí)別的時(shí)候，這時(shí)一些 T+1 的分析工作就可以開(kāi)始了，例如用戶留存分析、廣告投放效果分析、反欺詐、運(yùn)營(yíng)監(jiān)測(cè)、用戶行為分析等。

• 季度 / 年級(jí)別：在阿里，數(shù)據(jù)是我們最重要的資產(chǎn)，因此非常多的日志都是保存一年以上或永久保存，這類日志主要用于歸檔、審計(jì)、攻擊溯源、業(yè)務(wù)走勢(shì)分析、數(shù)據(jù)挖掘等。

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

阿里日志平臺(tái)現(xiàn)狀

目前阿里的日志平臺(tái)覆蓋幾乎所有的產(chǎn)品線和產(chǎn)品，同時(shí)我們的產(chǎn)品也在云上對(duì)外提供服務(wù)，已經(jīng)服務(wù)了上萬(wàn)家的企業(yè)。每天寫(xiě)入流量 16PB 以上，對(duì)應(yīng)日志行數(shù) 40 萬(wàn)億 + 條，采集客戶端 200 萬(wàn)，服務(wù)數(shù)千 Kubernetes 集群，是國(guó)內(nèi)最大的日志平臺(tái)之一。

為何選擇自建

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

數(shù)據(jù)規(guī)模：這些開(kāi)源日志系統(tǒng)可以很好的支持小規(guī)模的場(chǎng)景，但很難支持阿里這種超大規(guī)模（PB 級(jí)）的場(chǎng)景。

資源消耗：我們擁有百萬(wàn)規(guī)模的服務(wù)器 / 容器，同時(shí)日志平臺(tái)的集群規(guī)模也很大，我們需要減少對(duì)于采集以及平臺(tái)自身的資源消耗。

多租戶隔離：開(kāi)源軟件搭建的系統(tǒng)大部分都不是為了多租戶而設(shè)計(jì)的，當(dāng)非常多的業(yè)務(wù) / 系統(tǒng)使用日志平臺(tái)時(shí)，很容易因?yàn)椴糠钟脩舻拇罅髁?/ 不恰當(dāng)使用而導(dǎo)致打爆整個(gè)集群。

運(yùn)維復(fù)雜度：在阿里內(nèi)部有一套非常完整的服務(wù)部署和管理系統(tǒng)，基于內(nèi)部組件實(shí)現(xiàn)會(huì)具備非常好的運(yùn)維復(fù)雜度。

高級(jí)分析需求：日志系統(tǒng)的功能幾乎全部來(lái)源與對(duì)應(yīng)的場(chǎng)景需求，有很多特殊場(chǎng)景的高級(jí)分析需求開(kāi)源軟件沒(méi)辦法很好的支持，例如：上下文、智能分析、日志類特殊分析函數(shù)等等。

Kubernetes 日志平臺(tái)建設(shè)難點(diǎn)

圍繞著 Kubernetes 場(chǎng)景的需求，日志平臺(tái)建設(shè)的難點(diǎn)主要有以下幾點(diǎn)：

• 日志采集：采集在 Kubernetes 中極其關(guān)鍵和復(fù)雜，主要因?yàn)?Kubernetes 是一個(gè)高度復(fù)雜的場(chǎng)景，Kubernetes 中有各式各樣的子系統(tǒng)，上層業(yè)務(wù)支持各種語(yǔ)言和框架，同時(shí)日志采集需要盡可能的和 Kubernetes 系統(tǒng)打通，用 K8 的形式來(lái)完成數(shù)據(jù)采集。

• 資源消耗：在 Kubernetes 中，服務(wù)通常都會(huì)拆的很小，因此數(shù)據(jù)采集對(duì)于服務(wù)自身的資源消耗要盡可能的少。這里我們簡(jiǎn)單的做一個(gè)計(jì)算，假設(shè)有 100W 個(gè)服務(wù)實(shí)例，沒(méi)個(gè)采集 Agent 減少 1M 的內(nèi)存、1% 的 CPU 開(kāi)銷，那整體會(huì)減少 1TB 的內(nèi)存和 10000 個(gè) CPU 核心。

• 運(yùn)維代價(jià)：運(yùn)維一套日志平臺(tái)的代價(jià)相當(dāng)之大，因此我們不希望每個(gè)用戶搭建一個(gè) Kubernetes 集群時(shí)還需再運(yùn)維一個(gè)獨(dú)立的日志平臺(tái)系統(tǒng)。因此日志平臺(tái)一定是要 SaaS 化的，應(yīng)用方 / 用戶只需要簡(jiǎn)單的操作 Web 頁(yè)面就能完成數(shù)據(jù)采集、分析的一整套流程。

• 便捷使用：日志系統(tǒng)最核心的功能是問(wèn)題排查，問(wèn)題排查的速度直接決定了工作效率、損失大小，在 K8s 場(chǎng)景中，更需要一套高性能、智能分析的功能來(lái)幫助用戶快速定位問(wèn)題，同時(shí)提供一系列簡(jiǎn)單有效的可視化手段進(jìn)行輔助。

阿里 PB 級(jí) Kubernetes 日志平臺(tái)建設(shè)

Kubernetes 日志數(shù)據(jù)采集

無(wú)論是在 ITOM 還是在未來(lái)的 AIOps 場(chǎng)景中，日志獲取都是其中必不可少的一個(gè)部分，數(shù)據(jù)源直接決定了后續(xù)應(yīng)用的形態(tài)和功能。在十多年中，我們積累了一套物理機(jī)、虛擬機(jī)的日志采集經(jīng)驗(yàn)，但在 Kubernetes 中不能完全適用，這里我們以問(wèn)題的形式展開(kāi)：

問(wèn)題 1：DaemonSet or Sidecar

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

• DaemonSet 方式：在 K8S 的每個(gè) node 上部署日志 agent，由 agent 采集所有容器的日志到服務(wù)端。

• Sidecar 方式：一個(gè) POD 中運(yùn)行一個(gè) sidecar 的日志 agent 容器，用于采集該 POD 主容器產(chǎn)生的日志。

每種采集方式都有其對(duì)應(yīng)的優(yōu)缺點(diǎn)，這里簡(jiǎn)單總結(jié)如下：

?DaemonSet 方式Sidecar 方式

采集日志類型	標(biāo)準(zhǔn)輸出 + 部分文件	文件
部署運(yùn)維	一般，需維護(hù) DaemonSet	較高，每個(gè)需要采集日志的 POD 都需要部署 sidecar 容器
日志分類存儲(chǔ)	一般，可通過(guò)容器 / 路徑等映射	每個(gè) POD 可單獨(dú)配置，靈活性高
多租戶隔離	一般，只能通過(guò)配置間隔離	強(qiáng)，通過(guò)容器進(jìn)行隔離，可單獨(dú)分配資源
支持集群規(guī)模	中小型規(guī)模，業(yè)務(wù)數(shù)最多支持百級(jí)別	無(wú)限制
資源占用	較低，每個(gè)節(jié)點(diǎn)運(yùn)行一個(gè)容器	較高，每個(gè) POD 運(yùn)行一個(gè)容器
查詢便捷性	較高，可進(jìn)行自定義的查詢、統(tǒng)計(jì)	高，可根據(jù)業(yè)務(wù)特點(diǎn)進(jìn)行定制
可定制性	低	高，每個(gè) POD 單獨(dú)配置
適用場(chǎng)景	功能單一型的集群	大型、混合型、PAAS 型集群

在阿里內(nèi)部，對(duì)于大型的 PAAS 集群，主要使用 Sidecar 方式采集數(shù)據(jù)，相對(duì)隔離性、靈活性最好；而對(duì)與功能比較單一（部門(mén)內(nèi)部 / 產(chǎn)品自建）的集群，基本都采用 DaemonSet 的方式，資源占用最低。

問(wèn)題 2：如何降低資源消耗

我們數(shù)據(jù)采集 Agent 使用的是自研的 Logtail，Logtail 用 C++/Go 編寫(xiě)，相對(duì)開(kāi)源 Agent 在資源消耗上具有非常大的優(yōu)勢(shì)，但我們還一直在壓榨數(shù)據(jù)采集的資源消耗，尤其在容器場(chǎng)景。通常，為了提高打日志和采集的性能，我們都使用本地 SSD 盤(pán)作為日志盤(pán)。這里我們可以做個(gè)簡(jiǎn)答的計(jì)算：假設(shè)每個(gè)容器掛載 1GB 的 SSD 盤(pán)，1 個(gè)物理機(jī)運(yùn)行 40 個(gè)容器，那每臺(tái)物理機(jī)需要 40GB 的 SSD 作為日志存儲(chǔ)，那 5W 物理機(jī)則會(huì)占用 2PB 的 SSD 盤(pán)。

為了降低這部分資源消耗，我們和螞蟻金服團(tuán)隊(duì)的同學(xué)們一起開(kāi)發(fā)了 FUSE 的日志采集方式，使用 FUSE（Filesystem in Userspace，用戶態(tài)文件系統(tǒng)）虛擬化出日志盤(pán)，應(yīng)用直接將日志寫(xiě)入到虛擬的日志盤(pán)中，最終數(shù)據(jù)將直接從內(nèi)存中被 Logtail 采集到服務(wù)端。這種采集的好處有：

• 物理機(jī)無(wú)需為容器提供日志盤(pán)，真正實(shí)現(xiàn)日志無(wú)盤(pán)化。

• 應(yīng)用程序視角看到的還是普通的文件系統(tǒng)，無(wú)需做任何額外改造。

• 數(shù)據(jù)采集繞過(guò)磁盤(pán)，直接從內(nèi)存中將數(shù)據(jù)采集到服務(wù)端。

• 所有的數(shù)據(jù)都存在服務(wù)端，服務(wù)端支持橫向擴(kuò)展，對(duì)于應(yīng)用來(lái)說(shuō)他們看到的日志盤(pán)具有無(wú)線存儲(chǔ)空間。

問(wèn)題 3：如何與 Kubernetes 無(wú)縫集成

Kubernetes 一個(gè)非常大的突破是使用聲明式的 API 來(lái)完成服務(wù)部署、集群管理等工作。但在 K8s 集群環(huán)境下，業(yè)務(wù)應(yīng)用 / 服務(wù) / 組件的持續(xù)集成和自動(dòng)發(fā)布已經(jīng)成為常態(tài)，使用控制臺(tái)或 SDK 操作采集配置的方式很難與各類 CI、編排框架集成，導(dǎo)致業(yè)務(wù)應(yīng)用發(fā)布后用戶只能通過(guò)控制臺(tái)手動(dòng)配置的方式部署與之對(duì)應(yīng)的日志采集配置。因此我們基于 Kubernetes 的 CRD（CustomResourceDefinition）擴(kuò)展實(shí)現(xiàn)了采集配置的 Operator，用戶可以直接使用 K8s API、Yaml、kubectl、Helm 等方式直接配置采集方式，真正把日志采集融入到 Kubernetes 系統(tǒng)中，實(shí)現(xiàn)無(wú)縫集成。

問(wèn)題 4：如何管理百萬(wàn)級(jí) Logtail

對(duì)于人才管理有個(gè)經(jīng)典的原則：10 個(gè)人要用心良苦，100 個(gè)人要?dú)⒎ス麛?#xff0c;1000 個(gè)人要甩手掌柜。而同樣對(duì)于 Logtail 這款日志采集 Agent 的管理也是如此，這里我們分為 3 個(gè)主要過(guò)程：

• 百規(guī)模：在好幾年前，Logtail 剛開(kāi)始部署時(shí)，也就在幾百臺(tái)物理機(jī)上運(yùn)行，這個(gè)時(shí)期的 Logtail 和其他主流的 Agent 一樣，主要完成數(shù)據(jù)采集的功能，主要流程為數(shù)據(jù)輸入、處理、聚合、發(fā)送，這個(gè)時(shí)期的管理基本靠手，采集出現(xiàn)問(wèn)題的時(shí)候人工登錄機(jī)器去看問(wèn)題。

• 萬(wàn)規(guī)模：當(dāng)越來(lái)越多的應(yīng)用方接入，每臺(tái)機(jī)器上可能會(huì)有多個(gè)應(yīng)用方采集不同類型的數(shù)據(jù)，手動(dòng)配置的接入過(guò)程也越來(lái)越難以維護(hù)。因此我們重點(diǎn)在多租戶隔離以及中心化的配置管理，同時(shí)增加了很多控制相關(guān)的手段，比如限流、降級(jí)等。

• 百萬(wàn)規(guī)模：當(dāng)部署量打到百萬(wàn)級(jí)別的時(shí)候，異常發(fā)生已經(jīng)成為常態(tài)，我們更需要的是靠一系列的監(jiān)控、可靠性保證機(jī)制、自動(dòng)化的運(yùn)維管理工具，讓這些機(jī)制、工具來(lái)自動(dòng)完成 Agent 安裝、監(jiān)控、自恢復(fù)等一系列工作，真正做到甩手掌柜。

Kubernetes 日志平臺(tái)架構(gòu)

上圖是阿里 Kubernetes 日志平臺(tái)的整體架構(gòu)，從底到上分為日志接入層、平臺(tái)核心層以及方案整合層：

• 平臺(tái)提供了非常多的手段用來(lái)接入各種類型的日志數(shù)據(jù)。不僅僅只有 Kubernetes 中的日志，同時(shí)還包括和 Kubernetes 業(yè)務(wù)相關(guān)的所有日志，例如移動(dòng)端日志、Web 端應(yīng)用點(diǎn)擊日志、IoT 日志等等。所有數(shù)據(jù)支持主動(dòng) Push、被動(dòng) Agent 采集，Agent 不僅支持我們自研的 Logtail，也支持使用開(kāi)源 Agent（Logstash、Fluentd、Filebeats 等）。

• 日志首先會(huì)到達(dá)平臺(tái)提供的實(shí)時(shí)隊(duì)列中，類似于 Kafka 的 consumer group，我們提供實(shí)時(shí)數(shù)據(jù)訂閱的功能，用戶可以基于該功能實(shí)現(xiàn) ETL 的相關(guān)需求。平臺(tái)最核心的功能包括：

• 實(shí)時(shí)搜索：類似于搜索引擎的方式，支持從所有日志中根據(jù)關(guān)鍵詞查找，支持超大規(guī)模（PB 級(jí)）。

• 實(shí)時(shí)分析：基于 SQL92 語(yǔ)法提供交互式的日志分析方法。

• 機(jī)器學(xué)習(xí)：提供時(shí)序預(yù)測(cè)、時(shí)序聚類、根因分析、日志聚合等智能分析方法。

• 流計(jì)算：對(duì)接各類流計(jì)算引擎，例如：Flink、Spark Stream、Storm 等。

• 離線分析：對(duì)接離線分析引擎，例如 Hadoop、Max Compute 等。

• 基于全方位的數(shù)據(jù)源以及平臺(tái)提供的核心功能，并結(jié)合 Kubernetes 日志特點(diǎn)以及應(yīng)用場(chǎng)景，向上構(gòu)建 Kubernetes 日志的通用解決方案，例如：審計(jì)日志、Ingress 日志分析、ServiceMesh 日志等等。同時(shí)對(duì)于有特定需求的應(yīng)用方 / 用戶，可直接基于平臺(tái)提供的 OpenAPI 構(gòu)建上層方案，例如 Trace 系統(tǒng)、性能分析系統(tǒng)等。

下面我們從問(wèn)題排查的角度來(lái)具體展開(kāi)平臺(tái)提供的核心功能。

PB 級(jí)日志查詢

排查問(wèn)題的最佳手段是查日志，大部分人腦海中最先想到的是用 grep 命令查找日志中的一些關(guān)鍵錯(cuò)誤信息， grep 是 Linux 程序員最受歡迎的命令之一，對(duì)于簡(jiǎn)單的問(wèn)題排查場(chǎng)景也非常實(shí)用。如果應(yīng)用部署在多臺(tái)機(jī)器，那還會(huì)配合使用 pgm、pssh 等命令。然而這些命令對(duì)于 Kubernetes 這種動(dòng)態(tài)、大規(guī)模的場(chǎng)景并不適用，主要問(wèn)題有：

• 查詢不夠靈活，grep 命令很難實(shí)現(xiàn)各種邏輯條件的組合。

• grep 是針對(duì)純文本的分析手段，很難將日志格式化成對(duì)應(yīng)的類型，例如 Long、Double 甚至 JSON 類型。

• grep 命令的前提條件是日志存儲(chǔ)在磁盤(pán)上。而在 Kubernetes 中，應(yīng)用的本地日志空間都很小，并且服務(wù)也會(huì)動(dòng)態(tài)的遷移、伸縮，本地的數(shù)據(jù)源很可能會(huì)不存在。

• grep 是典型的全量掃描方式，如果數(shù)據(jù)量在 1GB 以內(nèi)，查詢時(shí)間還可以接受，但當(dāng)數(shù)據(jù)量上升到 TB 甚至 PB 時(shí)，必須依賴搜索引擎的技術(shù)才能工作。

我們?cè)?2009 年開(kāi)始在飛天平臺(tái)研發(fā)過(guò)程中，為夠解決大規(guī)模（例如 5000 臺(tái)）下的研發(fā)效率、問(wèn)題診斷等問(wèn)題，開(kāi)始研支持超大規(guī)模的日志查詢平臺(tái)，其中最主要的目標(biāo)是“快”，對(duì)于幾十億的數(shù)據(jù)也能夠輕松在秒級(jí)完成。

日志上下文

當(dāng)我們通過(guò)查詢的方式定位到關(guān)鍵的日志后，需要分析當(dāng)時(shí)系統(tǒng)的行為，并還原出當(dāng)時(shí)的現(xiàn)場(chǎng)情況。而現(xiàn)場(chǎng)其實(shí)就是當(dāng)時(shí)的日志上下文，例如：

• 一個(gè)錯(cuò)誤，同一個(gè)日志文件中的前后數(shù)據(jù)

• 一行 LogAppender 中輸出，同一個(gè)進(jìn)程順序輸出到日志模塊前后順序

• 一次請(qǐng)求，同一個(gè) Session 組合

• 一次跨服務(wù)請(qǐng)求，同一個(gè) TraceId 組合

在 Kubernetes 的場(chǎng)景中，每個(gè)容器的標(biāo)準(zhǔn)輸出（stdout）、文件都有對(duì)應(yīng)的組合方式構(gòu)成一個(gè)上下文分區(qū)，例如 Namesapce+Pod+ContainerID+FileName/Stdout。為支持上下文，我們?cè)诓杉瘏f(xié)議中對(duì)每個(gè)最小區(qū)分單元會(huì)帶上一個(gè)全局唯一并且單調(diào)遞增的游標(biāo)，這個(gè)游標(biāo)對(duì)單機(jī)日志、Docker、K8S 以及移動(dòng)端 SDK、Log4J/LogBack 等輸出中有不一樣的形式

為日志而生的分析引擎

在一些復(fù)雜的場(chǎng)景中，我們需要對(duì)日志中的數(shù)據(jù)進(jìn)行統(tǒng)計(jì)來(lái)發(fā)現(xiàn)其中規(guī)律。例如根據(jù) ClientIP 進(jìn)行聚合來(lái)查找攻擊源 IP、將數(shù)據(jù)聚合計(jì)算 P99/P9999 延遲、從多個(gè)維度組合分析等。傳統(tǒng)的方式需要配合流計(jì)算或離線計(jì)算的引擎進(jìn)行聚合計(jì)算，再對(duì)接可視化系統(tǒng)進(jìn)行圖形化展示或?qū)痈婢到y(tǒng)。這種方式用戶需要維護(hù)多套系統(tǒng)，數(shù)據(jù)實(shí)時(shí)性變差，并且各個(gè)系統(tǒng)間的銜接很容易出現(xiàn)問(wèn)題。

因此我們平臺(tái)原生集成了日志分析、可視化、告警等相關(guān)的功能，盡可能減少用戶配置鏈路。通過(guò)多年的實(shí)踐，我們發(fā)現(xiàn)用戶最容易接受的還是 SQL 的分析方式，因此我們分析基于 SQL92 標(biāo)準(zhǔn)實(shí)現(xiàn)，在此基礎(chǔ)上擴(kuò)展了很多針對(duì)日志分析場(chǎng)景的高級(jí)函數(shù)，例如：

• 同比環(huán)比：前后數(shù)據(jù)對(duì)比是日志分析中最常用的方式之一，我們提供了同比 / 環(huán)比函數(shù)，一個(gè)函數(shù)即可計(jì)算今日 PV 同比昨日、上周的增幅。

• IP 地理函數(shù)：基于淘寶高精度 IP 地理庫(kù)，提供 IP 到國(guó)家、省、市、運(yùn)營(yíng)商、經(jīng)緯度等的轉(zhuǎn)換，例如常見(jiàn)的 Nginx 訪問(wèn)日志、K8s Ingress 訪問(wèn)日志中的 remote-ip 可以直接用來(lái)分析地理位置分布。

• Join 外部數(shù)據(jù)源：將日志和 MySQL、CSV 等做 Join 分析，例如根據(jù) ID 從數(shù)據(jù)庫(kù)中查找用戶對(duì)應(yīng)的信息、和 CMDB 中的網(wǎng)絡(luò)架構(gòu)數(shù)據(jù)做關(guān)聯(lián)等。

• 安全函數(shù)：支持日志安全分析中的常見(jiàn)方式，例如高危 IP 庫(kù)查找、SQL 注入分析、高危 SQL 檢測(cè)等。

智能日志分析

在日志平臺(tái)上，應(yīng)用方 / 用戶可以通過(guò)日志接入、查詢、分析、可視化、告警等功能可以完成異常監(jiān)控、問(wèn)題調(diào)查與定位。但隨著計(jì)算形態(tài)、應(yīng)用形態(tài)以及開(kāi)發(fā)人員職責(zé)的不斷演變，尤其在近兩年 Kubernetes、ServiceMesh、Serverless 等技術(shù)的興起，問(wèn)題的復(fù)雜度不斷上升，常規(guī)手段已經(jīng)很難適用。于是我們開(kāi)始嘗試向 AIOps 領(lǐng)域發(fā)展，例如時(shí)序分析、根因分析、日志聚類等。

時(shí)序分析

通過(guò)時(shí)序預(yù)測(cè)相關(guān)方法，我們可以對(duì) CPU、存儲(chǔ)進(jìn)行時(shí)序建模，進(jìn)行更加智能的調(diào)度，讓整體利用率如絲般平滑；存儲(chǔ)團(tuán)隊(duì)通過(guò)對(duì)磁盤(pán)空間的增長(zhǎng)預(yù)測(cè)，提前制定預(yù)算并采購(gòu)機(jī)器；在做部門(mén) / 產(chǎn)品預(yù)算時(shí)，根據(jù)歷年賬單預(yù)測(cè)全年的消費(fèi)，進(jìn)行更優(yōu)的成本控制。
稍微大一些的服務(wù)可能會(huì)有幾百、上千甚至上萬(wàn)臺(tái)的機(jī)器，通過(guò)人肉很難發(fā)現(xiàn)每臺(tái)機(jī)器行為（時(shí)序）的區(qū)別，而通過(guò)時(shí)序聚類就可以快速得到集群的行為分布，定位出異常的機(jī)器；同時(shí)對(duì)于單條時(shí)序，可以通過(guò)時(shí)序異常相關(guān)的檢測(cè)方法，自動(dòng)定位異常點(diǎn)。

根因分析

時(shí)序相關(guān)的函數(shù)主要用來(lái)發(fā)現(xiàn)問(wèn)題，而查找問(wèn)題根源還需要模式分析相關(guān)的方法（根因分析，Root Cause Analysis）。例如 K8s 集群整體 Ingress 錯(cuò)誤率（5XX 比例）突然上升時(shí)，如何排查是因?yàn)槟硞€(gè)服務(wù)問(wèn)題、某個(gè)用戶引起、某個(gè) URL 引起、某個(gè)瀏覽器引起、某些地域網(wǎng)絡(luò)問(wèn)題、某個(gè)節(jié)點(diǎn)異常還是整體性的問(wèn)題？通常這種問(wèn)題都需要人工從各個(gè)維度去排查，例如：

• 按照 Service 去 Group，查看 Service 之間的錯(cuò)誤率有無(wú)差別；

• 沒(méi)有差別，然后排查 URL；

• 還沒(méi)有，按照瀏覽器；

• 瀏覽器有點(diǎn)關(guān)系，繼續(xù)看移動(dòng)端、PC 端；

• 移動(dòng)端錯(cuò)誤率比較高，看看是 Android 還是 IOS；

• ?...

這種問(wèn)題的排查在維度越多時(shí)復(fù)雜度越高，排查時(shí)間也越久，可能等到發(fā)現(xiàn)問(wèn)題的時(shí)候影響面已經(jīng)全面擴(kuò)大了。因此我們開(kāi)發(fā)了根因分析相關(guān)的函數(shù)，可以直接從多維數(shù)據(jù)中定位對(duì)目標(biāo)（例如延遲、失敗率等）影響最大的一組（幾組）維度組合。為了更加精確的定位問(wèn)題，我們還支持對(duì)比兩個(gè)模式的差異，例如今天發(fā)生異常時(shí)，和昨天正常的模式進(jìn)行對(duì)比，快速找到問(wèn)題的原因；在發(fā)布時(shí)進(jìn)行藍(lán)綠對(duì)比以及 A/B Test。

智能日志聚類

上面我們通過(guò)智能時(shí)序函數(shù)發(fā)現(xiàn)問(wèn)題、通過(guò)根因分析定位到關(guān)鍵的維度組合，但涉及到最終的代碼問(wèn)題排查，還是離不開(kāi)日志。當(dāng)日志的數(shù)據(jù)量很大時(shí)，一次次的手動(dòng)過(guò)濾太過(guò)耗時(shí)，我們希望可以通過(guò)智能聚類的方式，把相似的日志聚類到一起，最終可以通過(guò)聚類后的日志快速掌握系統(tǒng)的運(yùn)行狀態(tài)。

上下游生態(tài)對(duì)接

Kubernetes 日志平臺(tái)主要的目標(biāo)在解決 DevOps、Net/Site Ops、Sec Ops 等問(wèn)題上，然而這些并不能滿足所有用戶對(duì)于日志的所有需求，例如超大規(guī)模的日志分析、BI 分析、極其龐大的安全規(guī)則過(guò)濾等。平臺(tái)的強(qiáng)大更多的是生態(tài)的強(qiáng)大，我們通過(guò)對(duì)接上下游廣泛的生態(tài)來(lái)滿足用戶越來(lái)越多的日志需求和場(chǎng)景。

優(yōu)秀應(yīng)用案例分析

混合云 PAAS 平臺(tái)日志管理

某大型游戲公司在進(jìn)行技術(shù)架構(gòu)升級(jí)，大部分業(yè)務(wù)會(huì)遷移到基于 Kubernetes 搭建的 PaaS 平臺(tái)上，為提高平臺(tái)整體的可用性，用戶采集混合云架構(gòu)，對(duì)于日志的統(tǒng)一建設(shè)與管理存在很大困難：

• 眾多內(nèi)部應(yīng)用方：不希望應(yīng)用方過(guò)多的接觸日志采集、存儲(chǔ)等細(xì)節(jié)，并且能夠?yàn)閼?yīng)用方提供全鏈路的日志；

• 1000+ 微服務(wù)：需要支持大規(guī)模的日志采集方式；

• 多云 + 線下 IDC：希望多個(gè)云廠商以及線下 IDC 采用的是同一套采集方案；

• 應(yīng)用周期短：部分應(yīng)用的運(yùn)行生命周期極短，需要能夠及時(shí)將數(shù)據(jù)采集到服務(wù)端；

• 海外數(shù)據(jù)回國(guó)：海外節(jié)點(diǎn)的日志回國(guó)分析，需盡可能保證傳輸穩(wěn)定性和可靠性。

用戶最終選擇使用阿里云 Kubernetes 日志平臺(tái)的方案，使用 Logtail 的方案解決采集可靠性問(wèn)題，通過(guò)公網(wǎng)、專線、全球加速的配合解決網(wǎng)絡(luò)問(wèn)題，由系統(tǒng)管理員使用 DaemonSet 統(tǒng)一采集所有系統(tǒng)組件級(jí)別的日志，應(yīng)用方只需使用 CRD 采集自己的業(yè)務(wù)日志。對(duì)于平臺(tái)側(cè)，系統(tǒng)管理員可以訪問(wèn)所有系統(tǒng)級(jí)別日志，并進(jìn)行統(tǒng)一的監(jiān)控和告警；對(duì)于應(yīng)用側(cè)，應(yīng)用方不僅可以查到自己的業(yè)務(wù)日志，還能訪問(wèn)到和業(yè)務(wù)相關(guān)的中間件、Ingress、系統(tǒng)組件日志，進(jìn)行全鏈路的分析。

二次開(kāi)發(fā)日志管理平臺(tái)

在阿里有很多大的業(yè)務(wù)部門(mén)希望基于我們標(biāo)準(zhǔn)的日志平臺(tái)進(jìn)行二次開(kāi)發(fā)，來(lái)滿足他們部門(mén)的一些特殊需求，例如：

• 通過(guò)各類規(guī)則以及接口限制規(guī)范數(shù)據(jù)接入。

• 通過(guò) TraceID 將整個(gè)調(diào)用鏈串聯(lián)，構(gòu)建 Trace 平臺(tái)。

• 部門(mén)內(nèi)部多用戶的權(quán)限細(xì)化管理。

• 部門(mén)內(nèi)部各個(gè)子部門(mén)的成本結(jié)算。

• 與一內(nèi)部些管控、運(yùn)維系統(tǒng)打通。

這些需求可以基于我們提供的 OpenAPI 以及各語(yǔ)言的 SDK 快速的實(shí)現(xiàn)，同時(shí)為了減少前端的工作量，平臺(tái)還提供 Iframe 嵌入的功能，支持直接將部分界面（例如查詢框、Dashboard）直接嵌入到業(yè)務(wù)部門(mén)自己的系統(tǒng)中。

未來(lái)工作展望

目前阿里 Kubernetes 日志平臺(tái)在內(nèi)外部已經(jīng)有非常多的應(yīng)用，未來(lái)我們還將繼續(xù)打磨平臺(tái)，為應(yīng)用方 / 用戶提供更加完美的方案，后續(xù)工作主要集中在以下幾點(diǎn)：

• 數(shù)據(jù)采集進(jìn)一步精細(xì)化，持續(xù)優(yōu)化可靠性和資源消耗，做到極致化的多租戶隔離，爭(zhēng)取在 PaaS 平臺(tái)使用 DaemonSet 采集所有應(yīng)用的日志。

• 提供更加便捷、智能的數(shù)據(jù)清洗服務(wù)，在平臺(tái)內(nèi)部就可以完成異構(gòu)數(shù)據(jù)的清洗、規(guī)整等工作。

• 構(gòu)建面向 Ops 領(lǐng)域的、可自動(dòng)更新的、支持異構(gòu)數(shù)據(jù)的知識(shí)圖譜，讓問(wèn)題排查的經(jīng)驗(yàn)可以積累在知識(shí)庫(kù)中，實(shí)現(xiàn)異常搜索與推理。

• 提供交互式的訓(xùn)練平臺(tái)，構(gòu)建更加智能的 Automation 能力，真正實(shí)現(xiàn) Ops 的閉環(huán)。

?

相關(guān)工作與參考

阿里云日志服務(wù) https://www.aliyun.com/product/sls

阿里云 Kubernetes : https://www.aliyun.com/product/kubernetes

Kubernetes 審計(jì)日志方案 : https://yq.aliyun.com/articles/686982

Kubernetes Ingress 日志方案 : https://yq.aliyun.com/articles/693600

數(shù)據(jù)采集全球加速 : https://yq.aliyun.com/articles/620453

日志采集 CRD 配置： https://yq.aliyun.com/articles/596310

---

作者簡(jiǎn)介

元乙，阿里云日志服務(wù)技術(shù)專家，負(fù)責(zé)阿里巴巴集團(tuán)、螞蟻金服、阿里云等全站日志采集基礎(chǔ)設(shè)施建設(shè)與維護(hù)，覆蓋數(shù)百萬(wàn)服務(wù)器、數(shù)萬(wàn)應(yīng)用、每天數(shù)十 PB 數(shù)據(jù)，歷經(jīng)多次雙十一考驗(yàn)。目前主要關(guān)注 Kubernetes、微服務(wù)、IoT 等領(lǐng)域的 DevOps、AIOps 技術(shù)。

總結(jié)

以上是生活随笔為你收集整理的干货分享 | 阿里PB级Kubernetes日志平台建设实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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