前言

有一句話是這麼說的，「懂的就懂」，大概就是拿來形容今天要介紹的東西。 你如果不是負責監管資源的人，可能只聽過這些工具，但不太深入其中的奧義。 你如果是監管人員，那肯定每天都在操作這些東西。 不過鐵人賽嘛，我都是挑我本來沒很熟但想要變熟的東西來寫，所以這篇會簡單介紹四個常見的工具。 雖然這感覺像是小學生在搜集資料，不過還是很建議一次看完，一次搞懂。

1. Prometheus / 〖專注 Metrics 時序性收容〗

官網這麼寫的：
Prometheus is a Cloud Native Computing Foundation graduated project.
Monitor your applications, systems, and services with the leading open source monitoring solution. Instrument, collect, store, and query your metrics for alerting, dashboarding, and other use cases.
使用 Apache 2 License，如同前面章節提到的，任何人可以拿他來魔改，進行商業用途的部分也不用開源。 不過不能幹走名稱作為商業使用就是了。

• 官網連結： https://prometheus.io/
• GitHub： https://github.com/prometheus

歷史

• Prometheus 最初由 SoundCloud 的工程師 Matt T. Proud 與 Julius Volz 在 2012 年左右開發。
• 當時 SoundCloud 的基礎設施逐漸走向微服務架構，現有的監控工具（如 Graphite、Nagios）無法有效應對：
  • 大量的動態服務 (Ephemeral Services)
  • 雲原生與容器化的環境
  • 需要一個更靈活的「多維度資料模型」和「強大的查詢語言」
• 他們受到 Google Borgmon（Google 內部的監控系統）的啟發，設計了 Prometheus。
• 2015 年 Prometheus 正式開源，並以 Apache 2.0 License 發布。
• 很快受到 DevOps 與 SRE 社群的關注，因為它提供了：
  • Pull-based metrics 收集模式
    • https://dev.to/mikkergimenez/why-is-prometheus-pull-based-36k1
  • 功能強大的查詢語言 PromQL
    • https://prometheus.io/docs/prometheus/latest/querying/basics/
    • https://songjiayang.gitbooks.io/prometheus/content/promql/summary.html

    這部分因為坑很大，一時半刻無法講完，未來學習建議參考上述兩個連結（官方手冊、中文電子書）來學習。

• 2016 年 5 月：Prometheus 成為 CNCF (Cloud Native Computing Foundation) 的第二個專案（第一個是 Kubernetes）。 ---> 雲原生領域的鼻祖專案
• CNCF 的加入，讓 Prometheus 在社群推廣、標準化、與 Kubernetes 的整合上快速發展。

簡介

• 定位：時序資料庫 (Time Series Database, TSDB)
• 用途：專門收集、儲存與查詢「指標數據 (metrics)」，例如 CPU 使用率、記憶體、網路流量、應用程式效能指標。
• 特點：
  • 使用 Pull model (主動抓取 metrics endpoint，例如 /metrics)
  • 查詢語言：PromQL (Prometheus Query Language)
  • 適合監控 K8s、雲原生服務
• 缺點：
  • 不適合存放 大量日誌 (logs)
  • 資料保存時間有限 (除非搭配遠端儲存方案)

    時序性資料最難搞的就是要排序，儲存是最大成本。

2. Grafana / 〖從 Dashboard 延伸觸角到觀測三本柱〗

官網宣稱：
Centralized observability managed for you for LE$$
Metrics, logs, traces, and profiles, oh my! Gazillions of pre-built solutions to try. So much to explore, with capabilities galore.
集中化的觀測管理工具，還很省錢。

Your first, last, or everything pane of glass.
Visualize & monitor almost anything. From AWS to Zabbix and everything in between, can’t get enough of your graphs, babe.
意思是，可以監控多種平台，接收各種資料來源

Dashboards out of thin air
No panel? No data? This is what it sounds like when devs cry. Good thing Grafana Assistant, an LLM agent built directly into Grafana Cloud, can fix it for you.
AI for Grafana onboarding: Get your teams started quicker with Grafana Assistant

• 官網連結： https://grafana.com/
• GitHub： https://github.com/grafana/

歷史

• 創始人：Torkel Ödegaard（瑞典開發者）於 2013 開始開發。
• 當時他在使用 Graphite 監控系統時，發現內建的 UI 不好用，於是基於 Kibana 的代碼架構，創建了一個專門針對 時序資料 (time-series data) 的視覺化工具 → Grafana。
• 「Grafana」取自「Graph」和「Kibana」，象徵它專注於繪製圖表與儀表板。
• Grafana 很快獲得 DevOps 社群的支持，因為它能以漂亮、直覺的方式呈現監控數據。不再僅限於 Graphite，開始支援更多數據來源 (InfluxDB, OpenTSDB, Elasticsearch)。漸漸成為 時序數據可視化 的標準。
• 於 2014 成立公司 Raintank（後來更名為 Grafana Labs），專注於 Grafana 的維護與相關產品開發。 開始提供 SaaS 服務與企業功能，例如： Grafana Enterprise（支援更多數據源與進階功能）、Grafana Cloud（托管服務），逐步建立 插件 (Plugins) 與 Panel 生態系。
• Grafana 並未直接進入 CNCF，但因為它與 Prometheus、Loki、Tempo 等雲原生專案緊密整合，成為 CNCF 生態系的核心工具之一。
• 於 2020 推出 Loki（日誌系統）和 Tempo（分散式追蹤系統），補齊 Observability 三大支柱 (Metrics / Logs / Traces)
  • https://grafana.com/oss/loki/
  • https://grafana.com/oss/tempo/

  因為開了公司，不能只做一種餅，所以陸續補齊了其他兩塊餅！！

• 快速理解三種工具的混搭

  Prometheus + Grafana：系統監控
  Loki + Grafana：日誌視覺化
  Tempo + Grafana：追蹤分析

• 如今的 Grafana 已不再只是 Dashboard，他們已經做出了完整的觀測性平台。

簡介

• 定位：視覺化與監控大屏工具
• 用途：將 Prometheus、Elasticsearch、MySQL、CloudWatch… 等資料來源的數據以 Dashboard 圖表 呈現，並提供 Alerting 告警 功能。
• 特點：
  • 支援多數據源 (Prometheus, Elasticsearch, Loki, InfluxDB, PostgreSQL…)
  • 適合即時監控與大螢幕展示
  • 支援警示通知整合 (Slack, PagerDuty, Email…)
• 缺點：
  • 本身 不儲存數據，僅依賴外部數據源

3. Elasticsearch / 〖搜尋引擎〗

Elasticsearch is an open source, distributed search and analytics engine built for speed, scale, and AI applications. As a retrieval platform, it stores structured, unstructured, and vector data in real time — delivering fast hybrid and vector search, powering observability and security analytics, and enabling AI-driven applications with high performance, accuracy, and relevance.

• 官網連結： https://www.elastic.co/elasticsearch
• GitHub： https://github.com/elastic/elasticsearch

歷史

• 2004 年，Shay Banon 在學習 Java 時，接觸到 Apache Lucene（一個開源的全文檢索庫）。
  • https://lucene.apache.org/
• 為了幫助妻子開發食譜搜尋應用，他建立了 Compass，一個基於 Lucene 的搜尋引擎框架。
• 2010 年，Shay Banon 重寫 Compass，將其打造為分散式、可擴展、RESTful 的搜尋引擎，命名為 Elasticsearch。 第一版於 2010 年 2 月 發布。
• Elasticsearch 提供：
  • RESTful API → 使用 HTTP + JSON 進行查詢
  • 分散式設計 → 支援水平擴展 (scaling out)
  • 全文檢索 與 聚合分析 功能
• 在 2010 ~ 2012 這段時間，逐漸成為企業和網站的 搜尋解決方案。
• 2012：Shay Banon 與團隊成立公司 Elastic (Elastic NV)，專門維護與商業化 Elasticsearch。同時推出了更完整的 ELK Stack（Elasticsearch + Logstash + Kibana）：
  • Elasticsearch → 儲存 & 搜尋
  • Logstash → 日誌收集 & 處理
  • Kibana → 視覺化 & 查詢介面
• 2015：Elastic 公司上市，股票代號 ESTC（NYSE）。
• Elastic 開始強化整體產品線，形成 Elastic Stack：
  • Beats（輕量化資料收集代理）
  • X-Pack（安全性、監控、告警、報表等功能 → 後來部分收回 Elastic License）
  • Elastic Cloud（雲端託管服務）
• Elasticsearch 逐漸從單純的搜尋引擎，演變為 資料平台，廣泛應用於：
  • 日誌管理 (Log Management)
  • 安全分析 (SIEM)
  • APM (應用效能監控)
• 授權與社群爭議 (2021)
  • 2021 年 1 月：Elastic 將 Elasticsearch 與 Kibana 的授權從 Apache 2.0 改為 Server Side Public License (SSPL) 與 Elastic License
  • 原因是擔心 AWS 等雲供應商商業化利用而未回饋社群。
  • 事件始末(AWS 說詞)： 什麼是 ELK Stack？
    • 連結網址： https://aws.amazon.com/tw/what-is/elk-stack/
• AWS 帶頭建立 OpenSearch（Elasticsearch 舊版的分支 fork），延續 Apache 2.0 開源授權。，造成 Elasticsearch 與 OpenSearch 分裂。
• Elastic 官方：持續推進 Elastic Stack，定位為 搜尋 + 安全 (Security) + Observability 三大解決方案：
  • Search → 網站內搜尋、企業搜尋
  • Observability → 日誌、APM、Metrics
  • Security → SIEM、威脅偵測
• OpenSearch：在開源社群中快速成長，尤其受到 AWS 生態支持。
• Elasticsearch 本身：仍是全球最流行的 全文檢索 & 日誌分析引擎，廣泛應用於金融、電商、雲服務、政府單位等。

當年也是好好的 OpenSearch 用一用變成 ELK，這種公司對公司的八點檔劇碼，雖然隔岸觀火很刺激，但是硬碰硬還不知道誰輸誰贏，蠻麻煩的。

簡介

• 定位：全文檢索與分析引擎
• 用途：儲存與搜尋 非結構化或半結構化資料 (例如日誌、事件、文件、JSON)。
• 特點：
  • 透過 索引 (Index) 儲存與查詢資料
  • 可進行全文檢索 (Full-text search)、聚合分析 (Aggregation)
  • 常用於 日誌分析、SIEM、安全事件追蹤
• 缺點：
  • 不適合存放高頻率、細顆粒度的 metrics (時序資料 → Prometheus 更適合)

4. Kibana / 〖原本只是搜尋引擎的皮〗

Discover, iterate, and resolve with ES|QL on Kibana
Run data analytics at speed and scale for observability, security, and search with Kibana. Powerful analysis on any data from any source, from threat intelligence to search analytics, logs to application monitoring, and much more.

• 官網連結： https://www.elastic.co/kibana
• GitHub： https://github.com/elastic/kibana

歷史

• Rashid Khan（前 Elasticsearch 工程師）。 在 2013 時正在幫助客戶用 Elasticsearch 做資料搜尋，但缺乏直覺的 視覺化介面，於是設計了 Kibana。 第一版 (Kibana v1)：主要提供基本的 log 搜尋與簡單圖表，與 Elasticsearch 搭配使用。
• 「Kibana」靈感來自 Kibana chameleon（變色龍），象徵靈活的資料呈現。
• 與 ELK Stack 的結合 (2013–2015)
• 2013：Kibana v3 發布，支援 dashboard，可讓使用者建立互動式圖表。
• 2014：Kibana v4 發布，全面改用 AngularJS 重寫，提升互動與效能。
• 與 Elasticsearch (搜尋/儲存)、Logstash (收集/處理) 一起，形成 ELK Stack。
• 2015：Elastic 公司上市（NYSE: ESTC），Kibana 成為 Elastic Stack 的官方視覺化介面。
• 2015 到 2018 間進行了許多功能擴充：
  • Dashboard、Discover（搜尋介面）、Visualize（圖表編輯器）。
  • X-Pack 插件（安全、報表、警示等企業功能）。
  • Kibana 已經不只是「Elasticsearch UI」，而是 Elastic Stack 的核心入口。
• 開始觸及更多應用的時期 (2019–2020)，Kibana 定位擴展到 Observability 與 Security：
  • Elastic Observability → 日誌、APM、Metrics
  • Elastic Security (SIEM) → 威脅偵測、事件調查
  • 逐漸演變為 Elastic 解決方案中心 (Solution Center)，不再只是圖表工具。
• 2021 的變更授權事件，Elastic 也配合改變 Elasticsearch 與 Kibana 的授權 → Elastic License / SSPL，不再是 Apache 2.0。
• AWS 領導社群建立 OpenSearch Dashboard，作為 Kibana 的開源替代方案。 從此社群出現兩個分支：
  • Elastic 官方 Kibana
  • OpenSearch Dashboards（Kibana 的開源延續版）
• Elastic 官方 Kibana： 與 Elastic Stack 深度整合
  • 主打 Search / Observability / Security 三大領域
  • 常用於 企業級 SIEM 與監控
• OpenSearch Dashboards：
  • 繼續由社群（特別是 AWS）維護
  • 保持開源授權，更適合開源社群與中小型團隊

簡介

• 定位：Elasticsearch 的可視化工具
• 用途：提供圖表、Dashboard 與查詢介面，讓使用者能方便瀏覽與分析 Elasticsearch 內的數據。
• 特點：
  • 查詢語言：KQL (Kibana Query Language) 或 Lucene
  • 適合 日誌搜尋、Security 分析、商業資料探索
  • 與 Elasticsearch 整合最緊密
• 缺點：
  • 幾乎只能用 Elasticsearch 作為數據源 (不像 Grafana 有多來源支持)

結論

開源授權會影響很多層面，但更多時候是公司與公司之間的角力。 這不太像是支持球隊，挑順眼的球員或明星支持。 比較像在挑理念接近的社群和選擇對自己有利的工具，跟選舉一樣。
在 可觀測性 (Observability) 生態中，這四個工具經常 互補使用：

1. Metrics 指標監控

   • Prometheus：收集 & 儲存 metrics
   • Grafana：以圖表與告警方式呈現 Prometheus 的數據

   → 例如監控 CPU 使用率、Kubernetes Pod 狀態

2. Logs 日誌分析

   • Elasticsearch：儲存日誌 (通常搭配 Logstash/Fluentd/Beats 收集)
   • Kibana：提供搜尋、過濾、Dashboard 分析日誌

   → 例如調查錯誤日誌、API 請求 trace

3. 整合場景

   • Prometheus + Grafana → 系統與服務監控
   • Elasticsearch + Kibana (ELK) → 日誌搜尋與分析
   • Grafana + Elasticsearch → 也可把日誌資料可視化在 Grafana Dashboard
   • 更完整的方案 → Metrics (Prometheus) + Logs (Elasticsearch) + Traces (Jaeger/Tempo) + Grafana，組成 Observability 3 大支柱

四大工具歷史時間軸對照表