監控在發布中的作用#
監控是發布安全的最後一道防線。完善的監控體系可以在問題發生的第一時間發現異常，為快速回滾爭取時間。
發布後的監控不是可選項，而是必須項。沒有監控的發布就像閉著眼睛開車。
發布監控的目標#
| 目標 | 說明 |
|---|---|
| 快速發現 | 問題發生後盡快被監控系統捕獲 |
| 精確定位 | 能夠快速確定問題根因 |
| 影響評估 | 了解問題影響的範圍和程度 |
| 輔助決策 | 為是否回滾提供資料支撐 |
五類監控指標#
發布監控應該覆蓋從用戶端到系統底層的完整鏈路。
1. 用戶端監控#
用戶端監控捕獲最終用戶的真實體驗。
關鍵指標：
| 指標 | 說明 | 告警閾值範例 |
|---|---|---|
| 頁面載入時間 | 從請求到完成渲染 | > 3s |
| 首屏時間 | 首屏內容完成渲染 | > 1.5s |
| JavaScript 錯誤率 | 前端錯誤比例 | > 1% |
| 崩潰率 | App 崩潰比例 | > 0.1% |
採集方式：
- Web: 埋點 SDK、Performance API
- App: Crash 收集 SDK、效能監控 SDK
// Web Performance API 範例
const timing = performance.timing;
const pageLoadTime = timing.loadEventEnd - timing.navigationStart;
const ttfb = timing.responseStart - timing.navigationStart;
reportMetrics({
pageLoadTime,
ttfb,
userAgent: navigator.userAgent,
});2. 網路監控#
網路監控關注資料傳輸的可用性和效能。
關鍵指標：
| 指標 | 說明 | 告警閾值範例 |
|---|---|---|
| CDN 命中率 | CDN 快取命中比例 | < 90% |
| DNS 解析時間 | 域名解析耗時 | > 100ms |
| TCP 建連時間 | TCP 握手耗時 | > 200ms |
| SSL 握手時間 | TLS 建連耗時 | > 300ms |
監控點位：
- CDN 邊緣節點
- 負載均衡器
- API Gateway
3. 業務監控#
業務監控關注核心業務流程的健康狀況。
業務監控是最直接反映發布影響的指標。技術指標可能正常，但業務指標異常，說明存在邏輯問題。
關鍵指標範例（電商場景）：
| 指標 | 說明 | 告警閾值範例 |
|---|---|---|
| 下單成功率 | 訂單創建成功比例 | < 99% |
| 支付成功率 | 支付完成比例 | < 95% |
| 購物車添加量 | 每分鐘添加次數 | 環比下降 > 30% |
| 用戶登入量 | 每分鐘登入次數 | 環比下降 > 50% |
業務監控儀表板範例：
┌─────────────────────────────────────────────────────────┐
│ 業務監控儀表板 │
├─────────────────────────────────────────────────────────┤
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 下單成功率 │ │ 支付成功率 │ │ 登入用戶數 │ │
│ │ 99.2% │ │ 95.8% │ │ 12,345 │ │
│ │ ↓ 0.3% │ │ ↑ 0.5% │ │ ↑ 15% │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
├─────────────────────────────────────────────────────────┤
│ 訂單量趨勢 (過去 1 小時) │
│ ████████████████████░░░░ │
│ 13:00 13:15 13:30 13:45 14:00 │
└─────────────────────────────────────────────────────────┘4. 應用監控（APM）#
應用效能監控（APM）深入應用內部，追蹤請求的完整鏈路。
關鍵指標：
| 指標 | 說明 | 告警閾值範例 |
|---|---|---|
| 響應時間 | 請求處理耗時 | P99 > 500ms |
| 吞吐量 | 每秒處理請求數 | 環比下降 > 20% |
| 錯誤率 | 請求失敗比例 | > 1% |
| 呼叫鏈延遲 | 服務間呼叫耗時 | > 100ms |
分散式追蹤：
請求 ID: abc123
[Gateway] 0ms ─────────────────────────────────────── 150ms
│
└─[User Service] 10ms ─────────────── 80ms
│
└─[DB Query] 20ms ───── 50ms
│
└─[Order Service] 15ms ──────────────────── 120ms
│
└─[Payment API] 30ms ────────── 100ms常用 APM 工具：
- 商業：New Relic、Dynatrace、AppDynamics
- 開源：Jaeger、Zipkin、SkyWalking
APM 核心概念
Trace（追蹤） 一次完整請求的執行路徑，包含多個 Span。
Span（跨度） 追蹤中的單個操作，如一次 HTTP 呼叫、資料庫查詢。
Tag（標籤） 附加在 Span 上的鍵值對，用於篩選和分析。
範例：
{
"traceId": "abc123",
"spans": [
{
"spanId": "span1",
"operationName": "HTTP GET /users",
"duration": 150,
"tags": {
"http.status_code": 200,
"service.name": "user-service"
}
},
{
"spanId": "span2",
"parentSpanId": "span1",
"operationName": "MySQL SELECT",
"duration": 30
}
]
}5. 系統監控#
系統監控關注基礎設施層面的資源使用情況。
關鍵指標：
| 類別 | 指標 | 告警閾值範例 |
|---|---|---|
| CPU | 使用率 | > 80% |
| 記憶體 | 使用率 | > 85% |
| 磁碟 | 使用率 | > 90% |
| 網路 | 帶寬使用率 | > 70% |
| JVM | GC 暫停時間 | > 1s |
| JVM | 堆記憶體使用 | > 85% |
常用監控工具：
- 採集：Prometheus、Telegraf、collectd
- 展示：Grafana、Datadog
- 告警：Alertmanager、PagerDuty
發布監控策略#
發布前：建立基線#
在發布前記錄系統的正常狀態，作為對比基準。
基線指標：
- 響應時間 P99: 200ms
- 錯誤率: 0.1%
- QPS: 10,000
- CPU 使用率: 40%發布中：密切觀察#
發布過程中需要實時監控關鍵指標的變化。
監控重點：
- 錯誤日誌是否有新增異常
- 響應時間是否有明顯上升
- 錯誤率是否有波動
- 資源使用是否有異常
發布過程中的任何異常指標都應該謹慎對待。寧可過度反應，也不要忽視潛在問題。
發布後：持續驗證#
發布完成後的一段時間內（如 30 分鐘到數小時），需要持續關注系統狀態。
驗證清單：
- 各項指標是否回到正常範圍
- 是否有新的錯誤類型
- 用戶反饋是否有異常
- 下游服務是否受影響
告警設計#
告警分級#
| 等級 | 說明 | 響應時間 | 通知方式 |
|---|---|---|---|
| P0 | 核心功能不可用 | 立即 | 電話 + 短信 |
| P1 | 功能嚴重受損 | 15 分鐘 | 短信 + IM |
| P2 | 功能部分受損 | 1 小時 | IM + 郵件 |
| P3 | 非關鍵問題 | 下個工作日 | 郵件 |
告警規則設計#
避免告警風暴：
# 不好的告警規則
alert: HighErrorRate
expr: error_rate > 0.01
for: 0m # 立即告警
# 改進後的告警規則
alert: HighErrorRate
expr: error_rate > 0.01
for: 5m # 持續 5 分鐘才告警
labels:
severity: warning
annotations:
summary: "Error rate above 1% for 5 minutes"告警聚合：
# 將相關告警聚合
group_by: [service, environment]
group_wait: 30s # 收集告警
group_interval: 5m # 發送間隔
repeat_interval: 4h # 重複告警間隔告警處理流程#
flowchart TD
A[告警觸發] --> B[告警路由分發]
B --> C[值班人員確認]
C --> D[問題分析定位]
D --> E{決策}
E -->|修復| F[執行修復]
E -->|回滾| G[執行回滾]
F --> H[驗證恢復]
G --> H
H --> I[事後覆盤]
C -.- C1((確認告警有效性))
D -.- D1((使用監控資料))
E -.- E1((基於影響評估))監控驅動的發布決策#
自動回滾#
當監控指標超過閾值時，可以觸發自動回滾。
# 自動回滾規則範例
auto_rollback:
enabled: true
conditions:
- metric: error_rate
threshold: 5%
duration: 3m
- metric: response_time_p99
threshold: 2000ms
duration: 5m
cooldown: 30m # 回滾後的冷卻期自動回滾是把雙刃劍。設定過於敏感可能導致不必要的回滾；設定過於寬鬆則失去保護作用。需要根據業務特點仔細調整閾值。
金絲雀發布的監控#
金絲雀發布需要對比新舊版本的指標差異。
┌─────────────────────────────────────────────────────────┐
│ 金絲雀對比監控 │
├─────────────────────────────────────────────────────────┤
│ 舊版本 (90%) 新版本 (10%) │
│ │
│ 錯誤率: 0.1% 0.15% ⚠️ +50% │
│ 響應時間: 120ms 125ms ✓ +4% │
│ CPU: 45% 48% ✓ +7% │
│ │
│ 建議：繼續觀察，錯誤率有上升趨勢 │
└─────────────────────────────────────────────────────────┘對比指標：
- 錯誤率差異
- 響應時間差異
- 資源使用差異
決策邏輯：
- 差異在容許範圍內：繼續擴大流量
- 差異超出容許範圍：暫停或回滾
- 無法判斷：延長觀察時間
SLO 與發布監控
SLO（服務等級目標）可以指導發布監控的閾值設定。
SLI / SLO / SLA 關係：
- SLI（指標）：可用性 = 成功請求 / 總請求
- SLO（目標）：可用性 > 99.9%
- SLA（協議）：如果未達 SLO，賠償客戶
錯誤預算（Error Budget）：
月度 SLO: 99.9%
允許的停機時間: 30天 × 24小時 × 60分鐘 × 0.1% = 43.2 分鐘
如果本月已用完錯誤預算，應該暫停非關鍵發布。發布監控與 SLO 結合：
- 發布前檢查當前錯誤預算餘額
- 發布中監控 SLI 變化
- SLI 惡化時評估對錯誤預算的影響
- 錯誤預算耗盡時觸發回滾
監控體系建設#
監控覆蓋清單#
□ 用戶端監控
□ 頁面效能
□ 前端錯誤
□ 用戶行為
□ 網路監控
□ CDN 狀態
□ DNS 解析
□ SSL 憑證
□ 業務監控
□ 核心業務指標
□ 業務異常
□ 轉化漏斗
□ 應用監控
□ 請求追蹤
□ 服務依賴
□ 日誌聚合
□ 系統監控
□ 伺服器資源
□ 容器狀態
□ 中介軟體監控成熟度評估#
| 等級 | 特徵 | 能力 |
|---|---|---|
| L1 | 基礎監控 | 能發現問題 |
| L2 | 告警組態 | 能通知問題 |
| L3 | 集中展示 | 能快速定位 |
| L4 | 鏈路追蹤 | 能深入分析 |
| L5 | 智能運維 | 能自動處理 |
總結#
監控是發布品質的最後一道保障，完善的監控體系可以顯著提升發布的安全性和效率。
關鍵要點：
五類監控全覆蓋
- 用戶端：捕獲真實用戶體驗
- 網路：監控傳輸層健康
- 業務：反映業務流程狀態
- 應用：深入應用內部追蹤
- 系統：監控基礎設施資源
發布監控策略
- 發布前建立基線
- 發布中密切觀察
- 發布後持續驗證
告警設計
- 合理分級
- 避免告警風暴
- 建立處理流程
監控驅動決策
- 支援自動回滾
- 指導金絲雀發布
- 結合 SLO 管理
監控體系的建設是一個持續演進的過程。從基礎監控開始，逐步完善告警、追蹤、智能分析能力。最終目標是讓監控成為發布的「安全網」——即使出現問題，也能快速發現和恢復。