ELK Stack：從經典三件套到現代可觀測性平台

Aa

在現代分散式架構與雲端環境中，系統每天產生數以億計的日誌。如何將散落各處的事件轉化為可隨時追查的資訊，是維運與後端架構的核心挑戰。ELK Stack 作為集中式日誌分析的代名詞，深刻影響了過去十多年的系統觀測生態。

不過，今天人們口中的「ELK」不一定仍是原封不動的三件套。它可能特指 Elasticsearch、Logstash 與 Kibana，也可能是團隊對 Elastic 日誌平台的習慣性簡稱，即使負責收集日誌的工具已換成 Beats 或 Elastic Agent。

先分清楚「ELK」指的是哪一種用法，才容易理解經典架構與後續產品的關係，也不會誤以為少了 Logstash 就不再算 ELK。

什麼是 ELK Stack？三個核心元件如何分工

ELK Stack 是由 Elasticsearch、Logstash 與 Kibana 三個獨立工具組成的資料處理鏈。它將各主機上的原始事件集中起來，整理成有明確欄位的資料，供工程師查詢與製作圖表。

三個元件的分工如下：

簡單來說，Logstash 整理資料、Elasticsearch 儲存與搜尋、Kibana 呈現結果。

ELK 都是開源軟體嗎？

三個工具都起源於開源專案，目前則由 Elastic 公司主導開發與發行。因此，「開源專案」不代表背後沒有公司；企業可以雇用核心開發者、決定產品方向，並同時提供免費與付費功能。

三者目前的授權也不完全相同。Logstash 維持 Apache 2.0 授權；Elasticsearch 與 Kibana 的部分原始碼則可選擇 AGPLv3、SSPL 1.0 或 Elastic License 2.0，官方預設發行版採用 Elastic License 2.0。

其中 AGPLv3 是開放原始碼促進會（OSI）認可的開源授權，但 SSPL 與 Elastic License 2.0 並未獲 OSI 認可。這也是為什麼「看得到原始碼」不一定等同於「採用開源授權」。

所以，將 ELK 籠統稱為「三套開源軟體」並不夠精確。更準確的說法是：它們都源自開源生態，也由 Elastic 主導發展，但各元件與官方發行版的授權條件不盡相同。本文稍後的「授權分岔與生態演進」一節，會再說明 2021 年的授權轉折，以及 OpenSearch 為何因此誕生。

經典三件套的資料流：以 Nginx 日誌定位問題為例

為了理解三元件如何協同運作，我們以經典架構下的 Web 服務存取日誌為例。單台主機的文字紀錄容易閱讀，但在數十台伺服器同時運作時，唯有集中與結構化才能支援跨主機分析。

 [ 資料來源：Nginx / App / Syslog ]
               | 原始事件
               v
 [ Logstash：輸入 -> 處理 -> 輸出 ]
   - Input：file、syslog、beats
   - Filter：grok、mutate、date
   - Output：elasticsearch
               | 結構化文件
               v
 [ Elasticsearch：叢集與儲存 ]
   - 反向索引與列式儲存
   - 分散式搜尋與聚合運算
               | 查詢結果
               v
 [ Kibana：視覺化與分析 ]
   - Discover / Dashboard / 告警

從告警到定位：具體操作流程

假設線上系統發出 HTTP 500 錯誤率上升的告警。在沒有集中日誌的傳統環境中，值班工程師必須逐台登入主機、執行 tail 或 grep；一旦容器重新啟動，現場紀錄甚至可能直接遺失。

在經典 ELK 流程中，工程師可以透過查詢日誌來定位問題：

  1. 解析日誌欄位：Logstash 接收日誌文字，透過 Grok 模式將未結構化字串解析為 status、request_path 與 duration 等欄位；host 等主機資訊則可能由 Beats 等採集端一併附加。
  2. 篩選告警時段：工程師在 Kibana Discover 將時間範圍鎖定在告警區間；Elasticsearch 依 @timestamp 從已索引的資料中篩出相關事件。
  3. 依路徑與主機分組統計：先篩選出 status >= 500 的事件，再以 request_path 與 host 即時分組，迅速發現錯誤全數集中在特定主機的 /api/checkout 端點。

ELK 的核心價值，是讓工程師能在同一個介面查詢分散在各主機、格式不同的日誌，並交叉比對來找出問題。

Grok 如何把一行日誌拆成欄位？

Grok 是 Logstash 用來從文字中擷取欄位的篩選器。可以把它想成一組「有名稱的正規表示式積木」：IP、NUMBER、HTTPDATE 等內建模式各自負責辨識一種常見格式，工程師再將它們組合起來，不必從頭撰寫一大串難以閱讀的正規表示式。

Grok 不會自行猜測每段文字的意思。工程師仍要依照日誌格式指定哪一段是 IP、時間、請求路徑或狀態碼，並替擷取結果命名。假設 Nginx 產生以下存取日誌，其中最後一個數字代表以秒計算的請求處理時間：

 203.0.113.7 [22/Sep/2026:14:32:10 +0800] "POST /api/checkout HTTP/1.1" 500 842 0.731

對應的 Grok 模式可以寫成：

 %{IP:client_ip} \[%{HTTPDATE:timestamp}\] "%{WORD:http_method} %{URIPATHPARAM:request_path} HTTP/%{NUMBER:http_version}" %{NUMBER:status:int} %{NUMBER:bytes:int} %{NUMBER:duration:float}

%{IP:client_ip} 表示以內建的 IP 模式比對文字，並將結果存入 client_ip；%{NUMBER:status:int} 則辨識數字、命名為 status，再轉為整數。Logstash 依此產生結構化事件：

{
  "client_ip": "203.0.113.7",
  "http_method": "POST",
  "request_path": "/api/checkout",
  "status": 500,
  "bytes": 842,
  "duration": 0.731
}

接著，date filter 可以把原始時間轉成標準的 @timestamp。若某行日誌不符合 Grok 模式，預設會被標記為 _grokparsefailure，工程師便能另外檢查格式例外。

這個過程並非讓 Logstash 理解日誌的意思，而是依照已知格式，把每段文字擷取並命名。原本只能閱讀的字串因此成為可以篩選、分組與聚合的欄位。

演進歷程：從獨立專案到 Elastic 平台

ELK 並非由單一團隊預先規劃的套裝軟體，而是三個解決不同痛點的開源專案在發展過程中逐步靠攏的成果。

 2010 前後
 [Elasticsearch] -+
 [Logstash     ] -+--> [ELK Stack]  (2013, 同一家公司)
 [Kibana       ] -+        |
                           v
                    [Elastic Stack]  (2016, 5.0 / Beats)
                           |
                           v
                    [授權變更]  (2021, OpenSearch 分岔)
                           |
                           v
                    [增設 AGPLv3]  (2024)

三個獨立專案的整合

2010 年前後，三個元件各自以獨立開源專案誕生。Elasticsearch 是以 Apache Lucene 為核心的分散式搜尋引擎，將 Lucene 的搜尋能力封裝成可透過 RESTful API 與 JSON 操作的服務。Logstash 確立了「Input ➔ Filter ➔ Output」管線模型。Kibana 則專為 Elasticsearch 提供視覺化查詢介面。

2013 年，三項專案的主要維護者都加入了同一家公司，「ELK Stack」架構自此確立，迅速成為集中式日誌分析的產業標準。

從 Beats、Elastic Stack 到 Elastic Agent

早期常見的做法，是在每台伺服器上啟動 Logstash，持續讀取本機日誌檔新增的內容，解析後再傳送至 Elasticsearch。問題在於每台主機都要常駐一個功能完整的 Logstash JVM 行程；即使只用來搬運日誌，也會占用記憶體與 CPU。

官方隨後推出各自負責特定資料類型的輕量採集工具 Beats（如 Filebeat、Metricbeat）。2016 年，官方將各元件版本統一為 5.0，正式定名為 Elastic Stack。

主機數量增加後，逐一管理 Beats 設定檔也變得費力。近年官方推出 Elastic Agent，以單一 Agent 整合多種採集能力，搭配 Kibana 中的 Fleet 集中派送設定與管理升級；Logstash 則移到後端，專責整併不同來源的資料，以及複雜的資料擷取、轉換與載入（ETL）。

平台涵蓋的資料也逐步超出日誌。Elastic Agent 可以收集日誌（logs）、指標（metrics）與追蹤資料（traces），Kibana 則從早期的視覺化介面，擴張為探索資料、設定告警及管理可觀測性與安全功能的共同入口。

換句話說，Elastic Stack 並不是在 ELK 後面不斷加上新工具而已，而是從固定的三段式日誌管線，轉變成一組可以依資料來源與處理需求搭配使用的工具。

授權分岔與生態演進

2021 年，Elastic 將授權從 Apache 2.0 改為 SSPL 與 Elastic License 雙授權，AWS 隨即主導從既有程式碼分岔出 OpenSearch。2024 年，Elastic 宣布為原始程式碼增設 AGPLv3 開源選項。

NOTE

延伸閱讀：IaC 與 Terraform 三十年興衰史

優勢與代價：採用前要考量什麼？

ELK 提供靈活的搜尋與分析方式，但也需要相應的硬體資源與維運投入。

不只集中日誌：同一套資料鏈能做什麼？

集中式日誌仍是 ELK 最直觀的用途：Web Server、應用程式、作業系統與網路設備的事件被整理成共同欄位後，工程團隊便能在同一條時間軸上搜尋、比對部署前後差異，並建立容量趨勢與稽核查詢。

安全團隊也能以相同方式處理登入失敗、權限變更、防火牆與端點事件；產品點擊流、交易事件等時間序列資料，同樣可以送入這條資料鏈分析。

現代 Elastic 平台也將指標與追蹤資料整合到同一個查詢介面。工程師收到延遲告警後，可以查看相關請求經過哪些服務、各花了多少時間，再用 request ID 回查應用程式日誌。

這不代表所有資料都要經過 Logstash 或套用完全相同的索引策略，而是讓日誌、指標與追蹤資料能透過共同欄位與時間範圍相互對照。從「集中看 Log」走到「跨訊號追查問題」，正是 ELK 演變為可觀測性平台的關鍵一步。

核心優勢

必須面對的維運代價

成本也不只發生在叢集啟動當下。團隊還要決定哪些欄位需要索引、資料要保留多久、何時轉入較低成本的儲存層，以及如何處理備份、升級、權限與故障復原。採用託管服務可以轉移部分主機與升級工作，卻不會消除資料量、索引策略與保留政策帶來的成本。

為了降低這些儲存與維運成本，後來出現了更多適合雲原生環境的輕量日誌方案。

ELK 過時了嗎？從現代架構看它的角色

評估 ELK 是否仍適用，要分開看兩件事：過去的部署方式是否合適，以及它解決的問題是否仍然存在。

過去「每台主機必跑 Logstash、所有日誌全文索引」的重型做法，已不再是多數團隊的預設選擇；但「收集、正規化、保存、檢索與視覺化」的核心需求從未改變。在今日的觀測體系中，資料流向有了更多現代化的路徑選擇。

現代資料流不一定經過 Logstash

經典 ELK 把 Logstash 放在唯一入口，但現代架構會依處理複雜度選擇不同路徑。格式穩定、只需基本欄位轉換的資料，可以由 Elastic Agent、Beats 或應用程式直接送進 Elasticsearch，再由 Elasticsearch 內建的 ingest pipeline，在寫入前解析或轉換欄位。

需要跨來源整併、複雜條件轉換或同時輸出至多個目的地時，才讓 Logstash 承擔中央處理角色。

OpenTelemetry Collector 又提供另一種入口：應用程式可以先以通用標準產生與收集 logs、metrics、traces，再把資料送往 Elastic 或其他後端。

OpenTelemetry 解決的是遙測資料如何產生、收集與匯出，Elasticsearch、OpenSearch 或 Loki 解決的則是如何保存與查詢；兩者位於不同層級，不是只能擇一的競爭產品。

 [ 資料來源 ]
       |
       v
 [ 採集層：Elastic Agent / Beats / OTel Collector ]
       |
       v
 [ 處理層（依需求）：Logstash / ingest pipeline ]
       |
       v
 [ 儲存與查詢後端：Elasticsearch / OpenSearch / Loki ]
       |
       v
 [ 探索與視覺化：Kibana / OpenSearch Dashboards / Grafana ]

實際架構不必包含每一層，也不是所有工具都能任意互接；團隊會依採集方式、轉換需求與後端支援選擇路徑。

現代觀測生態中的定位對照

方案核心機制與定位適用情境與取捨
Elasticsearch / Elastic Stack反向索引 + 供聚合使用的磁碟列式結構，涵蓋日誌、指標與追蹤的全功能觀測平台支援任意全文檢索與多維即時聚合；儲存與 Java 叢集維運成本較高
OpenSearch從 Elasticsearch 7.10.2 分岔出的開源分支，維持同源分散式架構適合需維持 Apache 2.0 授權相容性或深度整合 AWS 託管服務的團隊
Grafana Loki僅對標籤（Labels）建索引，日誌本體壓縮存放於物件儲存（如 S3）適合以較低成本長期保存雲原生容器日誌；查詢時先以標籤縮小範圍，再逐行掃描日誌內容，不適合複雜全文探查
OpenTelemetry（OTel）業界通用的遙測標準與工具，專注於資料的產生、收集與匯出統一採集層，可串接 Elastic、Loki 等各類後端，降低供應商鎖定

先看查詢方式，再選擇後端

ELK 的優勢在於，工程師即使事前不知道問題出在哪裡，也能從錯誤訊息開始全文搜尋，再依服務、版本、主機與狀態碼逐步縮小範圍。若事故調查經常需要這種探索式查詢，資料又來自格式各異的系統，Elasticsearch 的全文索引與多維聚合就有明確價值。

反過來說，若資料格式一致、查詢大多圍繞少數已知標籤，而且主要目標是用較低成本長期保存大量 Kubernetes 日誌，完整索引所有內容可能並不划算。這時 Loki 之類以標籤索引搭配物件儲存的設計，往往更貼近實際需求。

因此，選型前應先回答幾個問題：各來源的資料格式差異多大？是否需要任意全文搜尋？常用查詢能否先用標籤縮小範圍？資料要保存多久？團隊是否有能力統一欄位格式，並管理索引從建立到分層儲存、刪除的生命週期，以及備份與升級？這些答案比「哪一套工具比較新」更能決定合適的架構。

結論：依查詢需求與維運能力選擇

今天談論「ELK」，可能指 2013 年成形的經典三件套，也可能指現代 Elastic 平台。它所建立的收集、儲存與查詢分工，仍是理解集中式日誌分析的基礎。

在做現代技術架構選型時，建議依據以下原則決策：

理解經典 ELK 從收集、處理到查詢的分工，再對照今天各元件能做什麼，就能依團隊需求組合出合適的觀測架構。

  1. Google《Site Reliability Engineering》導讀（上）
  2. Ansible 演進史（上）：Agentless、YAML 與 Red Hat 收購
  3. Kubernetes 演進史（上）：Borg、編排之戰與 Docker