本文是 Grafana Stack 的 vendor deep article，深化 overview 的元件組合段。初次接觸 Grafana Stack 的讀者建議先讀 Grafana Stack 服務頁。

定位

Grafana Stack（LGTM = Loki + Grafana + Tempo + Mimir）是自架觀測平台的完整選項，四個元件各自承擔一類訊號的儲存跟查詢。理解每個元件的責任邊界、部署模式跟故障特性，才能避免「裝了四個元件但不知道哪個壞了」的黑盒問題。

四元件的責任分工

Grafana 是查詢 / 視覺化層，Loki / Mimir / Tempo 是儲存 / 查詢層。Grafana 本身不存觀測資料，它連接 data source（Loki / Mimir / Tempo / Prometheus / Elasticsearch）做查詢跟渲染。

四個元件獨立部署、獨立擴展、各自有健康指標。一個元件故障不影響其他元件 — Loki 掛了時 Grafana 的 metric dashboard 跟 trace 查詢仍然正常，只有 log panel 會報錯。

部署模式

Monolithic mode

四個元件（或其中幾個）跑在同一個 process / container。適合小規模（每天數 GB log、數十萬 metric series、少量 trace）。部署最簡單 — 一個 docker-compose 或 Helm chart 起全套。

限制是沒辦法獨立擴展 — log 量大但 metric 量小時，monolithic mode 不能只加 Loki 的資源。

Microservices mode

每個元件拆成獨立的 deployment、各自 autoscaling。Loki 拆成 distributor / ingester / querier / compactor；Mimir 拆成類似的元件；Tempo 也有對應的分層。

適合中到大規模。部署跟維運複雜度顯著上升 — 每個元件的每個子服務都需要獨立的 health check、autoscaling 設定、persistent volume。

選擇判準

常見故障模式

Loki：ingester OOM

Loki ingester 把 log chunks 保存在記憶體，高流量時容易 OOM。觸發條件是突然的 log 量爆增（部署後 error storm、某服務開了 debug log level）。

判讀指標：loki_ingester_memory_chunks、process_resident_memory_bytes。修復方向：調整 chunk flush interval（更頻繁寫入 object storage、降低記憶體壓力）、加 ingester replica、或在 pipeline 層（OTel Collector）做 log volume rate limit。

Mimir：compactor 卡住

Mimir compactor 負責合併 ingester 寫入的 block。Compactor 卡住時，block 數量持續增長、query 需要掃描更多 block、延遲上升。

判讀指標：cortex_compactor_runs_completed_total 停滯、cortex_bucket_blocks_count 持續增長。修復方向：檢查 object storage 的寫入權限跟延遲、增加 compactor 資源（CPU / memory）、或暫時停止 ingestion 讓 compactor 追上。

Tempo：trace not found

使用者用 trace ID 查詢時回 “trace not found”，但 trace 確實存在。常見原因是 Tempo 的 bloom filter / compacted block index 還沒包含該 trace（ingestion 到可查詢有延遲），或 trace 被 retention policy 刪除。

判讀方式：查 trace 的 timestamp 是否在 retention 範圍內、查 tempo_ingester_traces_created_total 確認 ingestion 正常、查 compactor 是否正常運行。

Grafana：dashboard provisioning 漂移

用 provisioning（YAML / JSON 檔案）管理 dashboard 時，手動在 UI 修改的 dashboard 會在下次 provisioning 同步時被覆蓋。團隊成員在 UI 調整了 panel、下次重啟 Grafana 後修改消失。

修復方向：dashboard 修改統一透過 git → provisioning pipeline（GitOps），UI 只用於臨時調整跟探索。把 provisioning 的 allowUiUpdates 設為 false、強制所有變更走 git。

Dashboard Provisioning

Dashboard 的管理方式影響長期維護成本。手動在 UI 建立 dashboard 的起步最快，但隨 dashboard 數量增長會出現版本不一致、無法 rollback、owner 不明的問題。

Infrastructure as Code

Dashboard JSON 存在 git repo、透過 provisioning 同步到 Grafana。變更走 PR review、有版本歷史、可以 rollback。

Grafana 的 provisioning 機制讀 YAML config，指定 dashboard JSON 的來源（local file / HTTP / API）。Helm chart 部署時把 dashboard JSON 放在 ConfigMap 或 persistent volume。

Grafonnet / Jsonnet

用 Jsonnet（Grafana 的 dashboard-as-code library）產生 dashboard JSON。適合大量相似 dashboard 的場景 — 每個服務一個 dashboard，結構相同但 data source 跟 label 不同。

Grafonnet 的學習曲線比直接寫 JSON 高，但在 dashboard 數量 > 20 個時開始有維護效率的回報。

下一步路由

• Grafana Stack 服務頁：overview 跟日常操作
• Prometheus 服務頁：Mimir 的上游 metric 來源
• OTel Collector 部署模式：LGTM 的 ingestion 入口
• 4.11 telemetry pipeline：pipeline 各層的治理
• 4.18 operating model：dashboard / alert 的 ownership

本文是 Grafana Stack 的 vendor deep article，深化 overview「Loki 設計與限制」段。初次接觸 Grafana Stack 的讀者建議先讀 Grafana Stack 服務頁。

問題情境

團隊從 ELK stack 或 CloudWatch Logs 遷到 Grafana Stack 時，Loki 是 log backend 的預設選擇。遷移後最常遇到的衝擊是查詢模式的根本差異：Elasticsearch 做 full-text index（寫入時索引每個欄位、查詢時任意搜尋），Loki 只 index labels（寫入時只索引 stream labels、查詢時先篩 stream 再 grep content）。

這個差異是刻意的設計選擇 — Loki 的目標是「Prometheus for logs」：用跟 Prometheus metrics 相同的 label 體系管理 logs，讓 log 查詢跟 metric 查詢使用同一組 label selector。代價是失去 full-text search 的即時性。理解這個設計哲學才能正確設計 label、寫出有效率的 LogQL、避免常見的效能陷阱。

核心概念

Like Prometheus, but for logs

Prometheus 用 label set 識別 time series — {job="checkout", instance="10.0.1.5"} 是一條 series。Loki 用相同概念識別 log stream — {job="checkout", namespace="production"} 是一條 stream。同一條 stream 的所有 log entries 存在同一組 chunks。

Elasticsearch 的索引模式是「寫入時建 inverted index、查詢時走索引」。Loki 的索引模式是「寫入時只記錄 stream label → chunk 的 mapping、查詢時先用 label 選 stream、再在 chunk 內做 grep」。

這代表：

• 有 label filter 的查詢很快 — Loki 只掃對應 stream 的 chunks
• 沒有 label filter 的查詢很慢 — Loki 要掃所有 stream 的 chunks（相當於 full scan）
• Label cardinality 跟 Prometheus 一樣敏感 — 高 cardinality label 產生大量 stream、每個 stream 的 chunk 很小、index 膨脹

Stream 與 chunk

一條 stream = 一組唯一的 label set。每條 stream 的 log entries 依時間排序存在 chunks 裡。Chunk 是 Loki 的最小儲存單位。

1Stream: {job="checkout", namespace="production"}
2  └─ Chunk 1: [2026-06-22T00:00 ~ 2026-06-22T01:00] (compressed)
3  └─ Chunk 2: [2026-06-22T01:00 ~ 2026-06-22T02:00] (compressed)
4  └─ ...

Chunk 存在 object storage（S3 / GCS / MinIO），index 存在 key-value store（BoltDB / TSDB，3.0 起預設 TSDB）。Object storage 便宜（相比 Elasticsearch 的 SSD），這是 Loki 成本優勢的來源。

跟 Elasticsearch 的根本差異

判讀：如果團隊的 log 查詢模式是「先選 service/namespace/pod、再看時間範圍內的 log entries」，Loki 足夠。如果查詢模式是「在所有 log 裡搜某個 error message 或 request ID」，Elasticsearch 的 full-text index 更適合。

配置 step-by-step

Label 設計原則

Label 設計是 Loki 最重要的操作決策。原則跟 Prometheus 相同：低 cardinality、穩定、有查詢意義。

request_id / user_id / trace_id 不應該是 label，它們應該在 log content 裡用 structured JSON 欄位表達，查詢時用 LogQL 的 line filter 或 parser 提取。

LogQL 常見查詢模式

Stream selector + line filter（最基本）：

{job="checkout", namespace="production"} |= "error" |= "timeout"

先選 stream、再 grep 包含 “error” 和 “timeout” 的 log lines。|= 是包含、!= 是不包含、|~ 是 regex。

Structured metadata parser（JSON log）：

{job="checkout"} | json | status_code >= 500 | line_format "{{.method}} {{.path}} {{.status_code}}"

| json 解析 JSON log entry 的欄位，後續可以用欄位做 filter 和格式化。

Metric 聚合（log → metric）：

sum by (status_code) (rate({job="checkout"} | json | __error__="" [5m]))

計算每 5 分鐘每個 status_code 的 log entry 速率。這是 Loki 的「metric from logs」能力 — 不需要額外的 metrics pipeline，直接從 log 產生 time series。

Loki config 核心段

 1# loki-config.yaml
 2schema_config:
 3  configs:
 4    - from: 2024-01-01
 5      store: tsdb
 6      object_store: s3
 7      schema: v13
 8      index:
 9        prefix: loki_index_
10        period: 24h
11
12storage_config:
13  tsdb_shipper:
14    active_index_directory: /loki/index
15    cache_location: /loki/cache
16  aws:
17    s3: s3://loki-chunks-bucket
18    region: us-east-1
19
20limits_config:
21  ingestion_rate_mb: 10
22  ingestion_burst_size_mb: 20
23  max_streams_per_user: 10000
24  max_label_name_length: 1024
25  max_label_value_length: 2048

limits_config 是防護網。max_streams_per_user 限制每個 tenant 的 stream 數量，超過時新 stream 的 log 被拒（HTTP 429）。這是 label cardinality 爆炸的最後防線。

故障與邊界

Label cardinality 爆炸

觸發條件：label 包含高 cardinality 值（pod UID、request ID、container ID）。每個唯一 label set 產生一條 stream，stream 數量快速增長。

表現：loki_ingester_memory_streams 持續上升、ingester memory 增長、最終觸發 max_streams_per_user 限制（429 error）。跟 Prometheus series explosion 是同一個問題的 log 版本。

修法：檢查產出大量 stream 的 label。Loki 的 /loki/api/v1/labels 和 /loki/api/v1/label/{name}/values API 可以列出所有 label 值。找到高 cardinality label 後，從 promtail / alloy 的 pipeline 中移除該 label、改放進 log content 的 structured field。

Stream rate limit

觸發條件：單一 stream 的 ingestion rate 超過 per_stream_rate_limit（預設 3 MB/s）。通常是某個 service 大量噴 debug log。

表現：Loki 回傳 429 + rate limit exceeded error。部分 log entries 被丟棄。

修法：先解決 log 噴量問題（降低 debug log level 或加 sampling）。如果噴量合理（高 QPS 服務），調高 per_stream_rate_limit 或拆分 stream（加一層 label 分散流量）。

大時間範圍查詢 timeout

觸發條件：LogQL 查詢沒有精確的 label filter、時間範圍 > 24 小時。Loki 要掃描大量 chunks、query timeout（預設 3 分鐘）觸發。

表現：Grafana 顯示 query timeout error。

修法：查詢時先用 label selector 縮小 stream 範圍（{job="checkout", namespace="production"} 而非 {namespace="production"}），再用 line filter 進一步篩。如果業務需要長時間範圍的 log analytics，考慮用 LogQL 的 metric aggregation（rate(...) / count_over_time(...)）替代原始 log 掃描。

Chunk target size 與 ingestion rate 的關係

chunk_target_size（預設 1.5 MB）控制 chunk 的大小。ingestion rate 低的 stream 可能幾個小時才填滿一個 chunk — 這段期間 chunk 停在 ingester memory 裡。大量低 ingestion rate 的 stream（= 高 cardinality label）會讓 ingester 同時持有大量未 flush 的 chunks，佔用記憶體。

修法方向：降低 chunk_idle_period（預設 30 分鐘，時間到即使 chunk 未滿也 flush），或減少低 cardinality stream 的數量。

容量與成本

Loki 的成本結構跟 Elasticsearch 根本不同：

Loki 在「每天寫 TB 級 log、偶爾查一下」的場景成本遠低於 Elasticsearch。但在「每天查數百次、需要快速 full-text search」的場景，Elasticsearch 的 pre-indexed 查詢效能更好，Loki 每次 grep 的 compute cost 反而更高。

成本治理的判讀：監控 loki_ingester_bytes_received_total（ingestion volume）和 loki_querier_query_duration_seconds（query cost）。如果 query duration 持續上升，先檢查是 label filter 不夠精確還是 query 時間範圍太大。

整合與下一步

• Grafana Stack 服務頁：overview 與全棧操作
• LGTM Stack Operations：Loki 在 LGTM 全棧中的部署位置
• 4.12 Audit Log Governance：Loki 不適合 audit log 的 compliance 查詢（無 immutable storage 保證、無 fine-grained access control）— 合規需求用 BigQuery 或 dedicated audit backend
• Healthcare 存取追溯案例：分層 retention 在 Loki 用 tenant-level retention policy 實現
• 4.1 Log Schema：log 欄位設計影響 Loki 的 label 設計與 parser 效率
• Elasticsearch ILM 與 Log Pipeline：需要 full-text search 時的替代方案

本文是跨 vendor migration playbook、cross-link Prometheus 跟 Grafana Stack（Grafana Cloud Metrics、Mimir-backed）。跑 migration-playbook-methodology 6 維 audit 後對映 Operational = High → Type C operational redesign hybrid。

Feature / ops / cost 三維對照

跑 6 維 diff dimension audit：

Operational = High → Type C standard。

為什麼遷：retention / ops / vendor consolidation 三條 driver

Operational redesign

Migration 4-phase

Phase 0：Audit

• 列所有 Prometheus job / scrape config
• 統計 active series 數（Mimir tier 計費基準）
• 估 retention 需求

Phase 1：Grafana Cloud setup

• Account + organization 設定
• API key for remote_write
• Grafana Cloud Mimir endpoint 啟用

Phase 2：Dual-write

 1# prometheus.yml
 2remote_write:
 3  - url: https://prometheus-prod-XX-prod-us-central-0.grafana.net/api/prom/push
 4    basic_auth:
 5      username: <INSTANCE_ID>
 6      password: <API_KEY>
 7    write_relabel_configs:
 8      # Optional: drop high-cardinality before sending
 9      - source_labels: [__name__]
10        regex: 'high_card_metric_.*'
11        action: drop

跑 4-8 週、確認 query 結果一致 + cost 在預期。

Phase 3：Cutover

• Dashboard / alert 切到 Grafana Cloud endpoint
• 應用層 / Grafana 自管 instance 關閉 query 對 self-managed Prometheus

Phase 4：Cleanup

• Self-managed Prometheus stop scrape
• 留 1-2 月歷史查詢能力（用 archive snapshot）
• Decommission

Production 故障演練

Case 1：Cardinality 爆、cost 暴漲

徵兆：dual-write 第 2 週 Grafana Cloud series 從預估 100K 漲到 800K、cost 翻 8 倍。

根因：application-level high-cardinality label（user_id / request_id）沒被 drop、scraped 進來。

修法：

1. write_relabel_configs drop unbounded label
2. Application metric 設計改 fixed-bucket histogram、不用 unbounded label
3. Mimir cardinality limit 設保護 + alert

Case 2：Recording rule 對應失效

徵兆：cutover 後 Grafana dashboard 某些 panel 顯示空；發現用了 Prometheus 端 recording rule (job:request_count:rate5m)、Grafana Cloud 端沒對應 rule。

根因：Prometheus 端 recording rule 是 server-side、不會跟著 remote_write 帶過去；Grafana Cloud 需要自己 setup recording rule。

修法：

1. Export 所有 recording rule、import 到 Grafana Cloud Mimir
2. 或改用 raw query + Grafana query template、不依賴 recording rule

Case 3：PromQL 微差行為

徵兆：某些 query 在 self-managed Prometheus 跑得好好的、切 Grafana Cloud Mimir 後 returns slightly different results。

根因：Mimir 對某些 edge case（empty result handling / staleness marker timing）行為跟 Prometheus 略不同；多數 query 一致、< 1% query 受影響。

修法：

1. Pre-cutover dual-query 驗證、用 critical dashboard 比對
2. Affected query 重寫、用更 robust PromQL pattern
3. 文件 known incompatibility list

Case 4：Alert routing 改變

徵兆：Cutover 後 PagerDuty / Slack 收不到 alert；發現 Alertmanager 端 webhook 沒切。

根因：alert 邏輯從 self-managed Alertmanager 搬到 Grafana Cloud Alerting、routing / contact 配置完全重做。

修法：

1. Pre-cutover 在 Grafana Cloud 端 rebuild alert + routing
2. 雙 alert pipeline 跑 1-2 週、確認 Grafana Cloud 收到
3. Cutover 切 routing、SOC drill 一次

Case 5：歷史資料查不到

徵兆：Cutover 後 SOC 想 query 6 個月前事件、Grafana Cloud 只有 2 個月（dual-write 後的）資料。

根因：Grafana Cloud 從 dual-write 開始才有資料、之前的 self-managed Prometheus historical data 沒 backfill。

修法：

1. Phase 2 期間用 promtool tsdb dump + mimirtool 把 self-managed historical 灌進 Mimir
2. 或保留 self-managed Prometheus read-only 6 個月（給 historical query）
3. Long-term：retention 從 cutover 開始算、historical 是 one-time backfill

Capacity / cost

整合 / 下一步

跟 Datadog → Grafana Stack migration 對位

兩條 Grafana Stack 路線：

• Self-host (Mimir + Loki + Tempo) on K8s：開源、自管
• Grafana Cloud：SaaS、operational simplification

本篇是「self-managed Prometheus → Grafana Cloud」、互補；如果跑兩階段（self-host → Cloud）跟「Datadog → Grafana Cloud」差不多。

跟 OpenTelemetry 整合

OTel Collector 可同時 ship 到 Mimir (metric) + Loki (log) + Tempo (trace)；Migration 順便升 OTel 化避免下次 vendor 切換重複。

相關連結

• Source vendor：Prometheus
• Target vendor：Grafana Stack
• 平行 migration playbook (Type C)：PostgreSQL → Aurora / Kafka → MSK / ELK → Elastic Cloud
• 平行 D-type 對位：Datadog → Grafana Stack
• Methodology：Migration playbook methodology