開源之殤 ELK

運維就要無所不能，無所不會

大家好，我是 Stanley「史丹利」，今天聊聊日誌服務 ELK。

ELK 作爲日誌 UI 產品，自誕生就備受關注，時至今日也熱度不減，在 Github 上有着高達 54.7k 的關注。

K8S、MESOS、微服務技術出現後，更助力 ELK 成爲企業級日誌系統標配。

常見的構架如下：

elk

但如上架構通常會造成

  1. logstash 壓力過大，出現數據錄入延遲過大；

  2. 毛刺高峯數據寫入甚至會拖垮 Logstash；

  3. 支持的 Input 端有限；

等問題。爲了解決如上問題，業內通用方案是在 ELK 再加入一個  Kafka 實時流處理器，藉助   Kafka  接入海量吞吐，但 "平滑" 輸出數據的能力，很好的解決了如上三個問題。

事已至此，新的問題和瓶頸出現在 ElasticSearch 「後面簡稱 ES」，當數據量大到一定程度，TB 級別，ES 的查詢和成本投入簡直就是災難現場，主要有如下問題：

  1. ES 高內存、高 CPU、高存儲佔用，50TB，硬件投入樂觀估計在 50W，費用高昂；

  2. 隨熱數據不斷增加，定期清理策略逐步失效，搜索返回時間越來越長，分佈、聚合優化時間惡性延長；

  3. 擴縮容成本巨大，技術門檻高昂；

主要優化方案有：

  1. 冷熱數據隔離；

  2. 增加緩存；

  3. 提高數據預熱頻次；

  4. 增加分頁性能優化；

但只能緩解，無法根除！自建 ES 的成本及問題隨數據量增長，日趨明顯。

綜合考量，我們對自建 ES 和阿里 SLS 日誌解決方案做了對比，如下爲日誌架構及數據存儲方案對比：

架構圖對比

橘紅方框爲架構核心變動項。主要爲 SLS 日誌服務取代 ELK， OSS 存儲取代原來的硬件存儲。

除此外，我們還針對

四方面進行更爲詳盡的對比。

資源投入對比

這個表格算的腦殼疼，不得不說，商人就是商人，在費用計算上，永遠算不清楚... 和算到凌晨，還依然差了 3 分錢和阿里計算器對不上。

使用阿里 SLS，主要費用有 2 大塊「裏面有很多其它收費項，比如讀寫費用、數據加工費用、投遞費用等... 難算。。」：

sls 收費

如果只看 SLS 收費，我們認爲還算合理。3 年總花費大概 10W, 5 年在 17W, 算是良心便宜

只用 SLS 喫不消，需要永久保存的數據，按架構設計放在 OSS。

OSS 其實才是費用一大支出。

OSS 費用

3 年費用在 19.3w,5 年大概 45W, 這些費用都是基於折扣後的費用。其中 OSS 的花費逐年上漲，且比例攀升。主因是數據是增長且永久存放。

做一個費用整體對比

費用整體對比

依然能看的出，SLS 確實在費用投入上，無論是 1 年、3 年，還是 5 年，確實投入要比自建的要便宜很多，如果只用其基本功能，樂觀估計，成本可以優化 39%。

諾亞現在使用的是 K8S, 在 k8s 環境下，接入 SLS 也很方便，我們目前採用的方案是 sidecar + logtail 的方式。

sls 存取策略

SLS 的 UI 大致長這個樣子:

SLS UI

左側是 logstore, 相當於項目的概念，基於 logstore 級別可以：

sql 語法很靈活：

功能確實贊爆了。至此，我對阿里 SLS 的評價是：

sls 的數據過濾加工功能異常強大，幾乎可以加工達成我們想要的任何數據。目前發現也有一些缺陷：

  1. 價格不便宜

  2. 語法入門快，深入成本不低

  3. 速度慢，及時性一般。首次接入測試最少 6 分鐘後纔有數據

  4. 數據加工後，是基於原有的 logstore 複製流量修改後，重新錄入到一個全新的 logstore 。即數據雙份存儲。成本翻倍 (還不算加工的成本)

但總的來講，sls 算是目前接觸的最強大的日誌產品了。

嘮了這麼多，最後想說的是啥呢？... 別再自己折騰 ES 了，包括一些開源產品，公有云 PAAS 產品真的很香...

基於開源改造優化後的產品是真的香。。。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/WRU_6TaoPnaRtVnPpGRc0Q

猜你喜歡