排查線上問題最煩的地方，往往不是找到 bug，而是把請求路徑拼回來：安全規則擋了嗎？URL 有沒有被改寫？這是 cache hit 還是 miss？慢在哪一段？過去你得在幾份日誌和設定之間來回對照。2026 年 10 月 2 日，Cloudflare 宣布 Cloudflare Traces 進入 open beta，把平台內各個步驟記錄成單一請求層級的 timeline，這些問題就能在一個 trace 裡看完。
一個 span 對應一個平台步驟
根據 Cloudflare 的公告，Traces 會自動捕捉支援的平台操作：安全規則的評估與結果、Transform Rule 對請求的修改、routing（包括哪條 route 匹配了）、快取決策、Worker 執行，以及到 origin 的連線與處理時間。每一步是一個 span，帶有時間、結果和相關屬性。
公告裡舉的例子很實際：你可以展開 cache 和 origin 的巢狀 span，看到一次 cache miss 之後 539ms 的總耗時中有 527ms 花在等 origin 回應——這種「時間去哪了」的問題，以前要靠在不同地方打 log 才能回答。
這其實是 Workers Tracing 的延伸。去年 Cloudflare 已經為 Worker 呼叫推出自動埋點，涵蓋 outbound fetch 以及對 KV、R2、D1、Durable Objects 的呼叫。我先前在另一篇文章寫過，Cloudflare 正把觀測性收進同一個平台，Traces 是那條線的下一步。
取樣策略：低基準、針對性加量
追蹤不可能全量，Traces 的做法是兩層：
- 基準取樣率：例如平常設 1%，持續掌握請求行為，又不會資料量爆炸。
- Trace Rules：需要調查時，針對特定 hostname、來源 IP 或識別用的 request header 提高到 100%。某個客戶回報問題，就只對他們的流量做完整追蹤。
Trace Rules 用的是 Cloudflare Rules language，可以依路徑、方法、header、IP、地理位置或其組合來指定。因為不需要額外埋點或設定，開啟的成本主要就是取樣率與後續的資料量。
真正的分散式追蹤
Cloudflare Traces 支援接受並轉發 W3C traceparent header。也就是說，如果請求在你自己的服務端已經開始一個 trace，Cloudflare 的 span 可以接上同一條軌跡；Cloudflare 也會轉發新的 traceparent 給你的 origin，讓後面的 API 和資料庫服務繼續接下去。再把 Cloudflare 和應用程式的 span 都匯出到同一個支援 OTLP 的後端，整條鏈就是一份完整的 trace。
匯出走 OpenTelemetry 標準，資料不會被鎖在 Cloudflare 的 dashboard 裡——對已經有自家觀測平台的團隊來說，這點比功能本身更關鍵。
讓 agent 接手調查
公告裡有一段值得注意：搭配 Cloudflare Observability MCP server，coding agent 可以透過 SQL API 查詢你的 traces。想像你請 agent 排查一個 production 問題——它通常只能看程式碼和跑測試，看不到線上實際發生了什麼。有了 trace 存取權，agent 能比對失敗與成功的 trace、找出 span 分歧的環節，再結合 repo 裡的程式碼定位該改哪裡。
這把「診斷」從人肉讀 dashboard，變成 agent 可以執行的一個步驟。前提是你得先把 Traces 開起來，並且想清楚 agent 能查到哪些資料。
定價與時程
Traces 納入統一的 Cloudflare Observability 計價模型，依擷取量和保留時間計費，不是按 span 數量。Free 方案每天含 0.5GB 擷取、保留 7 天；付費方案含 50GB 擷取與 10 GB-month 儲存，超出部分為每 GB 擷取 $0.25、每 GB-month 儲存 $0.10。新計價從 2026 年 12 月 1 日起生效，同樣適用於既有的 Workers Tracing。
如果你本來就在 Cloudflare 上或把 Cloudflare 放在 origin 前面，實際的下一步很簡單：在 dashboard 開啟某個 zone 的 Tracing，設個低取樣率，匯出到你現有的 OTLP 後端，先看一週的 trace 長什麼樣，再決定 Trace Rules 要針對哪些流量加量。open beta 期間功能仍在擴充，公告列出的後續包括更廣的自動埋點、ad hoc tracing，以及最長 365 天的保留期。