Cloudflare Traces 公開測試：一條請求的 span 貫穿安全規則到源站
Cloudflare Blog · 2026-10-02
Cloudflare 以 Traces 取代「拼湊多份日誌來還原請求路徑」的除錯方式，把請求經過的每個平台步驟記成 OpenTelemetry span，放進同一條時間軸。這項功能於 2026-10-02 進入 open beta，作者為 Nevi Shah 與 Daniel Walsh，同日另有觀測平台八項更新文章，將 Traces 列為其中一項。
原本的問題
過去請求進到 Cloudflare 後，會依序經過安全規則、Transform Rules、快取、路由、Workers，最後才到源站。每一段各有各的日誌與設定頁，要回答「這個請求為什麼被擋、被改寫、或沒命中快取」，得自己把這些來源對起來。
文章把這個狀況描述為「從分散的日誌與設定重建請求路徑」。Traces 的目標就是讓這件事不必人工完成。
核心改動
Traces 自動把每個支援的步驟記為 span，包含耗時、結果與相關屬性，不需要自己加埋點。目前涵蓋的操作如下：
- 安全規則評估（自訂與受管規則集）
- Transform Rules 的 URL 轉換
- Page Rules、Snippets、Workers 的路由
- 快取決策與源站連線
取樣分兩層：先設一個基準取樣率（文章舉例為平時 1%），再用 Trace Rules 針對特定流量覆寫。Trace Rules 沿用 Cloudflare 其他規則的語言，可依路徑、方法、標頭、IP、地理位置比對。
| 需求 | 做法 |
|---|---|
| 平時低成本觀察 | 基準取樣率（例：1%） |
| 追查某條路徑或某個 IP | Trace Rules 提高該流量的取樣 |
| 串接自家後端的 trace | 接受並轉送 W3C traceparent |
| 送進既有觀測平台 | OTLP 匯出 |
跨系統串接與匯出
Cloudflare 會依可設定的「incoming propagation policy」接受進來的 traceparent 標頭，並把新的標頭轉送給源站，所以邊緣的 span 與應用程式內的 span 能接成同一條 trace。標頭格式見 W3C Trace Context。
匯出走 OTLP：先設帳號層級的 destination，再選哪些網域要送 trace。目前可從 dashboard、API 與 Terraform 設定。
影響範圍
已把 Cloudflare 放在源站前面的團隊，最直接的差別是排查 WAF 誤擋、Transform Rules 改寫錯誤、快取未命中時，可以直接看 span 而不是比對日誌。用 Workers 的團隊則是把原本只涵蓋 Workers 的追蹤延伸到整條請求路徑。
若自家服務已輸出 OpenTelemetry，要檢查的是：反向代理或應用程式是否保留 traceparent，以及 propagation policy 要不要信任外部帶入的標頭。文章未說明預設值，需看文件。
費用與時程
新定價自 2026-12-01 起生效，依攝入資料量與保留時間計費，而不是依 span 數量。文章列出的數字如下：
| 方案 | 每日攝入 | 保留 | 超量 |
|---|---|---|---|
| Free | 0.5 GB | 7 天 | 無 |
| Paid / Enterprise | 50 GB，另含 10 GB-month 儲存 | 最長 1 年 | $0.25/GB 攝入；$0.10/GB-month 儲存 |
需注意觀測平台更新文對 Paid 的保留標注為「最長 1 年（coming）」，而 Traces 文章的路線圖也列出延長到 365 天，可見一年保留尚未全面上線。路線圖另有 DDoS 規則與 Access 的埋點、已驗證的 context 傳遞、ad hoc tracing，以及 Workers 內的 OpenTelemetry API 支援，文章均未給日期。
原始來源：Introducing Cloudflare Traces、8 major updates to Cloudflare Observability