效能監控
效能監控把主機、Gately 程序與各站台的效能資料放在一頁，並在指標持續超過門檻時經通知中心傳送告警，條件解除後再傳送一則恢復通知。管理介面位於側邊欄「系統」分組 →「效能監控」。
它針對「半夜 CPU 跑滿、某個站台連線數暴增、後端變慢沒人知道」這類情境，資料只保存在記憶體中。需要 24 小時以上的歷史、跨實例彙總或複雜查詢時，請使用 Prometheus 與 Grafana。
效能面板
頁面右上角可切換 60 秒、1 小時、24 小時三個時間檔。
主機與 Gately 程序
| 圖表 | 內容 |
|---|---|
| 主機 CPU | 整機所有核心的平均使用率 |
| 主機記憶體 / 磁碟 | 已用記憶體佔實體記憶體的比例（不含可回收快取），設定目錄所在分割區的已用比例 |
| 系統負載 | 1 分鐘負載 |
| Gately 程序 CPU | Gately 程序佔整機算力的比例，與主機 CPU 口徑一致 |
| Gately 程序記憶體 | 常駐記憶體（MB） |
| 檔案描述元 / 協程 | 程序開啟的檔案描述元數與 Go 協程數 |
後台每 5 秒取樣一次：60 秒檔每次取樣一個點；1 小時檔每分鐘一個點，取該分鐘的平均值；24 小時檔每 5 分鐘一個點。CPU 圖表中的虛線為每個點所在時段內的峰值，短暫的尖峰不會被平均值抹平。在圖表上懸停可檢視特定時刻的數值。
部分平台取不到某些指標（例如 macOS 上沒有 CPU 使用率），對應圖表顯示「暫無資料」。
站台
開啟 Web 服務模組時，列出全部執行中的站台（含預設站台）：
| 欄 | 說明 |
|---|---|
| 進行中 | 站台目前正在處理的請求數，包括 WebSocket 等長連線 |
| 每秒請求 | 最近約 60 秒的平均每秒請求數 |
| 5xx 比例 | 最近約 60 秒內 5xx 回應佔已完成回應的百分比 |
| 延遲 P95 | 最近約 60 秒首位元組延遲的 95 百分位估算值 |
| 後端 | 健康後端數 / 後端總數，以及目前轉送中的連線數 |
點擊站台開啟站台統計，檢視 24 小時的請求、錯誤與延遲趨勢。
首位元組延遲
延遲為「首位元組延遲」：從請求到達至回應標頭送出的時間，代表後端或站台本身的回應速度。以下情況不計入：
- 回應內容的傳輸時間（大檔案下載不會拉高延遲）；
- WebSocket 等協定升級請求；
- 被存取控制直接中斷、或被管理員中斷的請求。
每個請求依耗時落入 50 個細分檔（1 毫秒到 60 秒，相鄰檔相差約 10%~25%），每檔同時累計次數與總耗時，百分位取所在檔的平均耗時，誤差不超過檔寬，不保存單一請求的資料。Prometheus 匯出的 gately_site_request_duration_seconds 直方圖使用其中 13 個常用邊界。
告警規則
點擊「新增告警規則」。新建時可點擊範本預填常見規則（主機 CPU 過高、磁碟空間不足、站台 5xx 過多、站台回應變慢等），再依需要修改。
| 欄位 | 說明 |
|---|---|
| 名稱 | 必填，最多 64 個字元，出現在通知標題中 |
| 指標 | 見下表 |
| 門檻 | 比較符 >、>=、<、<= 加數值，單位由指標決定 |
| 持續時長 | 1 到 1440 分鐘。條件持續滿足這麼久才發出告警，中途回落一次即重新計時 |
| 生效站台 | 站台與後端節點類指標可選，留空表示全部站台 |
| 最少請求數 | 5xx 比例與延遲指標使用，預設 20。最近約 60 秒的請求少於此數時不判定，避免低流量時一兩個錯誤或慢請求就觸發告警 |
| 告警等級 | 警告或錯誤，決定通知事件的等級 |
| 備註、啟用 | 選填 |
| 指標 | 單位 | 判定對象 |
|---|---|---|
| 主機 CPU 使用率 | % | 本機 |
| 主機記憶體使用率 | % | 本機 |
| 主機磁碟使用率（設定目錄所在分割區） | % | 本機 |
| Gately 程序 CPU 使用率 | % | Gately 程序 |
| Gately 程序常駐記憶體 | MB | Gately 程序 |
| 站台進行中的請求數 | 個 | 每個站台 |
| 站台每秒請求數 | 次/秒 | 每個站台 |
| 站台 5xx 回應比例 | % | 每個站台 |
| 站台首位元組延遲 P95 | 毫秒 | 每個站台 |
| 後端節點目前連線數 | 個 | 每個後端節點 |
站台與後端節點類指標對每個對象單獨判定、單獨告警，例如一條「5xx 比例 > 5%」的規則可以同時對兩個站台分別告警。「站台每秒請求數 < 1」可以發現流量突然中斷。
判定與通知
- 後台每 5 秒評估一次全部啟用的規則。
- 條件開始滿足時進入「計時中」，持續滿足到設定時長後轉為「告警中」，並發布
perf.alert事件。 - 告警中的條件解除後發布
perf.recovered事件。站台的 5xx 比例與延遲在最近約 60 秒請求不足時無法判定，同樣視為解除，恢復通知會註明。 - 站台被刪除或停用時，它的告警直接清除，不傳送恢復通知。
頁面頂部列出計時中與告警中的對象、目前值與持續時間。
修改規則的名稱、等級或備註不影響進行中的計時；修改指標、門檻、持續時長、生效站台或最少請求數，或者停用規則，會清除該規則的計時與告警狀態。已觸發的告警會補發一條恢復通知，註明規則已刪除、停用或修改。計時與告警狀態只保存在記憶體中，重新啟動後重新開始。
告警經通知中心傳送，需要在通知中心新增訂閱「效能監控：觸發告警」與「效能監控：告警恢復」的規則（可用「效能告警」範本），否則告警只寫入本頁日誌，頁面上也會出現提示。通知中心的靜默對效能告警同樣有效，不同對象的事件來源不同，不會互相吞掉；持續時長已經起到去抖作用，一般不需要再設定靜默。
資源與限制
- 歷史只保存在記憶體中：主機與程序每分鐘一個點，保留 24 小時；站台延遲每分鐘保存 P50 與 P95，有流量的站台約佔 23 KB。
- 告警規則最多 200 條，一條規則最多指定 200 個站台。
- 開啟 Web 服務模組時，單一請求增加的開銷約為一次取時間與幾次計數。
監控指標
效能監控開啟時，/api/metrics 另外匯出最近一次取樣的主機與程序指標，以及各規則的告警數，詳見監控指標。
介面
| 介面 | 說明 |
|---|---|
GET /api/perf/overview?range=60s|1h|24h | 主機與程序歷史 |
GET /api/perf/sites | 各站台最近約 60 秒的指標 |
GET /api/perf/alerts | 計時中與告警中的對象 |
GET /api/perf/metrics | 可用於告警的指標 |
/api/perf/rules | 告警規則的增刪改查、啟停、排序與分組 |
讀取需要 perf:read 權限，修改規則需要 perf:write 權限，見 API 權杖。