反向代理層的可觀測性黑盒子痛點
在現代雲端架構與微服務體系中，分散式追蹤（Distributed Tracing）已經成為工程團隊釐清跨系統呼叫延遲與定位錯誤的核心工具。然而，長期以來在網路架構的前端邊界，始終存在一塊難以穿透的盲區。根據科技媒體 InfoQ 的報導，許多團隊在將反向代理（Reverse Proxy）或內容傳遞網路（CDN）置於應用程式前端時，分散式追蹤鏈條往往呈現斷裂狀態。追蹤視圖通常只能記錄使用者客戶端發送請求，隨後直接跳轉至後端應用程式的執行過程，而介於兩者之間的邊緣代理層——包括安全防護檢查、流量改寫、快取判定與路由規則等行為——其具體耗時與決策邏輯，以往只能依賴事後的日誌紀錄（Logs）與靜態配置檔案來拼湊與推測。
這種可觀測性斷層在實際維運中衍生出大量的溝通與排查成本。當一個請求遭到阻擋或發生高延遲時，工程人員往往難以第一時間判斷究竟是哪一條 Web 應用防火牆規則介入、URL 重寫規則是否在路由匹配前生效，或是邊緣節點的快取未命中導致回源請求佔據了絕大部分時間。為了解決這一長期存在的結構性痛點，Cloudflare 近期正式推出 Cloudflare Traces 的公開測試版（Open Beta），將其自動追蹤機制從原本的 Workers 無伺服器運算環境擴展至整個 HTTP 請求路徑。
自動化跨度產生與 OpenTelemetry 標準整合
Cloudflare Traces 的核心機制在於將反向代理層所經歷的每一個處理步驟，自動轉換為符合 OpenTelemetry 標準的 Span（跨度，代表分散式追蹤中單一操作的時間區間與元數據）。這意味著開發者與維運團隊完全不需要編寫任何自訂埋點程式碼（Zero-instrumentation），就能在單一請求時間軸上獲得涵蓋邊緣各階段的完整視圖。
在具體運作上，請求經過的各個環節都會被封裝成帶有執行結果、耗時與上下文屬性的 Span。這些環節包括安全性規則的評估結果、Transform Rules（轉換規則，用於在邊緣修改標頭或改寫 URL）的執行時機、快取決策（Cache Decisions）、頁面規則（Page Rules）或輕量級腳本（Snippets）的匹配狀況，以及 Cloudflare Workers 的執行流程與最終回源（Origin）處理。藉由這套機制，過去難以直接觀測的效能細節得以透明化。例如在官方測試範例中，一個總耗時 539 毫秒的請求被清晰分解，明確揭示其中 527 毫秒均消耗在等待源站伺服器回應的快取未命中狀態，邊緣層的評估與處理則僅佔極小比例。
更關鍵的是，這項功能並非 Cloudflare 封閉生態系內的專有視圖，而是全面基於開放標準建構。系統能夠輸出標準的 OTLP（OpenTelemetry Protocol，用於傳輸遙測資料的開放通訊協定）格式，企業可以在帳號層級設定匯出目標（Destination），將追蹤資料無縫導流至現有的第三方可觀測性平台或自建分析後端，確保內部遙測架構的跨工具相容性與資料可攜性。
上下文傳遞與基於規則的精細取樣治理
要讓邊緣層的 Span 真正融入全鏈路追蹤，必須仰賴 Context Propagation（上下文傳遞，指在不同服務與網路節點之間傳遞追蹤識別碼的標準化機制）。Cloudflare Traces 支援 W3C traceparent 標頭標準。當外部請求抵達邊緣時，系統能夠讀取現有的追蹤標頭，將 Cloudflare 自身的處理階段附加至上游已啟動的追蹤鏈條中；同時，它也能產生並轉發新的 traceparent 標頭至後端源站伺服器，讓後續的微服務應用程式得以接續紀錄，形成完整的端到端呼叫圖譜。
然而，若無差別接受所有外部傳入的追蹤識別碼，極易引發追蹤資料污染與雜訊問題。為此，系統導入了傳入傳播策略（Incoming Propagation Policy），允許團隊控制是否採納呼叫端提供的上下文，以此防範惡意或無效的追蹤資料進入後端系統。
在取樣率控制方面，Cloudflare Traces 沿用了其成熟的規則引擎架構。面對海量的邊緣流量，全量追蹤在成本與頻寬上均不可行，因此團隊通常會配置一個較低的基準取樣率（例如正常流量下的 1%）。當特定情境需要深度排查時，工程人員可以透過 Trace Rules（追蹤規則）進行精準覆蓋。例如，團隊可以針對特定客戶的主機名稱、來源 IP 位址、特定請求標頭（如臨時除錯標頭）、地理位置或 URL 路徑模式設定 100% 取樣，在不影響整體系統負載的前提下，即時擷取異常請求的完整脈絡。
計費模式轉向：從跨度計量改為容量計費的成本意涵
隨著 Cloudflare Traces 進入公開測試，官方亦同步調整了包含 Workers Tracing 在內的計費架構。值得注意的是，這是該功能在兩個月內的第二次定價變更。在 2026 年 8 月的規劃中，官方原本預計自 2026 年 10 月 1 日起，針對產生的每一個 Span 作為計費事件收費；但在最新的公布中，此模式被正式推翻，並自 2026 年 12 月 1 日起全面轉向以數據擷取量（Data Ingested）與保留時間（Retention）為基礎的容量計費模型。
在新的定價架構下，免費方案提供每日 0.5GB 的資料擷取量與 7 天的資料保留期，不支援超額用量；付費方案（Paid）與企業級方案（Enterprise）則在每個帳單週期內內建 50GB 擷取量與 10GB-月的儲存空間。若超出額度，額外擷取量每 GB 收費 0.25 美元，額外儲存空間每 GB-月收費 0.10 美元，官方並預告未來將開放最長達一年的資料保留支援。
從按 Span 數量計費轉為按資料量計費，對架構師的成本控制策略具有實質影響。在新的模式下，資料量直接取決於取樣決策與 Span 內攜帶的屬性多寡。這也解釋了為何 Cloudflare 強調基於規則的取樣機制——維持低基準取樣率以控制日常成本，僅在特定流量或除錯場景下提高取樣率，成為控制可觀測性支出的關鍵治理策略。
智慧代理排查應用與現階段功能邊界
除了傳統的人工監控視圖外，這項更新亦延續了遙測資料與 AI Agent（人工智慧代理）結合的發展趨勢。透過 Cloudflare 推出的 Observability MCP（Model Context Protocol，一種允許大型語言模型與外部工具及資料庫安全互動的開放協定）伺服器，編程代理能夠直接透過 SQL API 查詢與檢索追蹤資料。當線上系統發生異常時，AI 代理可自動對比失敗請求與成功請求的 Span 差異，找出邊緣規則或程式碼執行的分歧點，並將異常定位結果直接關聯至軟體儲存庫中的原始碼，展現了遙測資料從人類儀表板走向機器自主診斷的演進歷程。
儘管 Cloudflare Traces 帶來了顯著的可觀測性提升，官方也坦承目前功能仍處於分階段推進的初期。在邊緣 HTTP 請求路徑上，分散式阻斷服務（DDoS）防護規則以及零信任存取架構（Cloudflare Access）的詳細追蹤尚未完全涵蓋；在 Workers 執行路徑中，非同步工作流程（Workflows）、佇列（Queues）與資料管道（Pipelines）的追蹤支援也仍在開發清單中。
此外，未來的技術藍圖還包括：支援身分驗證機制的上下文傳遞（Authenticated Context Propagation），以確保僅信任的呼叫端能夠延續追蹤；支援在不更動全局取樣率的情況下針對單一特定請求進行即時追蹤（Ad-hoc Tracing）；以及在 Workers 運行環境中提供原生 OpenTelemetry API 支援，允許開發者自訂為現有 Span 注入業務用屬性。目前該公開測試版已可透過 Cloudflare 控制台、API 或 Terraform 工具進行配置，並支援所有自訂網域。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。