作者
呂亞霖，2019年加入作業幫，作業幫架構研發負責人，在作業幫期間主導了雲原生架構演進、推動實施容器化改造、服務治理、GO微服務框架、DevOps的落地實踐。
莫仁鵬，2020年加入作業幫，作業幫高級架構師，在作業幫期間，推動了作業幫雲原生架構演進，負責作業幫服務治理體系的設計和落地、服務感知體系建設以及自研mesh、MQproxy研發工作。
摘要
日志是服務觀察的主要方式，我們依賴日志去感知服務的運行狀態、歷史狀況；當發生錯誤時，我們又依賴日志去了解現場，定位問題。日志對研發工程師來說異常關鍵，同時隨着微服務的流行，服務部署越來越分散化，所以我們需要一套日志服務來采集、傳輸、檢索日志
基於這個情況，誕生了以 ELK 為代表的開源的日志服務。
需求場景
在我們的場景下，高峰日志寫入壓力大（每秒千萬級日志條數）；實時要求高：日志處理從采集到可以被檢索的時間正常 1s 以內（高峰時期 3s）；成本壓力巨大，要求保存半年的日志且可以回溯查詢（百 PB 規模）。
ElasticSearch 的不足
ELK 方案里最為核心的就是 ElasticSearch， 它負責存儲和索引日志， 對外提供查詢能力。Elasticsearch 是一個搜索引擎， 底層依賴了 Lucene 的倒排索引技術來實現檢索， 並且通過 **shard **的設計拆分數據分片， 從而突破單機在存儲空間和處理性能上的限制
寫入性能
ElasticSearch 寫入數據需要對日志索引字段的倒排索引做更新，從而能夠檢索到最新的日志。為了提升寫入性能，可以做聚合提交、延遲索引、減少 refersh 等等，但是始終要建立索引， 在日志流量巨大的情況下（每秒 20GB 數據、千萬級日志條數）， 瓶頸明顯。離理想差距過大，我們期望寫入近乎准實時。
運行成本
ElasticSearch 需要定期維護索引、數據分片以及檢索緩存， 這會占用大量的 CPU 和內存，日志數據是存儲在機器磁盤上，在需要存儲大量日志且保存很長時間時， 機器磁盤使用量巨大，同時索引后會帶來數據膨脹，進一步帶來成本提升。
對非格式化的日志支持不好
ELK需要解析日志以便為日志項建立索引， 非格式化的日志需要增加額外的處理邏輯來適配。存在很多業務日志並不規范，且有收斂難度。
總結：日志檢索場景是一個寫多讀少的場景， 在這樣的場景下去維護一個龐大且復雜的索引， 在我們看來其實是一個性價比很低的事情。如果采用 ElasticSearch 方案，經測算我們需要幾萬核規模集群，仍然保證不了寫入數據和檢索效率，且資源浪費嚴重。
日志檢索設計
面對這種情況， 我們不妨從一個不同的角度去看待日志檢索的場景， 用一個更適合的設計來解決日志檢索的需求， 新的設計具體有以下三個點：
日志分塊
同樣的我們需要對日志進行采集，但在處理日志時我們不對日志原文進行解析和索引，而是通過日志時間、日志所屬實例、日志類型、日志級別等日志元數據對日志進行分塊。這樣檢索系統可以不對日志格式做任何要求，並且因為沒有解析和建立索引（這塊開銷很大）的步驟， 寫入速度也能夠達到極致（只取決於磁盤的 IO 速度）。
簡單來說， 我們可以將一個實例產生的同一類日志按時間順序寫入到一個文件中， 並按時間維度對文件拆分. 不同的日志塊會分散在多台機器上(我們一般會按照實例和類型等維度對日志塊的存儲機器進行分片)， 這樣我們就可以在多台機器上對這些日志塊並發地進行處理， 這種方式是支持橫向擴展的. 如果一台機器的處理性能不夠， 橫向再擴展就行。
那如何對入日志塊內的數據進行檢索呢？這個很簡單， 因為保存的是日志原文，可以直接使用 grep 相關的命令直接對日志塊進行檢索處理。對開發人員來說， grep 是最為熟悉的命令， 並且使用上也很靈活， 可以滿足開發對日志檢索的各種需求。因為我們是直接對日志塊做追加寫入，不需要等待索引建立生效，在日志刷入到日志塊上時就可以被立刻檢索到， 保證了檢索結果的實時性。
元數據索引
接下來我們看看要如何對這么一大批的日志塊進行檢索。
首先我們當日志塊建立時， 我們會基於日志塊的元數據信息搭建索引， 像服務名稱、日志時間， 日志所屬實例， 日志類型等信息， 並將日志塊的存儲位置做為 value 一起存儲。通過索引日志塊的元數據，當我們需要對某個服務在某段時間內的某類日志發起檢索時，就可以快速地找到需要檢索的日志塊位置，並發處理。
索引的結構可以按需構建， 你可以將你關心的元數據信息放入到索引中， 從而方便快速圈定需要的日志塊。因為我們只對日志塊的元數據做了索引， 相比於對全部日志建立索引， 這個成本可以說降到了極低， 鎖定日志塊的速度也足夠理想。
日志生命周期與數據沉降
日志數據以時間維度的方向可以理解為一種時序數據， 離當前時間越近的日志會越有價值， 被查詢的可能性也會越高， 呈現一種冷熱分離的情況。而且冷數據也並非是毫無價值，開發人員要求回溯幾個月前的日志數據也是存在的場景， 即我們的日志需要在其生命周期里都能夠對外提供查詢能力。
對於這種情況，如果將生命周期內的所有日志塊都保存在本地磁盤上， 無疑是對我們的機器容量提了很大的需求。對於這種日志存儲上的需求，我們可以采用壓縮和沉降的手段來解決。
簡單來說，我們將日志塊存儲分為本地存儲(磁盤)、遠程存儲(對象存儲)、歸檔存儲三個級別; 本地存儲負責提供實時和短期的日志查詢(一天或幾個小時)， 遠程存儲負責一定時期內的日志查詢需求(一周或者幾周)， 歸檔存儲負責日志整個生命周期里的查詢需求。
現在我們看看日志塊在其生命周期里是如何在多級存儲間流轉的， 首先日志塊會在本地磁盤創建並寫入對應的日志數據， 完成后會在本地磁盤保留一定時間(保留的時間取決於磁盤存儲壓力)， 在保存一定時間后， 它首先會被壓縮然后被上傳至遠程存儲(一般是對象存儲中的標准存儲類型)， 再經過一段時間后日志塊會被遷移到歸檔存儲中保存(一般是對象存儲中的歸檔存儲類型).
這樣的存儲設計有什么好處呢? 如下面的多級存儲示意圖所示， 越往下存儲的數據量越大， 存儲介質的成本也越低， 每層大概為上一層的 1/3 左右， 並且數據是在壓縮后存儲的， 日志的數據壓縮率一般可以達到10:1， 由此看歸檔存儲日志的成本能在本地存儲的1%的左右， 如果使用了 SSD 硬盤作為本地存儲， 這個差距還會更大。
價格參考：
| 存儲介質 | 參考鏈接 |
|---|---|
| 本地盤 | https://buy.cloud.tencent.com/price/cvm?regionId=8&zoneId=800002 |
| 對象存儲 | https://buy.cloud.tencent.com/price/cos |
| 歸檔存儲 | https://buy.cloud.tencent.com/price/cos |
那在多級存儲間又是如何檢索的呢? 這個很簡單， 對於本地存儲上的檢索， 直接在本地磁盤上進行即可。
如果檢索涉及到遠程存儲上的日志塊， 檢索服務會將涉及到的日志塊下載到本地存儲， 然后在本地完成解壓和檢索。因為日志分塊的設計，日志塊的下載同檢索一樣，我們可以在多台機器上並行操作; 下載回本地的數據復制支持在本地緩存后一定的時間后再刪除， 這樣有效期內對同一日志塊的檢索需求就可以在本地完成而不需要再重復拉取一遍(日志檢索場景里多次檢索同樣的日志數據還是很常見).
對於歸檔存儲， 在發起檢索請求前， 需要對歸檔存儲中的日志塊發起取回操作， 取回操作一般耗時在幾分鍾左右， 完成取回操作后日志塊被取回到遠程存儲上，再之后的數據流轉就跟之前一致了。即開發人員如果想要檢索冷數據， 需要提前對日志塊做歸檔取回的申請，等待取回完成后就可以按照熱數據速度來進行日志檢索了。
檢索服務架構
在了解上面的設計思路后， 我們看看基於這套設計的日志檢索服務是怎么落地的.
日志檢索服務分為以下幾個模塊:
- GD-Search
查詢調度器， 負責接受查詢請求， 對查詢命令做解析和優化， 並從 Chunk Index 中獲取查詢范圍內日志塊的地址， 最終生成分布式的查詢計划
GD-Search 本身是無狀態的， 可以部署多個實例，通過負載均衡對外提供統一的接入地址。
- Local-Search
本地存儲查詢器， 負責處理 GD-Search 分配過來的本地日志塊的查詢請求。
- Remote-Search
遠程存儲查詢器， 負責處理 GD-Search 分配過來的遠程日志塊的查詢請求。
Remote-Search 會將需要的日志塊從遠程存儲拉取到本地並解壓， 之后同 Local-Search 一樣在本地存儲上進行查詢。同時 Remote-Search 會將日志塊的本地存儲地址更新到 Chunk Index 中，以便將后續同樣日志塊的查詢請求路由到本地存儲上。
- Log-Manager
本地存儲管理器，負責維護本地存儲上日志塊的生命周期。
Log-Manager 會定期掃描本地存儲上的日志塊， 如果日志塊超過本地保存期限或者磁盤使用率到達瓶頸，則會按照策略將部分日志塊淘汰（壓縮后上傳到遠程存儲， 壓縮算法采用了 ZSTD）， 並更新日志塊在 Chunk Index 中的存儲信息。
- Log-Ingester
日志攝取器模塊， 負責從日志 kafka 訂閱日志數據， 然后將日志數據按時間維度和元數據維度拆分， 寫入到對應的日志塊中。在生成新的日志塊同時， Log-Ingester 會將日志塊的元數據寫入 Chunk Index 中， 從而保證最新的日志塊能夠被實時檢索到。
- Chunk Index
日志塊元數據存儲， 負責保存日志塊的元數據和存儲信息。當前我們選擇了 Redis 作為存儲介質， 在元數據索引並不復雜的情況下， redis 已經能夠滿足我們索引日志塊的需求， 並且基於內存的查詢速度也能夠滿足我們快速鎖定日志塊的需求。
檢索策略
在檢索策略設計上， 我們認為檢索的返回速度是追求更快， 同時避免巨大的查詢請求進入系統。
我們認為日志檢索一般有以下三種場景:
-
查看最新的服務日志。
-
查看某個請求的日志， 依據 logid 來查詢。
-
查看某類日志， 像訪問 mysql 的錯誤日志， 請求下游服務的日志等等。
在大部分場景下， 用戶是不需要所有匹配到的日志， 拿一部分日志足以處理問題。所以在查詢時使用者可以設置 limit 數量， 整個檢索服務在查詢結果滿足 limit設置的日志數量時， 終止當前的查詢請求並將結果返回給前端。
另外 GD-Search 組件在發起日志塊檢索時， 也會提前判斷檢索的日志塊大小總和， 對於超限的大范圍檢索請求會做拒絕。（用戶可以調整檢索的時間范圍多試幾次或者調整檢索語句使其更有選擇性）
性能一覽
使用 1KB 每條的日志進行測試， 總的日志塊數量在10000左右， 本地存儲使用 NVME SSD 硬盤， 遠程存儲使用 S3 協議標准存儲.
• 寫入
單核可支持 2W條/S的寫入速度， 1W 條/S的寫入速度約占用 1~2G 左右的內存，可分布式擴展，無上限
• 查詢(全文檢索)
基於本地存儲的 1TB 日志數據查詢速度可在 3S 以內完成
基於遠程存儲的 1TB 日志數據查詢耗時在 10S 間。
成本優勢
在每秒千萬級寫入，百 PB 存儲上，我們使用十幾台物理服務器就可以保證日志寫入和查詢。熱點數據在本地 nvme 磁盤上，次熱數據在對象存里，大量日志數據存儲在歸檔存儲服務上。
計算對比
因為不需要建立索引，我們只需要千核級別就可以保證寫入，同時日志索引是個寫多讀少的服務，千核可以保證百級別 QPS 查詢。
ES 在這個量級上需要投入幾萬核規模。來應對寫入性能和查詢瓶頸，但是仍不能保證寫入和查詢效率。
存儲對比
核心是在保證業務需求下，使用更便宜的存儲介質（歸檔存儲 VS 本地磁盤）和更少的存儲數據（壓縮率 1/10vs 日志數據索引膨脹）。能有兩個量級的差距。
【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
