本文是 Elastic Stack 的 vendor deep article，深化 overview「Index Lifecycle Management」跟「採集 pipeline」段。初次接觸 Elastic 的讀者建議先讀 Elastic Stack 服務頁。

問題情境

Elastic Stack 部署後，工程師通常能快速搜尋到 log。問題出在規模成長後：index 數量膨脹導致 cluster 效能退化、disk 滿了才發現沒有 lifecycle policy、shard 太小或太大造成查詢效能不均、採集 agent 的選擇在 Beats / Logstash / Elastic Agent / Fluent Bit 之間搖擺不定。ILM 跟 log pipeline 設計是 Elastic Stack 從「能用」到「可治理」的關鍵步驟。

核心概念

Data Stream vs Index Alias

Elasticsearch 7.9+ 引入 data stream，取代傳統 index alias + rollover 模式。兩者的核心差異：

Data stream 是 append-only 的 time-series 資料結構。每個 data stream 下有多個 backing index，由 ILM 自動管理 rollover。寫入只能 append（沒有 update / delete single document），適合 log、metrics、traces。

Index alias 是傳統模式 — 手動建立 write alias 指向 current index，配合 ILM rollover action 觸發新 index 建立。支援 update / delete，適合需要修改文件的場景（例如 enrichment pipeline 的 lookup index）。

選擇判讀：time-series 資料（log / metrics / APM trace）一律用 data stream。需要文件修改的 reference data、lookup table 用 index alias。新部署預設用 data stream，除非有明確理由。

ILM Policy 設計

ILM（Index Lifecycle Management）把 index 的生命週期分成五個 phase：

Hot phase：active write + 高頻查詢。Index 在 hot data node 上，用 SSD。Rollover 條件觸發後，current index 變 read-only，新 index 繼續寫入。

Warm phase：read-only + 中頻查詢。Index 搬到 warm data node（可以是 HDD 或較便宜的 SSD）。通常在 rollover 後 1-7 天觸發。可以執行 force merge（減少 segment 數量、提升查詢效能）跟 shrink（減少 shard 數量）。

Cold phase：searchable snapshot + 低頻查詢。Index 轉成 partial searchable snapshot，資料存在 object storage（S3 / GCS / Azure Blob），本地只保留 cache。查詢可用但較慢。適合 30 天到 1 年的保留。

Frozen phase：fully mounted searchable snapshot + 極低頻查詢。資料完全在 object storage，本地無 cache。查詢最慢但成本最低。適合 1 年以上的合規保留。

Delete phase：刪除 index。保留期到期後自動清理。

 1PUT _ilm/policy/application-log-policy
 2{
 3  "policy": {
 4    "phases": {
 5      "hot": {
 6        "actions": {
 7          "rollover": {
 8            "max_primary_shard_size": "30gb",
 9            "max_age": "1d"
10          }
11        }
12      },
13      "warm": {
14        "min_age": "3d",
15        "actions": {
16          "forcemerge": {"max_num_segments": 1},
17          "shrink": {"number_of_shards": 1}
18        }
19      },
20      "cold": {
21        "min_age": "30d",
22        "actions": {
23          "searchable_snapshot": {
24            "snapshot_repository": "s3-repo"
25          }
26        }
27      },
28      "delete": {
29        "min_age": "365d",
30        "actions": {"delete": {}}
31      }
32    }
33  }
34}

Rollover 條件的選擇：max_primary_shard_size 比 max_size 更精確（直接控制單一 primary shard 大小）。目標是每個 primary shard 在 20-50 GB 之間。太小（< 5 GB）造成 shard 過多、cluster state 膨脹；太大（> 50 GB）造成 recovery 慢、query 效能下降。

儲存成長回推 lifecycle 設計

Discord 儲存成長案例揭露一個在快速成長服務反覆出現的模式：資料量倍增後才發現 ILM 的 hot → warm → cold 邊界不對、hot tier 佔比過高是最常見的成本問題。

問題的根源是 ILM policy 在服務初期設計、之後沒有隨資料量調整。一個服務從 10 GB/day 成長到 100 GB/day 時：

• Hot tier 膨脹：原本 hot phase 設 7 天、10 GB/day × 7 天 = 70 GB。成長到 100 GB/day 後、hot tier 變成 700 GB、SSD 成本是原來的 10 倍
• Warm tier 延遲啟動：如果 warm phase 的 min_age 仍然是 7 天、資料在最貴的 tier 停留太久
• Cold/frozen phase 未啟用：初期資料量小時 cold phase 看不到成本效益、成長後才發現 30 天以上的資料全在 warm tier SSD 上

修法是把 ILM review 放進服務的 capacity review cadence（季度或半年）。Review 時看三個指標：hot_data_size / total_data_size（hot tier 佔比超過 30% 就該重新評估）、warm_tier_age_distribution（warm tier 是否堆了太多舊資料）、monthly_storage_cost_trend（成本是否跟資料量同比例增長）。

Searchable snapshot（cold/frozen phase）是成本降幅最大的一步 — 資料從 local SSD 搬到 object storage，儲存成本降 70-90%。但搬遷後查詢延遲從 ms 退化到秒級。判讀「什麼資料該移」的訊號是該 index 在過去 30 天的查詢頻率 — 沒被查過的 index 留在 warm tier 是浪費。

採集 Pipeline：Beats vs Elastic Agent vs 第三方

選擇判讀：

• 新部署、想要集中管理：Elastic Agent + Fleet。Fleet Server 提供 policy 集中推送、版本升級、health monitoring。代價是 Fleet Server 自身需要維運。
• 既有 Beats 部署、穩定運行：不急著遷移。Elastic Agent 的 Beats integration 內部仍用 Beats 引擎。
• K8s 環境、resource 敏感：Filebeat DaemonSet。資源消耗 ~50-100 MB per node，比 Elastic Agent 低。
• 多 destination（ES + S3 + Kafka）：Logstash 或 Vector。Beats 的 output 只能寫一個 destination（除非用 output plugin hack）。
• 已有 OTel Collector：OTel Collector 可以直接把 log 送到 Elasticsearch（OTLP exporter 或 Elasticsearch exporter），不需要額外 Beats。

配置 step-by-step

Ingest Pipeline 設計

Ingest pipeline 在 Elasticsearch 層做 log 的 parsing 跟 enrichment，在 index 前處理。

常用 processor：

• grok：regex pattern 解析非結構化 log。適合 nginx access log、syslog 等固定格式。
• dissect：delimiter-based parsing。比 grok 快 5-10 倍，但只能處理固定 delimiter 格式。
• date：把 log 中的 timestamp string 解析成 @timestamp。
• geoip：IP 地址轉地理位置。
• script：Painless script 做自訂轉換。效能代價高，只在其他 processor 做不到時使用。
• set / rename / remove：field 操作。

Pipeline 設計原則：先用 dissect（快）、dissect 做不到才用 grok（慢）。Pipeline 中的 processor 數量跟複雜度直接影響 ingest 吞吐。高 volume 場景（> 10K events/sec per node）要做 ingest pipeline benchmark。

Mapping Template 與 Dynamic Mapping 治理

Mapping template 定義 index 的 field type。Dynamic mapping 對未知 field 自動建立 mapping — 這是 Elastic 的便利功能，也是最常見的治理問題。

Dynamic mapping 風險：application log 帶 arbitrary JSON payload，dynamic mapping 對每個 key 建立 field mapping。一個 log 帶 100 個 unique key → 100 個 field mapping。大量 unique key 會導致 mapping explosion（field 數量爆、cluster state 膨脹、query routing 變慢）。

治理策略：

• 用 dynamic: strict 或 dynamic: false（strict = 拒絕未定義 field、false = 接受但不 index）
• 在 mapping template 明確定義已知 field，用 dynamic_templates 控制未知 field 的行為
• 對 arbitrary JSON payload 用 flattened field type（ES 7.3+）— 整個 JSON 存為 keyword，可查但不逐 key index

 1PUT _index_template/app-logs
 2{
 3  "index_patterns": ["app-logs-*"],
 4  "template": {
 5    "mappings": {
 6      "dynamic": "strict",
 7      "properties": {
 8        "@timestamp": {"type": "date"},
 9        "message": {"type": "text"},
10        "log.level": {"type": "keyword"},
11        "service.name": {"type": "keyword"},
12        "trace.id": {"type": "keyword"},
13        "metadata": {"type": "flattened"}
14      }
15    }
16  }
17}

Shard Sizing

Shard sizing 是 Elastic Stack 效能的核心變數。

目標：每個 primary shard 20-50 GB（Elastic 官方建議）。每個 data node 管理的 shard 數量上限約 20 per GB heap（預設 heap 一般設 30 GB → ~600 shard per node）。

Shard 過多的症狀：cluster state 過大（_cluster/stats 的 indices.shards.total 數千或數萬）、master node CPU 高（維護 cluster state）、recovery 慢。

Shard 過大的症狀：single shard query 慢（> 500ms for simple filter）、segment merge 時間長、recovery 時單一 shard 復原需要數分鐘。

Shard count 治理

大量 index 場景（微服務架構下每個服務每天產生一個 data stream backing index）容易累積過多 shard。一個 50 服務的組織、每個服務每天 rollover 一次、primary + 1 replica = 100 shard/day。30 天後 hot + warm tier 有 3000 個 shard。

Elasticsearch 的經驗法則是每個 data node 管理的 shard 數量上限約 20 per GB heap。30 GB heap 的 node 約能管 600 個 shard。3000 個 shard 需要至少 5 個 data node 才不觸發效能退化。

降低 shard 數量的手段：

• ILM shrink action：warm phase 把 primary shard 數量縮減（例如 3 → 1）。適合查詢頻率下降的舊 index
• 延長 rollover 週期：如果單個服務的日資料量只有 1-2 GB，每天 rollover 產生的 shard 太小。調整 rollover 條件為 max_primary_shard_size: 30gb（讓系統自動決定 rollover 時機）而非固定 max_age: 1d
• 合併小服務：QPS 很低的服務共用同一個 data stream（用 service.name field 區分），減少 data stream 數量

監控指標：_cat/health 的 active_shards 持續觀察趨勢。設 alert 在 shard count 超過 data_node_count × 500 時通知（留 buffer 給 recovery 跟 rebalance）。

故障演練與邊界

ILM rollover 沒觸發

觸發條件：ILM policy 已設定但 rollover action 沒有執行。常見原因：index 沒有正確關聯到 ILM policy、或 ILM 被暫停（_ilm/stop）。

判讀：用 GET <index>/_ilm/explain 看 ILM 狀態。managed: false 代表 index 不受 ILM 管理。step: ERROR 代表 ILM 卡在某個 action。

修復：確認 index template 的 index.lifecycle.name 指向正確的 ILM policy。如果 ILM step error，用 POST <index>/_ilm/retry 重試。

Searchable snapshot 查詢延遲高

觸發條件：cold / frozen phase 的 searchable snapshot index 被高頻查詢。

表現：query latency 從 ms 級退化到秒級。原因是每次查詢需要從 object storage（S3 / GCS）拉資料。

修復：cold phase 有 local cache、查重複 query 較快；frozen phase 無 cache、每次都拉。如果查詢頻率高到需要 sub-second 回應，這些 index 不應該在 cold/frozen phase — 調整 ILM policy 的 min_age 讓它們留在 warm phase 更久。

Cross-cluster search vs replication

Cross-cluster search（CCS）：查詢時 fan-out 到遠端 cluster。適合偶爾跨 cluster 查詢、不需要常駐複製。代價是查詢 latency 包含跨 cluster 的網路延遲。

Cross-cluster replication（CCR）：把 index 從 leader cluster 持續複製到 follower cluster。適合 DR、地理就近讀取。代價是複製的 storage 跟網路頻寬成本。

選擇判讀：「偶爾查」→ CCS。「需要低延遲讀 + DR」→ CCR。兩者可以並存。

容量與成本

Elastic Stack 的成本由三個維度決定：

License tier：Basic（免費、含 ILM / data streams）→ Gold（ML / alerting）→ Platinum（SIEM / endpoint）→ Enterprise。Elastic Cloud 的計費另加 infrastructure cost。

Data tier storage：hot tier 用 SSD（最貴）、warm tier 用 HDD 或便宜 SSD、cold/frozen tier 用 object storage（最便宜）。ILM 的 phase 設計直接影響 storage cost。

Node 數量：每增加 data node 增加 compute 成本。Shard sizing 跟 ILM 設計決定需要多少 node。

成本最佳化優先序：

1. ILM + searchable snapshot：30 天後移到 cold/frozen，storage 成本降 70-90%
2. Shard sizing：避免 shard 過多造成的 cluster overhead
3. Ingest pipeline：在 ingest 層 drop 不需要的 field，減少 index size
4. Mapping 治理：避免 mapping explosion 造成的 cluster state overhead
5. Retention policy：明確設定 delete phase，不讓過期資料佔空間

整合與下一步

• Elastic Stack 服務頁：overview 與日常操作
• 4.11 telemetry pipeline：採集 pipeline 在觀測架構中的定位
• 4.17 telemetry data quality：mapping drift 跟 field missing 的資料品質面
• 4.C3 Healthcare retention：ILM + searchable snapshot 在合規場景的應用
• Elastic Cloud migration：從自管 Elastic 遷移到 Elastic Cloud

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

5 年 ELK 集群的 lifecycle 收尾

跟前批 PostgreSQL → Aurora 同 Type C、本文用 lifecycle-driven entry — 看 5 年 ELK 集群典型壽命曲線：

多數中型 organization 在 lifecycle 第 4-5 年遇到 operational ceiling — SRE team 0.5-1.5 FTE 跑 ELK ops、新 feature 開發停滯、cost 跟 alternative observability vendor 比較。Elastic Cloud 把 operational stack 全託管、SOC 留在 Lucene query + dashboard + alert 層、不再管 cluster sizing。

為什麼遷：FTE / availability / version cadence 三條 driver

6 維 audit

Operational = High → Type C standard。

Operational redesign 對位

Migration 4-phase

Phase 0：Pre-migration audit

• 列 application 連線 endpoint (Logstash / Beats / SDK direct)
• 列 ILM policy + retention setting
• 估 deployment size（hot tier RAM / cold tier storage）

Phase 1：Elastic Cloud deployment 建置

• 選 region + provider（AWS / GCP / Azure）
• Hot tier RAM × N + cold tier S3-backed × N
• Snapshot lifecycle 配置

Phase 2：Data migration

• Cross-cluster replication (CCR) 從 self-managed → Cloud（推薦、incremental）
• 或 snapshot + restore（簡單但需要 maintenance window）

Phase 3：Cutover + cleanup

• Application 端切 endpoint
• Self-managed 端 read-only 1-2 月
• Decommission

Production 故障演練

Case 1：Application endpoint hardcode、cutover 失敗

徵兆：cutover 後 N 個 application 仍連舊 endpoint、log / metric 斷流。

根因：endpoint 寫死在 config file、deploy 時沒一起改。

修法：endpoint 用 ENV variable + service discovery、cutover 是 single deploy。

Case 2：CCR replication lag、cutover 時資料 gap

徵兆：CCR 跑 1 週、cutover 前 lag 200ms 看似 OK；application 切到 Cloud 後 search 顯示 缺最近 5 分鐘 data。

根因：CCR replication 不保證即時 catch up、cutover 期間仍可能 lag；且 follower index 對 write 不接受。

修法：

1. Cutover 流程加 drain window — 停 application write 5-10 分鐘、等 CCR catch up
2. 確認 follower index 已 promote 成 write-capable
3. 監控 CCR lag、< 100ms 才 cutover

Case 3：Auth 改變、SOC alert 失效

徵兆：cutover 後 SOC dashboard 顯示「authentication failed」、SIEM rule 全失效。

根因：self-managed 用 X-Pack basic auth、Cloud 用 API key + SSO；SOC tooling 沒改 auth。

修法：

1. Pre-cutover 列所有 tool 連線 ELK 的 auth
2. 改 API key、用 IAM-friendly token rotation
3. Cloud 端 enable SSO + 設 service account

Case 4：Cost 暴漲、cold tier 設定錯

徵兆：第一個月 Cloud 帳單比預估高 50%；cold tier 用 fast storage（hot-tier-level）而非 S3-backed。

根因：Cloud deployment template 預設 hot 是 fast、cold 也是 fast（slow 需要明示）；team 沒 review template。

修法：

1. Pre-cutover review deployment template、確認 cold tier = searchable snapshot to S3
2. Cost monitor 第一週密集 check
3. Hot tier RAM 估算 conservative

Case 5：Snapshot 跨 region 失效

徵兆：DR drill 切 region 失敗；Cloud 內建 snapshot 是 same-region、不跨 region。

根因：multi-region DR 需要 cross-region snapshot 或 multi-deployment、不是預設。

修法：

1. 評估 DR 需求、是否需要 cross-region
2. 配 additional deployment in DR region + CCR
3. Cost 增 50-100%、是 DR 投資不是 cost optimization

Capacity / cost

整合 / 下一步

跟 Splunk → Elastic Security migration 對位

兩篇都到 Elastic 生態、但 Splunk → Elastic Security 是 Schema 高差 Type A、本篇是 Operational 高差 Type C；如果同時跑兩個 migration、Splunk → Elastic Security 先、ELK Cloud 後（避免雙重變動）。

跟 Application observability stack 整合

Elastic Cloud + APM + OpenTelemetry：cutover 後可以 順便升 OTel 化 application、避免下次 vendor 切換重複工作。

相關連結

• Source vendor：Elastic Stack
• 平行 migration playbook (Type C)：PostgreSQL → Aurora / MongoDB → Atlas / Kafka → MSK
• Methodology：Migration playbook methodology