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

背景

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

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

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

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

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

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

優(yōu)化之前

集群費用

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

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

上述配置一年的價格將近 19 萬。

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

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

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

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

優(yōu)化方案

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

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

一站式日志服務(wù)

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

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

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

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

因為涉及到公司的具體業(yè)務(wù)，遷移細(xì)節(jié)本文就不詳細(xì)描述了，考慮清楚整個日志數(shù)據(jù)流的變化，整體過程還是非常順利的。

優(yōu)化之后

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

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

服務(wù)費用

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

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

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

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

小結(jié)

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

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

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

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

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

擴(kuò)展閱讀

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

鏈接