分析追蹤與服務地圖

AWS 監控與疑難排解

John Q. Martin

Principal Consultant

什麼是服務地圖？

從你的追蹤資料自動產生：無需手動設定

火車出發看板，列出多個服務，各有彩色狀態燈：綠色準時、橙色延遲、紅色停止

一眼判讀：綠色＝正常 · 橙色＝延遲 · 紅色＝停止

進入方式：

X-Ray 主控台 → Service map
套用篩選器
點選節點 → 檢視詳細分解

服務地圖顏色編碼

服務地圖顏色圖例：綠成功、黃用戶端錯誤、紅伺服端故障、紫節流、灰無流量

開啟服務地圖時，先找不是綠色的部分。

點任一節點可看：回應時間分佈、HTTP 狀態分解、錯誤類型。

如何閱讀服務地圖

服務地圖：API Gateway 與 OrderService 向外連到 DynamoDB Inventory，Payment 服務呈現黃色

臨界路徑分析

臨界路徑＝最長的服務呼叫鏈

API Gateway (50ms)
  -> OrderService (50ms)
    -> PaymentService (100ms)
      -> External API (200ms)

Total: 400ms

External API＝總延遲的 50%

可怎麼做：

External API 是你的最佳化目標
選項：加入快取、實作逾時＋後援、協商 SLA

比較替代路徑：

OrderService -> DynamoDB
Total: 120ms (快)

相依風險

服務地圖相依風險：環狀相依、單點故障與高風險外部相依

理解追蹤時間軸

追蹤時間軸：沿時間軸的子區段，顯示 payment-api 呼叫為最長操作

水平軸 時間：操作開始時間與持續時間
垂直軸 服務階層：子區段縮排於父節點下
對 payment-api 的 HTTP.POST（100–250ms）＝最長單一操作

模式 1：序列瓶頸

前（序列化－80ms）：

Query 1 (10-30ms)
         -> Query 2 (30-50ms)
                  -> Query 3 (50-70ms)
                           -> Query 4 (70-90ms)

後（平行化－20ms）：

四個查詢並行重疊執行，20ms 完成的追蹤時間軸

模式 2：N+1 查詢與聒噪式服務

N+1 查詢問題：

Get user list       (10-20ms)
Get user 1 details  (20-30ms)
Get user 2 details  (30-40ms)
... ×100 sequential queries

修正：批次查詢、預先載入（eager loading）

聒噪式服務（Chatty Services）：

兩個服務之間用 50 次小呼叫，取代 1 次批次呼叫
每次呼叫都要連線建立＋序列化＋往返
開銷放大 50 倍

修正：批次請求、訊息佇列、快取

模式 3：冷啟動與連鎖性故障

兩條時間軸：冷啟動有大片橘色初始化區段加小綠色處理器；熱啟動只有小綠色處理器

Lambda 冷啟動：

冷啟動：3000ms（初始化 2500ms＋處理器 500ms）
熱啟動：500ms（僅處理器）
首次呼叫可見大型初始化區段

修正：設定預置並行、最佳化初始化

連鎖性故障：

Service A [Error]
  -> Service B [Timeout 5s]
    -> Service C [Timeout 5s]
      -> Database [Timeout 5s]

相同的逾時區塊沿追蹤階層往下堆疊

修正：逾時、斷路器、後援機制

用註解篩選追蹤

X-Ray 主控台以註解鍵值配對篩選追蹤

比較群組：

付費用戶平均 200ms vs. 免費用戶平均 150ms → 付費功能增加延遲
EU West 比 US East 慢 3 倍 → 跨區資料存取問題

追蹤分析流程

識別－篩選：response_time > 1000ms，依持續時間排序
分析－找最長操作、序列瓶頸、平行化機會
註解－檢查與業務情境相關的註解：user ID、order ID、environment
檢閱－查看中繼資料：請求細節、錯誤訊息
關聯－與 CloudWatch Logs 交叉比對
診斷－根因：慢查詢、逾時、演算法、資源耗盡
修正－最佳化程式碼、加上快取、平行化、擴充
驗證－比較修正前後追蹤，監看延遲與錯誤率

從 X-Ray 資料建立警示

# 高延遲警示
aws cloudwatch put-metric-alarm \
  --alarm-name HighLatency \
  --metric-name ResponseTime \
  --namespace AWS/XRay \
  --statistic Average \
  --period 300 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold

# 高錯誤數警示
aws cloudwatch put-metric-alarm \
  --alarm-name HighErrorCount \
  --metric-name ErrorCount \
  --namespace AWS/XRay \
  --statistic Sum \
  --period 300 \
  --threshold 50 \
  --comparison-operator GreaterThanThreshold

影片重點總結

Service maps－自動產生的架構圖：節點（服務）、邊（連線）、顏色顯示健康狀態
顏色編碼－綠（成功）、黃（4xx）、紅（5xx 故障）、紫（429）、灰（無流量）
臨界路徑－最長呼叫鏈，找出你的最佳化目標
追蹤時間軸－揭露序列瓶頸、N+1 查詢、冷啟動、連鎖性故障
註解－依業務情境篩選與分組追蹤
流程－八步驟：identify → analyze → annotate → review → correlate → diagnose → fix → verify

分析追蹤與服務地圖

AWS 監控與疑難排解