三本柱中的Log, 與Grafana家族中的Loki
加上OTel collector能迸出什麼火花呢?

但先來簡單介紹一下Loki吧!

Loki的歷史與成長

Loki是Grafana lab在2018年開始的項目, 並且在KubeCon Seattle發表

自2019年起, 每年都穩定的在成長,
下圖是該Github repo的star成長趨勢

在Log存儲與處理這塊, 發展得很好, 絕對是個未來之星.
去年小弟我在傳產也引入了Loki, 文章在此Log Agent - Fluent Bit Output + Loki + Grafana

Grafana Loki也提供了類似FluentBit的logs collector, 叫做Promtail, 不過我這次不會介紹它, 因為FluentBit的守備範圍更廣就是了.
FluentBit的介紹, 去年小弟也有引入公司, 文章系列在此FluentBit系列

Grafana Loki與其他組件的合作模式

左邊就是我們的系統與logs collector, 負責收集log, 並且轉換格式, 加上label, 甚至過濾log等等的.

中間則是Loki, 負責存儲, 對分成index與chunk做存儲,
但它的索引方式, 明年小弟的主題再來介紹一些存儲引擎相關的.
Loki有對資料與索引本身做壓縮, 壓縮比率特高.
同時也提供LogQL, 給右半邊的媒介做查詢語言.

右邊是可視化的介面, 可以給Grafana作為DataSource來配置, 並透過LogQL存取.

Loki的特點

Loki很方便, 它提供了一些特點

1. 支援Multi tenants多租戶模式（吸引人吧!)
   設定上打開auth_enabled = true

# Enables authentication through the X-Scope-OrgID header, which must be present
# if true. If false, the OrgID will always be set to "fake".
[auth_enabled: <boolean> | default = true]

API Header戴上X-Scope-OrdID即可.
也能針對OrdID進行分區存儲.
FluentBIt的Loki插件, 也支援Multi tenants, 只要設定好tenant_id_key

2. 水平擴展, Loki的很多組件都可以單獨作為一個服務運作, 再大規模安裝佈署時, 就彈性很多了.

3. 高可用, 能透過memberlist_config這裡的設定, 讓多個instnces, 共用同一個shared object store來達成
   

4. 容易維護設定, Plugin也很豐富
   hmm...好像上面特點蠻多都有的!

5. 對於索引定位log, Loki在記憶體的使用是非常地有效率的; 相對於競品來說, 用到的記憶體不用這麼多. 這Idea來自於Prometheus.
   官網這句話能說明.

Loki takes a unique approach by only indexing the metadata rather than the full text of the log lines.

6. 對Grafana整合程度很高
7. Chunk能存儲在雲上的儲存庫上, 能存在AWS S3或Google GCS; Index存在
   AWS DynamoDB或GCP BigTable
8. LogQL的設計也是,有PromQL, 所以學會其中一套, 學另外一套超快der~~

補充, Loki+Promtail與競品的比較

Grafana Loki / Promtail / Grafana vs EFK

ElasticSearch是真的很強大, 能應用的場景超廣.
但若我們只是個中小公司, 只想要做可觀測性的存儲與可視化.
又想要硬體成本(mem/disk...)低一點點的話, GLP(Grafana+Loki+Promtail)是可以考慮的方案.

Loki Architecture Compo

上圖是Loki的佈署架構跟各組件, 它們之間的讀寫關係.

• Distributor : 負責Client端傳入的streams. 一旦distributor收到一組stream時, 會檢查格式正確性完整性, 並且根據租戶設定的配置來處理, 並且發送到多個ingester; 也因為他是第一個接收的組件, log寫入的數量可能很大, 也不可能直接就往後拋, 通常會在這裡多個批量的處理.

• Ingester : Ingester是個有內部狀態的組件, 負責把收到的log開始變成chunk 也會在這關對log進行gzip壓縮, 並且寫到 Object Store上, 也會需要對chunk重新整理.

• Query : 透過LogQL處理查詢, 來抓取ingester與Object Store的資料

• Object Store : 分成Index與Chunk; index負責索引的存儲, chuck負責log fulltext的內容存儲; 查詢事先找索引在找到具體的chunk.

每個組件都有其作用也能單獨佈署透過rpc/http來溝通
像我身上背的七星刀, 每把都有適合的切割場景, 然後也是存在兩組 (疑?)

今日小心得

Loki看起來是很多組件的集合, 各司其職, 又能各自佈署.
加上用的資源又少, 聽起來是個大殺器.

Grafana的Datastorce新增那邊, 對於Logging database, 就推薦Loki與Elasticsearch這個很常見的資料存儲.

這幾天組合起來使用給各位看看!

參考連結

Loki官網
Loki Configuration