作者：荊磊
背景
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
[2] 使用 Grafana ES 插件訪問 SLS
[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 兼容接口
[5] 使用 Kafka 協議上傳日誌
[6] SLS Kafka 導入
[7] ES 導入
相關鏈接：