AWS X-Ray — 分散式追蹤與應用程式效能

AWS X-Ray 分散式追蹤解決了 DevOps 工程師在處理事件時最痛苦的問題：在包含 17 個微服務的請求鏈中，延遲或錯誤究竟源自哪裡？ 僅靠日誌無法回答這個問題 —— 日誌散落在各個服務的孤島中，且缺乏跨服務的關聯性。指標可以提供摘要，但無法進行追蹤。X-Ray（以及其現代化的 OpenTelemetry 基於 ADOT 的模式）將完整的請求路徑重建為一條追蹤 (trace)，由多個區段 (segments)（每個服務一個）和次區段 (subsegments)（服務內部的每個外傳呼叫一個）組成。這讓你能查看服務圖 (service map)、深入分析緩慢的跨度 (span)，並與日誌和指標進行關聯。DOP-C02 要求你了解如何儀表化 (instrument) 每個運算平台（Lambda、ECS、EKS、EC2、內部部署）、挑選正確的取樣規則以限制成本、跨 SQS / SNS / EventBridge 傳播追蹤上下文，以及將 X-Ray 與 CloudWatch ServiceLens 整合以實現統一的可觀察性。

本指南假設你了解分散式追蹤的基本前提（追蹤 ID、父子跨度關係），且至少看過一次 X-Ray 主控台。重點在於 DOP-C02 的實作深度：區段 vs 次區段 vs 註釋 (annotations) vs 中繼資料 (metadata)、守護程序和 SDK 層級的取樣規則、EC2/ECS-on-EC2 上的 X-Ray 守護程序模型與 Lambda 和 Fargate 上的 AWS 代管擷取、Java/Node.js/Python/.NET/Go/Ruby 的 X-Ray SDK、作為新儀表化戰略繼承者的 AWS Distro for OpenTelemetry (ADOT)、追蹤上下文標頭 (X-Amzn-Trace-Id) 及其跨非同步邊界的傳播、用於追蹤模式異常偵測的 X-Ray 洞察 (Insights)、用於篩選的 X-Ray 群組、追蹤資料的 KMS 加密，以及將 X-Ray 追蹤與 CloudWatch 指標和日誌融合到單一主控台的 ServiceLens。網域 4.2（稽核、監控和分析日誌與指標以偵測問題）和網域 5.3（對系統和應用程式故障進行疑難排解）涵蓋了此內容。

為什麼 X-Ray 分散式追蹤對 DOP-C02 很重要

分散式追蹤是唯一能原生跨越服務的可觀察性工具。CloudWatch 指標一次只能看到一個服務。CloudWatch Logs 一次只能看到一個日誌群組。沒有追蹤，「訂單 API 很慢」會變成一場涉及 12 個服務、耗時數日的調查。有了 X-Ray，服務圖能在一個螢幕上顯示緩慢的節點，追蹤時間軸則能顯示具體是哪個下游呼叫消耗了時間。DOP-C02 在網域 4.2 和 5.3 中非常看重這項技能。多份考後報告將「X-Ray 服務圖」和「追蹤上下文傳播」列為高頻考試主題。

這裡的考試風格是豐富的整合情境。典型的題幹如下：「一個 API Gateway → Lambda → DynamoDB → SQS → Lambda → DynamoDB 鏈顯示 P99 延遲為 4 秒，且沒有明顯的罪魁禍首。哪兩個變更可以幫助團隊隔離緩慢的鏈接？」錯誤答案通常圍繞「增加日誌詳細程度」或「啟用 CloudWatch 詳細監控」。正確的一對是：在每個 Lambda 和 API Gateway 上啟用 X-Ray，並在 SQS 訊息屬性中傳播追蹤上下文。考試測試你是否知道哪些運算平台需要守護程序、哪些會自動儀表化，以及哪些需要跨隊列和事件匯流排手動傳播上下文。

白話文解釋 X-Ray 分散式追蹤

分散式追蹤在概念上不同於日誌或指標，沒接觸過的工程師有時會將其誤認為「高級日誌」。三個類比可以讓模型清晰起來。

類比 1：醫院病人就診地圖

一位病人帶著複雜的症狀進入急診室。他們經過分診、被送去檢查、接著進行專家會診、接著進入手術室、接著進入恢復室，最後出院。每個部門都寫下自己的筆記（CloudWatch Logs）。每個部門也取樣生命徵象（CloudWatch 指標）。但沒人擁有的是 —— 直到你構建它為止 —— 端到端的病人就診時間軸，精確顯示病人到達每個站點的時間、等待了多久、工作花了多久，以及是哪一步耽誤了出院。那個時間軸就是 X-Ray 追蹤。每個部門的部分就是一個區段。在影像部門的部分內，等待核磁共振 (MRI) 機器空出來的時間就是一個次區段。病人的手環就是追蹤上下文標頭 —— 每個部門讀取手環，將自己的部分與就診過程鏈接，並寫下筆記。沒有手環，放射科醫師就無法將「病人 X 的掃描」與「急診室的病人 X」聯繫起來 —— 他們是孤立的。考試喜歡考團隊擁有日誌但無法連接它們的情境：答案是傳播追蹤上下文，跨越服務和隊列。

類比 2：通過廚房的餐廳訂單

一家複雜的餐廳設有熱食線、冷食線、甜點台、酒窖和外送員。訂單小票在每個台位都會蓋上到達和離開的時間戳記 —— 這就是 X-Ray 追蹤時間軸。顧客的總等待時間就是追蹤持續時間。服務圖是顯示哪個台位供應哪個台位的廚房流程圖：客桌連接到領位台，領位台連接到廚房準備，廚房準備連接到熱食線、冷食線和甜點台，最後在出餐口匯合，交給外送員。當訂單很慢時，經理會查看服務圖，看哪個台位顯示紅框（高錯誤或高延遲），並從該台位調出幾個追蹤，看具體是哪個子步驟（油炸鍋、沙拉組裝、調醬師）導致了等待。註釋是小票上可搜尋的標籤 —— 桌號、聚餐人數、VIP 身份、飲食要求。中繼資料是主廚非搜尋性但有用的隨手筆記。取樣是「我們不詳細追蹤每張小票，只追蹤每 10 張中的 1 張，以及每張被投訴的小票」的政策 —— 限制了文書成本。

類比 3：郵政服務追蹤包裹

一個包裹從寄件人到收件人經歷多個路段：取件卡車、區域分揀設施、長途航空、目的地分揀、最後一英里貨車。每個路段都將追蹤號碼（追蹤 ID）掃描到資料庫中。客戶的追蹤頁面顯示時間軸 —— 09:14 取件、11:02 到達分揀設施、14:30 離開等。這完全就是一個 X-Ray 追蹤。服務圖是路徑圖。取樣是「我們記錄每個包裹的高層級掃描，但僅深度追蹤 1% 以保持資料庫可控，此外我們深度追蹤所有帶有 priority 旗標的包裹」。洞察 (Insights) 是郵政服務的異常偵測，它會在沒人執行查詢的情況下告訴你「今日芝加哥轉運中心的延遲比平時增加了 30%」。ServiceLens 則是營運主控台，在同一張地圖上覆蓋包裹指標（數量、延遲）。X-Ray 守護程序是本地掃描終端，負責批次處理掃描並發送出去 —— 在 Lambda 和 Fargate 上這已內建於平台；在 EC2 上你需要將其作為 sidecar 運行。

追蹤分析 — 區段、次區段、註釋、中繼資料

一條追蹤是區段和次區段組成的樹狀結構。當請求首次進入受儀表化的服務時，會創建根區段。下游服務繼承追蹤 ID 並創建子區段。在每個區段內，SDK 為外傳工作（對 DynamoDB、S3、HTTP 服務的呼叫或開發人員使用 subsegment.begin()/end() 包裝的自定義程式碼塊）創建次區段。

註釋可搜尋，中繼資料不可搜尋

註釋是編制索引的鍵值對（字串、數字、布林值），用於 X-Ray 主控台的篩選表達式：annotation.environment = "prod" AND annotation.user_id = "abc123"。限制：每個區段 50 個。將註釋用於調查時的切入維度。

中繼資料是任意 JSON，每個區段最多 64 KB，不可搜尋。將中繼資料用於工程師在調出追蹤後可能想要查看的額外上下文 —— 請求內容、回應大小、內部狀態。

錯誤 (Errors)、故障 (Faults) 與節流 (Throttles)

每個區段都帶有錯誤/故障/節流旗標。錯誤 = 客戶端錯誤（4xx HTTP，被捕獲並重新拋出的異常）。故障 = 伺服器端錯誤（5xx HTTP，未處理的異常）。節流 = 下游節流（429，ProvisionedThroughputExceededException）。服務圖按主要的旗標為節點著色 —— 故障為紅色、錯誤為橙色、節流為黃色。

取樣規則 — 具備可見性的成本控制

X-Ray 按錄製的區段計費。取樣定義了錄製請求的比例。兩個層級：

預設取樣（未配置規則）

每秒錄製第一個請求；對於後續請求，錄製 5%。這對於開發環境還可以，但對於高流量生產環境則不合適（10,000 RPS 的 5% = 每秒 500 個區段計費 = 昂貴）。

自定義取樣規則（推薦）

在 X-Ray 主控台或透過 API 定義規則。每條規則都有：

• 儲存庫大小 (Reservoir size)：每秒始終取樣的固定請求數（例如 1）。
• 固定速率 (Fixed rate)：儲存庫之外取樣的請求百分比（例如 0.05 = 5%）。
• 匹配條件：服務名稱、服務類型、主機、HTTP 方法、URL 路徑、資源 ARN —— 規則僅適用於匹配的請求。
• 優先順序：當多條規則匹配時，數字越小越優先。

使用案例：將 /healthcheck 保持在 0 儲存庫 + 0% 速率（完全不追蹤），將 /checkout 保持在 5 儲存庫 + 100% 速率（全部追蹤），將所有其他路徑保持在 1 儲存庫 + 5% 速率。

各運算平台上的 X-Ray

各平台的儀表化模式不同。

Lambda

在函數上啟用 Active tracing（CloudFormation: TracingConfig: { Mode: Active }）。AWS 會自動為調用創建區段。Lambda 執行環境已嵌入 X-Ray 守護程序 —— 無需 sidecar。在程式碼中添加 X-Ray SDK（或 AWS Lambda Powertools）會自動為下游 AWS SDK 呼叫和 HTTP 呼叫創建次區段。

Fargate (ECS 和 EKS)

將 X-Ray 守護程序作為 sidecar 容器運行在任務定義中，監聽任務內部的 UDP 2000 埠。應用程式容器的 SDK 將區段發送到 sidecar，由其轉發到 X-Ray API。ADOT 收集器是現代化的替代方案。

ECS on EC2

將守護程序作為 DaemonSet 運行在每台 EC2 主機上（每台執行個體一個守護程序，該執行個體上的所有容器透過主機網路共享）或作為每項任務中的 sidecar 運行。DaemonSet 在大規模下更有效率。

EKS

與 ECS 相同 —— 使用 DaemonSet 部署守護程序。較新的模式是將 ADOT 收集器作為 Kubernetes Deployment 或 DaemonSet 運行，支援 X-Ray 和 OpenTelemetry 相容的後端。

EC2 / 內部部署

在每台主機上安裝 X-Ray 守護程序（yum/apt 套件或二進位檔）。配置 SDK 發送到 UDP 127.0.0.1:2000。

API Gateway

在階段 (stage) 上切換 X-Ray 追蹤。API Gateway 會自動創建上游區段；如果整合目標也經過儀表化，則追蹤會繼續。

Application Load Balancer

ALB 將 X-Amzn-Trace-Id 標頭注入傳入的請求。ALB 本身不創建區段，但接收標頭的下游服務可以提取並傳播追蹤上下文。

追蹤上下文傳播 — 最難的部分

同步 HTTP 和 AWS SDK 呼叫在 SDK 經過儀表化時會自動傳播上下文。非同步邊界是工程師最常遺失上下文的地方。

SQS

生產者將追蹤上下文作為訊息屬性 (AWSTraceHeader) 添加。取用者 SDK 讀取屬性並繼續追蹤。如果你將追蹤 ID 放入訊息本文，AWS 不會自動連結。

SNS

與 SQS 相同 —— AWSTraceHeader 訊息屬性。

EventBridge

在 PutEvents 時將追蹤上下文添加到事件詳情 (detail) 中；接收的 Lambda 需要手動提取，除非使用整合的 AWS SDK 傳播。

Step Functions

Step Functions 與 X-Ray 原生整合；在狀態機上啟用後，追蹤會包含每個狀態轉換。

Kinesis

在紀錄資料或分割區金鑰中編碼追蹤上下文 —— 沒有原生的訊息屬性。大多數團隊在此使用 ADOT-OTel 傳播以獲取原生支援。

ADOT — AWS Distro for OpenTelemetry

新儀表化的戰略方向是 OpenTelemetry，而 AWS Distro (ADOT) 是受支援的管道，可將追蹤匯出到 X-Ray，將指標匯出到 CloudWatch / Managed Prometheus。為什麼 ADOT 對 DOP-C02 很重要：

• 供應商中立：同一套儀表化適用於 X-Ray、Datadog、Honeycomb、New Relic。
• 統一管道：透過同一個收集器處理追蹤和指標。
• OpenTelemetry 語義慣例：全行業標準化的屬性名稱。
• 面向未來：AWS 正在投資 ADOT，而僅限 X-Ray 的 SDK 已進入維護模式。

ADOT 作為 sidecar (Fargate)、DaemonSet (EKS) 或 Lambda 分層運行。考試測試你是否知道 ADOT 是新專案的首選，以及在跨供應商可移植性方面的優勢，而 X-Ray SDK 對於僅限 AWS 的技術堆疊仍可接受。

CloudWatch ServiceLens — 統一的主控台

ServiceLens 將 X-Ray 服務圖、CloudWatch 指標和 CloudWatch 日誌融合到一個視圖中。從服務圖上的節點，你可以：

• 深入分析區段時間軸。
• 跳轉到該服務的相關 CloudWatch 指標（延遲、錯誤、請求）。
• 運行限定在服務日誌群組、按追蹤 ID 篩選的 CloudWatch Logs Insights 查詢。
• 查看覆蓋在地圖上的 OK / ALARM 狀態的警報。

ServiceLens 是值班工程師的調查主控台。考試期望你知道它的存在，並且是題目提到「單一主控台處理追蹤、指標和日誌」時的答案。

X-Ray 洞察 (Insights) — 追蹤模式的異常偵測

X-Ray 洞察使用 ML 隨時間尋找異常的錯誤或延遲模式叢集，並將其浮現為洞察事件及根本原因假設（例如，「Orders 表上的 DynamoDB 節流導致過去 30 分鐘內 23% 的 OrderService 錯誤」）。洞察會作為 aws.xray 來源上的 EventBridge 事件發出，因此可以路由到 SNS、Lambda 或 Incident Manager 回應計劃。針對每個 X-Ray 群組啟用洞察。

X-Ray 群組 (Groups) — 限定範圍的服務圖

群組是儲存的篩選表達式。範例：

• service("checkout-api") AND annotation.environment = "prod"。
• responsetime > 5 OR fault = true。

群組擁有自己的服務圖、保留期和洞察配置。使用群組來限定按團隊、按服務或按環境的視圖。

加密與保留

X-Ray 資料預設使用 AWS 代管金鑰在靜態時加密。你可以配置一個客戶受管 KMS 金鑰，該金鑰在帳戶層級套用到該區域的所有追蹤。X-Ray 追蹤預設保留 30 天；長期保留需要透過 X-Ray 事件上的 Lambda 訂閱者將資料匯出到 S3。

高頻考試陷阱

陷阱 1：Lambda Active 追蹤 vs Passive 追蹤

在 Lambda 上啟用 Active 追蹤會為每個取樣決策 = 1 的調用創建一個區段。Passive 追蹤（遺留概念；很少考）僅在上游服務已經啟動追蹤時才創建區段。考試會用「Passive 追蹤已足夠」來干擾 —— 請選擇 Active 追蹤。

陷阱 2：Fargate 不需要 X-Ray 守護程序

Fargate 已將守護程序內建於任務代理程序中。干擾項：「在 Fargate 上部署守護程序作為 sidecar」 —— 錯誤（可選但非必要；首選內建方式）。

陷阱 3：跨 SQS 的追蹤標頭傳播

使用 AWSTraceHeader 訊息屬性，而非訊息本文。干擾項：「在訊息本文 JSON 中嵌入追蹤 ID」 —— 在 X-Ray 中不會自動連結。

陷阱 4：進入點的取樣決策

一旦上游取樣了 Sampled=1，在下游服務設置自定義取樣就沒有效果。進入點控制整個鏈條。

陷阱 5：註釋上限為 50 個

如果你需要超過 50 個索引欄位，則不能僅靠註釋。其餘的請使用中繼資料，或者拆分為多個次區段，每個次區段擁有自己的註釋。

陷阱 6：X-Ray vs CloudWatch Logs Insights 用於追蹤

X-Ray 用於跨服務的請求路徑延遲和錯誤分析。Logs Insights 用於日誌群組內的日誌內容查詢。當題目要求服務圖和下游呼叫計時時，不要選擇 Logs Insights。

陷阱 7：30 天保留期無法延長

對於長期追蹤存檔，請透過訂閱 X-Ray 事件的 Lambda 匯出到 S3。干擾項：「將 X-Ray 保留期配置為 1 年」 —— 無法配置。

DOP-C02 考試模式與情境演練

情境 1：尋找緩慢的微服務

題幹：「跨 6 個服務的鏈條 API P99 為 4 秒；團隊無法分辨哪個服務慢。」正確：透過 Active 追蹤 (Lambda)、守護程序 (EC2/ECS) 或 ADOT (EKS) 在每個服務上啟用 X-Ray；查看服務圖；選取延遲最高的節點並深入分析追蹤。

情境 2：跨 SQS 邊界追蹤請求

題幹：「追蹤似乎在第一個 Lambda 就結束了；SQS 取用者創建了一個新的根追蹤。」正確：在 PutMessage 時，將當前追蹤上下文填入 AWSTraceHeader 訊息屬性；取用者 SDK 會自動提取。

情境 3：高流量 API 的成本控制

題幹：「在 1000 RPS 下，X-Ray 帳單過高。」正確：定義一個自定義取樣規則，設置小的儲存庫 (1) 和低的固定速率 (1-5%)；透過 0/0 規則將 /healthcheck 完全排除。

情境 4：自動偵測延遲異常

題幹：「希望在無需手動檢查儀表板的情況下自動偵測異常的延遲叢集。」正確：在相關群組上啟用 X-Ray 洞察 (Insights)；透過 EventBridge 將洞察事件路由到 SNS 或 Incident Manager。

情境 5：跨供應商遙測

題幹：「團隊使用 Datadog 處理指標，使用 X-Ray 處理追蹤；希望使用單一儀表化函式庫。」正確：使用 AWS Distro for OpenTelemetry (ADOT)，透過 OTLP 匯出器將追蹤發送到 X-Ray，將指標發送到 Datadog。

常見問題 (FAQ)

Q1：我應該何時使用 X-Ray 或 CloudWatch Logs Insights？

X-Ray 用於跨服務的請求路徑追蹤 —— 當問題是「哪個服務或下游呼叫導致了此延遲」時。Logs Insights 用於服務內的日誌內容查詢 —— 當問題是「錯誤訊息是什麼」或「有多少使用者點擊了此端點」時。它們是互補的；ServiceLens 將它們融合。

Q2：在高流量下我該如何降低 X-Ray 成本？

使用帶有小儲存庫 (1 req/sec) 和低固定速率 (1-5%) 的自定義取樣規則。完全排除 /healthcheck 和類似的端點。取樣決策會在鏈條中向下傳播，因此配置進入點即可覆蓋整個追蹤。

Q3：新程式碼應該使用 X-Ray SDK 還是 ADOT？

對於新程式碼，首選 ADOT —— 它是未來的戰略方向，提供供應商中立性，並在一個管道中支援追蹤和指標。對於 X-Ray SDK 運作良好的現有程式碼，除非需要 OTel 功能，否則無需遷移。

Q4：我該如何跨 SQS 傳播追蹤上下文？

生產者設置 AWSTraceHeader 訊息屬性。取用者的 SDK 會提取它。沒有這個屬性，SQS 取用者會創建一個新的根追蹤，斷開鏈條。

Q5：Lambda 是否需要 X-Ray 守護程序？

不需要。Lambda 的執行環境已包含守護程序。你只需在函數上啟用 Active 追蹤，並（選配）添加 X-Ray SDK 或 AWS Lambda Powertools 來處理次區段。

Q6：X-Ray 保留追蹤多久？

30 天，不可配置。如需更長期的保留，請透過訂閱 X-Ray API 的 Lambda 進行匯出，並利用生命週期政策寫入 S3。

Q7：X-Ray 可以追蹤跨帳戶的流量嗎？

可以 —— 追蹤上下文標頭會跨 HTTP 和 AWS SDK 呼叫自然傳播，不論帳戶為何。每個帳戶儲存自己的區段。若要查看跨帳戶的統一服務圖，請使用 CloudWatch 跨帳戶可觀察性與監控帳戶共享 X-Ray 追蹤。

交叉參照

• CloudWatch 指標與 Logs Insights 是 ServiceLens 與 X-Ray 融合的指標與日誌層；請參閱 cloudwatch-metrics-logs-insights。
• CloudWatch 警報與 EventBridge 取用 X-Ray 洞察事件以進行自動化升級；請參閱 cloudwatch-alarms-eventbridge-integration。
• 部署失敗疑難排解利用 X-Ray 將失敗的部署請求與下游延緩關聯起來；請參閱 deployment-failure-troubleshooting。
• CloudTrail 與 Config 儀表板補充了 X-Ray 在治理和稽核方面的可見性；請參閱 cloudtrail-config-audit-dashboards。
• Incident Manager 與 Health 取用 X-Ray 洞察事件作為回應觸發器；請參閱 systems-manager-incident-manager-health。