Loki 是一個水平可擴展、高可用、多租戶的日志存儲與查詢系統(tǒng)。受 Prometheus 啟發(fā)，Loki 不對日志內(nèi)容進行索引，而是采用標簽（Label）作為索引，從而降低存儲成本。

Like Prometheus, but for logs.

架構設計

Loki 采用讀寫分離架構，由多個微服務構建而成，被設計成一個水平可擴展的分布式系統(tǒng)。

圖片

其中寫組件有：

1、Distributor 分發(fā)器：分發(fā)器通過 HTTP 接收到日志后，會進行驗證（驗證日志時間或日志行大小等是否滿足規(guī)則）、預處理（對 labels 按照 key 以字典順序排序，方便后續(xù)進行一致性 hash 算法來將日志發(fā)往 Ingester 接收器），同時還負責限速功能，流量過大時可以拒絕額外的請求。

2、Ingester 接收器：接收器是一個有狀態(tài)的組件，在日志流進入時對其進行 gzip/snappy 壓縮操作，并負責構建和刷新日志 chunk ，當內(nèi)存中的 chunk 達到一定的數(shù)量或者時間后，就會刷新 chunk 和對應的 index 索引存儲到本地文件系統(tǒng)或?qū)ο蟠鎯χ?。接收器默認會啟用 WAL 功能，防止數(shù)據(jù)丟失。

讀組件有：

1、Query Frontend 查詢前端：查詢前端是一個可選的組件，具有查詢拆分、緩存的作用。一個查詢可以拆解成多個小查詢，并行在多個 Querier 組件上進行查詢，最終合并返回給前端展示。查詢前端內(nèi)部有一個內(nèi)存隊列，還可以將其移出作為一個 Query Scheduler 查詢調(diào)度器的單獨進程運行。

2、Querier 查詢器：接收一個時間范圍和標簽選擇器，Querier 查詢器根據(jù) index 索引來確定哪些日志 chunk 匹配，然后將結果顯示出來。在查詢數(shù)據(jù)時，優(yōu)先查詢所有 Ingester 接收器中的內(nèi)存數(shù)據(jù)，沒查到再去查存儲。如果開啟了數(shù)據(jù)副本，數(shù)據(jù)可能重復，因此 Querier 還有數(shù)據(jù)去重的功能。

另外還有一些其它組件：

1、Ruler 規(guī)則器：負責日志告警功能，可以持續(xù)查詢一個 rule 規(guī)則，并將超過閾值的事件推送給 AlertManager 或者其它告警 Webhook 服務。

2、Compactor 壓縮器：負責定時對索引進行壓縮合并，同時負責日志的刪除功能。

3、Memcaches 緩存：這部分屬于外部第三方組件，支持的緩存類型有 in-memory、redis 和 memcached ，可以在 Ingester 、Query Frontend 、Querier 和 Ruler 上配置 Results 查詢結果緩存、Index 索引緩存或 Chunks 塊緩存。

組件之間的交互流程大致如下：

圖片

一致性哈希環(huán)設計

Loki 的分布式架構源自 https://github.com/cortexproject/cortex 項目，對于各組件服務狀態(tài)和數(shù)據(jù)的通信均采用一致性哈希環(huán)設計，哈希環(huán)的配置支持 consul、etcd、inmemory 或 memberlist ：

common:
  ring:
    kvstore:
      # 支持切換為 consul、etcd、inmemory
      store: memberlist

在 Loki 中定義了很多哈希環(huán)：IngesterRing、RulerRing 和 CompactorRing 等，以分發(fā)器（Distributor）和接收器（Ingester）組件為例，借助 IngesterRing 哈希環(huán)，Distributor 就可以確定日志流應該發(fā)往哪個 Ingester 實例，具體流程如下：

1、日志流的唯一性計算：每個日志流由租戶 ID 及其所有標簽的 key/value 組合唯一確定，并由此計算出日志流的 hash key —— 一個無符號的 32 位整數(shù)。

2、Ingester 的注冊：每個 Ingester 實例會在哈希環(huán)（IngesterRing）上注冊自身，并分配一組 token（每個 token 為隨機生成的無符號 32 位整數(shù)），用于確定其在哈希環(huán)中的位置。

圖片

3、日志流的分配：當 Distributor 需要分發(fā)日志時，它會在哈希環(huán)上找到第一個大于日志流 hash key 的 token，并將該 token 所屬的 Ingester 實例視為目標存儲節(jié)點。

a. 副本機制：若數(shù)據(jù)副本數(shù)（replication_factor） 大于 1（默認為 3），則繼續(xù)順時針查找，找到下一個 token 對應的不同 Ingester 實例，確保日志的多副本存儲，提高容錯能力。

b. 狀態(tài)約束：僅當目標 Ingester 處于 JOINING 或 ACTIVE 狀態(tài)時，才能接收日志寫入請求；僅當 Ingester 處于 ACTIVE 或 LEAVING 狀態(tài)時，才能處理日志讀取請求。

其動態(tài)演示效果如下：

圖片

但在這種機制下，若單個日志流中的數(shù)據(jù)量過大，就容易導致 Ingester 實例負載不均衡，如下：

圖片

此時，可以啟用自動分片流功能，通過在現(xiàn)有日志流中自動添加 __stream_shard__ 標簽及其值，以控制日志流速保持在 desired_rate 以下，達到負載均衡的效果：

limits_config:
  shard_streams:
    enabled: true
    desired_rate: 1536KB

圖片

存儲設計

在 Loki 中，標簽（label）實際就是在提取日志時分配給日志的一組任意 key/value，既是 Loki 對傳入數(shù)據(jù)進行分塊的鍵，也是查詢時用于查找日志的索引。

每個標簽的 key 和 value 的組合會唯一定義成一個日志流（stream），哪怕僅有一個標簽值發(fā)生了變化，都會重新創(chuàng)建一個新的日志流。

不同的日志流會在 Ingester 實例的內(nèi)存中構建出不同的日志 chunk ，滿足規(guī)則（達到 chunk_target_size 、max_chunk_age 或 chunk_idle_period上限）就會刷新到對象存儲或本地文件系統(tǒng)中：

圖片

因此，Loki 需要存儲兩種不同類型的數(shù)據(jù)：塊（chunk）和索引（index）。

• chunk：即日志本身，一個 chunk 包含很多 block ，進行壓縮后存儲
• index：即日志索引，key/value 結構，key 是日志 label 的哈希，value 則包含日志存在哪個 chunk 上、chunk 大小、日志的時間范圍等信息

其中 chunk 的存儲可以直接上傳到配置的存儲系統(tǒng)中（例如本地文件系統(tǒng)或 S3），而 index 的存儲處理稍微麻煩些。

在 2.0 之前，chunk 和 index 的存儲是分開的，意味著需要配置兩個存儲系統(tǒng)。而 2.0 開始，推行一種叫單一存儲架構的設計，實現(xiàn)了 “boltdb-shipper” 索引存儲，這種機制下只需要一個共享存儲，例如 S3，就可以同時用于 chunk 和 index 的存儲。到了 Loki 2.8 ，再次推出了更高效的 “tsdb-shipper” 索引存儲，這也是目前 3.x 版本所推薦的索引存儲方式。

這兩種索引存儲的原理大致上是相似的，工作可以分為 uploadsManager 和 downloadsManager 兩部分：

• uploadsManager：負責上傳 active_index_directory 內(nèi)的索引分片到配置的共享存儲中，同時負責定期清理工作
• downloadsManager：負責從共享存儲下載索引到本地緩存目錄 cache_location，同時負責定期同步和清理工作

簡單來理解就是，一個是把本地 boltdb 文件當作索引存儲，另一個把本地 tsdb 文件當作索引存儲，但這兩種索引存儲都有 “shipper” 的能力，可以把自身上傳到配置的共享存儲中，并保持同步。如此一來，我們就可以利用 S3 同時存儲 chunk 和 index 了。

隨著版本的迭代，不可避免會出現(xiàn)很多不同的存儲模式，好在 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

需要注意的是：

1. 升級架構，始終將新模式中的 from 日期設置為未來的日期，要注意是從 UTC 00:00:00 開始。
2. 全新部署，from 日期需要設置為以前的日期，才可以接收處理日志。
3. 架構變更是無法撤銷或回滾的，使用什么架構寫入的數(shù)據(jù)只能由該架構讀取。

查詢設計

Loki 第一次查詢時，Querier 查詢器會從共享存儲中下載查詢時間范圍內(nèi)的索引并解壓到本地緩存目錄 cache_location ，并按 resync_interval 周期同步，該索引緩存有效期受 cache_ttl 配置控制。這部分工作由之前介紹的索引存儲的 downloadsManager 完成，這也是為什么 Loki 的第一次查詢會比較慢。

拋開拉取索引耗時這部分因素，在 Loki 中，查詢從快到慢分別為：

圖片

• Label matchers 標簽匹配器（最快）：直接基于索引匹配到塊，查找出滿足 limit 的日志條數(shù)
• Line filters 行過濾器（中等）：把滿足標簽匹配器匹配到的塊，再進行過濾，直到查找出滿足 limit 的日志條數(shù)
• Label filters 標簽過濾器（最慢）：把滿足標簽匹配器匹配到的塊，進行二次標簽，然后再進行過濾，直到查找出滿足 limit 的日志條數(shù)

以行過濾器的查詢流程為例：

1、時間范圍拆分：Query Frontend 首先根據(jù) split_queries_by_interval 將查詢拆分為多個較小的時間段。例如，一個跨度為 4 小時的查詢可能被拆分為 4 個獨立的 1 小時子查詢，這種拆分可以并行處理不同時間段的數(shù)據(jù)。

圖片

2、動態(tài)分片：Query Frontend 繼續(xù)將每個時間段的子查詢進行進一步的動態(tài)分片。分片數(shù)量取決于數(shù)據(jù)量，數(shù)據(jù)量大的子查詢可能拆分為更多分片，而數(shù)據(jù)量小的可能僅少量分片。分片的目的是將 chunk 按日志流的標簽進一步細分，從而提升并行處理效率。

圖片

3、任務隊列與并行處理：Query Frontend 將拆分后的分片任務提交至 Query Scheduler 任務隊列中，根據(jù)公平調(diào)度策略將任務分配給空閑的 Querier 工作節(jié)點并行處理。Querier 會從 Ingester 中的內(nèi)存數(shù)據(jù)或?qū)ο蟠鎯χ欣臄?shù)據(jù)塊，解析并過濾日志內(nèi)容，最終返回匹配的結果。

圖片

4、結果合并：所有子查詢和分片的結果會被匯總到  Query Frontend  組件，進行排序、去重和合并，最終返回完整的查詢結果。

完整的查詢流程如下：

圖片

所以 Loki 的設計就是推薦使用并行化 (parallelization) 來實現(xiàn)最佳性能，將查詢分解成小塊，并將其并行調(diào)度，這樣就可以在小時間內(nèi)查詢大量的日志數(shù)據(jù)。

本文中的部分動圖和圖片引用自以下官方博客，推薦閱讀：

1. https://grafana.com/blog/2023/12/11/open-source-log-monitoring-the-concise-guide-to-grafana-loki/
2. https://grafana.com/blog/2023/12/20/the-concise-guide-to-grafana-loki-everything-you-need-to-know-about-labels/
3. https://grafana.com/blog/2023/12/28/the-concise-guide-to-loki-how-to-get-the-most-out-of-your-query-performance/
4. https://grafana.com/blog/2020/12/08/how-to-create-fast-queries-with-lokis-logql-to-filter-terabytes-of-logs-in-seconds/