更優效能與價效比，從自建 ELK 遷移到 SLS 開始

背景

ELK (Elasticsearch、Logstash、Kibana) 是當下開源領域主流的日誌解決方案，在可觀測場景下有比較廣泛的應用。

隨著數字化程序加速，機器資料日誌增加，自建 ELK 在面臨大規模資料、查詢效能等方面有較多問題和挑戰。如何解決可觀測資料的低成本、高可用是一個新的話題。

SLS 是由阿里雲推出的雲上可觀測 Serverless 產品，在功能層面對標 ELK，並且提供了高可用、高效能、低成本的方案。現在 SLS 推出了開源相容（Elasticsearch、Kafka 等）能力，可幫助自建 ELK 場景平滑切換到 SLS 上來，在保留開源使用習慣的同時，享受到雲上日誌的便捷和低成本。

SLS 與 Elasticsearch 的前世今生

Elasticsearch 是從 2010 年開始寫下第一行程式碼，整體使用 Java 語言，在 2012 年開始正式成立公司運作。它的底層是 Lucene 全文索引引擎，早期 ES 的主要場景是做企業搜尋（比如文件搜素、商品搜尋等）。近幾年可觀測場景資料日益增加，Elasticsearch 正式進入可觀測領域。

SLS 自 2012 年開始就面向可觀測場景，從阿里雲內部開始孵化，依託於阿里雲飛天的底座構建，使用的是 C++ 語言，以其高效能、高可靠等特性贏得了大量內部客戶認可。於 2017 年開始在阿里雲上正式對外提供服務。

可以看到，Elasticsearch 和 SLS 的產品歷程都超過 10 年。其中，SLS 一直在可觀測領域深耕，透過底層最佳化持續在可觀測領域提供高質量服務。

阿里雲 SLS 核心功能架構

SLS 底層使用阿里雲飛天盤古分佈檔案系統儲存，支援各類可觀測資料（Log/Metric/Trace）的儲存格式，預設使用多副本備份確保高可用，同時也支援多種儲存規格（熱存、冷存、歸檔）。在儲存層之上提供各類查詢和計算的能力，包括：

• SQL 分析標準 SQL92 支援
• 索引查詢和 SPL，索引查詢提供和 Lucene 類似的查詢能力
• 資料加工 方便對上報後的日誌進行二次加工
• 資料管道 提供類似 Kafka 的消費、寫入能力

在基礎的儲存、計算能力之前也提供了各類語言 SDK，方便業務整合。同時 SLS 也提供了垂直場景開箱即用的功能，包括 AIOps（異常檢測、根因分析）、Copilot（支援用自然語言的方式查詢資料）、告警、移動端監控、Flink、Spark 的消費 lib 等。另外，SLS 提供開源相容的能力，可以很方便地和現有的開源生態進行整合，包括 Elasticsearch、Kafka 等，透過使用 SLS 相容能力，可以很方便地將自建系統遷移到 SLS 上來。

SLS 與 Elasticsearch 功能對比

對比項	SLS	開源自建 ELK
採集能力	iLogtail（C++ 實現、高效能、開源）	Beats 系列、Logstash（效能較低）
儲存能力	單 Logstore 支援 PB 級	單 Index 百 GB 級 資料量大需要拆分 Index
查詢能力	支援	支援
無索引查詢	支援 SPL 方式做無索引查詢	不支援
SQL 分析	支援標準 SQL 92 語法	不完整的 SQL 支援
流式消費	支援（支援 Kafka 協議、SLS 原生協議） Flink/Spark 消費	不支援
告警	原生支援告警	需要 XPack 啟用 Kibana Watch 或者第三方（Grafana 告警、ElasticAlert 等）
視覺化	SLS 原生控制檯/Grafana/Kibana	Kibana、Grafana
DevOps 平臺整合	SLS 控制檯頁面可直接嵌入到 DevOps 平臺	Kibana 有限的嵌入能力，主要依賴 SDK API 做二次開發
AIOps	SLS 原生支援 AIOps	需 XPack 啟用

SLS 原生提供了豐富的功能，基於 Serverless 的特性，這些在雲上可以做到一鍵啟用。

SLS 與 Elasticsearch 的可運維性對比

對比項	SLS	開源自建 ELK
容量規劃	Serverless 無需關注	需關注容量•如果磁碟滿將直接影響可用性•ES 寫入效能差，需要為高峰預留足夠多的資源
機器運維	Serverless 無需關注	需要關注機器可用性，如果批次當機將影響可用性
效能調優	只需擴 Logstore Shard 即可	需要專業的 Elasticsearch 領域支援，可能需要社群支援
版本升級	Serverless 無需關注(SLS 後臺持續迭代，提升效能)	開源 ELK 不保證版本相容性，可能因為升級導致不可用
資料可靠性	底層使用業界領先的飛天盤古儲存，預設 3 副本儲存	按需設定副本數；如果是單副本，遇意外資料損壞，可恢復機率低
服務 SLA	SLS 保證	專人或專門團隊保證，可能因為大的 Query 導致叢集不可用

由於 SLS 是雲上 Serverless 服務，無需購買例項即可使用，免除了運維層面的煩惱。而自建 ELK 需要關注諸多運維層面的問題。 對於使用量較大的場景，比如資料量到 10TB 以上，往往需要專業的人來做 Elasticsearch 的維護和調優。

SLS 與 Elasticsearch 的效能對比

這裡在實驗室環境中做了一下簡單的查詢分析能力的測試。在 10 億級別的資料量中做查詢和分析，SLS 響應時間在秒級，而 Elasticsearch 隨著併發增大，響應時間有明顯上升，並且在整體延時上比 SLS 高。這裡還需要提到 Elasticsearch 的寫入效能問題，測下來單核能力在 2MB/s 左右，而 SLS 單 Shard 寫入能可以支援到 10MB/s ，透過擴大 Logstore 的 Shard 數可以輕鬆地提升寫入效能。

SLS 與 Elasticsearch 的成本對比

上面是一張成本對比圖，Elasticsearch 的機器數基本上是由峰值的寫入量決定的。對於 Elasticsearch 而言，寫入是最大的瓶頸；Elasticsearch 儲存空間需要考慮索引膨脹率和一定的空間預留。不然可能因為磁碟滿導致服務不可用。

對於 SLS 而言，作為 Serverless 服務，它提供按寫入量計費的方式，按照目前 0.4 元/GB 的寫入費用估算，在 10TB 每天的場景下，30、90、180 天下的成本相對 Elasticsearch 有明顯優勢。其中，SLS 費用預估時按照下面的方式測算：

• SLS 按流量計費 0.4 元/GB（送 30 天儲存）
• 90 天儲存按照 30 天熱 + 60 天低頻
• 180 天儲存按照 30 天熱 + 60 天低頻 + 90 天歸檔

那麼是不是隻有資料量大的情況下 SLS 才換算呢？答案是否定的，考慮一個場景，如果每天資料量是 10GB，需要保留 30 天，那麼每天的費用是 4 元，即每個月 120 元。需要一臺 ECS 至少 2core 4g 磁碟空間 400GB（300/0.75 空間預留）， 每月持有費用是大於 200 的。

SLS 開源相容能力

SLS 的 Elasticsearch 相容、Kafka 相容能力是基於 SLS 底層儲存計算能力構建的。本質上是將 Elasticsearch、Kafka 的請求轉換為 SLS 的協議進行請求，因此一份資料不管用什麼方式寫入 SLS，都可以用 Elasticsearch 相容的方式來查詢，也可以用 Kafka 相容的方式來消費。

以前，對於 Kafka+ELK 的架構，往往需要較多機器做資料同步（LogStash、HangOut 等）；現在使用一個 SLS 完全不需要資料同步，就可以用不同的協議來訪問。簡單來說就是一份資料提供了多種協議方式。 透過 Kafka 協議寫入的資料可以用 ES 協議來立馬查詢；同樣透過 Elasticsearch 協議寫入的資料，可以用 Kafka 立馬消費。使用 SLS 的開源相容能力，相當於同時擁有一個 Serverless 的 Kafka 和 Elasticsearch，並且是按量付費，無需購買例項。

使用 Kibana 訪問 SLS

用 Kibana 訪問 SLS 需要 3 個元件：

• Kibana
• Proxy 用於區分 Kibana 的後設資料請求和日誌資料請求
• Elasticsearch 只用於存 Kibana 的 meta 資料，資源佔用比較小，用一臺小規格 ECS 即可滿足

Kibana 將後設資料存在 Elasticsearch 中，會有 meta 更新的操作。 當前 SLS 提供的是不可修改的儲存，因此 meta 類的資料還需要一個小的 Elasticsearch 來承載。這個 Elasticsearch 只處理 meta 請求，因此負載和資料儲存量非常低，用小規格 ECS 可以滿足。

使用 Kibana 訪問 SLS 具體可以參考對接 Kibana[1]。

使用 Grafana Elasticsearch 外掛訪問 SLS

除了 Kibana 的方式來做日誌視覺化，也可以用 Grafana 的 Elasticsearch 外掛來訪問 SLS。使用 Grafana Elasticsearch 外掛訪問 SLS Elasticsearch 相容介面，有2個好處：

• 不需要寫 SQL 語句，透過介面操作即可完成圖表視覺化
• 不需要在 Grafana 額外安裝外掛

用 Grafana 自帶的 Elasticsearch 外掛訪問 SLS 具體可以參考使用 Grafana ES 外掛訪問 SLS[2]。

使用 Kafka SDK 寫入/消費 SLS

使用 Kafka 官方的 SDK 可以對接 SLS 的 Kafka 相容介面。支援 Kafka 寫入和消費兩種能力。

推薦使用 Kafka 官方 SDK 消費，具體可以參考 Kafka SDK 消費 SLS[3]、各類 Agent 寫 SLS Kafka 相容介面[4]。

開源 ELK 的平滑遷移方案

使用雙採方案進行遷移

在原先的機器上部署 SLS 的 iLogtail 採集 Agent，將業務日誌使用 iLogtail 採集到 SLS 上（一份日誌可以被多個 Agent 採集，不會衝突），然後使用 Elasticsearch 相容、Kafka 相容的能力對接原有的使用程式。透過這個方案可以很方便地做效能、資料完整性驗證。在充分驗證後，移除掉機器上 filebeat 的 Agent，即可完成鏈路切換。

使用開源 Agent 直寫遷移

如果是新的業務或者 APP 想要嘗試 SLS，沒有歷史包袱。但是又不想在機器上安裝 iLogtail。那麼可以複用原來的採集 Agent，將採集 Agent 的日誌以 Kafka 協議的方式寫入到 SLS。參考使用 Kafka 協議上傳日誌[5]。在日誌寫入 SLS 後，想保留開源使用習慣，可以使用 SLS 相容介面對接 Kibana、Grafana 等視覺化工具。

使用 Kafka 匯入遷移

如果我們不希望動原來的採集鏈路，同時又要保留原 Kafka（通常是依賴 Kafka 的歷史遺留程式較多，不好動），那麼可以使用這個方案。使用 SLS 的 Kafka 匯入功能，無需部署例項，在頁面上配置即可完成 Kafka 資料匯入到 SLS （支援持續匯入），參考 SLS Kafka 匯入[6]。將 Kafka 資料匯入到 SLS 後，可以使用 SLS 開源相容的能力保留開源使用的習慣。

使用 Elasticsearch 匯入功能遷移存量資料

對於 Elasticsearch 中歷史資料希望可以匯入到 SLS 中做保留的場景，可以使用 SLS 的 Elasticsearch 匯入功能，功能參考 ES 匯入[7]。

總結

本文介紹了 SLS 基本能力，並和開源自建 ELK 做了對比，可以看到 SLS 相比開源 ELK 有較大優勢。藉助 SLS Serverless 服務能力幫助運維團隊有效降低日誌系統的運維壓力與成本，提升日誌使用的體驗。現在 SLS 提供了豐富的開源相容能力，在體驗 SLS 諸多 Feature 同時，又可以保留開源使用習慣；在 ELK 日誌系統切換方便又可以做到平滑遷移。綜上，歡迎大家使用 SLS ，有任何問題可以透過客戶群、工單來聯絡我們。

參考連結：

[1] 對接 Kibana

https://help.aliyun.com/zh/sls/developer-reference/connect-log-service-to-kibana?spm=a2c4g.11186623.0.i10

[2] 使用 Grafana ES 外掛訪問 SLS

https://help.aliyun.com/zh/sls/user-guide/use-grafana-to-access-the-elasticsearch-compatible-api-of-log-service?spm=a2c4g.11186623.0.i13

[3] Kafka SDK 消費 SLS

https://help.aliyun.com/zh/sls/user-guide/overview-of-kafka-consumption?spm=a2c4g.11186623.0.i6

[4] 各類 Agent 寫 SLS Kafka 相容介面

https://help.aliyun.com/zh/sls/user-guide/use-the-kafka-protocol-to-upload-logs?spm=a2c4g.11186623.0.i15

[5] 使用 Kafka 協議上傳日誌

https://help.aliyun.com/zh/sls/user-guide/use-the-kafka-protocol-to-upload-logs?spm=a2c4g.11186623.0.i4

[6] SLS Kafka 匯入

https://help.aliyun.com/zh/sls/user-guide/import-data-from-kafka-to-log-service?spm=a2c4g.11186623.0.i5

[7] ES 匯入

https://help.aliyun.com/zh/sls/user-guide/import-data-from-elasticsearch-to-log-service?spm=a2c4g.11186623.0.i7

作者：荊磊

原文連結

本文為阿里雲原創內容，未經允許不得轉載。