Cloudflare 宣布以Cloudflare Traces公开测试版形式提供该服务，将自动跟踪范围从 Workers 环境扩展到 Cloudflare 平台内请求路径的其余部分。该服务在单个追踪记录中展示请求处理的各个阶段，包括安全规则、转换、缓存、路由、Workers 执行以及与源站的连接，并支持将追踪继续关联到技术基础设施中的其他服务。
统一查看请求路径
Cloudflare 将每个受支持的步骤记录为一个 span，其中包含时间、结果及相关属性。因此，团队可以了解请求被阻止或要求接受质询的原因，确定采取措施的安全规则，并检查请求到达应用程序之前由 Transform Rules 执行的修改。
该服务还会说明请求路径是否经过 Page Rules、Snippets 或 Workers，并区分请求在 Cloudflare 中耗费的时间与连接源站及应用程序所耗费的时间。它展示缓存和源站连接的详细信息，包括 cache miss 状态；来源给出的一个示例中，请求总共耗时 539 毫秒，其中从源站获取响应耗时 527 毫秒。
控制跟踪范围
该服务不要求进行特殊配置或使用额外工具。在域名上启用后，Cloudflare 会自动生成追踪记录。用户可以设置基本采样率，例如在正常运行期间跟踪 1% 的请求，然后使用 Trace Rules 将符合特定条件的流量覆盖率提高到 100%，条件可以包括主机名、IP 地址或特定标头。
Trace Rules 使用 Cloudflare 自身的规则语言，因此可以针对路径、HTTP 方法、标头、IP 地址、地理位置或它们的组合进行匹配。这为运营团队提供了一种隔离特定问题的方法，而无需增加整个域名的跟踪量。
与 OpenTelemetry 集成
Cloudflare Traces 能够接收传入请求中的W3C traceparent标头，使 Cloudflare 的 spans 加入始于其他服务的追踪记录。它还可以向源站传递新的 traceparent，使追踪继续贯穿 API、数据库及其他服务。
该服务支持通过 OTLP 协议将追踪记录导出到与 OpenTelemetry 兼容的目标。若要将 Cloudflare 的追踪记录与应用程序的追踪记录显示为一条完整链路，必须将数据发送到兼容 OpenTelemetry 的监控后端。此外，Cloudflare Observability MCP 服务器可以让软件代理通过 SQL API 查询追踪记录和监控数据，并比较失败请求与成功请求。
实际会发生什么变化？
这里的核心价值在于减少从相互独立的日志和配置中重新构建请求旅程的需要。不过，目前的覆盖范围尚未包括所有操作；该服务目前处于公开测试阶段，Cloudflare 计划稍后为 DDoS 规则、Access 以及 Workers 中的其他功能增加 spans，同时提供按需跟踪和更广泛的 OpenTelemetry 支持。
该服务纳入统一的 Cloudflare Observability 定价模式。变更将于 2026 年 12 月 1 日开始：免费计划每天包含 0.5 吉字节数据，保留期限为 7 天；付费计划和 Enterprise 每个计费周期包含 50 吉字节输入量和 10 吉字节·月存储量，超出部分的费用为每输入 1 吉字节 0.25 美元、每存储 1 吉字节·月 0.10 美元。Cloudflare Traces 可通过控制面板、API 或 Terraform 使用。