為什麼需要監控?
沒有監控就像開車不看儀表板。引擎過熱、油箱快空,你渾然不知, 直到車子拋錨才察覺。線上服務也是一樣:問題往往已經持續了一段時間, 你卻要等到用戶回報才知道。
沒有監控的典型場景
用戶回報:「你們網站壞了」
工程師:「蛤?我這邊沒問題...」
... 查了 30 分鐘 ...
工程師:「喔是 DB connection pool 滿了」
「但我們不知道這個問題已經持續了 2 小時,影響了 40% 的用戶」
有監控的情況:
DB connection pool 使用率超過 80% 持續 2 分鐘 → 自動告警到 Slack
工程師在問題惡化前 20 分鐘收到通知並處理完畢
用戶完全感知不到異常
Four Golden Signals — SRE 黃金四信號
Google SRE 團隊提出的「四黃金信號」是監控設計的基礎框架。 如果你只能監控四個指標,就監控這四個。 它們能反映出絕大多數的系統問題。
01
Latency(延遲)
請求花了多長時間完成?
不只看平均值(Mean),更要看 P95、P99。平均 100ms 但 P99 是 5s,代表 1% 的用戶體驗很差。
http_request_duration_seconds02
Traffic(流量)
系統承受多少負載?
RPS(Requests Per Second)是最直觀的指標。流量突然暴增或驟降都是需要調查的信號。
http_requests_total03
Errors(錯誤率)
請求失敗的比例是多少?
5xx Server Error 的比例。低錯誤率(< 0.1%)是基本要求,超過 1% 通常需要立即告警。
rate(http_requests_total{status=~"5.."})04
Saturation(飽和度)
系統資源使用了多少?
CPU、Memory、DB connections、磁碟空間。飽和度高(>80%)預示著效能問題即將發生。
node_memory_MemAvailable_bytesPrometheus 資料模型
Prometheus 採用 Pull 模型:它定期主動去拉取(scrape)各個服務暴露的/metrics端點,而不是讓服務把資料推送進來。 這個設計讓 Prometheus 本身就能感知哪些服務還在運行,哪些已經掛掉。
四種 Metric 型別
Prometheus 定義了四種 Metric 型別,每種適用不同的場景。 選錯型別會讓後續查詢和圖表變得困難。
Histogram vs Summary 怎麼選?
Histogram(推薦)
- • 服務端計算,客戶端負擔低
- • 支援跨多個 instance 聚合(多機部署必備)
- • 可在 Prometheus 端用 histogram_quantile() 計算 P99
- • 缺點:需要預先定義 bucket 邊界
Summary
- • 客戶端計算,精確度高
- • 無法跨多個 instance 聚合
- • 適合單機服務或不需聚合的場景
- • 計算成本在客戶端
結論:多機部署的生產環境一律用 Histogram,配合 histogram_quantile() 計算百分位數。
在 Node.js 暴露 Metrics
prom-client 是 Node.js 最主流的 Prometheus client library, 提供了四種 Metric 型別的封裝,並自動收集 Node.js 系統預設指標。
PromQL 查詢語言
PromQL 是 Prometheus 的查詢語言,用於從時間序列資料中提取有意義的指標。 掌握以下幾個核心函數,就能寫出 Grafana Dashboard 所需的所有查詢。
PromQL 常用函數速查
rate(metric[5m])Counter 的每秒增長率(最常用)
increase(metric[1h])Counter 在時間窗口內的總增量
sum by(label)(expr)按指定 Label 分組聚合
avg by(label)(expr)按指定 Label 分組取平均
histogram_quantile(0.99, ...)從 Histogram 計算百分位數
delta(gauge[5m])Gauge 在時間窗口的變化量
predict_linear(metric[1h], 3600)線性預測未來 1 小時的值
topk(5, metric)取值最大的前 5 個 series
Grafana Dashboard 設計
Prometheus 收集資料,Grafana 做視覺化。先設定 Prometheus scrape 設定, 再連接 Grafana 建立 Dashboard。
標準服務 Dashboard 應包含的 Panel
一個完整的服務 Dashboard 應該讓 On-call 工程師在 10 秒內判斷服務是否健康。 以下是推薦的 Panel 組合,按重要性排序。
1. Overview Row(最上方大數字)
RPS、Error Rate、P99 Latency 三個 Stat Panel。一眼看出當前服務健康狀態。用顏色閾值:綠色(正常)→ 黃色(警告)→ 紅色(危急)。
sum(rate(http_requests_total[5m]))2. Request Rate Graph(折線圖)
按 HTTP method(GET/POST/DELETE)分線,顯示過去 24 小時的流量趨勢。可以快速判斷是否有異常流量。
sum by(method) (rate(http_requests_total[5m]))3. Latency Distribution Graph(P50/P95/P99 三條線)
三條百分位數曲線。P99 突然上升通常是資源瓶頸或慢 Query 的早期信號。
histogram_quantile(0.99, sum by(le) (rate(http_request_duration_seconds_bucket[5m])))4. Error Rate Graph(按 Status Code 分色)
500/502/503/504 各自一條線。不同錯誤碼代表不同問題:502/504 通常是上游問題,500 是應用程式 bug。
sum by(status) (rate(http_requests_total{status=~"5.."}[5m]))5. Resource Usage(CPU / Memory / Disk)
系統資源使用率。設定 80% 告警閾值。特別注意 Memory 持續緩慢上升,可能是記憶體洩漏。
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 1006. DB Connection Pool(DB 連線池使用率)
連線池使用率接近 100% 是嚴重的效能瓶頸。新的請求會被阻塞等待連線,P99 延遲會飆升。
db_connections_active / db_connections_pool_size * 100推薦直接 Import 的社群 Dashboard
Grafana 有社群分享的 Dashboard JSON,可以直接 Import 免去從頭建立的時間。 在 Grafana 介面選 Dashboards → Import,輸入以下 ID 即可。
#11159
Node.js Dashboard
process、heap、GC、event loop
#9628
PostgreSQL Dashboard
query time、connections、cache hit rate
#6417
Kubernetes Dashboard
pod、node、namespace 資源使用
AlertManager — 告警規則
AlertManager 負責接收 Prometheus 的告警,做去重(dedup)、分組(grouping)、 靜默(silencing),最後路由到不同的通知管道(Slack、PagerDuty、Email)。 告警規則定義在 Prometheus 的 rule 檔案中。
好的告警設計原則
- ✓告警要 Actionable(收到後知道該做什麼)
- ✓用 for: 避免瞬間尖峰誤報(至少 1-5 分鐘)
- ✓Critical 才打電話,Warning 發 Slack 即可
- ✓告警訊息包含足夠的上下文(哪台機器、當前值)
- ✓恢復時(resolved)也要發通知
常見的告警反模式
- ✗告警太多導致疲勞(Alert Fatigue),工程師開始忽略
- ✗沒有 for 子句,瞬間尖峰就觸發
- ✗告警訊息不清楚,需要查了才知道問題在哪
- ✗只告警症狀(CPU 高),沒有告警原因(慢查詢)
- ✗所有告警都用 Critical 等級