跟 Backend 04 的分工：本文從 client-side RUM 角度說明 Datadog 的全棧追蹤、四種 RUM 事件與 session replay。Server-side 的 APM 平台治理（agent 配置、成本治理、OTel 相容遷移、從 New Relic 或 Grafana Stack 遷移）見 Backend 04 Datadog vendor page。

Datadog Real User Monitoring（RUM）從全棧 APM 的角度設計 client-side 監控。核心特徵是 client 端的使用者操作可以關聯到 server 端的 trace，形成從按鈕點擊到 database query 的完整請求鏈路。

全棧追蹤

Datadog RUM 的 SDK 在 HTTP 請求中自動注入 trace context header。Server 端的 Datadog APM agent 讀取 header，把 server 端的 trace 和 client 端的 action 關聯。

這個能力在 debug「API 慢」的問題時特別有用 — 從 client 端看到「這個按鈕的回應時間 3 秒」，點進去看到 server 端的 trace 顯示「database query 佔了 2.8 秒」。自架方案和 Sentry 都做不到這個深度的跨層關聯。

前提是 server 端也使用 Datadog APM。如果 server 端用其他 APM（New Relic、Elastic APM），client-server 的關聯需要自行實作或用 OpenTelemetry 橋接。

四種 RUM 事件

Datadog RUM 收集四種事件，和自架方案的四類事件有對應關係（模組一 商業方案對應）：

View：頁面或畫面的載入和離開。自動偵測 SPA 的 route 變換，對應 lifecycle 事件。

Action：使用者操作。自動捕獲 click、tap、scroll，可手動記錄自訂 action，對應 event 事件。

Error：JS exception、network error、自訂 error，對應 error 事件。

Long Task：執行時間超過 50ms 的任務（阻塞主執行緒），對應 metric 事件。

定價

Datadog RUM 按 session 數計費（每個 session 是一次使用者訪問）。和 Sentry 按事件數計費不同 — session 計費讓成本更可預測（不會因為單次訪問觸發大量事件而費用暴增）。

Datadog 的完整方案（RUM + APM + Logs + Infrastructure）費用較高，適合已經用 Datadog 做 server-side 監控的團隊。單獨用 RUM 而 server 端用其他方案，失去全棧追蹤的優勢。

Datadog RUM 的全棧追蹤能力獨一無二，但如果只需要行為分析而非 APM，Mixpanel / Amplitude 是更輕量的選擇。和 Sentry 的定位差異在於 Sentry 聚焦 error tracking、Datadog 聚焦全棧關聯。自架 vs 商業的判斷決策表從使用者規模和功能需求維度做系統性比較。

完整鏈路

以使用者在 web app 點擊「結帳」為例，一次操作產生的觀測鏈路：

 1Browser: user clicks "checkout"
 2  → RUM SDK 建立 client span（type: resource / xhr）
 3  → HTTP POST /api/checkout + W3C traceparent header
 4    → Server middleware 提取 trace context
 5    → Server 建立 child span（checkout-handler）
 6      → DB query span（order insert）
 7      → Cache span（inventory check）
 8      → Queue span（event publish）
 9    → Server 回 200 + response body
10  → Browser 收到 response → resource timing 結束
11  → RUM SDK 關閉 client span（記錄 duration + status）
12  → 統一 trace waterfall：client span 是 root、server spans 是 children

鏈路的每一段都需要 trace context 正確傳遞。任何一段斷掉，trace waterfall 就會出現孤立的 span — server 端看到的 trace 跟 client 端看到的 trace 是兩條不相關的紀錄。

Trace context propagation

W3C traceparent header

W3C Trace Context 是跨 vendor 的標準 propagation 格式。Header 長這樣：

1traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
2              │  │                                │                  │
3              │  trace-id (32 hex)                 parent-id (16 hex) flags
4              version

RUM SDK 在發起 XHR / fetch 時把 traceparent 注入 request header。Server 的 trace SDK 從 header 提取 trace-id 和 parent-id，建立 child span。

Client 端注入

各 RUM SDK 的注入方式：

三者的共同模式：只對設定的 domain 注入 trace header。不設定白名單時，header 不會被注入到第三方 API（避免 information leakage）。

Server 端提取

Server 端的 trace SDK（OTel auto-instrumentation 或 vendor agent）從 incoming request 的 header 提取 trace context：

 1# OTel Python 範例 — auto-instrumentation 自動處理
 2# 不需要手動提取，middleware 自動讀 traceparent header
 3# 建立的 span 會繼承 client 傳來的 trace-id 和 parent-id
 4
 5# 手動提取（不用 auto-instrumentation 時）
 6from opentelemetry.propagate import extract
 7ctx = extract(carrier=request.headers)
 8with tracer.start_as_current_span("checkout-handler", context=ctx):
 9    # server logic
10    pass

CORS 限制

跨域請求時，browser 的 CORS preflight 會阻止非標準 header。Server 需要明確允許 trace header：

1Access-Control-Allow-Headers: traceparent, tracestate, sentry-trace, baggage

CORS 是 client-server trace 串接最常見的斷裂原因。Server 沒有回 Access-Control-Allow-Headers: traceparent 時，browser 會 strip 掉 trace header，server 端收到的 request 沒有 trace context，建立的 span 成為新的 root — 跟 client span 斷裂。

跨層 correlation 設計

Trace ID 串接

統一 trace-id 是最基本的 correlation。同一個 trace-id 下的所有 span（client + server）可以在 trace backend 的 waterfall view 裡按時間排列，看到完整的 request 路徑。

Session 跟 transaction 的 mapping

RUM SDK 的 session（使用者的一次造訪）包含多個 user action，每個 action 可能觸發多個 HTTP request。Mapping 關係：

1RUM session
2  └── user action (click "checkout")
3        ├── HTTP request /api/checkout  →  server transaction (trace)
4        ├── HTTP request /api/inventory →  server transaction (trace)
5        └── client-side rendering time

Datadog RUM 和 Sentry 都支援從 session replay 點進去看對應的 server trace。這個 mapping 靠的是 RUM event 裡記錄的 trace-id，跟 server trace backend 裡的同一個 trace-id 做 join。

Breadcrumbs 跟 server log 的時間對齊

RUM SDK 收集的 breadcrumbs（使用者操作序列：page view → button click → form submit）跟 server-side log 的 timestamp 需要可比對。時間對齊的前提是 client 和 server 的 clock 差距在可接受範圍（通常 < 1s）。

NTP 同步的 server 端 clock 通常精準。Client 端（browser）依賴使用者裝置的系統時間，可能偏差數秒到數分鐘。RUM SDK 通常會記錄 relative timing（相對於 session 開始的 offset），而非絕對 timestamp，來降低 clock skew 的影響。

Error correlation

Client-side JS error 跟 server-side 5xx 可能是同一個問題的兩面。Correlation 方式：

• 同一 trace-id：client error 發生在某個 HTTP request 的 response 處理中，該 request 的 trace-id 跟 server-side 500 的 trace-id 相同 — 直接 correlation
• 時間窗 + endpoint：client error 沒有 trace-id（例如 CORS block 導致 request 沒發出），用時間窗 + endpoint 模式做 fuzzy correlation
• Server 無異常但 client 報錯：client-side rendering error（JSON parse failure、type error），server 端看不到 — 需要 RUM 獨立分析

Evidence package 整合

把 client-side 訊號納入 4.20 Observability Evidence Package 時，需要額外記錄：

Client perceived latency 跟 server-side latency 的差異本身就是一個觀測訊號。差異穩定在 50ms 是正常的 network overhead；差異突然從 50ms 跳到 500ms 代表網路或 CDN 出了問題 — 而這個問題 server-side dashboard 完全看不到。

失敗場景判讀

Vendor 整合模式

同 vendor 組合的串接最自然。跨 vendor 組合只要雙方都支援 W3C Trace Context，trace-level correlation 可以通；但 session-level 的功能（session replay → server trace）需要同 vendor 才有。

交接路由

• 4.10 Client-side / Synthetic / RUM：概念定位和 vendor 選型
• 4.3 Tracing Context：server-side trace context 設計
• 4.22 Checkout API Evidence Package：evidence 整合到 release gate
• 4.20 Observability Evidence Package：evidence 欄位標準
• Monitoring 03 SDK 設計：client-side SDK 埋點設計
• Monitoring 06 商業方案：Sentry / Datadog RUM 的 client-side 能力比較
• 監控資料的雙重用途：同一份 event data 如何同時服務行為分析與訊號治理