Rocky 與 AlmaLinux 如何使用 Performance Co-Pilot

Performance Co-Pilot 已內建於您的 Rocky 或 Alma 系統

Performance Co-Pilot (PCP) 位於 Rocky Linux 與 AlmaLinux 的 AppStream 儲存庫中，因此只需執行一個 dnf 指令與兩個 systemctl 指令，即可部署具備磁碟歷史紀錄功能的完整指標收集器。您無需安裝任何廠商代理程式，也無需對中央伺服器開放任何連接埠。本指南基於 Rocky Linux 9 與 AlmaLinux 9 以及 AppStream 版本的 PCP 6.3 編寫，於 2026 年 8 月進行驗證，以下所有指令均由您在自己的伺服器上執行。

鮮少人使用它的原因是命名方式。這些指令皆為簡短縮寫，掩蓋了其實際功能。只要了解這四個組件的名稱，其餘堆疊功能皆可透過命令列探索。

Rocky 與 Alma 提供的 PCP 套件版本相同，因為兩者皆由相同的原始碼重建。該原始碼源自 Red Hat，而這兩個發行版的出現，僅是因為 CentOS 停止了重建工作，此轉折詳述於 從 Red Hat 到 CentOS 再到 Rocky 與 AlmaLinux 的演變路徑。若您仍在兩者間抉擇，請參考 Rocky Linux 與 AlmaLinux 的比較。相同的堆疊在 Debian 與 Ubuntu 上以 pcp 套件提供，且指令名稱完全相同，僅安裝指令有所差異：請參閱 dnf 與 apt 指令對照表 以了解轉換方式。

Performance Co-Pilot 的架構組成

PCP 由四個運作組件構成，每個組件各司其職。

• pmcd 是效能指標收集常駐程式。它監聽 TCP 44321 埠，並僅回答一個問題：此指標當前的數值為何。它不會保留任何歷史紀錄。
• PMDA (performance metrics domain agent) 是外掛程式，負責提供資料給 pmcd。每個代理程式負責一個指標領域。linux 代理程式涵蓋核心層級，因此 CPU、記憶體、磁碟與網路數據皆由此取得。其他代理程式則涵蓋 systemd journal、NGINX、PostgreSQL、硬碟的 SMART 數據，或任何支援 OpenMetrics 的匯出器。此外還有 docker 代理程式，因此在已 於 Rocky 或 Alma 安裝 Docker 的主機上，各容器的 CPU 與記憶體讀數會與主機本身的數據位於相同的命名空間中。pmcd 載入的代理程式列於 /etc/pcp/pmcd/pmcd.conf 中，每個代理程式的安裝腳本都會自動編輯該檔案。
• pmlogger 以固定間隔對指標進行採樣，並將其寫入磁碟上的封存檔。這就是將即時讀數轉化為日後可回放之歷史紀錄的機制。
• pmie 是效能指標推論引擎。它針對即時指標評估運算式，並在條件成立時執行對應動作。

指標名稱為單一命名空間中的點分隔路徑，例如 kernel.all.load 或 disk.dev.read。指標可以包含實例：disk.dev.read 針對每個區塊裝置提供一個數值，而 filesys.full 則針對每個掛載的檔案系統提供一個數值。此概念後續會再次出現，因為報告工具與 pmie 規則皆以實例為運作單位。

由於 pmcd 不儲存任何資料，查詢永遠只反映當前狀態。任何您希望在未來檢視的資料，都必須在當下存入 pmlogger 封存檔中。這種架構分離解釋了本指南中大部分的設定方式。

安裝並啟動 Performance Co-Pilot

sudo dnf install -y pcp pcp-system-tools
sudo systemctl enable --now pmcd pmlogger
systemctl is-active pmcd pmlogger

is-active 應會輸出 active 兩次。安裝 pcp 套件不會啟動任何服務，因此若跳過 enable --now 指令，您將會得到無法連接至收集器的工具。現在請確認命名空間的回應：

pminfo | wc -l
pcp

pminfo 若不帶參數執行，會列出 pmcd 所知的所有指標名稱，在標準安裝中這會有數千行。pcp 會列出主機的單頁摘要。若出現提及 Cannot connect to PMCD 的錯誤，代表 pmcd 沒有回應，請閱讀 journalctl -u pmcd -n 30 與 /var/log/pcp/pmcd/pmcd.log。

第二個套件 pcp-system-tools 提供了讀取相同指標的報告指令：pmrep、pcp-atop、pcp-iostat 與 pcp-dstat。

此外還有 pcp-zeroconf。其說明文件指出，該套件包含用於提高指標收集頻率的設定調整，以及擴充的 pmlogger 設定與針對本機主機的自動化 pmie 警報。其安裝後腳本會自動為您啟用並重新啟動 pmcd、pmlogger 與 pmie。請注意其代價：封裝的設定檔採樣頻率為每 10 秒一次，而 pmlogger 預設為 60 秒，因此封存檔的成長速度會快上數倍。若您使用小型方案，請在安裝前閱讀保留策略章節。

我的 VPS 實際公開了哪些指標？

pminfo 是探索工具。給定一個子樹，它會列出所有葉節點。加上旗標後，它會說明指標的含義或目前的讀數。

pminfo disk
pminfo -t kernel.all.cpu
pminfo -dfmtT disk.all.read_bytes
pminfo -f kernel.all.load
pminfo -f kernel.all.cpu.steal

-t 會列印每個指標的單行說明，-T 為詳細說明，-d 為描述符，-m 為內部指標 ID，而 -f 則會抓取每個實例的當前數值。描述符是人們最常忽略的部分，這導致他們誤讀了自己的圖表。它提供了資料類型、單位以及語義：該數值是即時讀數、離散計數，還是只會不斷增加的計數器。

最後一種情況至關重要。disk.all.read 是開機後的作業計數器，因此單次抓取無法反映過去一分鐘的狀況。必須進行兩次抓取並計算兩者之間的時間差。報告工具會自動執行此減法運算，這就是為什麼 pmrep 預設顯示速率，且必須加上 -r 才能顯示原始計數器的原因。

kernel.all.cpu.steal 是在共享硬體上必須了解的指標。它計算虛擬 CPU 準備就緒但宿主機將實體核心分配給其他使用者時所耗費的時間，因此 steal 數值上升並非您的工作負載所致。其機制與應對方式請參閱 CPU steal time and noisy neighbours。

同時執行 pminfo kernel.all.pressure。如果它列出了指標，代表您的核心已發布壓力停滯資訊（Pressure Stall Information），而 kernel.all.pressure.io.full.avg 會顯示系統上每個任務因等待儲存裝置而阻塞的時間。如果名稱未知，代表您的核心未公開 /proc/pressure，請改用磁碟指標。

使用 pmrep 即時監控指標

pmrep -t 2sec -p kernel.all.load mem.util.available disk.all.read disk.all.write
pmrep -p -b MB :vmstat
pmrep -t 5sec -s 12 -p -o csv kernel.all.cpu.steal filesys.full

-t 用於設定採樣間隔，-p 用於加入時間戳記，-s 用於指定採樣次數後停止，-b 用於調整位元組單位，而 -o csv 則將輸出寫入為逗號分隔格式以便保存。以冒號開頭的名稱（例如 :vmstat）代表 pmrep 設定檔中預先定義的指標集，讓您無需手動輸入指標名稱即可獲得熟悉的欄位佈局。

相同的指令亦可讀取其他來源。-h 後接位址可從遠端主機的 pmcd 獲取資料，-a 後接封存檔路徑則可讀取歷史記錄而非即時 daemon。一套工具與語法即可處理兩者。當您管理的伺服器超過幾台時，-h 格式是從單一位置檢視所有伺服器最經濟的方式，而更廣泛的作法請參閱 管理多台 Linux 伺服器。

保留策略：pmlogger 填滿小型磁碟

封存檔存放於 /var/log/pcp/pmlogger/<hostname>。每個集合皆以 YYYYMMDD.HH.MM 為基礎名稱，包含一個 .index 檔案、一個 .meta 檔案，以及一個或多個編號的資料磁碟區。

ls -l /var/log/pcp/pmlogger/$(hostname)
du -sh /var/log/pcp/pmlogger/$(hostname)
systemctl list-timers 'pm*'

兩個 systemd 計時器負責執行維護工作。pmlogger_check.timer 會重新啟動任何已停止的記錄器。pmlogger_daily.timer 於 00:10 觸發並執行 Persistent=true，因此在系統重啟後會補執行，它會將當日的封存檔合併為一個檔案、進行壓縮，並捨棄超過保留期限的資料。該期限預設為 14 天。

調整前請先進行測量。讓系統執行一天，然後再次執行 du -sh。封存檔大小取決於採樣間隔以及記錄的指標數量，因此其他伺服器的數據並不適用於您的環境。

在 /etc/pcp/pmlogger/control.d/local 中設定時間限制。保留現有的控制行，並在其上方加入設定值，因為檔案是從頂部開始讀取，且設定僅適用於其下方的控制行。

$version=1.1
$ PCP_CULLAFTER=3

PCP_CULLAFTER=3 會捨棄超過三天的封存檔，這與將 -k 3 傳遞給 pmlogger_daily 的效果相同。此處無法設定大小限制。Rocky 9 AppStream 隨附 PCP 6.3.7（於 2026 年 10 月確認），Alma 9 則使用相同的原始碼進行重建。在該版本中，pmlogger_daily 沒有大小上限：$PCP_SPACELIMIT 變數及其 -d 選項最早出現於 PCP 7.1.1，於 2026 年 3 月 30 日發布。在 6.3.7 版本中，此檔案內的 $ PCP_SPACELIMIT 行會被靜默忽略。因此，天數是您唯一的調整手段。請根據您自己的 du -sh 測量結果選擇天數：計算方式為單日封存檔大小乘以保留天數，再加上直到午夜前持續增長的當日封存檔。限制會在 pmlogger_daily 執行時套用，這意味著若當日資料量異常，可能會在 00:10 前超出空間。請立即套用變更，無須等待計時器觸發：

sudo systemctl start pmlogger_daily
du -sh /var/log/pcp/pmlogger/$(hostname)

另一個手段是減少記錄量。主要記錄器的指標清單為 /var/lib/pcp/config/pmlogger/config.default，因為 pmlogger 會在 /var/lib/pcp/config/pmlogger 下解析非絕對路徑的 -c 名稱。請使用 pmlogconf 按群組進行編輯，而非手動修改：

sudo pmlogconf -r /var/lib/pcp/config/pmlogger/config.default
sudo systemctl restart pmlogger

它會逐一列出群組並詢問是否啟用，請拒絕您永遠不會讀取的群組。來自 proc 代理程式的「每處理程序指標」（per-process metrics）屬於高負載群組，因為它會記錄系統上每個處理程序的一組數值。

從封存檔重現事件

ls /var/log/pcp/pmlogger/$(hostname)
pmlogdump -l /var/log/pcp/pmlogger/$(hostname)/20260816
pmrep -a /var/log/pcp/pmlogger/$(hostname)/20260816 -S '@08:00' -T '@09:00' -t 5min -p :vmstat

請傳入基礎名稱 20260816。指定其中一個實體檔案（例如 20260816.0 或 20260816.meta）亦可，因為重現工具兩者皆支援。pmlogdump -l 會列印封存標籤，顯示該封存檔的來源主機與涵蓋的時間範圍。若該指令不存在，舊版 PCP 則稱為 pmdumplog。接著，使用 -S 與 -T 從封存檔中擷取特定時間視窗，並透過 -t 設定該視窗內的資料列頻率。

這正是保留封存檔的主要目的。當警報顯示系統在 08:40 發生故障時，封存檔能揭示 steal time 先行攀升，隨後磁碟活動才增加，這與您自行判斷的服務記憶體洩漏結論截然不同。事後無法再收集這些數據。若伺服器同時設定了定時修補，您也能透過相同的視窗化分析，判斷夜間效能下降是否與 dnf-automatic 套用安全性更新 或您自身的服務有關。

SMART PMDA 能在 VPS 虛擬磁碟上運作嗎？

SMART (Self-Monitoring, Analysis and Reporting Technology) 計數器存在於實體硬碟上。在 VPS 環境中，您僅是租戶，而您的 /dev/vda 通常是虛擬區塊裝置。底層是否能看到真實硬碟資訊取決於宿主機的決策，而非您能控制。因此，在安裝代理程式讀取數據前，請先檢查您伺服器本身的報告。

lsblk -d -o NAME,SIZE,ROTA,TRAN,MODEL
sudo dnf install -y smartmontools
sudo smartctl --scan
sudo smartctl -i /dev/vda
sudo smartctl -H /dev/vda

請直接讀取回傳結果，不要預設其功能。若 -i 能印出裝置型號與序號，且 -H 能印出健康評估，則代表底層裝置已透通，PCP 代理程式將能讀取數據。若系統回報無法偵測裝置類型，或顯示 SMART 支援不可用，則代表宿主機未將裝置透通給您，任何 PCP 設定變更皆無法解決此問題。若您的磁碟並非 /dev/vda，請使用 --scan 所報告的裝置名稱。

當 SMART 數據可用時，請加入代理程式：

sudo dnf install -y pcp-pmda-smart
cd /var/lib/pcp/pmdas/smart
sudo ./Install
pminfo smart
pminfo -f smart.health
pminfo -f smart.info.device_model
pminfo -f smart.attributes.reallocated_sector_count.raw

./Install 指令稿會將代理程式註冊至 pmcd，並將 smart 子樹加入命名空間，以便立即查詢指標。代理程式透過執行 smartctl 來讀取數據，其產生的錯誤會記錄至 /var/log/pcp/pmcd/smart.log 而非您的終端機。在 NVMe 裝置上，實用的名稱位於 smart.nvme_attributes 下，包含 percentage_used 與 media_and_data_integrity_errors。若某個指標存在但背後沒有數據，pminfo -f 會回傳 No value(s) available!，這代表代理程式已執行，但裝置未提供任何資訊。

若宿主機隱藏了裝置資訊，請改為監控行為而非韌體計數器：使用 disk.dev.avactive 觀察虛擬磁碟的忙碌程度，disk.all.read_bytes 與 disk.all.write_bytes 觀察吞吐量，以及 filesys.full 觀察真正導致伺服器停機的故障狀況。關於租戶能與不能獲取的儲存資訊，請參閱 VPS 上的磁碟健康監控。

設定會觸發通知的 pmie 規則

規則檔案是一組附帶動作的表達式。請將其寫入 /var/lib/pcp/config/pmie/vps.rules：

// any mounted filesystem over 90 percent full
some_inst (
    filesys.full > 90
) -> syslog "pcp: filesystem %i is over 90 percent full"
   & shell 60 min "/usr/local/bin/pcp-alert";

當至少有一個實例滿足條件時，some_inst 會使表達式成立，而訊息中的 %i 會展開為使條件成立的實例名稱。shell 動作中的 60 min 是抑制時間：動作執行後，pmie 在一小時內不會再次執行，這能避免磁碟空間不足時，每次評估都發出通知。請勿在 shell 指令中使用 %i，因為 pmie 會針對每個符合的實例重複整個參數來展開這些選擇器，這通常不是預期的指令行行為。syslog 字串也可以 -p 和 -t 開頭，pmie 會將其提取並以 logger 的方式傳遞。

檢查語法，然後在前台監控規則評估：

sudo -u pcp pmie -C -c /var/lib/pcp/config/pmie/vps.rules
sudo -u pcp pmie -v -t 10sec -c /var/lib/pcp/config/pmie/vps.rules

-C 會解析檔案，回報任何錯誤並在評估前退出。-v 會在每次取樣時列印每個表達式的值，讓您觀察規則讀取的實際數值。將閾值暫時調低至 1 即可觸發規則，這是驗證動作是否有效的唯一方法。按下 Ctrl+C 即可停止。

動作腳本可以執行任何您需要的操作。以下範例會發送請求至推播伺服器：

sudo tee /usr/local/bin/pcp-alert >/dev/null <<'EOF'
#!/bin/bash
curl -fsS -H 'Title: PCP alert' \
  -d 'filesystem over 90 percent full, see journalctl -t pmie' \
  https://ntfy.example.com/my-vps-alerts
EOF
sudo chmod 755 /usr/local/bin/pcp-alert

請將其指向您自己的端點。自行架設該接收器的方法請參考 自架 ntfy 推播伺服器。有一個細節決定了這些設定是否生效：作為 daemon，pmie 是以無特權的 pcp 帳號執行，因此 shell 動作也會以 pcp 身分執行。該腳本必須對該使用者具備可執行權限，讀取的任何 token 檔案也必須可讀，否則需要 root 權限的指令將會失敗。失敗原因會寫入 pmie 的 log 檔案，若通知未送達，請務必檢查該處。

將規則設為永久生效的獨立 pmie 實例：

sudo install -d -o pcp -g pcp /var/log/pcp/pmie/$(hostname)
sudo tee /etc/pcp/pmie/control.d/vps >/dev/null <<'EOF'
$version=1.1
LOCALHOSTNAME   n   n   PCP_LOG_DIR/pmie/LOCALHOSTNAME/vps.log   -c /var/lib/pcp/config/pmie/vps.rules -t 2min
EOF
sudo chmod 644 /etc/pcp/pmie/control.d/vps
sudo systemctl start pmie_check
sudo tail /var/log/pcp/pmie/$(hostname)/vps.log

這五個欄位分別是：監控的主機、是否為主要實例、是否需要 pmsocks、log 檔案路徑，以及傳遞給 pmie 的參數。LOCALHOSTNAME 是保留字，在第一個欄位會變為本機 pmcd，在路徑中則會變為您的主機名稱。主要實例欄位刻意設為 n，因為 pmie.service 只會啟動主要實例。任何額外的實例皆由 pmie_check 啟動，其計時器會在每小時的 28 分與 58 分執行，手動啟動只是為了跳過等待時間。控制檔案的規則是：除了 root 以外，任何使用者皆不得寫入。由 root 擁有（使用 sudo tee 設定）已符合此要求。但檔案必須保持可讀，因為 pmie_check.service 是以 pcp 使用者身分執行：若設為 600 等僅限 root 讀取的模式，pmie_check 將無法讀取該檔案，導致實例無法啟動。chmod 644 設定的權限模式與 PCP 安裝時對其自身 pmie 控制檔案所設定的相同。

若您不想手寫表達式，可以使用 pmieconf 來產生。sudo pmieconf rules 會列出已封裝的規則群組並顯示啟用狀態，而主要 pmie 會讀取由 pmieconf 維護的 /var/lib/pcp/config/pmie/config.default 檔案。這就是 pcp-zeroconf 所啟動的機制。手寫規則僅適用於您特有的條件，例如某個因特定應用程式而導致空間耗盡的目錄。

Performance Co-Pilot 的功能邊界

基礎安裝不包含網頁儀表板，也無法跨多台主機進行檢視。pmproxy 透過相同的指標提供 REST API，這正是 Grafana 的 PCP 資料來源所讀取的內容，也是繪製圖表的途徑。包含值班排程的警報路由也不在 pmie 的職責範圍內：pmie 負責執行動作，而該動作即為您編寫的指令稿。

PCP 負責回答單一主機上發生的狀況，提供高解析度的數據，且已預先安裝。中央監控伺服器屬於不同的工作範疇，具備各項服務檢查、使用者介面以及跨主機的警報功能。Zabbix 監控伺服器 可勝任此角色，而 Uptime Kuma 則用於回答服務是否仍有回應這類較簡單的問題。兩者並無衝突：pmcd 是監聽 44321 埠的本機 daemon，同一台伺服器上的其他代理程式既不會察覺也不會受到影響。

最實用的第一步是先觀察一週。讓 pmcd 與 pmlogger 持續執行，並限制封存目錄的大小；下次當伺服器在 03:00 變慢時，您將能取得 03:00 的實際數據，而非僅憑猜測。

FAQ

在 Rocky Linux 或 AlmaLinux 上使用 Performance Co-Pilot 需要安裝其他軟體嗎？

相關套件皆位於 AppStream 儲存庫中，因此 sudo dnf install -y pcp pcp-system-tools 即為完整的下載步驟，無需從發行版外部取得任何檔案。安裝 pcp 後服務不會自動啟動，請接著執行 sudo systemctl enable --now pmcd pmlogger，隨後執行 pminfo | wc -l 以確認收集器已回應。pcp-zeroconf 套件會自動啟用服務並將採樣頻率提升至 10 秒，在將其加入磁碟空間較小的伺服器前，請務必留意此點。

pmlogger 將封存檔儲存在哪裡，以及保留多久？

儲存於 /var/log/pcp/pmlogger/<hostname>，封存集名稱會以日期與時間命名。pmlogger_daily.timer 會在 00:10 執行，合併當日資料、進行壓縮，並預設刪除超過 14 天的封存檔。若要縮短保留時間，請在 /etc/pcp/pmlogger/control.d/local 的控制行上方加入 $ PCP_CULLAFTER=3。Rocky 9 與 Alma 9 中的 PCP 6.3.7 套件沒有大小限制。$PCP_SPACELIMIT 僅存在於 PCP 7.1.1（2026 年 3 月）及之後的版本，6.3.7 會忽略此設定，因此請根據伺服器每日產生的封存量來設定天數。請使用 du -sh /var/log/pcp/pmlogger/$(hostname) 查看目前的狀態。

為什麼我的 VPS 上 SMART PMDA 沒有回報任何數值？

因為 SMART 計數器來自實體硬碟，而您的磁碟通常是虛擬區塊裝置。在歸咎於 PCP 之前，請先執行 sudo smartctl -i /dev/vda：如果 smartctl 無法偵測裝置類型，或回報不支援 SMART，代表宿主機未暴露底層硬體資訊，代理程式將無法讀取任何資料。在此狀態下，指標仍存在於命名空間中，且 pminfo -f smart.health 會回應 No value(s) available!。來自代理程式本身的錯誤會記錄在 /var/log/pcp/pmcd/smart.log。請改為監控 disk.dev.avactive 與 filesys.full，因為這些指標描述的是您實際擁有的磁碟。

為什麼我的 pmie 規則從未觸發？

請依序排查。pmie -C -c <file> 可驗證檔案語法是否正確。sudo -u pcp pmie -v -t 10sec -c <file> 會在每次採樣時列印運算式數值，藉此觀察條件是否曾成立；將閾值降至 1 可強制觸發。若動作設定了如 60 min 的抑制時間，則每小時僅允許觸發一次。若規則在前台執行正常但作為服務執行時失敗，請記住 pmie.service 僅啟動主要實例，額外的控制檔案是由 pmie_check 啟動，該程序以 pcp 使用者身分執行，因此必須具備讀取控制檔案的權限。守護行程同樣以 pcp 身分執行，因此需要 root 權限的 shell 動作將會失敗。失敗原因會顯示在控制行指定的日誌檔案中。

我可以將 Performance Co-Pilot 與 Zabbix 或 Prometheus 同時執行嗎？

可以。pmcd 是監聽 TCP 44321 埠的本機守護行程，它不會影響其他代理程式的收集作業，因此 Zabbix agent 或 node exporter 可維持運作而不受影響。PCP 也能反向運作：OpenMetrics 代理程式可將現有匯出器的數據納入 PCP 命名空間，而 pmproxy 則透過 REST API 發布 PCP 指標供 Grafana 使用。常見的架構是利用 PCP 進行高解析度的本機歷史記錄，並由中央伺服器負責跨主機的告警。