一個 5xx 錯誤，過去要在三個介面之間來回切換
Cloudflare 的問題不在缺觀測資料，而是資料散在各產品裡。同一個 5xx 尖峰，可能來自 Worker、來自你的 origin，也可能來自 Cloudflare 連不上 origin——但調查時你得先知道每個訊號歸哪個產品管、該用哪個介面查。2026 年 10 月 2 日，Cloudflare 一次推出八項 Observability 更新，把 logs、traces、analytics、alerts、dashboards 和資料匯出收進同一個平台，並改為單一計價模型。
對每天在 Cloudflare 上搭建產品的人來說，這次更新裡有三件事會直接改變工作方式。
一個 SQL API，讓 agent 也能查線上狀態
最先值得動手的是統一的 SQL API（beta）。過去要分別接 Workers logs、HTTP request logs、安全事件和 analytics，現在用同一種 SQL 方言、同一套認證和同一個 API 就能查詢。新的 cf CLI 讓你或你的 agent 直接從命令列跑查詢，也可以透過 Cloudflare 的 Observability MCP server 做調查。 Workers 還多了一個原生 binding，能在 Worker 裡直接查 Analytics Engine 資料——例如計量客戶用量來跑帳務流程，或自動化事故調查。
如果你的 agent 已經在幫你營運軟體，這點特別關鍵：agent 要能從「改了什麼」閉環到「結果如何」，前提是它能查詢發生了什麼、定位失敗、驗證修復。這和我之前寫過的 Cloudflare 把 Web Search 塞進 AI Gateway 的控制平面 是同一個思路——把 agent 需要的操作面收進標準介面。
Traces 進入公開 beta：看見流量怎麼穿過整個平台
Cloudflare Traces（公開 beta）提供請求層級的視角，涵蓋安全規則、轉換、快取決策、路由、Workers 和 origin 處理。你可以設一個基準取樣率維持持續可見性，調查時再用 Trace Rules 針對特定 hostname、路徑、IP 或 header 提高取樣，並用 Ray ID 搜尋。Traces 支援透過 OpenTelemetry 匯出，W3C trace context 則讓你能接收上游 context 並傳給 origin。
對習慣本地開發的人來說，這補上了邊緣平台上最缺的那塊：你配置了什麼，和請求實際被怎麼處理之間，終於有一條看得見的路徑。
計價改變：12 月 1 日起按 ingestion 和 storage 收費
從 2026 年 12 月 1 日起，所有 logs 和 traces 改為統一訂閱與計價。因為日誌和 trace 的大小差異很大，新模型按你 ingest 和儲存的量計費，而不是事件數。Free 方案每天含 0.5 GB ingestion、保留 7 天；付費方案含 50 GB ingestion 和 10 GB-month 儲存，超出部分每 GB ingested 收 0.25 美元、每 GB-month 儲存收 0.10 美元。
如果你的服務產生大量日誌，建議現在就把現有輸出量抓出來估一輪，別等帳單告訴你。另外兩項也值得留意：Logpush 開放所有 self-serve 方案（過去僅限 Enterprise），配搭剛轉為 GA 的 Transformers 做過濾、遮蔽或重塑資料；domain analytics 則在所有方案提供 30 天保留期。
該從哪裡開始
如果想先感受價值，可以從自訂 Alerts（beta）下手：在統一 SQL API 支援的任何資料集上定義條件，例如 origin 5xx 超過閾值五分鐘、或部署後 Worker 錯誤率上升。Webhooks 現在所有方案都可用，可以直接把警告路由給你的 agent 即時調查。
限制也要記住：跨多個資料集的查詢還沒上線，最長一年的資料保留仍在規劃中，Traces 則只在公開 beta、僅涵蓋支援的功能。先把這次更新當成把現有觀測工作流逐步搬過去的機會，而不是一次重寫的理由。