DevOps 監控指南：Observability 與監控工具實作【2025】

系統掛了，使用者打電話來才知道——這是最糟糕的情況。好的監控系統應該讓你在使用者發現問題之前，就已經收到告警並開始處理。

監控是 DevOps 的關鍵環節。沒有監控，CI/CD 再快也沒意義，因為你不知道上線後系統是否正常。如果你還不熟悉 CI/CD，建議先閱讀 CI/CD 入門教學。這篇文章將帶你從基本概念到實作，建立完整的監控與可觀測性系統。

---

監控 vs 可觀測性（Observability）

這兩個詞經常混用，但有微妙差異。

傳統監控

傳統監控是「已知的已知」——你預先定義要監控什麼，設定告警條件，等待觸發。

特徵：

• 預先定義監控指標
• Dashboard 顯示關鍵數據
• 異常時觸發告警

限制：

• 只能監控預先想到的問題
• 遇到未知問題難以排查

可觀測性（Observability）

可觀測性是「未知的未知」——系統產出足夠的資料，讓你可以事後分析任何問題。

特徵：

• 系統產出完整的 Metrics、Logs、Traces
• 可以回答「為什麼會發生這個問題」
• 支援探索式的問題排查

比喻：

• 監控像是汽車儀表板，只顯示預設的資訊
• 可觀測性像是 OBD 診斷系統，可以查詢任何數據

想了解監控在整個 DevOps 流程中的定位，可以參考我們的 DevOps 完整指南。

---

Observability 三大支柱

可觀測性建立在三種資料類型上：Metrics、Logs、Traces。

Metrics（指標）

Metrics 是數值型的時間序列資料，用來表示系統狀態。

常見 Metrics 類型：

類型	說明	範例
Counter	只增不減的計數器	請求總數、錯誤次數
Gauge	可增可減的數值	CPU 使用率、記憶體用量
Histogram	數值分布	請求延遲分布
Summary	百分位數	P99 延遲

Metrics 範例（Prometheus 格式）：

# 請求總數
http_requests_total{method="GET", path="/api/users"} 12345

# 請求延遲直方圖
http_request_duration_seconds_bucket{le="0.1"} 1000
http_request_duration_seconds_bucket{le="0.5"} 1200
http_request_duration_seconds_bucket{le="1.0"} 1250

Logs（日誌）

Logs 是文字型的事件紀錄，用來記錄系統發生的事情。

Log 等級：

等級	用途	範例
DEBUG	開發除錯用	函數參數值
INFO	一般資訊	使用者登入成功
WARN	警告但不影響運作	API 回應較慢
ERROR	錯誤但系統仍運作	資料庫連線失敗（重試成功）
FATAL	嚴重錯誤，系統停止	無法啟動服務

結構化 Log 範例（JSON）：

{
  "timestamp": "2025-01-15T10:30:00Z",
  "level": "ERROR",
  "service": "user-service",
  "trace_id": "abc123",
  "message": "Database connection failed",
  "error": "connection timeout after 30s",
  "db_host": "db.example.com"
}

Traces（追蹤）

Traces 記錄請求的完整旅程，從進入系統到回應的每個步驟。

Trace 結構：

Trace ID: abc123
│
├── Span: API Gateway (50ms)
│   └── Span: User Service (30ms)
│       ├── Span: DB Query (15ms)
│       └── Span: Cache Lookup (5ms)
│
└── Total Duration: 50ms

Traces 的價值：

• 找出延遲發生在哪個服務
• 理解微服務間的呼叫關係
• 定位分散式系統的問題

插圖：Observability 三大支柱圖

場景描述： 一張三柱式的概念圖，左邊是 Metrics（用圖表線條代表）、中間是 Logs（用文字行代表）、右邊是 Traces（用連接的節點代表），三者上方連接到「Observability」標題，下方標示各自的用途。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: observability-three-pillars-diagram

---

DevOps 應該監控什麼？

四大黃金指標（Four Golden Signals）

Google SRE 提出的四個最重要的監控指標：

指標	說明	健康標準
Latency	請求延遲	P99 < 預期值
Traffic	流量 / QPS	在正常範圍內
Errors	錯誤率	< 1%
Saturation	資源飽和度	< 80%

USE Method（資源監控）

Brendan Gregg 提出的資源監控方法：

面向	監控內容
Utilization	資源使用率（CPU、Memory、Disk）
Saturation	排隊等待的工作量
Errors	錯誤事件數量

RED Method（服務監控）

適合監控微服務的方法：

面向	監控內容
Rate	每秒請求數
Errors	每秒錯誤數
Duration	請求延遲分布

DORA Metrics

DORA（DevOps Research and Assessment）定義的四個關鍵指標：

指標	說明	高效能團隊標準
部署頻率	多常部署到生產環境	每天多次
變更前置時間	從 Commit 到上線的時間	少於一天
服務恢復時間	從故障到恢復的時間	少於一小時
變更失敗率	部署導致問題的比例	0-15%

這四個指標讓你可以量化 DevOps 實踐的成效。

不確定該監控哪些指標？預約架構諮詢，讓我們幫你設計完整的監控策略。

---

監控工具介紹

工具全景圖

類別	工具	特色
Metrics	Prometheus	開源標準、Pull-based
Metrics	InfluxDB	時序資料庫
Visualization	Grafana	最強視覺化
Logs	Elasticsearch	全文搜尋
Logs	Loki	輕量、與 Grafana 整合
Traces	Jaeger	Uber 開源、CNCF 專案
Traces	Zipkin	Twitter 開源
APM	Datadog	全方位商業方案
APM	New Relic	全方位商業方案

---

Prometheus + Grafana 實作

這是最受歡迎的開源監控組合。

架構說明

┌─────────────┐     ┌─────────────┐
│   App +     │────>│ Prometheus  │
│  Exporter   │     │  (Metrics)  │
└─────────────┘     └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │   Grafana   │
                    │ (Dashboard) │
                    └─────────────┘

Prometheus 設定

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093

rule_files:
  - "alert_rules.yml"

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'app'
    static_configs:
      - targets: ['app:8080']

應用程式加入 Metrics

以 Node.js 為例：

const express = require('express');
const promClient = require('prom-client');

const app = express();

// 建立 Metrics Registry
const register = new promClient.Registry();

// 預設 Metrics
promClient.collectDefaultMetrics({ register });

// 自訂 Metrics
const httpRequestsTotal = new promClient.Counter({
  name: 'http_requests_total',
  help: 'Total number of HTTP requests',
  labelNames: ['method', 'path', 'status'],
  registers: [register]
});

const httpRequestDuration = new promClient.Histogram({
  name: 'http_request_duration_seconds',
  help: 'HTTP request duration in seconds',
  labelNames: ['method', 'path'],
  buckets: [0.1, 0.3, 0.5, 1, 3, 5, 10],
  registers: [register]
});

// Middleware 記錄 Metrics
app.use((req, res, next) => {
  const end = httpRequestDuration.startTimer({
    method: req.method,
    path: req.path
  });

  res.on('finish', () => {
    httpRequestsTotal.inc({
      method: req.method,
      path: req.path,
      status: res.statusCode
    });
    end();
  });

  next();
});

// Metrics Endpoint
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', register.contentType);
  res.end(await register.metrics());
});

PromQL 查詢範例

# 每秒請求數
rate(http_requests_total[5m])

# 錯誤率
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) * 100

# P99 延遲
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

# CPU 使用率
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

插圖：Prometheus + Grafana 架構圖

場景描述： 一張系統架構圖，顯示多個應用程式（標示 Exporter）連接到 Prometheus Server，Prometheus 連接到 Alertmanager 和 Grafana，使用者透過 Grafana 查看 Dashboard，標示資料流向箭頭。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: prometheus-grafana-architecture

---

日誌管理工具

ELK Stack vs Loki

面向	ELK Stack	Loki
全名	Elasticsearch + Logstash + Kibana	Grafana Loki
架構	全文索引	只索引 Label
資源需求	高	低
查詢能力	強大複雜查詢	較簡單
學習曲線	陡峭	平緩
適合場景	需要複雜搜尋	Grafana 生態系

Loki 設定範例

# loki-config.yaml
auth_enabled: false

server:
  http_listen_port: 3100

ingester:
  lifecycler:
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1

schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

storage_config:
  boltdb_shipper:
    active_index_directory: /loki/index
    cache_location: /loki/cache
  filesystem:
    directory: /loki/chunks

LogQL 查詢範例

# 查詢特定服務的錯誤日誌
{service="user-api"} |= "error"

# 使用正則表達式
{service="user-api"} |~ "status=[45].."

# 統計每分鐘錯誤數
count_over_time({service="user-api"} |= "error" [1m])

---

分散式追蹤

在微服務架構中，一個請求可能經過多個服務。分散式追蹤幫助你理解請求的完整路徑。

OpenTelemetry

OpenTelemetry 是 CNCF 的專案，提供統一的 Metrics、Logs、Traces 收集標準。

Node.js 整合範例：

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'http://jaeger:4318/v1/traces',
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Jaeger 架構

┌──────────────┐     ┌──────────────┐
│    App 1     │────>│   Jaeger     │
└──────────────┘     │   Collector  │
                     └───────┬──────┘
┌──────────────┐             │
│    App 2     │────────────>│
└──────────────┘             │
                             ▼
                     ┌──────────────┐
                     │   Storage    │
                     └───────┬──────┘
                             │
                             ▼
                     ┌──────────────┐
                     │   Jaeger UI  │
                     └──────────────┘

更多工具選擇與比較，可以參考 DevOps 工具完整指南。

---

雲端監控服務

主流雲端監控

雲端	服務名稱	特色
AWS	CloudWatch	AWS 服務深度整合
GCP	Cloud Monitoring	Stackdriver 前身
Azure	Azure Monitor	Application Insights 整合

全方位 APM 服務

服務	特色	適合團隊
Datadog	功能最全面、整合最廣	中大型團隊
New Relic	APM 起家、AI 告警	需要深度 APM
Dynatrace	AI 驅動、自動化	企業級需求

---

告警設計最佳實踐

告警設計不當會導致「告警疲勞」——太多無意義的告警讓團隊麻痺。

告警設計原則

1. 只告警可行動的事件

每個告警都應該有明確的處理步驟。如果收到告警後什麼都不用做，那就不該是告警。

2. 分級告警

等級	條件	通知方式
Critical	影響使用者、需立即處理	電話 + Slack
Warning	可能惡化、需要關注	Slack
Info	僅供記錄	Dashboard

3. 設定合理的閾值

# Prometheus Alert Rules
groups:
  - name: application
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error rate detected"
          description: "Error rate is {{ $value | humanizePercentage }}"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
          ) > 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High latency detected"
          description: "P99 latency is {{ $value | humanizeDuration }}"

4. 避免告警疲勞

• 合併相似告警
• 設定靜默期
• 定期檢視與調整告警

---

監控成熟度模型

五個階段

階段	特徵	能力
Level 1	被動監控	使用者回報才知道問題
Level 2	基礎監控	有 Dashboard，基本告警
Level 3	主動監控	完整 Metrics、Logs、告警分級
Level 4	可觀測性	Traces、Root Cause Analysis
Level 5	預測性	AIOps、異常預測、自動修復

自我評估

• 有 Dashboard 顯示系統狀態
• 有告警機制，不依賴使用者回報
• 告警有分級，Critical 不超過每週 5 次
• 可以追蹤一個請求的完整路徑
• 有 DORA Metrics 的量測
• 可以在 30 分鐘內定位問題根因

想了解更多關於 SRE 如何運用這些監控實踐，可以參考 DevOps vs SRE 比較。學習完整的 DevOps 技能路徑，請參考 DevOps 學習路線圖。

插圖：監控成熟度模型圖

場景描述： 一張階梯式的成熟度模型圖，從左下到右上依序標示五個階段：被動監控、基礎監控、主動監控、可觀測性、預測性，每個階段標示關鍵能力，階梯上方用不同顏色區分成熟度等級。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: monitoring-maturity-model-levels

---

常見問題 FAQ

監控系統本身需要監控嗎？

需要。建議用不同的服務來監控你的監控系統，或使用外部監控服務（如 UptimeRobot）監控內部服務是否存活。

Prometheus 適合長期儲存嗎？

Prometheus 預設只保留 15 天資料。長期儲存建議使用 Thanos 或 Cortex 等解決方案。

Log 要保留多久？

依據合規需求而定。一般建議：

• Hot storage：7-30 天
• Warm storage：90 天
• Cold storage：1-7 年（依法規）

自建 vs 使用 SaaS？

面向	自建	SaaS
成本	前期低、維護成本高	訂閱制、可預期
彈性	高度客製	功能固定
維護	需要專人	不需維護
建議	大團隊、合規需求	小團隊、快速啟用

如何處理告警風暴？

• 設定告警聚合
• 使用 inhibition rules 抑制相關告警
• 設定靜默期避免重複通知
• 事後檢視告警設計是否合理

---

結論

監控是 DevOps 實踐中不可或缺的一環。好的監控系統讓你：

1. 早期發現問題：在使用者之前知道異常
2. 快速定位根因：從 Metrics 到 Logs 到 Traces 的完整追蹤
3. 量化改進成效：用 DORA Metrics 衡量 DevOps 成熟度
4. 建立信心：對系統狀態有清楚的掌握

建議的實作順序：

1. 先建立基本 Metrics（Prometheus）
2. 加入視覺化（Grafana）
3. 設計告警機制
4. 整合 Log 管理
5. 導入分散式追蹤

監控不是一次性專案，而是持續改進的過程。從最痛的問題開始，逐步完善監控能力。

想建立完整的 Observability 系統，但不知從何開始？預約架構諮詢，我們幫你設計監控架構，從 Metrics 到 Traces 一次到位。