哈囉大家好！今天要來聊聊 Service Mesh 如何「看見」這些在網格中流動的流量呢？

這就是可觀測性 (Observability) 要解決的問題。Istio 官方提供像 Prometheus (收集與儲存指標) 和 Grafana (視覺化指標) 這對黃金組合。

Part 1：安裝監控套件與 Istio 的優勢

如何快速安裝 Prometheus & Grafana？

你可能會想，要安裝這一整套監控系統，是不是很複雜？對於學習和測試來說，Istio 提供了一個超棒的捷徑。在安裝 Istio 時，可以選擇 demo 這個設定檔 (profile)，它會自動把 Prometheus, Grafana, Jaeger 等一整套可觀測性工具都打包安裝好。

當你執行：

istioctl install --set profile=demo -y

Istio 的 demo profile 會自動幫你安裝一整套觀測性（Observability）元件，其中包含：

可以透過以下指令確認 Prometheus 是否有安裝成功：

kubectl get pods -n istio-system

若是 demo profile，應該會看到類似這樣：

NAME                                READY   STATUS    RESTARTS AGE
prometheus-5f6d8f8d7c-xxxxx           2/2     Running   0       2m
grafana-7c4d9c8df6-xxxxx              1/1     Running   0       2m
jaeger-xxxxxxx                        1/1     Running   0       2m
kiali-xxxxxxx                         1/1     Running   0       2m

不過 demo profile 的目的主要是「體驗與學習」，所以功能幾乎全開，也因此佔資源較多。在 正式環境 中，通常會改用 default：然後再自行安裝像是 Prometheus Operator 或 kube-prometheus-stack 來管理監控。

Part 2：Prometheus 如何抓到 Istio 的資料？

這正是整個流程最神奇的地方。Prometheus 採用一種稱為 「拉取 (Pull / Scrape)」 的模型來收集指標。

1. Sidecar 的指標端點：Istio 注入的每一個 Sidecar，都會自動在一個固定的 HTTP 端點上暴露所有流量指標，這個端點通常是 /stats/prometheus。

2. Pod 上的「註解」：我們該如何告訴 Prometheus要去採訪哪些 Pod 呢？答案是透過 K8s 的註解 (Annotations)。當 Istio 注入 Sidecar 時，它會自動為我們的 Pod 加上類似這樣的註解：

   prometheus.io/scrape: "true"
   prometheus.io/path: "/stats/prometheus"
   prometheus.io/port: "15020"
   

3. Prometheus 的自動發現：Prometheus 的設定檔 (prometheus.yml) 中，會有一段 kubernetes_sd_config 的設定。它會告訴 Prometheus：「請去 K8s API Server 查詢，自動發現所有帶有 prometheus.io/scrape: "true" 註解的 Pods，並將它們加入你的採訪清單。」

4. 執行抓取：Prometheus 會定期地（例如每 15 秒）根據清單，訪問這些 Pods 的 15020 埠和 /stats/prometheus 路徑，將上面暴露的所有指標數據，「拉取」回自己的資料庫中儲存。

5. 驗證狀態：打開 Prometheus 的網頁介面，前往 Status > Targets 頁面。如果有看到 Istio 相關的 Pods 狀態是 UP，那就代表 Prometheus 已經成功地與它們建立了連線，並正在穩定地抓取指標數據。

Part 3：如何查詢資料？初探 PromQL

Prometheus 有自己專屬的查詢語言，稱為 PromQL。透過 PromQL，我們可以從收集到的各種 Metrics 中挑選、聚合與分析資料。

以 Istio 為例，早期大家習慣使用 istio_requests_total 這類指標來查詢請求數量。不過在新版 Istio 中，這些 Metrics 已經被 Envoy Proxy 的標準名稱所取代，例如：

• envoy_cluster_upstream_rq_total：代表發往上游服務的總請求數量

Part 4：K8s 叢集監控的全景圖

然而一個完整的 K8s 監控體系，並不只包含應用服務的請求量，我們還需要同時掌握 節點 → Pod → 容器 → 應用 的狀態。

監控層級關係圖

對應工具 & PromQL 指標

為了監控這些不同層級，我們需要組合使用不同的工具。介紹一些專案有使用到的工具：

• Node Exporter：這個工具安裝在每個節點上，可以監控虛擬機的 CPU、記憶體等資源使用情況。它不是 K8s 原生，需要額外安裝。
• cAdvisor：Kubelet 內建的工具，用來監控每個容器的 CPU 和記憶體使用量。。
• metrics-server：可以看到每個 Pod 的 CPU/記憶體使用量。

除了今天介紹的 Prometheus 外，還有另外一個他的好夥伴 Grafana，這兩個系統時常搭配一起使用。在明天的文章中，我們就要來認識 Grafana！明天見！