淺析 Grafana Loki 日志聚合系統
Loki 是一個水平可擴展、高可用、多租戶的日志存儲與查詢系統。受 Prometheus 啟發，Loki 不對日志內容進行索引，而是采用標簽（Label）作為索引，從而降低存儲成本。
Like Prometheus, but for logs.
架構設計
Loki 采用讀寫分離架構，由多個微服務構建而成，被設計成一個水平可擴展的分布式系統。
圖片
其中寫組件有：
1、Distributor 分發器：分發器通過 HTTP 接收到日志后，會進行驗證（驗證日志時間或日志行大小等是否滿足規則）、預處理（對 labels 按照 key 以字典順序排序，方便后續進行一致性 hash 算法來將日志發往 Ingester 接收器），同時還負責限速功能，流量過大時可以拒絕額外的請求。
2、Ingester 接收器：接收器是一個有狀態的組件，在日志流進入時對其進行 gzip/snappy 壓縮操作，并負責構建和刷新日志 chunk ，當內存中的 chunk 達到一定的數量或者時間后，就會刷新 chunk 和對應的 index 索引存儲到本地文件系統或對象存儲中。接收器默認會啟用 WAL 功能，防止數據丟失。
讀組件有：
1、Query Frontend 查詢前端：查詢前端是一個可選的組件，具有查詢拆分、緩存的作用。一個查詢可以拆解成多個小查詢，并行在多個 Querier 組件上進行查詢，最終合并返回給前端展示。查詢前端內部有一個內存隊列，還可以將其移出作為一個 Query Scheduler 查詢調度器的單獨進程運行。
2、Querier 查詢器：接收一個時間范圍和標簽選擇器，Querier 查詢器根據 index 索引來確定哪些日志 chunk 匹配，然后將結果顯示出來。在查詢數據時，優先查詢所有 Ingester 接收器中的內存數據，沒查到再去查存儲。如果開啟了數據副本，數據可能重復，因此 Querier 還有數據去重的功能。
另外還有一些其它組件：
1、Ruler 規則器：負責日志告警功能，可以持續查詢一個 rule 規則，并將超過閾值的事件推送給 AlertManager 或者其它告警 Webhook 服務。
2、Compactor 壓縮器：負責定時對索引進行壓縮合并，同時負責日志的刪除功能。
3、Memcaches 緩存：這部分屬于外部第三方組件，支持的緩存類型有 in-memory、redis 和 memcached ，可以在 Ingester 、Query Frontend 、Querier 和 Ruler 上配置 Results 查詢結果緩存、Index 索引緩存或 Chunks 塊緩存。
組件之間的交互流程大致如下：
圖片
一致性哈希環設計
Loki 的分布式架構源自 https://github.com/cortexproject/cortex 項目，對于各組件服務狀態和數據的通信均采用一致性哈希環設計，哈希環的配置支持 consul、etcd、inmemory 或 memberlist ：
common:
ring:
kvstore:
# 支持切換為 consul、etcd、inmemory
store: memberlist在 Loki 中定義了很多哈希環：IngesterRing、RulerRing 和 CompactorRing 等，以分發器（Distributor）和接收器（Ingester）組件為例，借助 IngesterRing 哈希環，Distributor 就可以確定日志流應該發往哪個 Ingester 實例，具體流程如下：
1、日志流的唯一性計算：每個日志流由租戶 ID 及其所有標簽的 key/value 組合唯一確定，并由此計算出日志流的 hash key —— 一個無符號的 32 位整數。
2、Ingester 的注冊：每個 Ingester 實例會在哈希環（IngesterRing）上注冊自身，并分配一組 token（每個 token 為隨機生成的無符號 32 位整數），用于確定其在哈希環中的位置。
圖片
3、日志流的分配：當 Distributor 需要分發日志時，它會在哈希環上找到第一個大于日志流 hash key 的 token，并將該 token 所屬的 Ingester 實例視為目標存儲節點。
a. 副本機制：若數據副本數（replication_factor） 大于 1（默認為 3），則繼續順時針查找，找到下一個 token 對應的不同 Ingester 實例，確保日志的多副本存儲，提高容錯能力。
b. 狀態約束：僅當目標 Ingester 處于 JOINING 或 ACTIVE 狀態時，才能接收日志寫入請求；僅當 Ingester 處于 ACTIVE 或 LEAVING 狀態時，才能處理日志讀取請求。
其動態演示效果如下：
圖片
但在這種機制下，若單個日志流中的數據量過大，就容易導致 Ingester 實例負載不均衡，如下：
圖片
此時，可以啟用自動分片流功能，通過在現有日志流中自動添加 __stream_shard__ 標簽及其值，以控制日志流速保持在 desired_rate 以下，達到負載均衡的效果：
limits_config:
shard_streams:
enabled: true
desired_rate: 1536KB
圖片
存儲設計
在 Loki 中，標簽（label）實際就是在提取日志時分配給日志的一組任意 key/value，既是 Loki 對傳入數據進行分塊的鍵，也是查詢時用于查找日志的索引。
每個標簽的 key 和 value 的組合會唯一定義成一個日志流（stream），哪怕僅有一個標簽值發生了變化，都會重新創建一個新的日志流。
不同的日志流會在 Ingester 實例的內存中構建出不同的日志 chunk ，滿足規則（達到 chunk_target_size 、max_chunk_age 或 chunk_idle_period上限）就會刷新到對象存儲或本地文件系統中：
圖片
因此，Loki 需要存儲兩種不同類型的數據：塊（chunk）和索引（index）。
- chunk：即日志本身，一個 chunk 包含很多 block ，進行壓縮后存儲
- index：即日志索引，key/value 結構，key 是日志 label 的哈希，value 則包含日志存在哪個 chunk 上、chunk 大小、日志的時間范圍等信息
其中 chunk 的存儲可以直接上傳到配置的存儲系統中（例如本地文件系統或 S3），而 index 的存儲處理稍微麻煩些。
在 2.0 之前，chunk 和 index 的存儲是分開的，意味著需要配置兩個存儲系統。而 2.0 開始，推行一種叫單一存儲架構的設計，實現了 “boltdb-shipper” 索引存儲，這種機制下只需要一個共享存儲，例如 S3，就可以同時用于 chunk 和 index 的存儲。到了 Loki 2.8 ，再次推出了更高效的 “tsdb-shipper” 索引存儲，這也是目前 3.x 版本所推薦的索引存儲方式。
這兩種索引存儲的原理大致上是相似的，工作可以分為 uploadsManager 和 downloadsManager 兩部分：
- uploadsManager：負責上傳
active_index_directory內的索引分片到配置的共享存儲中，同時負責定期清理工作 - downloadsManager：負責從共享存儲下載索引到本地緩存目錄
cache_location，同時負責定期同步和清理工作
簡單來理解就是，一個是把本地 boltdb 文件當作索引存儲，另一個把本地 tsdb 文件當作索引存儲，但這兩種索引存儲都有 “shipper” 的能力，可以把自身上傳到配置的共享存儲中，并保持同步。如此一來，我們就可以利用 S3 同時存儲 chunk 和 index 了。
隨著版本的迭代，不可避免會出現很多不同的存儲模式，好在 Loki 允許通過日期起點來定義不同時間段使用不同的存儲模式：
schema_config:
configs:
-from:2024-01-01
store:boltdb-shipper
object_store:s3
schema:v12
index:
prefix:index_
period:24h
-from:2025-01-01
store:tsdb
object_store:s3
schema:v13
index:
prefix:index_
period:24h需要注意的是：
- 升級架構，始終將新模式中的 from 日期設置為未來的日期，要注意是從 UTC 00:00:00 開始。
- 全新部署，from 日期需要設置為以前的日期，才可以接收處理日志。
- 架構變更是無法撤銷或回滾的，使用什么架構寫入的數據只能由該架構讀取。
查詢設計
Loki 第一次查詢時，Querier 查詢器會從共享存儲中下載查詢時間范圍內的索引并解壓到本地緩存目錄 cache_location ，并按 resync_interval 周期同步，該索引緩存有效期受 cache_ttl 配置控制。這部分工作由之前介紹的索引存儲的 downloadsManager 完成，這也是為什么 Loki 的第一次查詢會比較慢。
拋開拉取索引耗時這部分因素，在 Loki 中，查詢從快到慢分別為：
圖片
- Label matchers 標簽匹配器（最快）：直接基于索引匹配到塊，查找出滿足 limit 的日志條數
- Line filters 行過濾器（中等）：把滿足標簽匹配器匹配到的塊，再進行過濾，直到查找出滿足 limit 的日志條數
- Label filters 標簽過濾器（最慢）：把滿足標簽匹配器匹配到的塊，進行二次標簽，然后再進行過濾，直到查找出滿足 limit 的日志條數
以行過濾器的查詢流程為例：
1、時間范圍拆分：Query Frontend 首先根據 split_queries_by_interval 將查詢拆分為多個較小的時間段。例如，一個跨度為 4 小時的查詢可能被拆分為 4 個獨立的 1 小時子查詢，這種拆分可以并行處理不同時間段的數據。
圖片
2、動態分片：Query Frontend 繼續將每個時間段的子查詢進行進一步的動態分片。分片數量取決于數據量，數據量大的子查詢可能拆分為更多分片，而數據量小的可能僅少量分片。分片的目的是將 chunk 按日志流的標簽進一步細分，從而提升并行處理效率。
圖片
3、任務隊列與并行處理：Query Frontend 將拆分后的分片任務提交至 Query Scheduler 任務隊列中，根據公平調度策略將任務分配給空閑的 Querier 工作節點并行處理。Querier 會從 Ingester 中的內存數據或對象存儲中拉取對應的數據塊，解析并過濾日志內容，最終返回匹配的結果。
圖片
4、結果合并：所有子查詢和分片的結果會被匯總到 Query Frontend 組件，進行排序、去重和合并，最終返回完整的查詢結果。
完整的查詢流程如下：
圖片
所以 Loki 的設計就是推薦使用并行化 (parallelization) 來實現最佳性能，將查詢分解成小塊，并將其并行調度，這樣就可以在小時間內查詢大量的日志數據。
本文中的部分動圖和圖片引用自以下官方博客，推薦閱讀：
- https://grafana.com/blog/2023/12/11/open-source-log-monitoring-the-concise-guide-to-grafana-loki/
- https://grafana.com/blog/2023/12/20/the-concise-guide-to-grafana-loki-everything-you-need-to-know-about-labels/
- https://grafana.com/blog/2023/12/28/the-concise-guide-to-loki-how-to-get-the-most-out-of-your-query-performance/
- https://grafana.com/blog/2020/12/08/how-to-create-fast-queries-with-lokis-logql-to-filter-terabytes-of-logs-in-seconds/
