Cloudflare Traces 開放公測：自動追蹤安全規則、Transform、快取、Worker 與來源站，還能用 Trace Rules 只放大問題流量，並匯出 OpenTelemetry。
網站突然變慢的時候，會議裡最常出現的對話是這樣的：「是 WAF 擋到了嗎？」「Transform Rule 改過路徑？」「快取沒打中？」「Worker 還是來源站在拖？」每個人打開自己的儀表板，像在拼一塊沒有盒蓋圖的拼圖。
2026 年 10 月 2 日，Cloudflare 部落格宣布 Cloudflare Traces 進入開放公測。重點不是再多一個漂亮圖表，而是把「請求在 Cloudflare 裡怎麼被處理」變成一條可跟蹤的時間軸：支援的安全規則、轉換、快取決策、路由、Worker 執行與來源站處理，都能落在同一個 trace 裡，還能接到你自己的服務或來源站，繼續往下走。
對把官網、活動頁、API 閘道架在 Cloudflare 前面的台灣工作室與品牌來說，這幾乎是「終於不用靠感覺除錯」的升級。
它解決的，是我們每天都在猜的問題
官方點名幾類超常見的問題，現在可以直接在 span 裡找答案：
- 為什麼被擋或被挑戰？ 看自訂／託管規則何時評估、花了多久、最後動作是什麼，並透過 span events 找出真正出手的那條規則。
- URL 有沒有被 Transform Rule 改寫？ 打開
http_request_transformspan，看每個變更、影響哪個請求元件、是哪條規則，以及它相對於路由與來源站處理的位置。 - 是 Page Rules、Snippets 還是 Worker 接手？
workers_routingspan 會顯示是否匹配、路由類型，以及匹配的 route pattern。 - 回應是不是打到快取？時間花在哪？ 展開巢狀的 cache、upstream、origin spans。官方範例裡，一次請求總共 539ms，其中有 527ms 花在打到來源站拿回應——這種「原來慢在這裡」的畫面，比十封郵件有用。
重點是：不必先在程式裡埋一堆追蹤碼。 對網域啟用 tracing 後，Cloudflare 會自動產生這些 spans。你也可以在儀表板開啟，或讓代理幫你設定。
採樣不是全開或全關：Baseline + Trace Rules
全站 100% 追蹤很香，帳單與資料量通常不香。Cloudflare 的設計是兩層：
- Baseline sampling rate：平常只追蹤一定比例的請求，例如 1%，維持連續可見度，又不用為每筆請求存 trace。
- Trace Rules：用與 Cloudflare Rules 相同的語言，針對路徑、方法、標頭、IP、地區或其組合，覆寫採樣率。某個客戶回報問題時，你可以只對該主機名稱、來源 IP 或臨時 debug header 追蹤 100%，其他人維持 1%。
這對代理維運很友善：平時省錢，出事時精準放大，不必整個網域開到爆。
真正的分散式追蹤：吃進又送出 traceparent
很多團隊要的不是「Cloudflare 自己的 log」，而是一條從頭到尾的故事。Cloudflare Traces 可以：
- 接受 傳入請求上的 W3C
traceparent，讓 Cloudflare spans 加入在到達平台之前就開始的 trace（由 incoming propagation policy 控制是否接受）。 - 轉送 新的
traceparent給來源站，讓下游已儀器化的 API、資料庫與其他服務接續同一條 trace。
若要把一切看成一條相連的 trace，把 Cloudflare 與應用程式的 spans 送到同一個相容 OpenTelemetry 的後端即可。官方也強調這是對 OpenTelemetry 的長期投資：以 OTel spans 表達請求活動，並用 OTLP 送出，資料可攜、不綁死單一觀測工具。
讓 coding agent 也能「看到」線上發生什麼
Cloudflare 進一步提到：透過 Cloudflare Observability MCP server，coding agent 可以用 SQL API 查詢 traces（以及其餘可觀測資料）。代理能找對請求、比較失敗與成功的 traces、找出 span 分歧點，再對照程式庫提出修復。
這對工作室工作流很有畫面感：客戶說「結帳偶發 403」，代理不只讀程式，還能對照當時 Cloudflare 上是哪條規則、哪段路由、快取是否命中。當然，最後仍要人審變更——代理是很勤快的偵探，不是自動法官。
定價與時程：先公測，12 月起用新模型
Traces 將納入統一的 Cloudflare Observability 定價：依攝取量與保存量計費，而不是按 span／事件數。新定價預計 2026 年 12 月 1 日 起適用於 Cloudflare Tracing 與 Workers Tracing。
官方表格摘要：
| 方案 | 包含用量 | 保存 | 超量 |
|---|---|---|---|
| Free | 每天 0.5 GB 攝取 | 7 天 | 不可超量 |
| Paid / Enterprise | 每計費週期 50 GB 攝取、10 GB-month 儲存 | 最長一年（即將推出） | 每 GB 攝取 $0.25；每 GB-month 儲存 $0.10 |
公測後路線圖還包括：更多自動儀器化（例如 DDoS 規則、Access；Workers 路徑的 Workflows、Queues、Pipelines）、經認證的 context 傳播、隨需追蹤單筆請求、Workers 上的 OpenTelemetry API，以及最長 365 天保存。
給企業網站與維運團隊的行動清單
- 先在預覽或一個次要網域開啟 Traces，確認儀表板時間軸與你的心智模型一致。
- Baseline 設低、Rules 設精。 平常 1%（或依流量調整），對
/checkout、特定客戶主機或 debug header 拉高。 - 若已有 OTel 後端，接上 OTLP 匯出，讓 Cloudflare spans 與應用 spans 同屏。
- 把「被擋／被改寫／未快取」做成除錯劇本，訓練客服與工程用同一套 span 名稱說話。
- 盯住 12/1 定價。 公測期先摸清資料量，再決定保存天數與採樣，避免上線後才被帳單嚇到。
- Agent 查 trace 很好用，但權限要控管。 MCP／SQL 存取應限縮在需要除錯的人員與環境。
台灣品牌常見場景：活動檔期與結帳尖峰
電商檔期、報名系統開跑、B2B 客戶抱怨「偶發被挑戰」——這些時刻最需要 Traces。過去我們常只能看防火牆事件列表、快取分析、來源站 APM，三份報表對時區、對 request id，還不一定對得起來。現在若 Cloudflare 與應用都送到同一個 OTel 後端，客服工單上的「大約下午三點、某個手機門號開的結帳頁」就有機會對到具體 span。
實務建議是：檔期前一週先開 baseline，確認資料量可接受；檔期中對 /checkout、/api/pay、登入相關路徑用 Trace Rules 提高採樣；檔期後再降回。這樣既有事故時的解析力，又不會讓觀測費用變成另一場事故。
另一個常被忽略的價值是變更驗證。你剛加了一條 Transform Rule 或調了快取鍵，如何證明它只影響預期路徑？抽樣 trace 比「感覺比較快」有說服力得多，也比較能寫進維運紀錄交給客戶。
與現有工具怎麼共存
Traces 不是要你丟掉現有的 uptime 監控或錯誤追蹤。它補的是 Cloudflare 這一段長期偏黑盒的路徑。錯誤追蹤告訴你應用丟了例外；uptime 告訴你 externally 可不可以連；Traces 告訴你請求在邊緣被改了什麼、擋了什麼、有沒有打到快取。三者疊在一起，戰情室才完整。
若你的來源站在台灣機房、CDN 在全球，跨區延遲本來就敏感。官方範例那種「539ms 裡有 527ms 在打來源站」的畫面，往往能立刻決定下一步是優化來源站、調整快取，還是檢查是否被錯誤地略過快取——而不是三個團隊互相猜。
你可能會問
Q：我只有把 Cloudflare 當 CDN／WAF，沒寫 Worker，有用嗎？
有。官方明確說：不論你是在 Cloudflare 上建構，還是只是把 Cloudflare 放在來源站前面，目標都是讓你看到流量如何穿過平台。
Q：一定要改應用程式碼嗎？
啟用網域級 tracing 不需要特殊儀器化、設定或外掛。若要做端到端相連，才需要在上下游處理 traceparent。
Q：會不會影響效能？
採樣與 Trace Rules 就是為此存在。先低比例觀察，再對問題流量放大，而不是全站全開。
Q：跟 Workers Tracing 什麼關係？
Workers Tracing 是先前一步：自動儀器化 Worker 呼叫與 KV、R2、D1 等。Cloudflare Traces 把視野擴到整條請求路徑，並與 Workers Tracing 共用未來的觀測定價模型。
結語：可觀測，才談得上可維運
Cloudflare Traces 最打動我們的地方，是它把「設定了什麼」和「請求實際發生什麼」拉到同一條線上。慢、擋、繞路、打回來源站——這些不再是會議裡的猜測，而可以是 span 上的事實。
若你的品牌網站或活動檔期正靠 Cloudflare 擋流量、加速與防護，歡迎找我們一起規劃採樣策略、OTel 匯出與除錯劇本。我們的目標很務實：出事前有基線，出事時找得到人（也找得到那條規則）。