ELK 替代與遷移指引

評估 ELK 替代方案：先保留有效資產，再驗證遷移範圍

協助正在運行 Elasticsearch、Logstash、Kibana 或 EFK 的團隊，以收集、解析、Index Lifecycle、查詢、權限、保留、雙寫及回滾準則比較自建、共存或遷移。

觀測雲技術市場團隊約 9 分鐘 3項官方資料

本文由評估選項之一的觀測雲發布。結論只建基於截至 2026-08-17 的官方公開文件；本文未進行相同工作負載的跨產品效能或價格測試。

查看日誌管理平台

範圍備註： 本文比較營運責任與遷移方法，不比較未以相同工作負載驗證的價格、吞吐量或查詢效能。

  • Pipeline 與 Field Mapping
  • Index Lifecycle
  • 雙寫與回滾
  • 日誌與 Trace 關聯
觀測雲日誌 Index 與保留策略設定介面
產品證據

比較搜尋介面前，先核對 Field、Index、保留、權限及復原路徑。

直接結論

運作穩定且責任清楚的 ELK，毋須純粹為更換平台而重建

若團隊能持續管理收集、Pipeline、Shard、Index Lifecycle、備份、權限及警報，保留 ELK 往往風險較低。當維護責任、管治，或由日誌前往 Trace、Metrics、Kubernetes 的調查路徑長期受阻，才應啟動保留原路徑的共存 PoC。

較適合繼續自建

  • 有平台團隊負責容量、升級、備份及故障
  • Pipeline、Template、ILM、Query 及 Alert 已標準化
  • 需要深入控制 Elasticsearch 設定或 Plugin

值得評估共存或遷移

  • 日誌平台維護持續佔用 SRE 核心工作
  • Field、權限、保留及成本政策難以跨團隊管治
  • 調查仍要人手拼接日誌、Trace、Pod、Host 及 Release

評估準則

選擇目的地前先訂立驗收準則

列出 Filebeat、Fluent Bit、Fluentd、Logstash、Elastic Agent 及自訂輸入的路徑與負責人

匯出 Pipeline、Mapping、Template、Data Stream、ILM、Shard、Replica 及 Archive 設定

以相同日誌樣本比較解析、時間、查詢、Alert、權限及刪除結果

以書面確認香港／澳門的合約、幣別、稅項、支援、Data Location、審計、保留及 Export

預先定義雙寫時期、同等準則、停止條件、回滾入口及歷史資料範圍

決策矩陣

以相同責任比較自建與分階段遷移

在較小螢幕可橫向捲動此表格。

決策範圍
繼續自建 ELK / EFK
與觀測雲共存或遷移評估
營運責任
自行管理 Cluster、Shard、Index、升級、備份及故障
使用觀測雲已公開的服務邊界，團隊仍管理收集與資料政策
現有資產
原樣保留 Pipeline、Index、Query、Alert 及 Kibana 流程
保留原收集路徑，先驗證外部 Index 或雙寫流程
調查範圍
以 Elasticsearch 內的日誌及文件搜尋為主
驗證日誌能否連接 Trace、Metrics、Service、Pod、Host、RUM 及 Event
退出風險
沒有遷移專案，但現有營運技術債仍然存在
達到同等與回滾準則前，保留原路徑及 Export 方法

把「ELK」拆成實際生產路徑

Elastic 將 Ingest Pipeline 定義為建立 Index 前的轉換與補充，ILM 則管理 Index Lifecycle。遷移清單必須保存這些規則所承載的業務語義。

  • 按資料來源記錄輸入、解析、路由及失敗處理
  • 核對 Field Type、Timestamp、Data Stream 及 Index 命名
  • 找出依賴 Kibana Query、Dashboard 及 Alert 的團隊

以雙寫證明同等性，不以示範代替驗收

選一個具代表性的 Service 及日誌類型，在不停止原 ELK 的情況下送往候選平台。若暫時未能遷移，可先驗證官方文件說明的外部 Index 路徑。

  • 比較解析、時間、Label、遮罩及重複資料
  • 重播常用 Query 及 Alert 並保存差異
  • 觀察遺失、延遲、Retry 及權限越界

只有證據鏈變短，才值得擴大範圍

驗收不應停在「日誌可搜尋」。由錯誤日誌開始，確認能否在同一調查內前往 Trace、Service、Pod、Host、Release 及使用者影響。

  • 重播自身 Postmortem 的事故
  • 記錄工具切換與複製識別碼次數
  • 通過後才擴大資料來源、保留及使用團隊

遷移路徑

由一個可回滾的日誌來源開始

  1. 凍結收集、Pipeline、Index、ILM、權限、Alert 及依賴清單
  2. 雙寫一個 Service，同時維持原 ELK 路徑
  3. 比較 Field、Timestamp、Query、Alert 及權限
  4. 重播真實事故，由日誌前往 Trace、Pod、Host 及 Release
  5. 核准驗收、停止及回滾條件後才擴大範圍

常見問題

選型與遷移常見問題

觀測雲可以直接替代 ELK 嗎？

不能單憑產品名稱判斷。須逐項驗證收集、解析、Index、搜尋、Alert、權限、保留、Export 及關聯，遷移期間亦要保留 ELK 回滾路徑。

甚麼情況不應遷移 ELK？

若現有系統穩定、責任清楚、成本可控，而且跨遙測調查並非瓶頸，遷移工作與風險可能高於收益。

ELK 遷移最常遺漏甚麼？

Field Type、時間語義、Pipeline、ILM、權限、Alert 依賴、已儲存 Query 及 Export 要求，往往比基本寫入更容易遺漏。

歷史日誌是否必須第一天全部遷移？

不需要預設。先確認法規、調查及成本要求，再選擇保留舊 Cluster、外部 Index 存取、分階段 Backfill 或只遷移新資料。

下一項決策

繼續核實相關能力

日誌管理平台核實收集、解析、保留、權限、遮罩及管治。 Pipeline 資料處理核實擷取、轉換、過濾及敏感資料處理。 日誌監控由搜尋及 Alert 前往 Trace、Service 及 Resource。

下一步

把現有 ELK 清單轉成可回滾 PoC

準備收集路徑、每日資料量、Pipeline、Index、保留、權限、Alert 及真實事故，一起訂立驗證及回滾邊界。