AWS 服務系列（七）：監控與可觀測性 - CloudWatch、X-Ray 與 CloudTrail 全方位監控

前言

在分散式系統中，「系統是否正常運作？」已經不再是一個簡單的是非題。我們需要知道「為什麼回應變慢了？」、「哪個服務出現瓶頸？」、「是誰修改了這個設定？」。這就是**可觀測性（Observability）**的核心價值。

AWS 提供了強大的監控三劍客：CloudWatch（監控與日誌）、X-Ray（分散式追蹤）與 CloudTrail（稽核紀錄）。本篇將教你如何整合這三個工具，構建全方位的監控體系。

本篇重點：

可觀測性三大支柱：Metrics、Logs、Traces
CloudWatch Metrics 與 Alarm 警報策略
CloudWatch Logs Insights 進階查詢技巧
X-Ray 分散式追蹤實戰
CloudTrail 安全稽核與故障排查

可觀測性三大支柱

graph TD
    subgraph "Observability"
        A[Metrics 指標] -->|CloudWatch Metrics| D[趨勢分析、警報]
        B[Logs 日誌] -->|CloudWatch Logs| E[錯誤詳情、上下文]
        C[Traces 追蹤] -->|AWS X-Ray| F[請求路徑、效能瓶頸]
    end
    
    D --> G[儀表板]
    E --> G
    F --> G

支柱	關注點	AWS 服務	範例
Metrics	發生了什麼？(What)	CloudWatch Metrics	CPU 使用率 80%、HTTP 500 次數
Logs	為什麼發生？(Why)	CloudWatch Logs	`Error: Connection timeout`
Traces	在哪裡發生？(Where)	AWS X-Ray	Service A -> Service B (2s delay)

CloudWatch：監控的核心

CloudWatch 是 AWS 的統一監控服務，收集指標、日誌和事件。

Metrics 與 Alarms

標準指標 vs 自定義指標：

標準指標：AWS 自動收集（如 EC2 CPU、RDS 連線數）。
自定義指標：應用程式主動發送（如活躍使用者數、訂單金額）。

警報策略最佳實踐：

設定多層級警報：
- Warning (警告)：CPU > 70%，發送 Slack 通知（不需立即處理）。
- Critical (嚴重)：CPU > 90%，發送 PagerDuty/簡訊（需立即處理）。
使用複合警報 (Composite Alarms)：
- 避免警報風暴。例如：只有當 “CPU 高” 且 “延遲高” 時才觸發。

CloudWatch Logs Insights

Logs Insights 提供了強大的查詢語法，讓你能在數百萬條日誌中快速找到問題。

實用查詢範例：

找出最近 20 筆錯誤日誌：

fields @timestamp, @message
| filter @message like /Error/ or @message like /Exception/
| sort @timestamp desc
| limit 20

統計每 5 分鐘的 API 請求次數：

1
2
3

fields @timestamp, path, method
| stats count(*) as requestCount by bin(5m)
| sort requestCount desc

分析 Lambda 執行時間與記憶體使用：

1 2	filter @type = "REPORT" \| stats avg(@duration), max(@duration), max(@maxMemoryUsed) by bin(1h)

結構化日誌 (Structured Logging)：
強烈建議應用程式輸出 JSON 格式的日誌，這樣 Insights 才能自動解析欄位。

// 好的日誌格式
{
    "level": "error",
    "userId": "12345",
    "action": "checkout",
    "error": "payment_gateway_timeout",
    "latency": 5000
}

X-Ray：分散式追蹤

為什麼需要 X-Ray？

在微服務架構中，一個請求可能經過 API Gateway -> Lambda -> DynamoDB -> SNS。如果請求變慢，很難知道是哪一環出了問題。X-Ray 提供了Service Map和Trace Timeline，讓你一目了然。

sequenceDiagram
    participant Client
    participant API as API Gateway
    participant Lambda
    participant DB as DynamoDB
    
    Client->>API: Request (Trace ID: 1-abc...)
    API->>Lambda: Invoke (帶入 Trace ID)
    Lambda->>DB: Query (帶入 Trace ID)
    DB-->>Lambda: Result
    Lambda-->>API: Response
    API-->>Client: Response
    
    Note over Client,DB: X-Ray 記錄完整的呼叫鏈路與耗時

Go 語言整合 X-Ray

要在 Go 應用程式中啟用 X-Ray，需要使用 AWS X-Ray SDK。

package main

import (
    "context"
    "github.com/aws/aws-lambda-go/lambda"
    "github.com/aws/aws-sdk-go-v2/config"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb"
    
    // X-Ray SDK
    "github.com/aws/aws-xray-sdk-go/xray"
    "github.com/aws/aws-xray-sdk-go/instrumentation/awsv2"
)

var dbClient *dynamodb.Client

func init() {
    cfg, _ := config.LoadDefaultConfig(context.Background())
    
    // 關鍵：對 AWS Client 進行插樁 (Instrumentation)
    awsv2.AWSV2(cfg)
    
    dbClient = dynamodb.NewFromConfig(cfg)
}

func handler(ctx context.Context) error {
    // 建立自定義 Subsegment
    ctx, seg := xray.BeginSubsegment(ctx, "CustomLogic")
    defer seg.Close(nil)
    
    // 模擬業務邏輯
    // ...
    
    // 呼叫 DynamoDB (會自動被 X-Ray 記錄)
    _, err := dbClient.ListTables(ctx, &dynamodb.ListTablesInput{})
    
    if err != nil {
        // 記錄錯誤到 X-Ray
        seg.AddError(err)
        return err
    }
    
    return nil
}

func main() {
    lambda.Start(handler)
}

X-Ray 採樣規則 (Sampling Rules)：

預設採樣：每秒第一個請求 + 其餘請求的 5%。
生產環境建議根據流量調整，避免產生過多 Trace 資料導致成本增加。

CloudTrail：稽核與合規

CloudTrail 記錄了 AWS 帳號內的所有 API 呼叫活動。這對於安全稽核和故障排查至關重要。

Event History vs Trails

特性	Event History	Trails
範圍	唯讀，最近 90 天	可長期保存到 S3
費用	免費	S3 儲存費用
功能	簡單搜尋	進階分析 (Athena)、跨帳號聚合
事件類型	管理事件 (Management Events)	管理事件 + 資料事件 (Data Events)

實戰：誰刪除了我的 EC2？

當發生意外變更時，CloudTrail 是你的第一線調查工具。

查詢步驟：

進入 CloudTrail Console -> Event history
Filter: Event name = TerminateInstances
查看 User name 和 Source IP address

CloudTrail 與 CloudWatch Logs 整合

將 CloudTrail 日誌發送到 CloudWatch Logs，可以設定警報。例如：當有人嘗試登入 Root 帳號時發送通知。

// CloudWatch Metric Filter Pattern
{
    "userIdentity": {
        "type": "Root"
    }
}

實戰：全方位故障排查流程

假設你收到了一個 “API 回應過慢” 的警報，該如何使用這三套工具進行排查？

Step 1: CloudWatch Metrics (發現問題)

查看 API Gateway 的 Latency 指標，確認是持續性變慢還是偶發尖峰。
查看 5XXError 指標，確認是否有錯誤發生。

Step 2: X-Ray (定位瓶頸)

打開 X-Ray Service Map，找出變紅或變黃的節點。
點擊 Trace Timeline，發現是 DynamoDB 的回應時間異常長。
查看該 Segment 的詳細資訊，發現是 Scan 操作耗時過久。

Step 3: CloudWatch Logs (深入細節)

使用 Trace ID 在 CloudWatch Logs Insights 中搜尋相關日誌。
發現應用程式日誌顯示 “Scan operation processed 1000 items”，確認是因為全表掃描導致效能問題。

Step 4: CloudTrail (追查原因)

懷疑是最近的部署或設定變更導致。
查詢 CloudTrail，發現昨天有開發者修改了 DynamoDB 的索引設定，或者部署了新的程式碼版本。

構建監控儀表板 (Dashboard)

CloudWatch Dashboard 可以將不同服務的指標整合在一個頁面。

建議的 Dashboard 佈局：

總體健康狀況 (Overall Health)
- 系統可用性 (Availability %)
- 請求總量 (Request Count)
- 平均延遲 (Average Latency)
關鍵資源指標 (Key Resources)
- EC2/ECS CPU & Memory
- RDS CPU & Connections
- SQS Queue Depth (堆積數量)
業務指標 (Business Metrics)
- 訂單成立數
- 支付成功率
- 活躍使用者數