昨天講完三本柱，今天我們來列清單，看這 30 天到底要在叢集裡裝哪些東西。

我自己查資料的時候，覺得很多教學太快跳到指令的部分，直接教怎麼安裝和執行，但沒有說明為什麼要選擇使用這個工具，裝完還缺什麼。結果就是照著做完，得到一堆有在跑的東西，卻不知道它們彼此之間是什麼關係。

所以今天不會出現任何安裝指令。今天只講每個工具站在什麼位置、解決什麼問題、我為什麼選它而不是別的。名詞第一次出現我都會解釋，不需要任何先備知識。

先看一筆資料的旅程

直接把所有工具列成一份清單，我會記不住，也不理解他們間的關係，但是把它想成一條輸送帶就簡單多了。我們的程式產生了一筆資料，例如「這個結帳請求花了 230 毫秒」，接下來它要經過五站：

1. 產生：程式自己把資料吐出來
2. 收集：有東西負責把資料拿走
3. 儲存：資料進到一個可以被查詢的資料庫
4. 查看：有一個畫面讓我們畫圖、下條件搜尋
5. 通知：出事的時候有東西主動來吵我們

三本柱各自有一條輸送帶，前三站各走各的，但是第四站共用同一個畫面，這就是昨天講的「能不能互相跳轉」的基礎。下面就照這五站來介紹。

第 1 站 產生：OpenTelemetry

OpenTelemetry（縮寫 OTel）不是一個要安裝的軟體，它是一套標準，規定遙測資料長什麼樣、欄位怎麼命名、程式要怎麼把它送出去。遙測資料（telemetry）就是系統為了讓我們觀察它而吐出來的資料，metrics、logs、traces 都算。這套標準由 CNCF 維護，也就是管理 Kubernetes 的同一個基金會。

它為什麼重要？在它出現以前，我們換一套監控系統，就要把程式裡面所有埋點重寫一次。有了共通格式之後，程式只認標準，後端要換誰就換誰。

實際使用的時候它有兩個部分，共用同一個名字，這點我一開始很容易搞混：

• SDK：放進程式裡面的函式庫，負責產生資料
• Collector：一個獨立跑的中繼站程式，下一站會講

第 2 站 收集：資料是被拿走的，還是自己送出去的

這裡有一個對新手很重要、但是很少人講明白的差別。

Prometheus 用拉的（pull）。我們的程式開一個網址，慣例上是 /metrics，上面就印著當下的數字，Prometheus 每隔一段時間（例如 15 秒）自己跑來讀一次。程式完全不需要知道 Prometheus 的存在。

traces 用推的（push）。追蹤資料是一個請求走完之後才產生的、有頭有尾的東西，沒辦法用「來讀一下現在的值」這種方式拿，所以是程式主動送出去。

log 是第三種。程式只管把 log 印出來，Kubernetes 會幫我們存成檔案，然後另外派一個小程式去讀那些檔案，這個小程式叫做 Grafana Alloy。

這裡要提醒一個時效性的坑：Loki 傳統上的 log 收集器叫 Promtail，網路上絕大多數教學都還在教它，但是它已經停止開發了，官方改推 Alloy。照著舊教學做的話，我們會裝到一個沒有未來的元件。

至於 OpenTelemetry Collector，它站在中間，接收所有送過來的資料，處理一下（過濾、改名、抽樣）之後再決定轉送給誰。多這一層的好處是程式只要認得它一個，哪天想換資料庫只要改 Collector 的設定檔，不用動到所有程式。

第 3 站 儲存：三種資料三個家

替代品不選的理由分別是這樣。VictoriaMetrics 跟 Thanos 是為了「規模變超大」而生的，我在筆電上用不到。

ELK 是 Elasticsearch、Logstash、Kibana 的合稱，業界最經典的 log 方案，它把每個字都建了索引，什麼都搜得到，功能比 Loki 強得多。代價是很吃資源，光 Elasticsearch 自己就可能吃掉好幾 GB 記憶體，而我的預算是一台筆電。Loki 只對標籤建索引，換來的就是輕量。

Jaeger 是老牌的 trace 系統，很成熟。我選 Tempo 唯一的理由是之後要做的「從圖表直接點進 trace」（這件事叫 exemplar），在 Grafana 加 Tempo 的組合下設定最少。並沒有說 Tempo 是比較強的工具。

第 4 站 查看：Grafana

Grafana 是一個把資料畫成圖表的網頁介面，它自己不存任何資料，只負責去問別人要。

它是這整套的關鍵，因為 Prometheus、Loki、Tempo 都可以掛在同一個 Grafana 底下，我們在同一個畫面裡就能從一張指標圖跳到相關的 log，再跳到那條 trace。三個資料庫，一個畫面。

第 5 站 通知：Alertmanager

Prometheus 負責判斷「這個條件成立了」，但是它自己不發通知。Alertmanager 是接手的那一個，負責決定要通知誰、要不要把十個相似的告警合併成一則、以及半夜到底要不要吵你。

把「判斷」跟「通知」拆開是刻意的設計，之後會講這樣拆的好處。

這麼多東西要怎麼裝：Helm 與 Operator

上面數一數有六七個軟體，一個一個裝會裝到放棄，所以實際上會用兩個東西幫忙。

Helm 是 Kubernetes 的套件安裝工具，地位大概相當於 Ubuntu 的 apt 或是 macOS 的 brew。它的套件叫做 chart，一個 chart 裡面打包了一組軟體加上它們的預設設定。

我們要用的 chart 叫 kube-prometheus-stack，它一次幫我們裝好 Prometheus、Grafana、Alertmanager，外加兩個資料來源：

• node-exporter：跑在每個節點上，回報這台機器的 CPU、記憶體、磁碟
• kube-state-metrics：回報 Kubernetes 自己的狀態，例如有幾個 Pod 正在重啟

它還會裝一個 Operator。Operator 是常駐在叢集裡面的程式，專門幫我們管理某個複雜軟體的設定。以 Prometheus 為例，沒有 Operator 的話，想多監控一個服務就得手動改設定檔然後重啟它；有了它，我們只要建立一個叫做 ServiceMonitor 的東西說「去抓這個服務」，Operator 就會自己翻譯成設定套用下去。ServiceMonitor 這種 Kubernetes 原本沒有、由 Operator 自己發明的物件類型叫做 CRD（Custom Resource Definition，自訂資源定義），Day 8 會實際用到。

為什麼幾乎都選 Grafana 家族

看到這裡可能會發現，Loki、Tempo、Alloy、Grafana 都是同一家公司的產品。

這是刻意的。它們個別未必是最強的，ELK 的搜尋比 Loki 強、Jaeger 也比 Tempo 成熟，但是這個系列的核心主張是「三種資料要能互相跳轉」，而同一家的產品在這件事情上的整合成本最低。

筆電要準備什麼

記憶體是最容易卡住的地方。如果只有 8 GB，建議做 Day 16–19 的 traces 時先把 Loki 停掉，這兩個不用同時跑。

另外工具版本我會統一記成一張表放在每篇開頭。

我刻意不做的五件事

先寫清楚，免得大家期待落空。

1. 不做 ingress。 ingress 是讓叢集外部的流量進到叢集裡面的入口機制。最主流的實作 ingress-nginx 已經宣布停止維護，現在教它只會誤導人，而且流量入口也不是我的主軸。我一律用 kubectl port-forward，一行指令把叢集裡的服務暫時接到自己電腦的某個埠。
2. 不做 service mesh。 service mesh（服務網格，例如 Istio）會在每個 Pod 旁邊塞一個代理程式接管網路流量，所以可以自動產生 trace，不用改程式碼。聽起來很誘人，但是它會蓋掉「自己埋點」的學習過程，而且它本身就是一個 30 天的題目。
3. 不上雲。 全部在筆電上跑，讀者零成本就能重現。代價是碰不到多節點的真實網路問題。
4. 不做 profiling。 昨天提過的第四根柱子。30 天塞不下，而且它跟我的主軸（跨服務的故障排查）不完全重疊。
5. 不把示範服務寫漂亮。 它的職責是會壞，程式碼夠用就好。完整原始碼會放在公開的 repo，文章裡面只貼關鍵片段。

小結

今天一樣沒有裝任何東西，但是我們現在知道了：

• 資料要走五站，產生、收集、儲存、查看、通知，三本柱前三站各走各的，第四站共用 Grafana
• 選型的原則是一致性優先於個別最佳
• 還有我不會做的五件事

「為什麼」這個區塊到今天結束。明天 Day 5 開始動手，用 kind 在筆電上開出第一個叢集。