使用 AWS X-Ray 的分散式追蹤與結構化日誌

在 AWS 上部署應用程式

Dunieski Otano

Amazon Web Services Solutions Architect

大家找不到的慢請求

  • 有一個請求花了 4 秒
  • 各服務各自的日誌看起來都正常
  • 沒有人看得到完整路徑

放大鏡沿著分散式服務地圖追蹤一個慢速請求，紅色節點為瓶頸

在 AWS 上部署應用程式

分散式追蹤能解決什麼

左側是紅色、各服務各自孤立的日誌孤島；右側是綠色的 X-Ray Gantt 追蹤時間軸，將同一請求串起跨越 API Gateway、Lambda、DynamoDB 與外部 API

  • 一個請求會觸及多個服務
  • 只有日誌無法呈現端到端路徑
  • 追蹤（trace）把整個請求串起來
  • 清楚看到時間花在哪裡
在 AWS 上部署應用程式

Segments、Subsegments 與 Service map

  • Segment：單一服務完成的工作
  • Subsegment：Segment 內的單位，如資料庫呼叫
  • Service map：所有 Segment 的可視化圖
  • 每個節點都顯示延遲與錯誤

X-Ray 追蹤剖析：每個服務一個 segment，DB 呼叫為 subsegment，組成 service map 圖，節點上顯示延遲與錯誤率

在 AWS 上部署應用程式

Annotations 與 metadata 的差異

Annotations

  • 已索引的鍵值，可篩選
  • 用在你要搜尋的欄位，如客戶等級

Metadata

  • 額外細節，未索引
  • 可附加作為脈絡，但不能用來搜尋
在 AWS 上部署應用程式

用 trace ID 關聯日誌

  • 每個追蹤都有唯一的trace ID
  • 在你的結構化日誌中加入 trace ID
  • 從慢速追蹤跳到對應的日誌行
  • 日誌與追蹤合為一體化調查

結構化日誌行中突顯 xray_trace_id 欄位，箭頭自 X-Ray 追蹤檢視指向 CloudWatch Logs 中相符日誌行以進行關聯調查

在 AWS 上部署應用程式

讀 service map 尋找瓶頸

X-Ray 服務地圖中高延遲節點被標示，向下鑽研到追蹤時間軸，最長的 segment 條列為瓶頸

  • 先看service map，不是日誌
  • 找出延遲最高的節點
  • 鑽研進它的追蹤時間軸
  • 最長的 segment 就是嫌疑犯
在 AWS 上部署應用程式

跨完整請求的追蹤

  • API Gateway、Lambda 與下游呼叫都會被追蹤
  • 各自把segment 加入同一個追蹤
  • 一個 trace ID 連結日誌與 segments
  • 每個請求都有端到端可視性

從 API Gateway 經過 Lambda 到 DynamoDB 與外部 API 的端到端分散式追蹤，每個 segment 標頭都顯示相同 trace ID 以串聯所有日誌與 segments

在 AWS 上部署應用程式

一起來練習吧！

在 AWS 上部署應用程式

Preparing Video For Download...