前言
本文作為即将釋出的混合雲産品 CDS-SLS（Cloud Defined Storage-Simple Log Service）一系列文章中的第二篇，主要進行 CDS-SLS 各功能點概覽性的介紹。日志作為數字化的載體，裡面包含了背景程式的運作資訊，業務營運等資訊。
日志的查詢分析從最早的幾台機器的手工 pssh+grep 發展到每個業務的小規模 ELK 或者 EFK（Elasticsearch, Logstash/Filebeat/Fluentd, Kibana），量大的再加上 Kafka，如果有采集 Metric的需求還需要加 Collectd，如果有可視化需求還需要增加 Grafana，對存儲備份有需求的還會引入 Ceph，對于基礎配置的一緻性管理引入 Salt 等，每增加一個元件在高并發場景下硬體成本和運維成本迅速增加。
CDS-SLS 作為雲化的日志平台，把這些元件進行了高内聚和低耦合，線下使用者最低可以在6台規模的機器上将上述所有的功能自動化部署，在運維、營運、财務管理、資料分析報表等大資料場景領域以低代碼模式有效解決傳統軟體中的痛點。
術語&背景
CDS
CDS(Cloud Defined Storage)雲定義存儲。屬于軟體定義存儲SDS(Software Defined Storage)的一種輸出形式，CDS 具備與公共雲統一的存儲架構和統一的使用者體驗，減小底座，提供靈活的部署規模和部署形态，融合多個存儲産品，提供企業級存儲的運維和管理。
CDS支援各種存儲産品的混部組合，例如 CDS-OSS + CDS-SLS ，CDS-EBS + CDS-SLS 等。産品方面會有靈活版（SLS 最小規模六台，計劃推出縮減到四台的更精簡版本）和企業版（SLS 6台到數百台）兩種輸出形式。CDS 一方面提高專有雲企業版和靈活版的産品競争力和産品成熟度；另一方面，在端、邊緣和客戶資料中心等環境實作各類資料的接入、備份、分析。
SLS
SLS(Simple Log Service) 阿裡雲日志服務。SLS 起源于阿裡雲早期飛天底座中的神農監控服務目前已發展為集采集、查詢分析、可視化一體的面向雲原生可觀測性的 *Ops(DevOps、SecOps、 FinOps) 整體解決方案。
SLS的主要功能概覽
SLS 中的日志資料是 AppendOnly，寫多讀少，對時間敏感但并非要求嚴格保序，查詢頻率和熱度随時間迅速遞減。CDS-SLS 版本繼承自阿裡雲上的 SLS，目前 SLS 已經連續多年支撐阿裡雙十一/雙十二活動，同時支撐衆多如新春紅包、周年大促等重大活動，在穩定性、功能性以及性能方面得到了充分的驗證。
本文着重從運維相關的角度來展開 SLS 的各個功能點。SLS 的主鍊路包含資料采集-資料查詢分析-可視化-智能應用，作為計算和存儲并重的産品，為了進一步降低線下使用者的硬體成本，會進行一些非通用性的功能的裁剪，将硬體本身的計算資源和存儲資源發揮到極緻。
上圖是公共雲使用者視角下的 SLS 功能，對于 CDS-SLS 線下使用者，可以在天基平台看到 SLS 服務對應的各個子子產品，也能完整看到各程序對應的 CPU 和記憶體占用。從服務的角度分為資料類和排程類兩個大類，前者拆分為 34 個服務角色，後者拆分為 10 個服務角色。拆分後服務的更新和擴縮容将會變得更加容易。
SLS内部服務拆分
sls-service-master 主要進行排程相關的服務，它的每個服務角色有多個執行個體確定高可用。主要的服務功能集中在 sls-backend-server 中，大緻的分層結構如下：
CDS-SLS 目前預設底層分布式存儲是盤古 2.0 系統。盤古 2.0 作為阿裡雲的存儲底座具備高性能高穩定性的特征。SLS 的内部業務子產品也進行了很好的微服務的拆分，底層使用C++自研，以實作極緻的性能。
SLS的各子產品中有大量的背景參數可以調節，隻是我們為了友善客戶使用，預設值往往能滿足絕大多數客戶的需求。很多設計都秉承"提供機制而不是政策（Separation of mechanism and policy）"和“單一職責（Do one thing and do it well）”的經典UNIX思想。
- 使用者關心的流控，背景提供多種次元的精确控制，預設的參數可以覆寫絕大部分場景。
- 資料采集Agent（Logtail）經過多年百萬機器大規模驗證，在性能、穩定性上都有很好保證，相比開源軟體，可以大幅降低對機器資源的占用（最高可降低90%）。
- "查詢|分析"的管道式的設計就很好的貫徹了單一職責，查詢和分析分别對應不同的背景服務。
混合雲場景的特殊設計
叢集形态
目前的天基中的SLS相關的叢集有兩個：
- 底座中的 sls-common 叢集共享底座的盤古，提供最基本的查詢分析，供阿裡雲底座中各服務進行自運維，限于底座資源儲存時間 7 天。在混合雲網絡隔離不可達的場景下顯著提升運維的效率，開發人員通過幾個關鍵詞讓現場人員查詢即可很快定位問題。
- 使用者單獨購買的 CDS-SLS 叢集，獨占一套盤古，叢集中隻運作SLS相關的程序，有效緩解了底座共享資源緊張的問題，是以日志的 TTL 可以永久儲存，并且有體驗更好的控制台。
本文提到的絕大多數功能都是針對使用者單獨購買的 CDS-SLS 叢集。
國産化信創支援
目前 CDS-SLS 會支援海光，鲲鵬，飛騰等CPU的架構，并會有嚴格的和 Intel X86 相同的驗收測試。之後還會針對線下輸出場景更多異構 CPU 和混合場景的測試支援。
針對HTTPS的通路會支援國密 TLS 信道傳輸，讓一些金融或者政企行業的資料通路更合規。
開源ELK方案對比和遷移
ELK的背景
Elastic主要基于Lucene實作，2012 年 Elastic 基于 Lucene 基礎庫包成了一個更好用的軟體，并且在 2015 年推出 ELK Stack（Elastic Logstash Kibana）解決集中式日志采集、存儲和查詢問題。但是 Lucene 設計場景是 Information Retrial，面對是 Document 類型，是以對于可觀測分析（Log/Trace/Metric）資料有一定限制，例如規模、查詢能力、以及一些定制化功能（例如智能聚類 LogReduce）。
| Elasticsearch | 日志服務 | 說明 |
| index | logstore | 允許使用者将多個 index 上的資料遷移至一個 logstore。 |
| type | logItem 中的字段 __tag__:_type | |
| document | logItem | Elasticsearch 的文檔和日志服務中的日志一一對應。 |
| mapping | logstore 的索引 | 工具預設情況下會為您自動建立好索引。 |
| field datatypes | logItem 資料類型 | 具體映射關系參考 資料類型映射 。 |
日志采集端功能對比
目前主流開源社群的日志采集端一般是 Logstash 和 Fluentd，早期版本會進行一些功能和性能的比較，測試結果資料參考
| 功能項 | Logstash | Fluentd | Logtail |
| 日志讀取 | 輪詢 | 事件觸發 | |
| 檔案輪轉 | 支援 | ||
| Failover處理 (本地checkpoint) | |||
| 通用日志解析 | 支援grok（基于正規表達式）解析 | 支援正規表達式解析 | |
| 特定日志類型 | 支援delimiter、key-value、json等主流格式 | 支援key-value格式 | |
| 資料發送壓縮 | 插件支援 | LZ4 | |
| 資料過濾 | |||
| 資料buffer發送 | |||
| 發送異常處理 | |||
| 運作環境 | JRuby實作，依賴JVM環境 | CRuby、C實作，依賴Ruby環境 | C++實作，無特殊要求 |
| 線程支援 | 支援多線程 | 多線程受GIL限制 | |
| 熱更新 | 不支援 | ||
| 中心化配置管理 | |||
| 運作狀态自檢 | 支援cpu/記憶體門檻值保護 |
使用者如果之前是 logstash 采集，也可以很容易遷移到 SLS，可以參考：
Logstash資料源接入SLSLogstash支援所有主流日志類型，插件支援最豐富，可以靈活 DIY，但性能較差，JVM 容易導緻記憶體使用量高，作為最重要的插件之一的 Grok 性能問題導緻很多使用者從 ELK 變為 EFK。
Fluentd 支援所有主流日志類型，插件支援較多，性能表現較 Logstash 有提升但受限于 Ruby 的 GIL 大鎖，性能還需要進一步提高，官方文檔也明确了這個缺陷。
Ruby has GIL (Global Interpreter Lock), which allows only one thread to execute at a time. While I/O tasks can be multiplexed, CPU-intensive tasks will block other jobs. One of the CPU-intensive tasks in Fluentd is compression.
Logtail 占用機器 CPU、記憶體資源最少，結合阿裡雲日志服務的 E2E 體驗良好，目前經過幾年的疊代，功能已經比較完善，尤其是針對容器場景進行了大量的性能優化和使用者體驗的優化，對于 Daemonset 和 Sidecar 模式的支援比較成熟。
查詢分析對比
•低門檻：完整 SQL92 标準，JDBC 完整協定，支援 Join
•高性能：查詢延遲相比 ES 低、
•智能：支援機器學習AI算法、支援場景化聚合函數
- 場景化函數：通過十餘年實戰經驗沉澱針對資料分析場景的 30+ 聚合計算函數
- 機器學習函數：大資料與機器學習相結合，豐富的機器學習函數
- 多管道資料源：發揮阿裡雲平台優勢關聯更多資料源，如IP地理位置庫資料、威脅情報資料、白帽子安全資産庫
ELK到SLS的資料一鍵遷移
目前的很多使用者都是在被多個分散的小的 ES 叢集水位和消息隊列高并發的時候難以運維選擇了 SLS，是以從 ES 到SLS 的遷移就變得非常關鍵，如何能優雅而且容易的把資料遷移到 SLS，目前 SLS 已經給出了比較成熟易用的方案。
ELK到SLS的資料一鍵遷移方案詳情重要特征
- 支援斷點續傳：調用參數中 cache_path 指定 checkpoint 的存放位置，當遷移程式中斷後，重新打開時指定相同的 cache_path 便可以繼續遷移任務。
- 遷移速率快：單個 SLS shard， 單個 ES shard，pool_size 為1，可實作接近5M/s的遷移速度。可通過調整 SLS shard 和 pool_size 大小來達到提速。
常用的遷移指令模式
- 将 hosts 為 localhost:9200 的 Elasticsearch 中的所有文檔導入日志服務的項目 project1 中。
aliyunlog log es_migration --cache_path=/path/to/cache --hosts=localhost:9200 --project_name=project1
- 指定将 Elasticsearch 中索引名以 myindex_ 開頭的資料寫入日志庫 logstore1，将索引 index1,index2 中的資料寫入日志庫 logstore2 中。
aliyunlog log es_migration --cache_path=/path/to/cache --hosts=localhost:9200,other_host:9200 --project_name=project1 --logstore_index_mappings='{"logstore1": "myindex_*", "logstore2": "index1,index2"}}'
後續
在保證穩定性的前提下為了追求極緻性能會持續進行新版本的疊代更新和更多新功能的引入，客戶的通用類需求會放在更高的優先級。例如使用者比較直覺能感受到的硬體機型 SLS 線上下會從單一款計劃增加到三款來滿足更多類客戶的精細化需求，在正常基礎上會引入計算門檻相對低一點的硬體和對于日志儲存時長有特殊長時間要求的的金融類客戶的存儲高密機型。
軟體層面更快更智能的查詢分析作為核心功能會讓 CDS-SLS 在一站式的日志平台中給客戶更好的體驗，SLS 起于日志，不止于日志，其他更多功能後續會持續分享。
原創作品：阿裡雲存儲 禅車
系列文章傳遞門：
- 【CDS技術揭秘系列 總篇】阿裡雲的雲定義存儲來了 https://developer.aliyun.com/article/792044?spm=a2c6h.13148508.0.0.3eef4f0ecyZOjQ
- 【CDS技術揭秘系列 01】阿裡雲CDS-OSS容災大揭秘 https://developer.aliyun.com/article/792000?spm=a2c6h.13148508.0.0.3eef4f0ecyZOjQ