TL;DR 快訊總結
- Grafana Loki 係 Grafana Labs 開發嘅開源日誌聚合系統，主打「只索引 label、唔索引內容」嘅低成本架構
- 最大優勢：儲存成本比 Elasticsearch 低 3-5 倍，同 Grafana 儀錶板無縫整合
- 主要缺點：冇全文搜尋、高基數（high cardinality）查詢會變慢、自架需要一定學習曲線
- 選購建議：已用 Grafana 睇 metrics、預算有限、查詢以 label 為主嘅團隊啱用；需要強大全文字搜尋嘅就揀 Elasticsearch
點解已有 Elasticsearch，仲要考慮 Grafana Loki？
做 observability 嘅人都知，日誌（log）係最食資源、最燒錢嘅一環。傳統嘅 ELK（Elasticsearch + Logstash + Kibana）方案要為咗全文搜尋而建立巨型倒排索引，隨住日誌量增加，你要不斷加 node、加記憶體、加 SSD，帳單越嚟越難睇。
👉 延伸閱讀：Palo Alto PA-550 系列全面評測：企業級防火牆新標準
正正因為呢個痛點，Grafana Labs 喺 2018 年推出 Loki，走咗一條同 Elasticsearch 完全相反嘅路線：唔索引日誌內容，只索引 label（標籤）。呢個設計理念令佢可以用極低成本儲存海量日誌，同時同 Grafana 儀錶板、Prometheus 指標、Tempo tracing 整合成一套完整嘅可觀測性（observability）平台。但係咪真係咁抵用？本文會拆開嚟講。
架構與技術拆解：Loki 點樣慳錢
要理解 Loki 點解平，就要明白佢同 Elasticsearch 喺索引策略上嘅根本分別。
Elasticsearch 會將每一行日誌嘅內容拆成 token，建立一個「詞 → 文件」嘅倒排索引，方便你做全文搜尋。代價係呢個索引體積可以同原始數據一樣大，甚至更大，而且查詢時要喺記憶體入面快速存取，所以記憶體同 SSD 需求極高。
Loki 完全唔做呢樣嘢。佢只會將日誌嘅 metadata（例如 app=api、env=prod、cluster=us-central 呢啲 label）建立一個極細嘅索引，而日誌內容本身就以壓縮形式直接丟去物件儲存（object storage，例如 S3、GCS）。Grafana Labs 嘅官方講法係，呢個 label 索引只係原始數據嘅約 1/10,000（即四個數量級咁細）。
用一個 ASCII 圖睇清楚佢哋嘅分別：
Elasticsearch（全文索引，貴）
+----------+ +--------------------------+
| Log | --> | Inverted Index |
| Stream | | (word -> doc mapping) |
+----------+ | 體積 ≈ 原始數據 1-2x |
+--------------------------+
Grafana Loki（只索引 label，平）
+----------+ +---------------+ +------------------+
| Log | --> | Promtail | --> | Label Index |
| Stream | | (agent) | | (極細 ~1/10000) |
+----------+ +---------------+ +------------------+
|
v
+------------------+
| Object Storage |
| (S3/GCS 壓縮) |
+------------------+
查詢嘅時候，Loki 會先用 label 索引快速定位邊啲日誌流有需要睇，然後再喺物件儲存度攞返壓縮嘅日誌，喺商業硬件上並行解壓同掃描。呢個「讀取路徑」設計令佢可以喺超大數據集上做任意查詢，同時唔使養一堆昂貴嘅記憶體密集型 instance。
部署模式：三種揀法
Loki 有三種部署模式，由簡單到複雜：
- Monolithic（單一進程）：適合細規模、開發環境，一個 binary 搞掂曬
- Simple Scalable（簡單擴展）：拆做 read path 同 write path，適合中型部署
- Microservices（微服務）：每個元件獨立部署，適合超大規模、需要獨立擴展嘅企業
採集端就用 Promtail（或者新嘅 Grafana Agent / Alloy），佢會負責收日誌、加 label、再推送俾 Loki。
核心功能評測
儲存成本：真係平咗好多
Loki 最突出嘅賣點就係成本。因為日誌內容唔做全文索引，直接壓縮放去物件儲存，而物件儲存（S3、GCS）每 GB 成本遠低於 SSD 同記憶體。社羣同第三方比較普遍認為，喺大規模場景下，Loki 嘅儲存成本可以比 Elasticsearch 低 3-5 倍。對於要保留日誌 30 日以上、又唔想燒錢嘅團隊，呢個係好有吸引力嘅數字。
查詢語言：LogQL 學習成本
Loki 用自己嘅查詢語言 LogQL，語法同 PromQL 有啲似，所以已經熟 Prometheus 嘅團隊會覺得好上手。但如果你習慣咗 Elasticsearch 嘅 Lucene 全文查詢語法，就要重新適應。LogQL 擅長用 label selector 過濾，例如 {app="api", env="prod"} |= "error"，但要做複雜嘅全文分析、模糊搜尋就會比較吃力。
高基數問題：Loki 最大嘅坑
呢個係 Loki 最常被吐槽嘅地方。高基數（high cardinality）label——即係一個 label 有幾千甚至幾萬個唔同值（例如用 request_id 做 label）——會令 label 索引急劇膨脹，查詢變慢，甚至拖冧成個系統。官方一直強調要避免將高基數資料放落 label，但新手好容易踩中呢個地雷。Reddit 上有用户直指「如果只想揾個 dumping ground 丟日誌，Loki 唔係你最好嘅選擇」。
Reddit / IT 社羣真實評價
綜合 Reddit 嘅 r/grafana、r/devops 同 Hacker News 討論，真實用户嘅意見好兩極：
讚賞點（Pros）
「我哋用 Grafana 睇 metrics 好耐，加 Loki 之後成個 observability stack 好一致，唔使再維護一套 ELK，省咗好多心力。」
「成本真係差好遠。同樣嘅日誌量，Loki 放 S3 嘅錢，連 Elasticsearch 集羣嘅十分一都唔夠。」
吐槽 / 踩坑點（Cons）
「搜尋方面有啲擔憂，尤其係 high cardinality 日誌。一踩中高基數 label，查詢慢到想死。」
「如果你要嘅係強大全文字搜尋、要做複雜 aggregation，Loki 唔係好啱。佢係 label-based，唔係 full-text search。」
總體嚟講，社羣共識係：Loki 定位清晰——平、夠用、同 Grafana 整合好，但唔係 Elasticsearch 嘅完全替代品。你用唔用得啱，取決於你嘅查詢模式係咪以 label 為主。
橫向競品對比
| 維度 | Grafana Loki | Elasticsearch (ELK) | Datadog Log Management |
|---|---|---|---|
| 定位 | 開源、label-based 日誌聚合 | 全文搜尋 + 分析引擎 | 全託管 SaaS 可觀測性平台 |
| 核心優勢 | 成本極低、同 Grafana 整合 | 強大全文字搜尋、成熟生態 | 開箱即用、零維護 |
| 部署難度 | 中等（自架要學 LogQL） | 高（集羣調校複雜） | 低（SaaS 即用） |
| 誤報率/效能 | 高基數 label 會拖慢 | 高基數表現佳但燒資源 | 效能好但成本高 |
| 價格區間 | 開源免費／Grafana Cloud 按量 | 開源免費／Elastic Cloud 貴 | 按 host 或用量計費，最貴 |
部署 / 使用最佳實踐
如果你決定用 Loki，以下幾點可以幫你避開最常見嘅坑：
- 嚴控 label 數量：label 只用嚟做「環境識別」（app、env、cluster），千祈唔好放 request_id、user_id 呢啲高基數值落 label，要用 structured metadata 代替
- 預先規劃儲存：揀好物件儲存（S3、GCS、MinIO 自架），設定好 retention，日誌放得耐成本線性上升，但遠平過全文索引
- 用 Grafana Agent / Alloy 取代舊 Promtail：新 agent 同時支援 metrics、logs、traces，統一採集管道
- 配合 Prometheus + Tempo：Loki 本身只處理 logs，要完整 observability 就同 metrics、tracing 一齊部署，喺 Grafana 度做關聯跳轉
- 先細規模試行：由 monolithic 模式起步，驗證查詢模式啱唔啱你，先考慮擴展到 scalable / microservices
常見問題 FAQ
Loki 係咪可以完全取代 Elasticsearch？
唔係。Loki 專注喺 label-based 日誌聚合，冇 Elasticsearch 嗰種強大全文字搜尋同複雜分析能力。如果你嘅團隊日日都要做模糊搜尋、全文檢索，或者要喺日誌度做複雜 aggregation，Elasticsearch 仍然係更啱嘅選擇。
Grafana Loki 幾錢？
開源版 Loki 完全免費，但你要自己負責部署同維護。Grafana Labs 亦有雲端託管嘅 Grafana Cloud，按用量收費，入門有免費額度，適合想慳運維成本嘅團隊。
Loki 同 Prometheus 有咩關係？
兩者都係 Grafana Labs 旗下嘅開源項目。Prometheus 處理 metrics（指標），Loki 處理 logs（日誌），查詢語言 LogQL 亦係參照 PromQL 設計。佢哋可以喺 Grafana 儀錶板度無縫整合，方便你由一個 metrics 異常直接跳去睇相關日誌。
結語：邊類企業啱、邊類唔啱
推薦呢類團隊用 Grafana Loki：已經用緊 Grafana 或 Prometheus、查詢以 label（服務、環境、pod）為主、日誌量大同預算有限、或者想要一套開源、可自架嘅輕量 observability 方案。呢類團隊會好快感受到成本同整合上嘅好處。
唔啱呢類團隊用：重度依賴全文搜尋、要做複雜日誌分析或 aggregation、日誌查詢模式高度自由（唔知要查咩 keyword）、或者已經有成熟 ELK 投資又冇強烈成本壓力嘅企業。硬要搬去 Loki，只會令你哋喺 LogQL 同 label 設計度碰壁。
🔗 參考資料：NVD NIST 漏洞資料庫
一句講曬：Loki 唔係萬能，但喺「平 + 夠用 + 同 Grafana 整合」呢條賽道上，佢的確係一個好有競爭力嘅選擇——前提係你搞清楚自己嘅日誌查詢習慣先。
#IT產品 #產品推介
