一文看懂 K8s 日志系統(tǒng)設(shè)計(jì)和實(shí)踐

上一篇中我們介紹了為什么需要一個(gè)日志系統(tǒng)、為什么云原生下的日志系統(tǒng)如此重要以及云原生下日志系統(tǒng)的建設(shè)難點(diǎn)，相信DevOps、SRE、運(yùn)維等同學(xué)看了是深有體會(huì)的。本篇文章單刀直入，會(huì)直接跟大家分享一下如何在云原生的場(chǎng)景下搭建一個(gè)靈活、功能強(qiáng)大、可靠、可擴(kuò)容的日志系統(tǒng)。

需求驅(qū)動(dòng)架構(gòu)設(shè)計(jì)

技術(shù)架構(gòu)，是將產(chǎn)品需求轉(zhuǎn)變?yōu)榧夹g(shù)實(shí)現(xiàn)的過(guò)程。對(duì)于所有的架構(gòu)師而言，能夠?qū)a(chǎn)品需求分析透徹是非?；疽彩欠浅Ｖ匾囊稽c(diǎn)。很多系統(tǒng)剛建成沒(méi)多久就要被推翻，最根本的原因還是沒(méi)有解決好產(chǎn)品真正的需求。

我所在的日志服務(wù)團(tuán)隊(duì)在日志這塊有近10年的經(jīng)驗(yàn)，幾乎服務(wù)阿里內(nèi)部所有的團(tuán)隊(duì)，涉及電商、支付、物流、云計(jì)算、游戲、即時(shí)通訊、IoT等領(lǐng)域，多年來(lái)的產(chǎn)品功能的優(yōu)化和迭代都是基于各個(gè)團(tuán)隊(duì)的日志需求變化。

有幸我們最近幾年在阿里云上實(shí)現(xiàn)了產(chǎn)品化，服務(wù)了數(shù)以萬(wàn)計(jì)的企業(yè)用戶(hù)，包括國(guó)內(nèi)各大直播類(lèi)、短視頻、新聞媒體、游戲等行業(yè)Top1互聯(lián)網(wǎng)客戶(hù)。產(chǎn)品功能從服務(wù)一個(gè)公司到服務(wù)上萬(wàn)家公司會(huì)有質(zhì)的差別，上云促使我們更加深入的去思考：究竟哪些功能是日志這個(gè)平臺(tái)需要去為用戶(hù)去解決的，日志最核心的訴求是什么，如何去滿(mǎn)足各行各業(yè)、各種不同業(yè)務(wù)角色的需求...

需求分解與功能設(shè)計(jì)

上一節(jié)中我們分析了公司內(nèi)各個(gè)不同角色對(duì)于日志的相關(guān)需求，總結(jié)起來(lái)有以下幾點(diǎn)：

1. 支持各種日志格式、數(shù)據(jù)源的采集，包括非K8s
2. 能夠快速的查找/定位問(wèn)題日志
3. 能夠?qū)⒏鞣N格式的半結(jié)構(gòu)化/非結(jié)構(gòu)化日志格式化，并支持快速的統(tǒng)計(jì)分析、可視化
4. 支持通過(guò)日志進(jìn)行實(shí)時(shí)計(jì)算并獲得一些業(yè)務(wù)指標(biāo)，并支持基于業(yè)務(wù)指標(biāo)實(shí)時(shí)的告警（其實(shí)本質(zhì)就是APM）
5. 支持對(duì)于超大規(guī)模的日志進(jìn)行各種維度的關(guān)聯(lián)分析，可接受一定時(shí)間的延遲
6. 能夠便捷的對(duì)接各種外部系統(tǒng)或支持自定義的獲取數(shù)據(jù)，例如對(duì)接第三方審計(jì)系統(tǒng)
7. 能夠基于日志以及相關(guān)的時(shí)序信息，實(shí)現(xiàn)智能的告警、預(yù)測(cè)、根因分析等，并能夠支持自定義的離線(xiàn)訓(xùn)練方式以獲得更好的效果

為滿(mǎn)足上述這些功能需求，日志平臺(tái)上必須具備的功能功能模塊有：

1. 全方位日志采集，支持DaemonSet、Sidecar各種采集方式以應(yīng)對(duì)不同的采集需求，同時(shí)支持Web、移動(dòng)端、IoT、物理機(jī)/虛擬機(jī)各種數(shù)據(jù)源的采集；
2. 日志實(shí)時(shí)通道，這個(gè)是為了對(duì)接上下游所必備的功能，保證日志能夠被多種系統(tǒng)所便捷的使用；
3. 數(shù)據(jù)清洗（ETL: Extract，Transform，Load），對(duì)各種格式的日志進(jìn)行清洗，支持過(guò)濾、富化、轉(zhuǎn)換、補(bǔ)漏、分裂、聚合等；
4. 日志展現(xiàn)與搜索，這是所有日志平臺(tái)必須具備的功能，能夠根據(jù)關(guān)鍵詞快速的定位到日志并查看日志上下文，看似簡(jiǎn)單的功能卻最難做好；
5. 實(shí)時(shí)分析，搜索只能完成一些定位到問(wèn)題，而分析統(tǒng)計(jì)功能可以幫助快速分析問(wèn)題的根因，同時(shí)可以用于快速的計(jì)算一些業(yè)務(wù)指標(biāo)；
6. 流計(jì)算，通常我們都會(huì)使用流計(jì)算框架（Flink、Storm、Spark Stream等）來(lái)計(jì)算一些實(shí)時(shí)的指標(biāo)或?qū)?shù)據(jù)進(jìn)行一些自定義的清洗等；
7. 離線(xiàn)分析，運(yùn)營(yíng)、安全相關(guān)的需求都需要對(duì)大量的歷史日志進(jìn)行各種維度的關(guān)聯(lián)計(jì)算，目前只有T+1的離線(xiàn)分析引擎能夠完成；
8. 機(jī)器學(xué)習(xí)框架，能夠便捷、快速的將歷史的日志對(duì)接到機(jī)器學(xué)習(xí)框架進(jìn)行離線(xiàn)訓(xùn)練，并將訓(xùn)練后的結(jié)果加載到線(xiàn)上實(shí)時(shí)的算法庫(kù)中。

開(kāi)源方案設(shè)計(jì)

cdn.com/ca9654af34388e612fb46c6ea67b269d3ae7e89f.png">

借助于強(qiáng)大的開(kāi)源社區(qū)，我們可以很容易基于開(kāi)源軟件的組合來(lái)實(shí)現(xiàn)這樣一套日志平臺(tái)，上圖是一個(gè)非常典型的以ELK為核心的日志平臺(tái)方案：

• 利用FileBeats、Fluentd等采集Agent實(shí)現(xiàn)容器上的數(shù)據(jù)統(tǒng)一收集。
• 為了提供更加豐富的上下游以及緩沖能力，可以使用kafka作為數(shù)據(jù)采集的接收端。
• 采集到的原始數(shù)據(jù)還需要進(jìn)一步的清洗，可以使用Logstash或者Flink訂閱Kafka中的數(shù)據(jù)，清洗完畢后再寫(xiě)入kafka中。
• 清洗后的數(shù)據(jù)可以對(duì)接ElasticSearch來(lái)做實(shí)時(shí)的查詢(xún)檢索、對(duì)接Flink來(lái)計(jì)算實(shí)時(shí)的指標(biāo)和告警、對(duì)接Hadoop來(lái)做離線(xiàn)的數(shù)據(jù)分析、對(duì)接TensorFlow來(lái)做離線(xiàn)模型訓(xùn)練。
• 數(shù)據(jù)的可視化可以使用grafana、kibana等常用的可視化組件。

為什么我們選擇自研

采用開(kāi)源軟件的組合是非常高效的方案，得益于強(qiáng)大的開(kāi)源社區(qū)以及龐大用戶(hù)群體的經(jīng)驗(yàn)積累，我們可以很快搭建出這樣一套系統(tǒng)，并且可以滿(mǎn)足我們絕大部分的需求。

當(dāng)我們把這套系統(tǒng)部署好，能夠把日志從容器上采集上來(lái)、elasticsearch上能夠查到、Hadoop上能夠成功執(zhí)行SQL、Grafana上能看到圖、告警短信能收到......完成上述流程打通后，加加班可能只需要花費(fèi)幾天的時(shí)間，當(dāng)系統(tǒng)終于跑通的時(shí)候，這時(shí)候終于可以長(zhǎng)舒一口氣，躺在辦公椅上放松放松。

然而理想很豐滿(mǎn)現(xiàn)實(shí)很骨感，當(dāng)我們預(yù)發(fā)通了，測(cè)試完了上到生產(chǎn)，開(kāi)始接入第一個(gè)應(yīng)用，逐漸更多的應(yīng)用接入，越來(lái)越多的人開(kāi)始使用......這時(shí)候很多問(wèn)題都可能暴露出來(lái)：

• 隨著業(yè)務(wù)量的上漲，日志量也越來(lái)越大，Kakfa和ES要不斷擴(kuò)容，同時(shí)同步Kafka到ES的Connector也需要擴(kuò)容，最煩的是采集Agent，每臺(tái)機(jī)器上部署的DaemonSet Fluentd根本沒(méi)辦法擴(kuò)容，到了單Agent瓶頸就沒(méi)辦法了，只能換Sidecar，換Sidecar工作量大不說(shuō)，還會(huì)帶來(lái)一系列其他的問(wèn)題，比如怎么和CICD系統(tǒng)集成、資源消耗、配置規(guī)劃、stdout采集不支持等等。
• 從剛開(kāi)始上的邊緣業(yè)務(wù)，慢慢更多的核心業(yè)務(wù)接入，對(duì)于日志的可靠性要求越來(lái)越高，經(jīng)常有研發(fā)反應(yīng)從ES上查不到數(shù)據(jù)、運(yùn)營(yíng)說(shuō)統(tǒng)計(jì)出來(lái)的報(bào)表不準(zhǔn)、安全說(shuō)拿到的數(shù)據(jù)不是實(shí)時(shí)的......每次問(wèn)題的排查都要經(jīng)過(guò)采集、隊(duì)列、清洗、傳輸?shù)鹊确浅６嗟穆窂剑挪榇鷥r(jià)非常高。同時(shí)還要為日志系統(tǒng)搭建一套監(jiān)控方案，能夠即時(shí)發(fā)現(xiàn)問(wèn)題，而且這套方案還不能基于日志系統(tǒng)，不能自依賴(lài)。
• 當(dāng)越來(lái)越多的開(kāi)發(fā)開(kāi)始用日志平臺(tái)調(diào)查問(wèn)題時(shí)，經(jīng)常會(huì)出現(xiàn)因?yàn)槟?-2個(gè)人提交一個(gè)大的查詢(xún)，導(dǎo)致系統(tǒng)整體負(fù)載上升，其他人的查詢(xún)都會(huì)被Block，甚至出現(xiàn)Full GC等情況。這時(shí)候一些大能力的公司會(huì)對(duì)ES進(jìn)行改造，來(lái)支持多租戶(hù)隔離；或者為不同的業(yè)務(wù)部門(mén)搭建不同的ES集群，最后又要運(yùn)維多個(gè)ES集群，工作量還是很大。
• 當(dāng)投入了很多人力，終于能夠把日志平臺(tái)維持日常使用，這時(shí)候公司財(cái)務(wù)找過(guò)來(lái)了，說(shuō)我們用了非常多的機(jī)器，成本太大。這時(shí)候開(kāi)始要優(yōu)化成本，但是思來(lái)想去就是需要這么多臺(tái)機(jī)器，每天大部分的機(jī)器水位都在20%-30%，但是高峰的水位可能到70%，所以不能撤，撤了高峰頂不住，這時(shí)候只能搞搞削峰填谷，又是一堆工作量。

上述這些是一家中等規(guī)模的互聯(lián)網(wǎng)企業(yè)在日志平臺(tái)建設(shè)中經(jīng)常會(huì)遇到的問(wèn)題，在阿里這些問(wèn)題會(huì)放大非常多倍：

• 比如面對(duì)雙十一的流量，市面上所有的開(kāi)源軟件都無(wú)法滿(mǎn)足我們那么大流量的需求。
• 面對(duì)阿里內(nèi)部上萬(wàn)個(gè)業(yè)務(wù)應(yīng)用，幾千名工程師同時(shí)使用，并發(fā)和多租戶(hù)隔離我們必須要做到極致。
• 面對(duì)非常多核心的訂單、交易等場(chǎng)景，整個(gè)鏈路的穩(wěn)定性必須要求3個(gè)9甚至4個(gè)9的可用性。
• 每天如此大的數(shù)據(jù)量，對(duì)于成本的優(yōu)化顯得極為重要，10%的成本優(yōu)化帶來(lái)的收益可能就有上億。

阿里K8s日志方案

針對(duì)上述的一些問(wèn)題，我們經(jīng)過(guò)多年的時(shí)間，開(kāi)發(fā)并打磨出這樣一套K8s日志方案：

1. 使用我們自研的日志采集Agent Logtail實(shí)現(xiàn)K8s全方位的數(shù)據(jù)采集，目前Logtail在集團(tuán)內(nèi)有數(shù)百萬(wàn)的全量部署，性能、穩(wěn)定性經(jīng)過(guò)多次雙十一金融級(jí)考驗(yàn)。
2. 化繁為簡(jiǎn)，數(shù)據(jù)隊(duì)列、清洗加工、實(shí)時(shí)檢索、實(shí)時(shí)分析、AI算法等原生集成，而不是基于各種開(kāi)源軟件搭積木的形式實(shí)，大大降低了數(shù)據(jù)鏈路長(zhǎng)度，鏈路長(zhǎng)度的降低也意味著出錯(cuò)可能性的減少。
3. 隊(duì)列、清洗加工、檢索、分析、AI引擎等全部針對(duì)日志場(chǎng)景深度定制優(yōu)化，滿(mǎn)足大吞吐、動(dòng)態(tài)擴(kuò)容、億級(jí)日志秒級(jí)可查、低成本、高可用性等需求。
4. 對(duì)于流式計(jì)算、離線(xiàn)分析場(chǎng)景這種通用需求，無(wú)論是開(kāi)源還是阿里內(nèi)部都有非常成熟的產(chǎn)品，我們通過(guò)無(wú)縫對(duì)接的方式來(lái)支持，目前日志服務(wù)支持了數(shù)十種下游的開(kāi)源、云上產(chǎn)品的對(duì)接。

這套系統(tǒng)目前支撐了整個(gè)阿里集團(tuán)、螞蟻集團(tuán)、云上上萬(wàn)家企業(yè)的日志分析，每天寫(xiě)入的數(shù)據(jù)量16PB+，開(kāi)發(fā)、運(yùn)維這樣一套系統(tǒng)問(wèn)題和挑戰(zhàn)非常多，這里就不再展開(kāi)，有興趣的同學(xué)可以參考我們團(tuán)隊(duì)的技術(shù)分享：阿里10PB/天日志系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)。

總結(jié)

本篇主要從架構(gòu)層面去介紹如何搭建一套K8s的日志分析平臺(tái)，包括開(kāi)源方案以及我們阿里自研的一套方案。然而實(shí)際這套系統(tǒng)落地到生產(chǎn)環(huán)境并有效運(yùn)行還有很多工作要做：

1. K8s上以什么樣的姿勢(shì)來(lái)打日志？
2. K8s上的日志采集方案選擇，DaemonSet or Sidecar？
3. 日志方案如何與CICD去集成？
4. 微服務(wù)下各個(gè)應(yīng)用的日志存儲(chǔ)如何劃分？
5. 如何基于K8s系統(tǒng)的日志去做K8s監(jiān)控？
6. 如何去監(jiān)控日志平臺(tái)的可靠性？
7. 如何去對(duì)多個(gè)微服務(wù)/組件去做自動(dòng)的巡檢？
8. 如何自動(dòng)的監(jiān)控多個(gè)站點(diǎn)并實(shí)現(xiàn)流量異常時(shí)的快速定位？

后續(xù)文章我們會(huì)一步一步來(lái)和大家分享如何把這套系統(tǒng)落地，敬請(qǐng)期待。

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