【CDS技术揭秘系列 02】阿里云CDS-SLS大揭秘
前言
本文作為即將發布的混合云產品 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等主流格式 | 支持delimiter、key-value、json等主流格式 | 支持key-value格式 |
數據發送壓縮 | 插件支持 | 插件支持 | LZ4 |
數據過濾 | 支持 | 支持 | 支持 |
數據buffer發送 | 插件支持 | 插件支持 | 支持 |
發送異常處理 | 插件支持 | 插件支持 | 支持 |
運行環境 | JRuby實現，依賴JVM環境 | CRuby、C實現，依賴Ruby環境 | C++實現，無特殊要求 |
線程支持 | 支持多線程 | 多線程受GIL限制 | 支持多線程 |
熱升級 | 不支持 | 不支持 | 支持 |
中心化配置管理 | 不支持 | 不支持 | 支持 |
運行狀態自檢 | 不支持 | 不支持 | 支持cpu/內存閾值保護 |
用戶如果之前是 logstash 采集，也可以很容易遷移到 SLS，可以參考：Logstash數據源接入SLS
Logstash支持所有主流日志類型，插件支持最豐富，可以靈活 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 起于日志，不止于日志，其他更多功能后續會持續分享。
原創作品：阿里云存儲 禪車
系列文章傳遞門：
原文鏈接：https://developer.aliyun.com/article/792110?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的【CDS技术揭秘系列 02】阿里云CDS-SLS大揭秘的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Flink Forward Asia 2
- 下一篇： 如何迁移开源 Flink 任务到实时计算