阿里雲日誌服務作為阿里集團底層日誌平臺，提供完善易用的數據採集方案，PB 級數據實時索引和分析能力，在阿里集團被廣泛應用。數千工程師直接使用日誌服務進行日常問題排查，也有大量應用基於日誌服務進行二次開發，如阿里集團所有大型 Trace 系統底層都使用日誌服務。
在此背景下，我們邀請了阿里雲高級技術專家孫廷韜（花名：龍悟）老師來 7 月深圳 ArchSummit 全球架構師峰會上演講，他本人重點負責阿里雲日誌服務架構設計和實現，此次將介紹阿里雲 10PB+/ 天日誌系統設計和實現的話題。
可以先通過一個大圖，看看阿里雲日誌服務提供的核心功能：
- 採集：
- Logtail: 多年百萬級服務器錘鍊，簡便、可靠、高性能 ;
- SDK/Producer: Java/C/Go/iOS/Android/web tracking;
- 全球加速: 集成 DCDN 全球加速
- 存儲 & 消費 :
- ConsumerGroup: 自動負載均衡、failover、服務端 checkpoint 持久化 ;
- 生態集成：支持 Blink/Flink/Storm/Spark Streaming 等多種流系統，已對接各類監控系統 ;
- Shipper：支持 Oss、MaxCompute 數據轉存
- 查詢 & 分析：
- Text、Json、Double、Long;
- 支持中文，Json 自動展開，全文 / 鍵值 ;
- 百億級規模查詢 ;
- DevOps 場景：上下文、Live Tail、LogReduce、異常檢查、預測、根因分析 ;
- 分析功能：SQL92、交互式查詢、機器學習、安全特色函數
- 可視化
- 原生 Dashboard、十幾種圖形展示 ;
- JDBC 接口，支持 DataV、Grafana、QuickBI 展示。
阿里雲生產環境下的日誌特點
在生產環境下，阿里雲日誌有如下特點：
- 規模大: 每日產生的各類日誌超過數十 PB;
- 種類雜：包含各類訪問日誌、系統日誌、應用日誌等各類日誌，種類繁多，格式複雜 ;
- 來源多：服務器端、網絡設備、嵌入式、web 端、Docker、移動 app 多種數據源實時產生數據 ;
- 應用廣：各條業務線對於日誌的使用需求廣泛，如監控報警、問題診斷、數據分析和深入挖掘、報表等各類場景，因此使用和消費模式也會多種多樣 ;
- 要求高：對於系統的穩定、可用性都有非常苛刻的要求，以滿足關鍵業務的需求 ;
- 峰值大：在雙十一等活動，舜時會產生大量日誌，如何應對這樣的峰值，也是很大的挑戰。
日誌服務通過構建統一的系統，來解決不同用戶在日誌的採集、存儲、查詢和分析上的一些通用需求，簡化用戶使用日誌的複雜度，使得用戶能夠更專注於日誌數據價值的挖掘。
阿里雲日誌系統核心功能
針對阿里雲的日誌特點，日誌系統需要滿足以下這些條件：
- 高可靠性：對於一些日誌數據不落地的場景，如果後端服務不可用，很可能導致數據丟失 ;
- 資源隔離：能夠提供良好的 QOS，不因個別用戶的異常，影響其他用戶 ;
- 高性價比：針對日誌的一些特性，進行系統優化，儘可能降低處理海量數據的成本，如每天採集、存儲、索引 1PB 日誌，機器資源消耗最大能降低到多少 ;
- 管理能力：如何管理百萬級客戶端的，如何快速發現、定位日誌採集過程的異常；如何進行版本的維護升級 ;
- 快速查詢分析：在海量日誌中，進行快速的查詢和分析，及時返回結果給用戶。
日誌系統的設計
阿里雲日誌系統主要有以下模塊：
- 負責採集數據的客戶端 Agent;
- 提供 Resutful API 接口的前端模塊 ;
- 進行數據存儲和索引的模塊 ;
- 查詢分析模塊 ;
- 負責 Meta 信息管理模塊 ;
- 負責監控、運維的管理模塊
在日誌系統的設計過程中遇到的主要挑戰有：
- 如何在性能、成本之間如何進行平衡以及取捨。現有硬件條件下， 每 GB SSD 磁盤的價格是普通 HDD 的 5 倍，在每日數十 PB 寫入量的情況下，全部使用 SSD 磁盤，成本不可接受，但是 HDD 的磁盤讀取延時、吞吐能力要比 SSD 差不少，在受限硬件條件下，如何滿足海量數據的查詢需求？針對這個苛刻的成本和性能問題，我們團隊根據日誌場景的特點，從 0 開始打造了一款專門為日誌數據存儲和索引的分佈式引擎：
- a. 在倒排索引字典上，使用 succinct tree 進行編碼，字典只有 FST 結構的 40~70%；
- b. 倒排索引數據使用自研的混合 Bitmap 結構，可以直接在 encoding 後 Bitmap 上進行 and、not、or 操作，無需對 bitmap 進行反序列化；
- c. 使用改進的 BKD-Tree 對數值進行索引，配合高效的壓縮算法，讀寫速度是開源版本的 1.4~2 倍，壓縮率提高 50%，部分 distinct 值個數較少場景壓縮率提高 10 倍；
- d. 大量使用 SIMD 指令來提高數值壓縮、解壓速度。
- 在大規模分佈式集群，如何打造 always available 的服務。系統要有良好的抗壓和異常自我恢復能力，在各種高壓情況下（如應用出錯、代碼 bug 等情況，流量可能成百、上千倍放大），系統要通過自身技術手段，自動、快速、準確定位異常流量，攔截在系統最外層，保證內部不被打垮。在分佈式系統中，軟硬件的異常時常發生，系統需要能進行自動遷移和隔離，最終保障系統的可用性。同時，為了最大程度提高資源使用效率，我們採用多租戶共享集群資源的方式，但是應用場景多樣，每個應用對日誌使用模式並不相同，資源的消耗也有差異，例如，部分應用查詢分析特別頻繁，屬於 CPU 密集型；部分應用流量特別大，是網絡密集型；部分應用則週期性出現峰值等。如何在有限的資源下，提供良好的 QOS，滿足各應用需求的同時，提高資源使用效率，也是一個不小挑戰。
- 如何挖掘日誌特性，設計適合日誌數據的存儲和索引結構，使其能在十 億、百億級場景下，進行快速查詢分析。在阿里的場景下，單一應用每天產生上百 TB 日誌是很常見，單次查詢，覆蓋十億、百億行日誌也是是一個非常普遍的情況。在這樣的規模下，如何進行加速，在設計上有不小挑戰，分佈式查詢是一個必選項，一次查詢可能會在數百節點之間同時進行。我們在設計時候，通過儘可能減少節點之間數據交互量；採用多層 Cache 結構，來複用索引、原始數據、臨時計算結果；使用協程進行計算、IO 分離等；智能調節數後臺索引 Compaction 速度等多種方式，來實現超大規模快速查詢分析。
- 可靠、高效管理數百萬臺服務器的採集配置也是一個難點。特別是在雙十一等特殊時期，需要系統能進行精準、快速的流控，確保高優先級數據及時採集，低優先級任務不因過多資源消耗而影響業務性能。為此，我們設計前端採集 Agent 和後端管理模塊時，加入一套可靠的管理協議，所有的配置可以在控制檯進行操作，由後端管理模塊同步前端採集 Agent，無需登陸機器進行配置管理。同時，在雙十一等特殊時期，可以動態修改每個日誌源不同的採集上限，進行優先級控制。
日誌系統的穩定性如何保障
關於日誌系統的穩定性，所有的模塊需要做到可以水平擴展。無論是接收流量的前端模塊，數據存儲索引和查詢模塊，或是管理百萬服務器配置管理模塊，都需要做到水平擴展，才能撐起每日數十 PB 的日誌量。
異常流量和請求在前端模塊被攔截，防止穿透至後端。我們在設計系統的時候，為每個模塊定義了標準處理能力，如負責數據索引的模塊，確定每個 shard 讀寫能力標準，當實際流量超過標準，機器在還有富餘資源時，會繼續提供服務，而資源不夠，並且 shard 未開啟自動分裂的情況下，觸發限流操作，系統內部的反饋機制，能夠在毫秒級別延時內，將該 shard 流控信息，同步到所有上千個前端進程，各前端在一定時間內，可直接拒絕該 shard 流量。通過這樣的機制，異常流量在系統最前端被攔截，防止後端單點被打爆，經線上實測，穿透到後端的異常流量只有正常流量的 1%~3%。
模塊內部進行自動調度和負載均衡。系統內部，會實時統計各應用日誌的流量和資源消耗，進行中心彙總，系統在分鐘級別可發現集群中存在的熱點和類型，並確定導致熱點的日誌源，根據熱點的類型，匹配合適的遷移目標，將熱點流量遷移至可以到合適的機器上，進行資源消耗互補。
資源隔離，自動根據負載調節資源使用限制。日誌場景下，數據都帶有時間信息，在進行日誌查詢和分析的時候，也限定了時間窗口。每次查詢，後端根據當前負載以及應用之前資源消耗等信息，限定這次查詢執行併發數、磁盤讀取量、執行時間、內存消耗等資源上限，查詢的中間結果被緩存在內存中，後續查詢可複用 cache 中的結果加快查詢速度。
完善的監控體系。監控對於一個系統來說至關重要，我們在覆蓋系統的關鍵指標、硬件狀態、外部訪問監控的基礎上，也使用系統自身提供的異常檢查功能進行對自己進行異常檢查。
日誌數據的處理
在 Sec/Dev/IT Ops 領域，日誌數據發揮了重要的作用，主要包括以下幾個方面：
- 實時查詢和分析：日誌服務本身提供海量日誌實時檢索和 SQL 分析、上下文查詢（Context），實時 Tail（Live Tail）、日誌數據智能聚類 (LogReduce)、異常檢查和根因分析等能力，用戶可直接在日誌服務上進行問題排查、異常定位、深入挖掘日誌數據價值 ;
- 可視化分析：通過自定義畫布 (Canvas)，配合數十種圖形和 Drill down/Roll up，非常方便地構建交互式可視分析儀表盤，數據所見即所得 ;
- 告警：日誌服務原生提供日誌分析結果告警功能，對於告警消息的投遞，除了傳統的短信、郵件外，也支持 webhook，如投遞給釘釘機器人，或自定義鏈接進行自動報警處理邏輯觸發 ;
- 二次開發：不少團隊基於日誌服務，根據其業務特點進行二次開發，如各類 Tracing 系統、客服系統等。
日誌系統和其他系統的對接
下圖展示了阿里雲日誌系統可以跟哪些系統對接：
- 各類流式系統：Flink/Blink， Storm (JStorm)，Spark Streaming。日誌服務提供各流式系統提供日誌消費消費 lib，屏蔽數據拉取、checkpoint 保存、failover 等細節，只需關注數據流的處理邏輯即可，簡化各類流系統實時消費日誌的複雜度，完成數據實時 ETL、監控等場景 ;
- 離線系統：對數據有更深入分析的場景，如用戶畫像、關聯分析等場景，可以使用日誌服務的歸檔功能，將數據保留至阿里雲對象存儲 (OSS)， 或 MaxCompute 這樣的系統，進行後續分析 ;
- DataWorks: 對數據外部存儲還有更多需求的用戶，可以使用 DataWorks 實時消費日誌日誌，導入到各類其他系統，如 MySQL 等數據庫 ;
- Serverless：對於不想自己運維流式系統，但是又有自定義分析需求的場景，也可以使用 Serverless 的模式來消費日誌，如阿里雲函數計算 FC，只需要編寫日誌處理函數，運行由函數計算進行託管。
轉自：https://www.infoq.cn/article/WgIY55h3raQDY0cI-823
閱讀更多 機器不學習 的文章
