上一篇中我們介紹了為什么需要一個(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)品需求分析透徹是非常基本也是非常重要的一點(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)：

支持各種日志格式、數(shù)據(jù)源的采集，包括非K8s

能夠快速的查找/定位問(wèn)題日志

能夠?qū)⒏鞣N格式的半結(jié)構(gòu)化/非結(jié)構(gòu)化日志格式化，并支持快速的統(tǒng)計(jì)分析、可視化

支持通過(guò)日志進(jìn)行實(shí)時(shí)計(jì)算并獲得一些業(yè)務(wù)指標(biāo)，并支持基于業(yè)務(wù)指標(biāo)實(shí)時(shí)的告警（其實(shí)本質(zhì)就是APM）

支持對(duì)于超大規(guī)模的日志進(jìn)行各種維度的關(guān)聯(lián)分析，可接受一定時(shí)間的延遲

能夠便捷的對(duì)接各種外部系統(tǒng)或支持自定義的獲取數(shù)據(jù)，例如對(duì)接第三方審計(jì)系統(tǒng)

能夠基于日志以及相關(guān)的時(shí)序信息，實(shí)現(xiàn)智能的告警、預(yù)測(cè)、根因分析等，并能夠支持自定義的離線訓(xùn)練方式以獲得更好的效果

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

全方位日志采集，支持DaemonSet、Sidecar各種采集方式以應(yīng)對(duì)不同的采集需求，同時(shí)支持Web、移動(dòng)端、IoT、物理機(jī)/虛擬機(jī)各種數(shù)據(jù)源的采集；

日志實(shí)時(shí)通道，這個(gè)是為了對(duì)接上下游所必備的功能，保證日志能夠被多種系統(tǒng)所便捷的使用；

數(shù)據(jù)清洗（ETL: Extract，Transform，Load），對(duì)各種格式的日志進(jìn)行清洗，支持過(guò)濾、富化、轉(zhuǎn)換、補(bǔ)漏、分裂、聚合等；

日志展現(xiàn)與搜索，這是所有日志平臺(tái)必須具備的功能，能夠根據(jù)關(guān)鍵詞快速的定位到日志并查看日志上下文，看似簡(jiǎn)單的功能卻最難做好；

實(shí)時(shí)分析，搜索只能完成一些定位到問(wèn)題，而分析統(tǒng)計(jì)功能可以幫助快速分析問(wèn)題的根因，同時(shí)可以用于快速的計(jì)算一些業(yè)務(wù)指標(biāo)；

流計(jì)算，通常我們都會(huì)使用流計(jì)算框架（Flink、Storm、Spark Stream等）來(lái)計(jì)算一些實(shí)時(shí)的指標(biāo)或?qū)?shù)據(jù)進(jìn)行一些自定義的清洗等；

離線分析，運(yùn)營(yíng)、安全相關(guān)的需求都需要對(duì)大量的歷史日志進(jìn)行各種維度的關(guān)聯(lián)計(jì)算，目前只有T+1的離線分析引擎能夠完成；

機(jī)器學(xué)習(xí)框架，能夠便捷、快速的將歷史的日志對(duì)接到機(jī)器學(xué)習(xí)框架進(jìn)行離線訓(xùn)練，并將訓(xùn)練后的結(jié)果加載到線上實(shí)時(shí)的算法庫(kù)中。

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

借助于強(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)做離線的數(shù)據(jù)分析、對(duì)接TensorFlow來(lái)做離線模型訓(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ù)鹊确浅６嗟穆窂?#xff0c;排查代價(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日志方案：

使用我們自研的日志采集Agent Logtail實(shí)現(xiàn)K8s全方位的數(shù)據(jù)采集，目前Logtail在集團(tuán)內(nèi)有數(shù)百萬(wàn)的全量部署，性能、穩(wěn)定性經(jīng)過(guò)多次雙十一金融級(jí)考驗(yàn)。

化繁為簡(jiǎn)，數(shù)據(jù)隊(duì)列、清洗加工、實(shí)時(shí)檢索、實(shí)時(shí)分析、AI算法等原生集成，而不是基于各種開(kāi)源軟件搭積木的形式實(shí)，大大降低了數(shù)據(jù)鏈路長(zhǎng)度，鏈路長(zhǎng)度的降低也意味著出錯(cuò)可能性的減少。

隊(duì)列、清洗加工、檢索、分析、AI引擎等全部針對(duì)日志場(chǎng)景深度定制優(yōu)化，滿(mǎn)足大吞吐、動(dòng)態(tài)擴(kuò)容、億級(jí)日志秒級(jí)可查、低成本、高可用性等需求。

對(duì)于流式計(jì)算、離線分析場(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)行還有很多工作要做：

K8s上以什么樣的姿勢(shì)來(lái)打日志？

K8s上的日志采集方案選擇，DaemonSet or Sidecar？

日志方案如何與CICD去集成？

微服務(wù)下各個(gè)應(yīng)用的日志存儲(chǔ)如何劃分？

如何基于K8s系統(tǒng)的日志去做K8s監(jiān)控？

如何去監(jiān)控日志平臺(tái)的可靠性？

如何去對(duì)多個(gè)微服務(wù)/組件去做自動(dòng)的巡檢？

如何自動(dòng)的監(jiān)控多個(gè)站點(diǎn)并實(shí)現(xiàn)流量異常時(shí)的快速定位？

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的云原生下日志方案的架构设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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