阿里雲國際帳號 如何在阿裡雲伺服器上搭建Prometheus與Grafana性能監控系統

第一章：為什麼要把監控做成一套「能長期跑」的系統

很多團隊在上線前會做壓測、在問題發生後才臨時加監控。結果往往是：儀表板看起來很漂亮，但告警不準、資料缺失、硬碟很快爆滿、調整參數時又互相牽制。Prometheus 與 Grafana 的組合之所以常被選擇，核心在於它不只是一個工具，而是一套相對清晰的資料流：指標（metrics）被抓取（scrape）後保存，再透過查詢語言 PromQL 進行分析與展示，最後用告警把「看見問題」推到「在事情變糟前就處理」。

阿里雲國際帳號 在阿里雲部署時，還要多考慮雲端環境的現實：安全群組（防火牆）如何放行、網路規劃是否導致抓取失敗、實例重啟後配置是否還能自動生效、資料留存時間是否與磁碟容量匹配。下面我會用一個可落地的流程帶你把這套監控系統搭起來，並確保它能穩定運行，而不是只跑一次就結束。

第二章：規劃部署架構與資源邊界

在開始安裝前，先把「要監控什麼、由誰被抓取、資料往哪裡存」想清楚。一般情況下，你至少會有三類角色：

• Prometheus：負責定時抓取目標的指標並存儲時序資料。
• Grafana：負責可視化與告警。它不存資料，只查 Prometheus（或其他儲存）並展示。
• Exporter：把系統或應用的狀態轉成 Prometheus 能理解的指標。常見是 node_exporter。

你可以把 Prometheus 與 Grafana 放在同一台阿里雲實例上（初期最省事），也可以拆成兩台（規模稍大時更穩）。若你監控範圍不大（例如幾十個節點），通常同機部署足夠。當指標量上升到一定程度，Prometheus 的磁碟與 CPU 會變成瓶頸，這時再拆分會更划算。

建議的最小方案

假設你有一到數十台被監控主機（含同一台也可），可以採用下列方案：

• 一台「監控伺服器」：安裝 Prometheus + Grafana +（可選）Alertmanager。
• 每台被監控伺服器：安裝 node_exporter。
• Prometheus 透過內網 IP 抓取 node_exporter。

阿里雲國際帳號 這樣的好處是：抓取流量走內網，速度快且穩，對外網暴露的端口也能降到最小。

容量與留存：先算再安裝

Prometheus 的磁碟留存主要由以下因素決定：

• 阿里雲國際帳號 抓取頻率（scrape interval）
• 指標數量（target 數 × 指標種數）
• 儲存規則與壓縮效果
• 留存時間（例如 15 天、30 天等）

初期你可以保守設置留存 7~15 天，等你觀察到磁碟用量曲線再調整。不要一上來就設成 180 天，然後用戶地盤突然爆磁碟。

第三章：阿里雲環境準備—網路、安全群組與時間同步

無論你使用哪套教程，這一步做不好，後面 90% 都會卡住。

1. 安全群組放行端口

監控伺服器通常需要：

• Grafana 端口：3000
• 阿里雲國際帳號 Prometheus 介面：9090（若你只想內網訪問，可只允許內網段）

每台被監控主機的 node_exporter 端口：

• 9100（建議同樣只允許 Prometheus 所在的監控伺服器內網 IP 連線）

建議你關掉不必要的對外開放，至少先做到「內網可抓取、外網少暴露」。

2. 時間同步（非常重要）

Prometheus 與 Grafana 的查詢和聚合依賴時間軸一致性。如果你的節點之間時間差太大，圖表會出現錯位或告警誤判。建議在所有主機上保持 NTP 同步（例如 chrony 或系統自帶時間服務）。部署完成後，抽查幾台主機的時間差。

3. 確認內網連通性

在監控伺服器上測試連到 node_exporter 的端口是否通，例如：

• 能否連到被監控主機的 :9100
• Prometheus 所配置的抓取目標是否解析到正確的 IP

你會在這一步提前省下大量時間。

第四章：安裝 Prometheus—把「抓取配置」先做對

這裡以 Linux 伺服器為例。你可以使用原始碼編譯或下載官方二進位檔。關鍵是：安裝後要用 systemd 管理，並設定好目錄、權限、配置檔路徑。

1. 建立目錄與使用者

建議準備類似：

• /opt/prometheus：程式檔
• /etc/prometheus：配置檔
• /var/lib/prometheus：資料留存（務必放在容量足夠的磁碟）

並建立 prometheus 使用者，讓服務以非 root 身份運行。

2. 編寫 prometheus.yml

Prometheus 的核心就是 scrape_configs。一個典型配置會包含：

• 抓取間隔（scrape_interval）
• 每個 target 的地址（static_configs 或服務發現）
• 標籤（labels）用來區分來源

你可以從靜態配置開始，等流程跑通再考慮動態服務發現。

阿里雲國際帳號 示例：靜態抓取 node_exporter

以監控伺服器內網抓取為例（你要把 IP 換成你的實際地址）。配置要點在於：你要給每個目標一個清晰的 job 與 instance 標籤。

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['10.0.1.10:9100']
        labels:
          env: 'prod'
          role: 'app'
      - targets: ['10.0.1.11:9100']
        labels:
          env: 'prod'
          role: 'db'

為了後面告警與面板可讀性，請避免只用裸標籤。合理地加上 env、role，讓你之後分組查詢更直觀。

3. 檢查配置是否能啟動

Prometheus 啟動前先做語法與目標檢查：

• 確認 prometheus.yml 格式正確
• 確認目標端口可連線
• 在 Prometheus 介面檢查 Status > Targets：看到目標狀態為 UP

如果你發現全是 DOWN，不要急著調 PromQL。先把 scrape 這條管線打通。

第五章：安裝 node_exporter—把主機指標變成可用的信號

node_exporter 幫你把 CPU、記憶體、磁碟、網路、負載等資訊暴露成 Prometheus 指標。它通常是性能監控系統的「地基」。

1. 安裝與啟動

同樣建議用二進位檔或官方包裝方式，並用 systemd 管理。

重點包括：

• 監聽地址（通常是 0.0.0.0 或內網 IP）
• 端口（9100）
• 排除不需要的 mount 或網路介面（視你的環境而定）

2. 設置出口標籤（可選但很實用）

阿里雲國際帳號 如果你的 exporter 都在不同角色機器上，建議在 Prometheus 端用 labels 區分；或在 exporter 啟動參數中使用額外標籤。這樣你在 Grafana 裡做圖表時能直接按角色篩選。

3. 用指標檢查「是否抓到了你想要的」

在 Prometheus 介面點進 Graph，你可以先用簡單查詢確認資料存在，例如 CPU 使用率、磁碟使用、網卡流量。圖表能正常出現，代表你的鏈路大致沒問題。

第六章：安裝並配置 Grafana—把資料變成可讀的儀表板

Grafana 的價值在於：你不用只看單一指標，而是用一組互相印證的面板告訴你「今天系統到底怎麼了」。

1. 配置 Grafana 與資料源

阿里雲國際帳號 當 Grafana 啟動後，進入設定：

• Data Sources > Add data source > Prometheus
• URL 指向 Prometheus：例如 http://<監控伺服器IP>:9090

選擇 Save & Test，確保 Grafana 能連到 Prometheus。

2. 推薦面板：從「系統健康」開始

一套可用的監控看板可以先從這些面板構成：

• CPU 使用率（整體與核心）
• 記憶體使用率與可用量
• 負載（load average）與 CPU 的關係
• 磁碟容量與 inode 使用
• 磁碟 I/O（讀寫延遲或吞吐）
• 網路流量（收發包與位元組）

不要一上來就堆滿 30 張面板。你要先把最能反映問題的幾張做好，讓日常排查效率立刻上來。

3. 面板查詢要注意維度一致性

阿里雲國際帳號 Prometheus 指標通常帶有標籤，如 instance、job。Grafana 的模板變數（如 datasource、instance dropdown）能讓你切換不同機器。但你要確保：所有面板在用同一套標籤邏輯。否則你會遇到「這張圖能篩，那張圖不能」這種很煩的狀況。

4. 範例：磁碟空間告警面板的做法

你可以用磁碟容量百分比作為視覺化。當你做成圖時，建議顯示：

• 已用百分比（或剩餘百分比）
• 不同實例分組顯示
• 時間趨勢（觀察是否加速逼近臨界值）

當圖表清楚時，告警就好設定，因為你知道「告警觸發的原因」是什麼。

第七章：告警策略—讓人能及時行動，而不是只看到紅色

告警的本質是「把問題交給對的人」。如果告警頻繁誤報，就會造成疲勞；如果告警太少，就會錯過關鍵變化。你需要一個合理的策略：先確保關鍵指標可信，再逐步擴大範圍。

1. 是否需要 Alertmanager

在 Prometheus 社群裡，最常見的做法是 Prometheus + Alertmanager + Grafana。Grafana 也能做告警，但多數情況下 Alertmanager 更適合聚合、降噪與路由。

若你是小規模環境，可以先用最簡單路徑：Prometheus 規則 +（可選）Alertmanager。等告警規則多了再補進去。

2. 告警從「磁碟、CPU、記憶體、服務存活」四類開始

對於 node_exporter 指標，你可以先定義這幾個告警類型：

• 磁碟空間：剩餘小於某個比例（例如 < 15%）
• 記憶體壓力：可用記憶體過低或交換區異常
• CPU 壓力：短時間內長期高使用率（避免單次尖峰）
• 節點狀態：抓取失敗（target 變為 DOWN）

這些告警足夠應對多數「突然變慢或服務掛掉」的前兆。

3. 用 for 子句與趨勢避免抖動

很多指標會有波動。你可以在 Prometheus 告警規則裡使用 for，例如連續 5 分鐘觸發，而不是瞬間就拉紅。這能大幅減少噪音。

4. 告警通知要「能處理」

通知通道可以是企業微信、Slack、郵件或簡訊（取決於你團隊工具）。但不管你用什麼渠道，建議通知內容至少包含：

• 告警名稱與嚴重度（warning / critical）
• 影響的實例（instance）
• 觸發的原因（用值與閾值說明）
• 建議下一步（例如檢查該機器的 /var 分區或重啟服務）

讓值班同學能在一分鐘內做第一個判斷。

第八章：加入更多 Exporter 與應用指標—把監控從「看主機」升級到「看服務」

只看主機還不夠，尤其你在談性能監控。性能問題常常出現在應用層：請求延遲、錯誤率、佇列堆積、連線池耗盡等。

1. 常見的應用指標采集方式

• 程式內嵌指標：應用使用 Prometheus client（Java、Go、Python、Node 等均可）。
• 第三方 exporter：例如 Nginx exporter、MySQL exporter、Redis exporter、JVM exporter 等。
• 阿里雲國際帳號 Blackbox exporter：做 HTTP/HTTPS 探測，確認外部可用性與延遲。

你不需要一次全部接入。建議先抓「最影響用戶」的鏈路，例如入口服務與資料庫。

2. 在 Grafana 做「服務級」面板的思路

服務級看板最好遵循「使用者視角」：

• 延遲（p95 / p99）
• 錯誤率（4xx/5xx 或失敗次數）
• 吞吐（每秒請求數）
• 資源（CPU、記憶體）與延遲的關聯

當你能在同一張面板或同一套看板看到這些關係，排查就會從「猜測」變成「證據鏈」。

第九章：常見踩坑與排錯流程—把失敗經驗變成檢查清單

你一定會遇到問題。關鍵是：遇到問題時你要有路徑，而不是反覆試錯。

1. Targets 全是 DOWN

最常見原因：

• 安全群組未放行 9100
• Prometheus 配置 target IP/端口寫錯
• 被監控主機上 exporter 未啟動或監聽地址錯誤
• DNS 解析失敗或使用了不能連通的域名

排查順序建議：先在監控伺服器測連通性，再看被監控端 exporter 服務狀態，最後回頭看 Prometheus 配置。

2. 圖表空白或延遲很大

可能原因：

• 時間不一致（時間漂移）
• 資料留存太短導致查詢範圍超出資料
• 抓取間隔設得太大，而你查詢的窗口太短

你可以用 Prometheus 的 Graph 確認指標是否存在，再看 Grafana 的時間範圍選擇是否符合預期。

3. Prometheus 磁碟很快滿

常見原因：

• 阿里雲國際帳號 留存時間設太長
• 抓取太密（scrape_interval 太短）
• 指標數量激增（例如 exporter 暴露了大量高基數標籤）

解法通常是：降低留存、調整 scrape interval、避免高基數標籤（例如把 request id 這類放進 labels）。先止血，再優化。

4. 查詢很慢、Grafana 反應遲鈍

PromQL 查詢的複雜度也會影響效能。過度使用大範圍聚合、跨很多維度分組，都可能拖慢。

建議先把面板查詢做簡化：限制時間範圍、合理聚合維度、避免不必要的 join 操作。當你有明確面板需求時，再逐步加深。

第十章：一個「從零到可用」的落地清單

如果你希望整套流程能快速完成，我建議你按以下清單走：

• 確認部署方式：監控伺服器與被監控伺服器分開（至少先內網抓取）。
• 開通安全群組：Grafana 3000、Prometheus 9090（內網）、node_exporter 9100（僅允許監控伺服器）。
• 所有節點做時間同步。
• 安裝 Prometheus：配置 prometheus.yml 的 scrape_configs，先用靜態 target。
• 安裝 node_exporter：確保能在被監控端訪問 :9100 指標頁面。
• 啟動 Prometheus：在 Status > Targets 確認目標 UP。
• 安裝 Grafana：新增 Prometheus 資料源並 Save & Test。
• 做至少 6~10 張核心面板：CPU/記憶體/磁碟/網路/負載/告警關聯。
• 建立第一批告警：磁碟、記憶體、CPU、節點狀態。用 for 減少抖動。
• 觀察一段時間：確認磁碟留存與查詢速度，再調整抓取頻率與留存策略。

這樣你不會在「能不能跑」之後才進入「能不能用」的階段。

第十一章：結語—把監控做成團隊的語言

Prometheus 與 Grafana 的強大在於它們能把雜亂的現象收斂成可量化、可追溯的指標。更重要的是，當你把告警規則、面板命名與標籤策略做一致，團隊就會形成一套共同語言：看到告警，知道從哪裡開始查；看到波動，知道哪些指標要先驗證。

在阿里雲這種多實例、多網段的環境裡，部署難點往往不在工具本身，而在網路、安全群組、時間同步與容量規劃。只要你把這幾件事先做對，整套系統就能穩定地陪你把性能問題從「事後補救」變成「事前預警」。