# Open Source Observability

## 第一章〈The Evolution of Observability（可觀測性的演進）〉主要探討可觀測性（Observability，簡稱 O11y）的發展歷程、傳統架構的限制，以及現代觀點（稱為 Observability 2.0）所帶來的變革。以下是本章的重點整理與說明：

---

### 🔍 可觀測性是什麼？

可觀測性是透過系統所產生的資料，來理解其內部狀態的能力，包含：

* 偵測與診斷問題
* 優化效能
* 維持系統穩定性與安全性
* 持續改善系統與程式碼架構

它不只是技術工具，而是一種「社會技術概念（sociotechnical concept）」，與組織文化、開發流程、除錯與部署方式息息相關。

---

### 🏛️ 傳統的可觀測性堆疊（Observability Stack）

過去以「三大支柱」為主（Peter Bourgon 在 2017 年提出）：

1. **Metrics（指標）**：例如 CPU 使用率、記憶體、延遲等。
2. **Logs（日誌）**：系統行為的記錄，可結構化或非結構化。
3. **Traces（追蹤）**：跨系統的請求流程，例如分散式架構下的 API 呼叫流程。

後來演進為 MELT 模型，加入：

* **Events（事件）**：如系統溫度過高觸發的警報等。

---

### ❗ 傳統堆疊的限制

* 各支柱使用不同工具、資料庫與查詢語言（如 PromQL、LogQL、TraceQL），導致分析時資料無法整合。
* 工具之間無法協作，使用者需自行串接（高成本）。
* 資料儲存分散、查詢效率低、成本高、整合困難。

---

### 🌐 Observability 2.0：解構與整合

由 Honeycomb 的 Charity Majors 推廣的一種新思維，特點如下：

1. **不再強調支柱**，改用「廣泛結構化資料（wide structured events）」。
2. 所有訊號（metrics、logs、traces）都可從單一來源導出，建立「單一真實資料來源（single source of truth）」。
3. 利用統一的資料模型與查詢語言，打破資料孤島。
4. 推動開放標準如 OpenTelemetry（OTel）來統一資料收集、格式與傳輸協議。

---

### ⚠️ 當前的挑戰與過渡

* 現有工具多數仍基於 Observability 1.0 設計。
* OTel 在不同訊號類型的支援程度不一（例如追蹤支援較成熟）。
* 市場上仍有許多廠商利用開源包裝成封閉解決方案，用戶需謹慎選擇。

---

### 📈 小結

第一章總結了從監控（Monitoring）進化為可觀測性的歷程，並強調：

* 傳統做法難以應付現代分散式系統與巨量資料需求。
* Observability 2.0 提供以資料為核心的整合觀點。
* 開源與開放標準是關鍵，讓用戶能避開封閉生態系的綁架。

如果你希望我幫忙用圖示或表格整理這章內容，也可以告訴我！

## 第二章〈Key Benefits of a Disaggregated Stack（解耦式堆疊的主要優勢）〉探討將可觀測性架構「解耦」的好處，也就是將傳統一體式平台分拆成獨立模組（資料收集、儲存、查詢、視覺化等），讓每一層都可以自由選擇最佳工具。以下是本章的重點整理：

---

### 🧱 為什麼要解耦觀測堆疊？

傳統可觀測性平台常常是「整包買斷式」，例如：

* 工具只能一起使用（無法拆開）。
* 儲存與視覺化綁定在特定廠商上。
* 成本高、彈性低，遷移困難。

而「解耦式架構」允許使用者自由選擇每一層的最佳組件，像組裝 IKEA 家具一樣，自由度更高。

---

### ✅ 解耦式架構的三大優勢

#### 1. **彈性與客製化（Flexibility and Customization）**

* 可混搭開源、商用、SaaS、on-prem 等不同部署形式。
* 所有 OTel 元件皆支援統一協議 OTLP（使用 Protobuf，可走 HTTP/gRPC）。
* 可選擇是否使用 OTel Collector 作為中介層（集中管理/轉送資料）。

📌 例如：

* 用 Apache Pinot 儲存資料
* 用 Grafana 顯示
* 用 OTel Collector 收集不同來源資料

---

#### 2. **資料主權與可重複利用（Data Autonomy and Reusability）**

* 很多商業觀測工具會要求你「上傳資料到他們雲端」，產生：

* 數據外洩風險
* 雲端出口費用（egress cost）
* 違反資料地區法規

🟡 解耦式架構允許：

* 「自己選擇資料儲存地點」
* 使用 BYOC（Bring Your Own Cloud）方式部署
* 避免被某家廠商綁住或限制資料用法

---

#### 3. **可擴展與成本效益（Cost-Effectiveness in Scaling）**

隨著資料量暴增（例如 Uber 每秒處理數百萬筆 metrics），傳統做法不敷使用：

* 有些公司因為成本壓力只能保留幾天的資料
* 有些資料收集了卻從未查詢（稱為 WORN：Write Once, Read Never）

📉 解法：

* 使用分層儲存（Tiered Storage）：熱門資料放在高效能儲存，冷資料移至便宜的 S3
* 避免資料被高查詢成本「逼得不敢用」
* 使用支援預測性計價的系統，以利預算控制

---

### 📌 備註

圖 2-1 清楚比較了「傳統封閉堆疊」與「解耦式堆疊」的差異，後者具有更多彈性與模組化的能力。

---

### 📘 小結

「解耦式可觀測性堆疊」雖然可能需要更多整合與維運成本，但它提供了：

* 更高的靈活性與控制權
* 更佳的資料治理
* 更具可預期的成本管理能力

這也是越來越多大型企業和平台工程團隊轉向開放、組合式架構的原因。

---

## 第三章〈Core Layers of a Disaggregated Stack（解耦式堆疊的核心層級）〉深入介紹了解耦式可觀測性架構中三個主要層級的功能與實作方式，分別是：

1. **資料收集層（Instrumentation, Agents, and Data Collection）**
2. **儲存與查詢層（Storage and Query Mechanisms）**
3. **視覺化與自動化層（Visualization, Analysis, and Automation Tools）**

---

### 1️⃣ 資料收集層：Instrumentation, Agents, and Data Collection

#### ✨ 核心概念

* **Instrumentation（儀器化）** 是系統產生 telemetry 的基礎。
* 收集方式從早期的 **批次（batch）上傳**，演進為現在的 **即時（streaming）傳送**。
* 現代架構要求能即時收集並彈性轉發資料，例如使用 Apache Kafka。

#### 📦 工具範例與差異

* **Fluentd / Fluent Bit**：擅長收集日誌（logs），特別適合 Kubernetes。
* **Jaeger**：專注於 trace 收集。
* **OTel Collector**：通用代理層，可收集、轉換、轉送所有類型 telemetry。

#### 🛠️ 關鍵技術

* **eBPF**：一種高效能內核層級觀測工具，現也納入 OTel 生態。
* OTel 並非唯一解，也可自建符合規範的 agent（例如 Byte Buddy 實作）。

---

### 2️⃣ 儲存與查詢層：Storage and Query Mechanisms

#### 🧩 核心觀點

* 傳統觀測平台「封裝」了儲存引擎，但解耦式架構允許自選最適合的資料庫。
* 各種 telemetry 有不同資料型態：time series、text、blob，對儲存引擎要求不同。

#### 💡 架構型態分級

| 類型 | 說明 |
| --------------------- | ----------------------------------------------------- |
| **Observability 1.0** | 三種 telemetry 各自使用不同系統與語法（如 Prometheus + Loki + Tempo） |
| **Observability 1.5** | 將資料儲存於同一資料庫中不同表格，用 JOIN 串接 |
| **Observability 2.0** | 使用單一「wide event log」表格，從中推導 metrics、logs、traces |

#### 🧵 Query 統一化挑戰

* 現存語言（如 PromQL、LogQL、TraceQL）不一致。
* CNCF 正在推動統一查詢語言語意（Semantic DSL），但仍在發展中。

---

### 3️⃣ 視覺化與自動化層：Visualization, Analysis, and Automation Tools

#### 📊 傳統工具

* **Grafana / Kibana**：主流可視化工具
* **OpenSearch Dashboards**：Kibana 的開源分支
* **Flame Graph**：常用於效能分析

#### 🤖 自動化與智能反應

* 目標是 **主動辨識異常 → 自動處理**（如 Kubernetes 自動重啟 pod）
* 可與 Prometheus Alertmanager 等結合實現自動擴展、錯誤修復

#### 🛑 還需人為介入？

* 有些情境仍需人工確認、審核變更
* 當前階段偏向「人機協作」，而非完全 AI 驅動

---

### 📌 小結

| 層級 | 說明 | 工具示例 |
| ------- | ---------------------------- | -------------------------------------- |
| 資料收集 | Agent 收集 metrics/logs/traces | OTel Collector、Fluent Bit、Jaeger |
| 儲存查詢 | 儲存與查詢不同格式的資料 | ClickHouse、Apache Pinot、Trino |
| 視覺化與自動化 | 呈現、分析與觸發警報或行動 | Grafana、Kibana、Prometheus Alertmanager |

這三層組合起來就是解耦式觀測堆疊的主幹。使用者可針對需求，自行選擇替代工具組裝自己的觀測平台。

---

## 第四章〈Implementing the Collection Layer（實作資料收集層）〉專注於如何在可觀測性系統中有效建立與擴展資料收集層，特別是對於大規模系統（如企業級環境）如何應對資料量與多樣性的挑戰。以下是重點整理與說明：

---

### 🏗 為什麼要建立資料收集層？

小型應用可能可以直接將 telemetry 寫入資料庫，但對於大型組織來說：

* **資料來源眾多**（e.g., 上千台機器）
* **資料量巨大**（每秒數百萬筆事件）
* 必須考慮可擴展性、穩定性與處理效能。

因此建議使用 **Collector（收集器）** 搭配 **Streaming System（資料串流系統）**。

---

### 1️⃣ 架構模式：三種部署型態

| 模式 | 說明 |
| ---------------- | ----------------------------------- |
| **直接寫入** | Agent → 資料庫（適合開發環境） |
| **Collector 模式** | Agent → OTel Collector → 資料庫 |
| **Streaming 模式** | Agent → Collector → Kafka（等）→ 多個消費者 |

📌 OTel Collector 可以運作在：

* **Agent 模式**：部署在應用主機上，近距離收集
* **Gateway 模式**：集中式部署，彙整多個來源

---

### 2️⃣ 如何管理資料量與種類（Managing Data Volume and Variety）

#### ✂️ 降低資料量的方法

* **刪減不必要的 Metrics**
* **控制 Cardinality（例如：過多 tag 造成維度爆炸）**
* **Sampling 抽樣策略**：

* Head Sampling（追蹤一開始就決定是否收）
* Tail Sampling（根據結果決定是否收，如錯誤事件）

#### 📦 多樣性挑戰

不同資料類型有不同儲存與傳輸需求：

##### 📊 Metrics

* 常見格式為 JSON：`timestamp + metric_name + value + labels`
* Label 動態變化大，會造成：

* JSON 解析複雜
* 維度膨脹，查詢與儲存效能下降

##### 📜 Logs

* 容量巨大（大型企業常達 Petabyte 等級）
* 結構多變（純文字、JSON、半結構）
* 大多數仍為非結構化，查詢困難、成本高
* Uber 的 Healthline App 使用 Apache Pinot 處理即時異常偵測

##### 🔍 Traces

* 為多層級 Spans 的巢狀結構（類似樹狀呼叫圖）
* 大型 trace 可包含上百萬 spans
* 儲存與查詢都需支援巢狀結構與圖遍歷

---

### 3️⃣ Streaming Systems（串流系統）

用於處理高吞吐、低延遲的資料流，常見工具包括：

* **Apache Kafka**（最廣泛）
* **Apache Pulsar**
* **Amazon Kinesis**
* **Redpanda**
* **Confluent**

作用：

* 提供「耐久性、擴展性、高可靠性」
* 支援「一對多」資料傳遞（如：儲存、即時分析、備援）

---

### 4️⃣ Stream Processing（串流處理）

#### ✨ 處理選項：

* 在 **OTel Collector** 層進行轉換／強化（如 enrich metadata）
* 使用 **Flink / Storm** 等進行進階分析（例如錯誤率計算、聚合）

應用範例：

* 在 Flink 中針對 Kafka event stream 實作動態條件篩選
* 在 Collector 中進行 metrics 的轉換（metrics transform processor）

---

### 🔚 小結

| 面向 | 重點 |
| ----- | --------------------------------- |
| 架構選擇 | 小型可省略，中大型建議加 Collector + Kafka |
| 處理策略 | Sampling、Label 控制、Tiering |
| 工具組合 | OTel Collector、Kafka、Flink |
| 多樣性應對 | Logs、Metrics、Traces 分別處理邏輯與查詢特性不同 |

---

## 第五章〈Optimizing Storage and Query for Performance（優化儲存與查詢效能）〉深入探討在解耦式可觀測性架構中，如何選擇與設計儲存後端與查詢機制，以處理大量、高維度且結構多樣的 telemetry 資料。以下是完整解說與重點整理：

---

### 🧱 儲存選擇多元化：依據資料類型與使用情境

#### 🔹 傳統對應關係（Observability 1.0）：

| 資料類型 | 常用儲存引擎 |
| ------- | ------------------------------------- |
| Metrics | Prometheus、InfluxDB、Timescale |
| Logs | Elasticsearch、OpenSearch、Grafana Loki |
| Traces | Jaeger、Tempo、Hypertrace |

📌 問題在於這些工具彼此獨立，資料無法交叉查詢，增加了管理與分析的難度。

---

### 🚀 新趨勢：支援「多種資料」的分析型資料庫

#### ✅ Apache Pinot、ClickHouse 等新興資料庫

* 可支援 metrics、logs、traces 同時儲存與查詢
* 適合實現 Observability 1.5 或 2.0 架構
* 提供高速查詢、壓縮與索引能力

📦 例如：

* Jaeger 可改用 ClickHouse 做儲存（效能更佳）
* 也有直接將 Jaeger agent 的資料串流進 Apache Pinot 的做法

---

### 🎯 儲存與查詢的挑戰與最佳化策略

#### 1. **高基數（High Cardinality）**

* 指欄位中的唯一值數量非常多（如：UserID、PodID、SessionID）
* 常見於：微服務架構、用戶行為分析、K8s 監控

➡️ 解法：使用**近似統計算法**

* 如：HyperLogLog、Theta Sketch、CPC Sketch（Apache Pinot 支援）

---

#### 2. **高維度（High Dimensionality）**

* 指一筆資料包含大量屬性（Attributes/Labels）
* 例子：每台手機可記錄地點、型號、OS版本、記憶體、電量等多種屬性

➡️ 解法：資料建模時需合理「扁平化」、善用壓縮與欄位類型優化

---

#### 3. **JSON 結構的挑戰**

* 現代 telemetry 常以 JSON 格式傳送，具巢狀、多層級、動態欄位特性

➡️ 解法：

* Apache Pinot 提供 JSON 索引（加快查詢）
* 使用專門的 SQL 擴充語法處理巢狀結構

---

### 🧠 索引（Indexing）最佳化技巧

| 索引類型 | 用途 | 備註 |
| --------------- | ---------------------- | -- |
| Forward index | 最常見，基礎查詢使用 | |
| Inverted index | 適合文字查詢（如 log） | |
| Timestamp index | 適合時間序列資料（如 metrics） | |
| Star-tree index | 適合聚合查詢（例如 latency 平均值） | |
| JSON index | 加快巢狀資料的 key 查找效率 | |

🔧 注意：高基數欄位不適合使用字典編碼，應改用 raw index 儲存。

---

### 🗜️ 壓縮技術（Compression）

* 壓縮不只省空間，也能加快查詢（較少 I/O）
* 例子：

* **CLP（Compressed Log Processor）**：Apache Pinot 提供，針對大量重複性 log 設計
* **位元壓縮 + 字典編碼**：適合低基數欄位

---

### 🔚 小結與選型建議

| 面向 | 建議 |
| ---------- | ---------------------------------- |
| 多種資料類型混合查詢 | 使用 Apache Pinot 或 ClickHouse |
| 高基數欄位 | 使用近似算法（HyperLogLog、Theta Sketch 等） |
| 查詢效能 | 善用索引（JSON、Star-tree、Timestamp） |
| 儲存成本 | 使用壓縮、分層儲存 |
| 架構發展 | 從 1.0 → 1.5 → 2.0 漸進式過渡 |

---

## 第六章〈Best Practices for Visualization（視覺化的最佳實踐）〉聚焦在如何有效呈現可觀測性資料，使人或系統能快速理解與反應。這章強調工具選擇、整合能力、可擴充性，以及授權考量等實務面議題。以下是詳細解析：

---

### 🎯 為什麼視覺化這麼重要？

視覺化不只是畫圖，它的目的是：

* 幫助人類或系統「觀察異常、理解趨勢」
* 驅動**主動反應**或**自動調整**
* 是觀測資料的「最後一哩路」

---

### 🧰 常見的開源視覺化工具

| 工具 | 特點 |
| ------------------------- | ------------------------ |
| **Grafana** | 多種資料來源、自由度高、現代觀測主流 |
| **Kibana** | 傳統 ELK Stack 一部分，適合 logs |
| **OpenSearch Dashboards** | Kibana 的開源分支 |
| **Apache Superset** | 原為商業分析設計，逐漸用於可觀測性視覺化 |
| **Observable Plot** | 用於客製化視覺圖形的工具組 |

📌 特別提到：

* **Flame Graph（火焰圖）**：非常適合用於效能分析（如 CPU 使用）

---

### 🔁 工具選擇的轉變：從封閉到彈性整合

過去：

* Kibana 因為與 Elasticsearch 整合緊密，很受歡迎
但現在：
* Grafana 因為支援多種資料來源（非綁定某家廠商），彈性更高，成為**解耦式觀測架構**首選。

例如：

> ScyllaDB 的監控系統就整合了 Grafana + Prometheus + Alertmanager

---

### 🔗 如何整合自訂資料庫？

即使資料庫不在「支援列表」中，也可以：

* **自己寫外掛（Grafana Plugin）**
* 使用 **gRPC-based Remote Storage API**（如 Jaeger 提供）
* 參考像 **Cisco Webex** 將 Apache Pinot 與 Grafana/Kibana 整合的做法

📦 StarTree Cloud 也後續支援了 Grafana 整合（商業服務版本）

---

### 🔒 軟體授權問題：不可忽視！

視覺化工具是否**真正開源**？授權方式會影響商業部署與擴充性：

| 工具 | 授權 |
| ------------------- | ----------------------------- |
| **Grafana** | AGPL v3（比 Apache 嚴格） |
| **Kibana** | SSPL / Elastic License（非真正開源） |
| **Apache Superset** | Apache 2.0 |
| **SigNoz** | MIT（最寬鬆） |

✅ 選擇時應考慮：

* 是否能「自由修改與擴充」
* 是否符合你公司內部開源政策

---

### 📌 小結重點

| 面向 | 重點建議 |
| ----- | --------------------------------------- |
| 工具選擇 | Grafana 適合解耦式堆疊；Kibana 仍適用於 ELK 架構 |
| 整合彈性 | 可透過 plugin / gRPC API / 自行開發方式支援非標準資料來源 |
| 視覺化目標 | 不只是顯示，更應能促成「洞察 → 反應」的自動化流程 |
| 授權考量 | 注意工具是否真正開源，以及其對企業內部部署的限制 |

---

## 第七章〈Future Trends in Observability（可觀測性的未來趨勢）〉聚焦在未來幾年可觀測性領域的主要演進方向，特別是三大關鍵主題：

1. **OpenTelemetry 的快速演進**
2. **平台工程師的體驗優化**
3. **AI 與 Observability 的雙向融合**

以下是逐段重點整理與說明：

---

### 1️⃣ OpenTelemetry 的發展方向

#### 📌 核心里程碑與計畫

* **OTel Weaver（Rust-based 平台）**：2025 正在發展中

* **Phase 1**：語意標準化（Semantic Conventions）
* **Phase 2**：Schema 設計
* 未來可能加入 **WASM plugin** 支援

#### 🚀 其他語言 SDK 進展

* **Go SDK**：

* 增加 runtime metrics、logs API、`otelhttp` 等功能
* 正在 Beta 測試基於 **eBPF 的自動化追蹤**

---

### 2️⃣ 提升平台工程師體驗（Platform Engineering）

#### 🎯 核心思維

> 「可觀測性本身不應成為工程師的負擔，而是他們的助手。」

* 觀測工具要能「隱形運作」、**不干擾使用流程**。
* 關鍵是輸出 **有意義的洞察**，而非產生大量雜訊。

#### 👀 自我觀測：誰來觀測可觀測性系統？

* 需要對自己的觀測系統進行儀器化與監控（如資源瓶頸、漏資料等）
* 如同哲學命題「誰來監督監督者？」

---

### 3️⃣ AI 與 Observability 的融合（雙向趨勢）

#### 🤖 AI for Observability（AI 增強觀測）

AI 用於：

* 自動異常偵測（如：BigPanda）
* 多系統事件關聯（Event Correlation）
* 生成式 AI 助理（如 New Relic 可直接問「哪裡慢？」）
* 回報摘要生成、自動排程、事件分析

➡️ 幫助快速縮短 MTTR（Mean Time to Recovery）

---

#### 🧠 Observability for AI（觀測 AI 模型）

AI 本身也需要觀測工具以確保：

* **推論準確性**（防止 hallucination）
* **延遲與效能追蹤**
* **合規與倫理監控**

出現新創公司如：

* **Langfuse、HoneyHive**：專注於 LLM Observability
* **Evidently（開源）**：監測模型輸入輸出與統計特徵變化

📌 推測未來會有一套 **AI Observability 開放標準**（類似 OTel）

---

### 📌 小結：未來的關鍵趨勢

| 趨勢領域 | 描述 |
| ----------- | ------------------------------- |
| 📈 開放標準 | OTel + Query Semantic DSL 持續演進中 |
| 🧱 解耦架構 | Observability 2.0 / 1.5 越來越普及 |
| ⚙️ 平台整合 | 與平台工程、安全、AI 工具整合愈加緊密 |
| 🤝 雙向 AI 融合 | 不只是 AI for Ops，也要 Ops for AI |

> 本書希望成為你理解這些變化的起點與地圖。

---