隆重推出 Cloudflare Traces：贯穿整个平台追踪请求

今天，我们推出 Cloudflare Traces 公测版，将自动追踪从 Workers 扩展到请求路径的其余环节。在一条 trace 中，你可以看到受支持的安全规则、转换、缓存决策、路由、Worker 执行以及回源处理，然后让这条 trace 继续贯穿运行在 Cloudflare 上、你的源站或技术栈其他位置的服务。这是我们对 OpenTelemetry 的长期投入，也是为了让 Cloudflare 成为你技术栈中可观测性最强的一环。现在你可以：

自动追踪跨越 Cloudflare 的请求：在单条请求级时间线中捕获受支持的平台操作，无需额外设置。
控制哪些请求被追踪：设置基准采样率，然后用 Trace Rules 为匹配的流量覆盖该采样率。
端到端 trace 上下文传播：接受并转发 W3C traceparent 标头
在 Cloudflare 中调查 trace：直接在 Cloudflare 仪表板中查看请求时间线和 span 详情。
用 OpenTelemetry 导出 trace：通过兼容 OpenTelemetry Protocol (OTLP) 的端点将 span 发送到任意目的地。

你可以在任意域上在 Cloudflare 仪表板中启用追踪，也可以让你的 agent 替你完成设置：

把我们在调试 Cloudflare 时所用的可见性交给你

我们自己的团队做调查时，用的是内部 trace，单条 trace 往往包含数千个 span，由数十个服务和功能生成。这让我们能深挖某个请求的每一处细节。我们认为这种可见性不该止步于我们的内部系统。

Workers Tracing 是我们公开平台内部情况的第一步。去年，我们为 Worker 调用推出了自动插桩，涵盖出站 fetch 以及对 KV、R2、D1、Durable Objects 和其他 Workers 的调用。它展示 Workers 运行时内部执行的工作，无需为每个操作编写追踪代码。

Cloudflare Traces 的目标，是让每一位使用 Cloudflare 的用户都获得同等程度的可见性——无论你是在 Cloudflare 上构建应用，还是只是把 Cloudflare 放在源站前面。你可以看到流量如何流经我们的平台，并把 Cloudflare 的配置与请求处理时间、路由决策等结果对应起来。

端到端追踪一个请求

一个请求在 Cloudflare 内部的路径可能相当复杂：它可能经过安全规则、转换、路由、缓存，或者被代理到另一个服务。Cloudflare Traces 把每个受支持的步骤记录为一个 span，包括耗时、结果和相关属性。你不必再从分散的日志和配置中拼凑出这个请求，而是可以在一处看到它流经整个系统的路径。

你可以回答这类问题：

请求为什么被拦截或质询，是哪条安全规则触发的？

查看自定义规则或托管规则何时评估该请求、评估耗时多久，以及最终执行了什么动作。通过 span 事件即可定位到导致拦截或质询的那条规则。

URL 在到达应用之前是否被 Transform Rule 重写过？

展开 http_request_transform span，可以看到每一处改动、受影响的请求组成部分，以及对应的规则。你还能看到这次转换相对于路由和源站处理发生在哪个环节。

哪些 Page Rules、Snippets 或 Workers 处理或修改了这个请求？

workers_routing span 会显示是否有路由匹配、使用了哪种路由类型，以及匹配到的路由模式。

响应是否来自缓存？时间花在了 Cloudflare、源站连接和应用中的哪些环节？

展开嵌套的 cache、upstream 和 origin span，就能看到请求的时间花在了哪里。下面这个例子中，缓存未命中并回源，539ms 中有 527ms 花在等待响应上。

配置追踪

不需要任何特殊的埋点、配置或插件。为某个域启用追踪后，Cloudflare 会自动生成这些 span。只要遵循开放标准，你就能把追踪延伸到第三方服务，再回到 Cloudflare。在此基础上，你可以用基线采样率和 Trace Rules 控制哪些请求被追踪。

设置基线采样率

你可以在任何域上启用追踪，并设置基线采样率，在可见性、数据量和成本之间取得平衡。正常运行时可以只追踪 1% 的请求，这样既能持续观察请求行为，又不必为每个请求都采集 trace。

配置 Trace Rules

Trace Rules 让你在保持低基线采样率的同时，为某次具体排查采集完整 trace。如果某个客户反馈了问题，你可以对该客户的主机名、源 IP 或用于识别的请求头追踪 100% 的流量，其余流量仍保持 1%。排查过程中，你也可以对带有临时调试头的请求追踪 100%，其他流量仍走基线。这样无需提高整个域的追踪比例，就能复现问题。

Trace Rules 使用同一套 Cloudflare Rules language，因此你可以按路径、方法、请求头、IP 地址、地理位置或这些属性的组合来匹配。

接受并传递 trace context

我们最常听到的需求之一，是真正的分布式追踪：一条 trace 跟随请求进入 Cloudflare，穿过我们的平台，再继续延伸到你的技术栈其余部分。

Cloudflare Traces 可以接受传入请求中的 W3C traceparent header，让 Cloudflare 的 span 加入一条在请求到达我们平台之前就已开始的 trace。传入传播策略决定 Cloudflare 是否接受该 context。

Cloudflare 还可以向你的源站转发新的 traceparent 请求头。任何其他接入插桩的服务都能提取该上下文，让追踪在 API、数据库以及运行在 Cloudflare 或其他平台上的服务之间延续。若想把所有内容看成一条连通的追踪，可以把 Cloudflare 的 span 和应用自身的 span 发送到同一个兼容 OpenTelemetry 的后端。

将追踪导出到你的可观测性平台

你可以通过 OTLP 把 Cloudflare 的 span 导出到兼容的可观测性平台，它们会与来自技术栈其余部分的遥测数据并列显示。配置一个账户级目标，然后选择哪些域名向它发送追踪。这是我们践行 OpenTelemetry 的一部分：Cloudflare 将请求活动表示为 OpenTelemetry span，并通过 OTLP 投递，让数据在各可观测性工具之间保持可移植。

让你的 agent 去调查 Cloudflare Traces

当你让编码 agent 排查一个生产环境问题时，它可能会检查你的代码、跑测试，但未必看得到请求在生产环境中经历了什么。借助 Cloudflare Observability MCP server，你的 agent 可以利用我们的 SQL API 查询追踪数据（以及你全部的可观测性数据！），从而获得调查生产遥测数据的能力。

让 agent 找出相关的请求，把失败的追踪与成功的追踪对比，定位它们的 span 在哪里开始分叉。由于 agent 还能查看你的代码仓库，它可以把这些发现与相关代码对应起来，缩小需要改动的范围，并帮你提交一个修复供你审查。

定价

Cloudflare Traces 将纳入统一的 Cloudflare 可观测性定价模型。定价不按 span/事件数量计费，而是取决于你写入多少可观测性数据以及保留多久。新定价将从 2026 年 12 月 1 日起在 Cloudflare Tracing（以及 Workers Tracing！）全面生效。

套餐	包含用量	保留时长	额外用量
Free	每天 0.5 GB 摄取量	7 天	不可用
Paid 和 Enterprise	每个计费周期 50 GB 摄取量
10 GB-月存储量	最长 1 年
（即将推出）	每 GB 摄取量 $0.25
每 GB-月存储量 $0.10

下一步

开放测试之后，我们计划推出：

更广泛的自动埋点：在 HTTP 请求路径（例如 DDoS 规则、Access）和 Workers 执行路径（例如 Workflows、Queues、Pipelines）上增加更多 span。
经过认证的上下文传播：让受信任的调用方延续已有的 trace，而不必接受每个传入请求携带的上下文。
临时追踪：按需捕获某个特定请求，而不改变基线采样率。
Workers 中的 OpenTelemetry API 支持：继续完善我们的 OpenTelemetry API，以便为已有 span 添加属性或获取 trace 上下文。
更长的保留时长：将 trace 数据保留最长 365 天，以支持耗时更长的排查。

开始使用

按照 Cloudflare Traces 文档追踪你的第一个请求，并通过 Trace Rules 调整采样。Cloudflare Traces 已开放测试，可通过 dashboard、API 或 Terraform 使用，并支持导出到 OTLP 目标端。