降本增效 - 應(yīng)用優(yōu)化 (三) 日志成本降低 100 倍

背景

本文接著前兩篇 “降本增效” 系列文章，復(fù)盤一下在業(yè)務(wù)系統(tǒng)中的日志功能優(yōu)化。

• 吃著火鍋唱著歌，突然就裁員了^[1]
• 一招搞定大報(bào)表下載^[2]

筆者所在業(yè)務(wù)線，老的日志查詢功能依賴于一套 EFK 集群，該集群除了作為日志查詢分析之外，還作為另外一條已經(jīng)陣亡的產(chǎn)品線的搜索模塊， 但是當(dāng)對(duì)應(yīng)的產(chǎn)品和運(yùn)維人員都被優(yōu)化掉之后，這套集群就只是作為日志查詢，于是一個(gè)降本增效的優(yōu)化目標(biāo)又有了 (最主要的問題是負(fù)責(zé)該集群的運(yùn)維同事也被優(yōu)化了，沒人維護(hù)了)。

如無特殊說明，本文中云服務(wù)商均指阿里云 (畢竟剛收到一波代金券)。

優(yōu)化目標(biāo)

1. 降低集群配置甚至直接去掉集群，降低云服務(wù)資源費(fèi)用
2. 從按年付費(fèi)開通集群，轉(zhuǎn)換到按需付費(fèi)模式，提升業(yè)務(wù) (公司) 的現(xiàn)金流
3. 自動(dòng)化管理，無需運(yùn)維介入工作 (主要是也沒有運(yùn)維人員了)
4. 不同的環(huán)境 (開發(fā)/灰度/生產(chǎn)) + 不同的服務(wù)組合，可以使用單獨(dú)的日志倉庫進(jìn)行存儲(chǔ)和查詢，做到應(yīng)用層無感知
5. 日志采集和推送更符合 “云原生” 理念，可以更方便集成到 Kubernetes 中

優(yōu)化之前

集群費(fèi)用

涉及到公司的業(yè)務(wù)體制，優(yōu)化之前的集群不方便截圖，不過這里可以直接給一個(gè)阿里云普通 EFK 集群規(guī)模價(jià)格費(fèi)用，直觀地感受一下 “鈔能力”。

這里以一個(gè)普通的 ElasticSearch 小集群為例來看看對(duì)應(yīng)的價(jià)格:

上述配置一年的價(jià)格將近 19 萬。

此外，因?yàn)?Kubernetes 中的服務(wù) (Pod) 日志要先傳送到 Kafka 等 MQ 作為中轉(zhuǎn), 然后再轉(zhuǎn)到 ElasticSearch，所以這里還需要加幾個(gè) Kafka 實(shí)例的費(fèi)用，日志的數(shù)據(jù)流大概如下圖所示。

粗略地計(jì)算下來，使用 ElasticSearch + Kafka + Kibana 這套技術(shù)棧作為日志存儲(chǔ)與檢測(cè)服務(wù)，一年的云服務(wù)費(fèi)用大概在 25 萬左右，這是單單硬件的費(fèi)用。

技術(shù)維護(hù)

除了硬件之外，還需要軟件的維護(hù)費(fèi)用，包括從日志收集、轉(zhuǎn)發(fā)、檢索配置、服務(wù)可用、數(shù)據(jù)歸檔等開發(fā)運(yùn)維工作量，轉(zhuǎn)換為成本也就是人員工資。

優(yōu)化方案

仔細(xì)分析上面的問題之后，其實(shí)核心就是要解決兩個(gè)問題: 硬件成本 + 運(yùn)維費(fèi)用，因?yàn)楣舅袠I(yè)務(wù)都是微服務(wù) + Kubernetes 架構(gòu)體系，同時(shí)使用阿里云作為服務(wù)廠商， 要想短期內(nèi)取得 “腳本增效” 收益并取得可見的效果，顯然最好的方案就是站在巨人的肩膀上，避免自己造輪子 (主要確實(shí)也沒有足夠的人力來造輪子)。

筆者遇到的問題，自然也有很多人都會(huì)遇到，大家都會(huì)遇到的問題，自然會(huì)被云計(jì)算服務(wù)商的產(chǎn)品經(jīng)理定位為共性問題，最后對(duì)應(yīng)的產(chǎn)品經(jīng)過抽象和包裝，自然也就應(yīng)運(yùn)而生了。

一站式日志服務(wù)

最終筆者將目標(biāo)鎖定在阿里云提供的開箱即用日志應(yīng)用 SLS, 下面是官方對(duì) SLS 的介紹。

日志服務(wù) （Simple Log Service，簡(jiǎn)稱 SLS） 是云原生觀測(cè)分析平臺(tái)，為 Log/Metric/Trace 等數(shù)據(jù)提供大規(guī)模、低成本、實(shí)時(shí)平臺(tái)化服務(wù)。一站式提供數(shù)據(jù)采集、加工、分析、告警可視化與投遞功能，全面提升研發(fā)、運(yùn)維、運(yùn)營和安全等場(chǎng)景數(shù)字化能力。

優(yōu)化方案確定之后，遷移的過程還是比較快的，從測(cè)試 -> 灰度 -> 生產(chǎn)全面部署，花了 3 周的時(shí)間，期間經(jīng)歷了如下工作:

• 開通 SLS 日志服務(wù)
• 創(chuàng)建日志項(xiàng)目，并且關(guān)聯(lián)到對(duì)應(yīng)的 Kubernetes 集群
• 創(chuàng)建 測(cè)試/灰度/生產(chǎn) 不同環(huán)境下的的日志倉庫，配置倉庫的數(shù)據(jù)分片、數(shù)據(jù)存儲(chǔ)時(shí)長等
• 設(shè)置單個(gè)服務(wù) (數(shù)據(jù)源) 對(duì)應(yīng)的具體日志倉庫
• 確認(rèn)服務(wù) (例如 Deployment) 的日志是否正常傳輸?shù)綄?duì)應(yīng)的日志倉庫
• 配置日志倉庫的數(shù)據(jù)預(yù)處理 (例如 JSON 數(shù)據(jù)序列展開)
• 配置日志倉庫的報(bào)警提示
• 開啟日志倉庫中的全文索引
• 刪除日志從收集 -> 中轉(zhuǎn) -> ElasticSearch 路徑中棄用的運(yùn)維配置
• 釋放閑置的 Kafka 實(shí)例
• 釋放閑置的 ElasticSearch 服務(wù)

因?yàn)樯婕暗焦镜木唧w業(yè)務(wù)，遷移細(xì)節(jié)本文就不詳細(xì)描述了，考慮清楚整個(gè)日志數(shù)據(jù)流的變化，整體過程還是非常順利的。

優(yōu)化之后

優(yōu)化之后的日志數(shù)據(jù)流如下圖所示。

接著對(duì)比一下優(yōu)化前后的費(fèi)用，看看具體的效果。

服務(wù)費(fèi)用

這里以前文中對(duì)應(yīng)的 ElasticSearch 集群規(guī)模為樣本，計(jì)算一下使用 SLS 日志服務(wù)的對(duì)應(yīng)的價(jià)格，日志服務(wù)配置如下:

• 按量計(jì)費(fèi)
• 每日寫入日志數(shù)據(jù)量 100 GB
• 保存數(shù)據(jù)周期為 31 天
• 開啟冷熱數(shù)據(jù)分離
• 開啟日志數(shù)據(jù)結(jié)構(gòu)的全文索引

技術(shù)維護(hù)

運(yùn)維成本幾乎為 0, 只需要?jiǎng)?chuàng)建倉庫并且在 Kubernetes 中的 Deployment 設(shè)置日志倉庫數(shù)據(jù)源即可，而且無需擔(dān)心服務(wù)性能、可用性問題，并且還有很多開箱即用的數(shù)據(jù)處理插件，真正實(shí)現(xiàn) “降本增效”。

小結(jié)

采用 SLS 日志服務(wù)之后，單純的日志存儲(chǔ)與檢索即使按年來計(jì)算也就在 2000 左右，乍一看，日志服務(wù)的成本似乎節(jié)省優(yōu)化了 100 倍，但是與此同時(shí)也付出了必要的代價(jià):

• 去掉了 ElasticSearch 服務(wù)，很多搜索功能無法實(shí)現(xiàn)了，如果后期再開啟新的業(yè)務(wù)，還是需要重新購置服務(wù)的
• 日志功能完成集成到了云服務(wù)計(jì)算廠商中，深度綁定

但是好在前文中設(shè)定的 5 個(gè)優(yōu)化目標(biāo)全部完成，又是一次軟件設(shè)計(jì)的 trade off 之旅。

優(yōu)化工作的本質(zhì)是面向收益編程。

一篇復(fù)盤文章，感覺硬生生地寫成了一篇軟文？話說回來，日志功能改造完成之后，業(yè)務(wù)技術(shù)棧中 Java 的比例越來越低，感覺在不歸路上越走越遠(yuǎn) :-)

擴(kuò)展閱讀

• 吃著火鍋唱著歌，突然就裁員了^[1]
• 一招搞定大報(bào)表下載^[2]
• Kubernetes 系統(tǒng)日志^[3]
• Kubernetes 日志架構(gòu)^[4]
• 阿里云 - 檢索分析服務(wù) Elasticsearch^[5]

鏈接