背景

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 原生提供了豐富的功能，基於 Serverless 的特性，這些在雲上可以做到一鍵啓用。

SLS 與 Elasticsearch 的可運維性對比

由於 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-lo...

[2] 使用 Grafana ES 插件訪問 SLS

https://help.aliyun.com/zh/sls/user-guide/use-grafana-to-acce...

[3] Kafka SDK 消費 SLS

https://help.aliyun.com/zh/sls/user-guide/overview-of-kafka-c...

[4] 各類 Agent 寫 SLS Kafka 兼容接口

https://help.aliyun.com/zh/sls/user-guide/use-the-kafka-proto...

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

https://help.aliyun.com/zh/sls/user-guide/use-the-kafka-proto...

[6] SLS Kafka 導入

https://help.aliyun.com/zh/sls/user-guide/import-data-from-ka...

[7] ES 導入

https://help.aliyun.com/zh/sls/user-guide/import-data-from-el...

作者：荊磊

原文鏈接

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