本文是 AWS CloudWatch 的 vendor deep article，深化 overview「Logs Insights query」跟「Logs lifecycle」段。初次接觸 CloudWatch 的讀者建議先讀 CloudWatch 服務頁。

問題情境

CloudWatch Logs 的成本模型跟 self-hosted log stack 不同 — ingestion、storage 跟 query 分開計費，每一層都有明確的 cost lever。理解 log group 設計、retention 設定與 subscription filter 的組合，才能在 AWS-native 環境下控制日誌成本而不犧牲事故判讀能力。

Log group 設計

拆分粒度

Log group 是 CloudWatch Logs 的計費與 retention 邊界。同一個 log group 內的所有 log stream 共用 retention policy 和 access control（IAM resource policy）。

合理的拆分粒度是 一個服務一個 log group，而非一個帳號一個或一個 container 一個。服務級拆分讓 retention、查詢範圍與 IAM 權限自然對齊服務 ownership。

Lambda 的預設行為是每個 function 自動建一個 log group（/aws/lambda/<function-name>）。function 數量超過數十個後，需要用 naming convention 加 tag 控制，否則 retention policy 難以統一套用。

Naming convention

推薦格式：/<environment>/<service>/<component>，例如 /prod/checkout-api/app、/prod/checkout-api/access-log。統一前綴讓 Logs Insights 的 multi-log-group query 用 prefix matching 篩選。

Logs Insights 查詢語法

核心語法

Logs Insights 的查詢結構是 pipe-based：每行用 | 分隔，依序處理。

1fields @timestamp, @message, @logStream
2| filter @message like /ERROR/
3| parse @message "order_id=* status=*" as order_id, status
4| stats count(*) as error_count by status
5| sort error_count desc
6| limit 20

常用 command 對照：

JSON 自動解析

CloudWatch Logs 會自動辨識 JSON 格式的 log event。JSON 欄位用 dot notation 存取：

1fields @timestamp, requestId, level, message
2| filter level = "ERROR"
3| stats count(*) by bin(5m)

如果 log 是 JSON 格式，parse 通常不需要 — 直接用欄位名稱。混合格式（部分 JSON、部分 plain text）時，需要用 isPresent() 判斷欄位是否存在。

效能考量

Logs Insights 的查詢成本按掃描的 data 量計費（每 GB scanned），不按結果數。減少掃描量的方式：

• 縮短時間範圍：事故判讀先查最近 30 分鐘，確認 pattern 後再擴大
• 指定 log group：避免對所有 log group 做全域查詢
• 用 limit 限制結果集大小（不影響掃描量，但減少資料傳輸）

跨 log group 查詢最多同時查 50 個 log group。超過時需要拆成多次查詢或用 subscription filter 把資料匯到集中儲存。

Retention policy

設定方式

Retention policy 在 log group 級別設定。每個 log group 可以獨立選擇 1 天到 10 年、或永不過期。

1aws logs put-retention-policy \
2  --log-group-name /prod/checkout-api/app \
3  --retention-in-days 30

常見 retention 策略按服務性質分：

未設定 retention 的 log group 預設永不過期 — 這是 CloudWatch 日誌成本超支的常見原因。新 log group 建立後應立即設定 retention。

FinTech 合規場景的 log group 分離

FinTech 審計證據案例揭露一個常見問題：audit log 跟 operational log 混在同一個 log group，retention 只能統一設定。結果要嘛 operational log 為了合規被迫留太久（成本浪費）、要嘛 audit log 跟著 operational log 的短 retention 被刪掉（合規風險）。

CloudWatch 的 log group 設計天然支援這種分離 — audit log 跟 operational log 用不同 log group、各自設定 retention：

Audit log group 的額外治理：

• IAM 權限分離：audit log group 的讀取權限（logs:GetLogEvents）限縮到 compliance team 跟 security team，application developer 只能讀 operational log group。避免 audit log 被隨意查詢或汙染
• Immutability：CloudWatch Logs 本身不支援 WORM（write once read many），合規要求 immutable 存檔時用 subscription filter 把 audit log 同步送到 S3 + Object Lock
• Cross-account 集中：audit log 的 cross-account aggregation（見下方段落）的 IAM 權限要比 operational log 嚴格 — aggregated sink 的 destination 只能由 security team 控制

Infrequent Access log class

CloudWatch Logs 提供兩種 log class：Standard（完整查詢、即時 subscription filter、metric filter）跟 Infrequent Access（僅支援 Logs Insights 查詢、不支援即時 subscription filter 跟 metric filter、ingestion 成本約降 50%）。

Audit log 的存取模式通常是「寫入頻繁、查詢極少（只在稽核或事故時才查）」— 正好符合 Infrequent Access 的定位。把 7 年 retention 的 audit log group 設成 Infrequent Access，ingestion 成本直接砍半。

注意 Infrequent Access 的限制：不能用 subscription filter 即時轉發到 Lambda 或 Kinesis，不能用 metric filter 從 log 產生 CloudWatch metric。如果 audit log 需要即時異常偵測（例如偵測大量失敗交易），要用 Standard class + subscription filter 做即時處理、再用 Lambda 寫到長期 audit log group（Infrequent Access）。

自動化套用

用 AWS Config rule 或 CloudFormation / CDK 的 log group 定義統一設定 retention。Lambda function 自動建立的 log group 不會自動套用 retention，需要額外自動化（Lambda post-hook 或 EventBridge rule + Lambda 設定 retention）。

Cross-account log aggregation

架構模式

多帳號環境下，常見做法是設立一個「觀測帳號」（observability account），把其他帳號的 logs 匯入。

兩種匯入方式：

Subscription filter + Kinesis Data Firehose：每個 source 帳號的 log group 設 subscription filter，把 log event 送到 observability 帳號的 Kinesis Data Firehose，再寫到 S3 或 OpenSearch。適合需要長期存檔或進階查詢的場景。

CloudWatch cross-account observability：AWS 原生功能，在 monitoring account 直接查詢 source accounts 的 CloudWatch 資料（metrics、logs、traces）。設定較簡單，但查詢延遲較高，且 Logs Insights 的 cross-account 查詢有 region 限制。

Subscription filter 實務

Subscription filter 可以把 log event 送到 Lambda（即時處理）、Kinesis Data Stream（緩衝）、Kinesis Data Firehose（直接寫 S3/OpenSearch）或另一個 log group。

每個 log group 最多 2 個 subscription filter — 這是硬限制。如果同一個 log group 需要同時送 S3 archive 跟即時 alerting，要用 Kinesis Data Stream 做 fan-out，讓 stream 下游各自消費。

filter pattern 語法支援 JSON 欄位匹配：

1{ $.level = "ERROR" }

只把 ERROR 級別的 log 送到 alerting pipeline，可以大幅降低下游處理量跟成本。

Cost governance

計費結構

CloudWatch Logs 的成本由三個維度組成：

Ingestion 是最大成本。降低 ingestion 的手段：

• 調整 log level：production 只保留 INFO 以上，DEBUG 只在問題排查時短暫開啟
• 去除重複資訊：access log 跟 application log 不要記錄相同欄位
• 用 metric filter 替代 log query：高頻計數（error count、request count）用 CloudWatch Metric Filter 從 log 產生 metric，查詢成本從 log scan 轉成 metric query

成本觀測

用 CloudWatch 自己的 metric 觀測 log 成本：

• IncomingBytes（per log group）：監控哪個 log group ingestion 最大
• IncomingLogEvents（per log group）：監控 event 數量
• AWS Cost Explorer 按 CloudWatch 拆分：看 log ingestion vs storage vs API call 的比例

降本決策樹

判斷成本是否合理的順序：

1. 最大 ingestion 的 log group 是哪個？是否合理（核心服務的 access log 量大是正常的）
2. Retention 是否都有設定？未設定的 log group 會持續累積 storage 成本
3. 是否有 DEBUG 級別 log 在 production 長期開啟？
4. 是否有 subscription filter 把全量 log 送到外部？能否加 filter pattern 只送需要的部分

整合與下一步

• 觀測管線整合：CloudWatch Logs → Subscription Filter → Kinesis Firehose → S3 / OpenSearch，見 4.11 Telemetry Pipeline
• Audit log 治理：合規場景的 log retention 跟 access control，見 4.12 Audit Log Governance
• Evidence package：把 Logs Insights query link 跟時間窗放進 evidence，見 4.20 Observability Evidence Package
• OTel 整合：ADOT 可以把 log 送到 CloudWatch Logs 或其他 backend，見 OpenTelemetry Collector 部署模式

本文是 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 時的替代方案