牧場主今日工作

昨天我們建立了 Prometheus 數據收集中心，今天要來打造真正實用的監控面板！我們使用的 kube-prometheus-stack 是業界標準的監控方案，也是 Rancher 監控功能的基礎元件。它整合了 Prometheus Operator、Grafana、AlertManager 等核心組件，提供完整的監控能力。雖然 Helm 管理的 Grafana 設定被「鎖住」無法在 UI 修改，但這反而更適合 GitOps 和團隊協作！

Helm 管理的 Grafana 優缺點分析

GitOps 友善的配置管理

強制透過 Config 調整的優點：

• 稽核友善：所有變更都有版本記錄
• 多人協作：避免手動修改造成的設定衝突
• GitOps 整合：配置即程式碼，可追蹤變更歷程
• 環境一致性：dev/staging/prod 環境設定同步

kube-prometheus-stack 監控工作流程：

實務操作策略：

• 透過 Helm values 管理所有核心設定
• 匯入社群模板作為基礎，再進行微調
• 建立儀表板版本控制流程
• 善用 Rancher 預建的 ServiceMonitors

社群模板 vs 自建面板策略

社群模板的優缺點：

# 優點：
+ 快速部署（5分鐘 vs 數天）
+ 專家級設計品質
+ 經過大量用戶驗證
+ 美觀的視覺效果

# 缺點：
- 通常不會 100% 符合需求
- 需要微調和客製化
- 可能包含不需要的面板

最佳實務策略：

1. 主流監控：使用社群模板（如 Prometheus/Node Exporter）
2. 特殊需求：基於模板進行微調
3. 自訂應用：自己建立（因為找不到現成的）
4. 混合使用：拿別人的模板當基礎，效率更高

kube-prometheus-stack 預設模板

內建的完整儀表板清單：

核心監控：

• AlertManager / Overview - 告警管理總覽
• Grafana Overview - Grafana 自身監控

Kubernetes 資源監控：

• Kubernetes / API server - K8s API 伺服器效能
• Kubernetes / Compute Resources / Cluster - 叢集整體資源
• Kubernetes / Compute Resources / Namespace (Pods) - 命名空間 Pod 資源
• Kubernetes / Compute Resources / Node (Pods) - 節點級 Pod 資源
• Kubernetes / Compute Resources / Pod - 單一 Pod 詳細監控
• Kubernetes / Kubelet - Kubelet 健康狀態

網路監控：

• Kubernetes / Networking / Cluster - 叢集網路總覽
• Kubernetes / Networking / Namespace (Pods) - 命名空間網路流量
• Kubernetes / Networking / Pod - Pod 網路詳情

儲存監控：

• Kubernetes / Persistent Volumes - 持久化儲存監控

節點系統監控：

• Node Exporter / AIX - AIX 系統監控
• Node Exporter / MacOS - macOS 系統監控
• 以及 Linux 相關的 Node Exporter 儀表板

DNS 監控：

• CoreDNS - 叢集 DNS 解析監控

這些都是 mixin 專案維護的生產級品質儀表板，可以直接使用！

探索預設儀表板的技巧

# 在 Grafana 中快速找到想要的儀表板
1. 左側選單 → Dashboards → Browse
2. 使用搜尋功能：
   - 搜尋 "compute" 找資源使用相關
   - 搜尋 "networking" 找網路相關
   - 搜尋 "node" 找節點硬體相關
   - 搜尋 "api" 找 K8s API 相關

# 推薦的日常監控儀表板
- 叢集總覽：Kubernetes / Compute Resources / Cluster
- 節點監控：Kubernetes / Compute Resources / Node (Pods)
- 故障排查：Kubernetes / Compute Resources / Pod

存取 Grafana 與預設檢查

透過 port-forward 存取

# 確認 Grafana 服務正在運行
kubectl get pods -n monitoring | grep grafana

# 使用 port-forward 存取（臨時方式）
kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80

首次登入：

• URL: http://localhost:3000
• 帳號: admin
• 密碼: admin123（我們在 values.yaml 中設定的）

檢查預設配置

資料來源確認：

1. 左側選單 → Connections → Data Sources
2. 應該看到 Prometheus 已經配置完成
3. URL: http://kube-prometheus-stack-prometheus:9090
4. 點擊 Test 按鈕確認連線正常

預設儀表板檢查：

1. 左側選單 → Dashboards
2. 瀏覽 General 資料夾中的預設儀表板
3. 重要的預設儀表板：
   • Kubernetes / Compute Resources / Cluster
   • Node Exporter / Nodes
   • Kubernetes / Networking / Cluster

RKE2 Control Plane 監控限制

重要提醒：RKE2 的 Control Plane 組件可能會顯示 No data：

# 這些儀表板可能缺少資料
- Kubernetes / API server (部分指標)
- etcd 相關監控
- kube-scheduler 監控
- kube-controller-manager 監控

原因分析：

• RKE2 Control Plane 組件使用 TLS 客戶端憑證認證
• Prometheus 無法直接存取這些受保護的 metrics 端點
• 需要額外的代理機制來轉發指標

解決方案 - PushProx 代理機制：

# PushProx 是 Prometheus 生態系的開源專案
# https://github.com/prometheus-community/PushProx

# PushProx 架構：
# 1. Client DaemonSet 部署在 host network
# 2. 建立對中央 proxy 的出站連線  
# 3. 允許 metrics 收集而不需開放入站埠口
# 4. 解決 NAT/Firewall 環境的監控問題

kube-prometheus-stack 的優勢：

• 標準化架構：業界通用的監控方案
• Prometheus Operator 管理複雜的 Prometheus 配置
• 豐富的 Exporter：node-exporter、kube-state-metrics 等
• 完整生態系：Grafana、AlertManager 開箱即用

Rancher Monitoring 的本質：

• Rancher Monitoring = kube-prometheus-stack + UI 整合
• 透過 Rancher UI 簡化 ServiceMonitor/PrometheusRule 管理
• 內建 PushProx 來解決 Control Plane 監控問題
• 本質上就是把 kube-prometheus-stack 包裝成更容易使用

實務建議：

• 我們直接使用 kube-prometheus-stack，學習標準做法
• 基礎的 Node、Pod、Service 監控已經足夠大多數場景
• 如果需要 Control Plane 監控，可以參考 Rancher 的 PushProx 實作
• 這樣既學到核心技術，又避免 vendor lock-in

匯入社群儀表板模板

如何尋找合適的儀表板

官方儀表板庫：

• 前往 https://grafana.com/grafana/dashboards/
• 搜尋關鍵字：kubernetes、prometheus、node-exporter
• 篩選條件：
  • Data source: Prometheus
  • Collector: 選擇你使用的 exporter
  • Sort by: Downloads (下載量) 或 Rating (評分)

選擇儀表板的方法

實用建議：

# 最直接的方法
1. 看起來不錯？直接匯入試試看
2. 不合用？刪掉換下一個
3. 覺得太複雜？找簡單一點的
4. 缺少功能？再找個補足的

# 沒什麼標準，就是試用
- 匯入很快，刪除也很快
- 多試幾個自然知道哪個好用
- 適合自己環境的就是最好的

匯入儀表板的通用步驟

通用匯入流程：

# 在 Grafana UI 中操作
1. 左側選單 → Dashboards → New → Import
2. 輸入方式三選一：
   - Dashboard ID (如: 1860)
   - 上傳 JSON 檔案
   - 貼上 JSON 內容
3. 點擊 Load
4. 設定參數：
   - Name: 自訂儀表板名稱
   - Folder: 選擇或建立資料夾
   - Prometheus: 選擇資料來源
5. 點擊 Import

刪除不需要的儀表板

清理方法：

# 在 Grafana UI 中
1. 左側選單 → Dashboards → Browse
2. 找到不要的儀表板
3. 點擊儀表板 → Settings → Delete dashboard
4. 確認刪除

# 就是這麼簡單

儀表板自訂與優化

修改匯入的儀表板

重要限制：Helm 管理的 Grafana 中，無法修改預設儀表板，但可以：

1. 複製 (Clone) 儀表板進行修改
2. 建立全新的自訂儀表板
3. 匯入的社群儀表板可以自由修改

複製儀表板操作：

1. 開啟想要修改的儀表板
2. 點擊右上角的 「齒輪」圖示 → Settings
3. 點擊 "Save As..." 
4. 輸入新名稱，例如："Custom K8s Monitoring"
5. 選擇儲存位置（建議建立 "Custom" 資料夾）
6. 現在可以自由編輯複製的版本

透過 Helm values 調整 Grafana 設定

透過 Helm 管理設定的優勢

為什麼用 Helm values 而不是 UI 設定？

• 持久性：Pod 重啟後設定不會遺失
• 版本控制：配置變更可以追蹤和回滾
• 一致性：多環境部署使用相同配置
• 自動化：可以整合到 CI/CD 流程

可以選擇的設定方式：

• 在 Grafana UI 中手動設定（存在 PVC 中，重建 PVC 才會消失）
• 透過 Helm values 預先設定（配置即程式碼，便於版本控制）

需要進階設定的話，可以參考官方文件進行 Helm values 調整。

今日總結與明日預告

今天我們深入了解了 Helm 管理 Grafana 的實務運用！從 GitOps 友善的配置管理到社群模板的活用，我們建立了實用的監控視覺化體系。

重點回顧：

• GitOps 優勢：強制透過 Config 管理，有稽核紀錄和版本控制
• 混合策略：社群模板+微調，既高效又符合需求
• 內建資源：kube-prometheus-stack 預設提供生產級儀表板
• 實用技能：儀表板匯入、刪除、複製修改

實務心得：

• 社群模板通常需要微調，但比從零開始效率高很多
• 對於非主流監控需求，自建面板仍有其必要性
• Helm 強制使用 IaC 方式，反而對團隊協作和稽核更友善

明天我們要部署完整的 LGTM Stack 統一可觀測性平台，整合 Loki、Mimir、Tempo 到現有的 Grafana 中，讓我們的牧場擁有 Logs、Metrics、Traces 的全方位監控能力！

💡 牧場主小提示：Grafana 的價值在於把複雜的監控數據變成直觀的視覺化資訊！記住：善用社群模板比從零開始效率高很多，IaC 看似麻煩，但對於多人協作的團隊來說是天賜良物。當你能在 5 分鐘內匯入一個專業級儀表板時，你會感謝那些無私分享的社群貢獻者！