Cloudflare Traces：沿着一次请求看清整个平台

原作者：Mar Witek、Dan Lapid、Nevi Shah、Daniel Walsh。来源：Introducing Cloudflare Traces: follow requests through our entire platform。原文发表于2026年10月2日；按2026年10月5日取回版本译写，保留公开测试状态和支持范围。

2026年10月2日，Cloudflare 宣布 Cloudflare Traces 进入公开测试，把此前主要面向 Workers 的自动追踪扩展到请求路径的其他部分。一条 trace 可以同时展示受支持的安全规则、请求转换、缓存决策、路由、Worker 执行及源站处理，并继续连接运行于 Cloudflare、源站或应用栈其他位置的服务。这是 Cloudflare 对 OpenTelemetry 的长期投入，也意在让平台中的请求行为更容易被观察。

此次发布提供五项能力：自动把受支持的平台操作放入同一条请求级时间线；用基础采样率和 Trace Rules 决定记录哪些请求；接收及转发 W3C traceparent 请求头；在 Cloudflare 控制台查看时间线及 span 详情；通过 OpenTelemetry Protocol（OTLP）把 span 导出到兼容的接收端。域名启用追踪后，平台自动生成这些 span，无须再为每个受支持的操作编写埋点。原文提供控制台入口，也提及可以由代理协助设置。

让用户看见 Cloudflare 自己排障时使用的信息

Cloudflare 内部团队调查问题时，会使用自己的追踪系统。一条内部 trace 往往包含由数十个服务及功能生成的数千个 span，因此工程师能深入查看某次请求的细节。作者认为，这种可见性不应只存在于内部系统。

Workers Tracing 是向用户展示平台内部行为的第一步。原文所说的“去年”，Cloudflare 为 Worker 调用推出了自动埋点，覆盖对外 fetch，以及 KV、R2、D1、Durable Objects 和其他 Workers 调用。开发者不需要为每项操作单独写追踪代码，也能看到 Workers 运行时内部完成了哪些工作。

Cloudflare Traces 把同样的可见性延伸到其他 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，就能查看时间分布。原文示例发生了缓存未命中，请求因此发送到源站；539毫秒的总过程中，有527毫秒用于取得响应。这是原文截图中某次请求的观测值，不是缓存未命中的一般耗时，也不是本次整理的实测结果。

原文截图与数值说明：原文正文把一次 cache miss 的观测写作 539 ms 总耗时、其中 527 ms 用于取得响应；但当前公开的配图展示另一条 trace，界面数值为 6.95 ms，总体 span 中 upstream 为 3.38 ms。下图只用于说明 Traces 的界面和 span 层级，不作为 527/539 ms 数值的证据。

配置追踪

启用域名追踪后，Cloudflare 自动生成受支持的 span，不要求安装专门插件或另外为这些平台操作埋点。遵循开放的上下文标准，trace 还可以穿过第三方服务再返回。随后可以用基础采样率及 Trace Rules 控制记录哪些请求。

设置基础采样率

可以为域名启用追踪并设置基础采样率，在可见性、数据量及成本之间取得平衡。例如正常运行时追踪1%的请求，持续观察请求行为，而不必为每次请求保存完整 trace。

配置 Trace Rules

Trace Rules 允许保留较低的基础采样率，同时为特定调查捕获完整追踪。如果只有一位客户报告问题，可以对其主机名、源IP或可识别请求头匹配的流量采样100%，其他流量继续采样1%。调查期间，也可以只对带临时调试请求头的请求采样100%。这样能针对问题复现，而不必扩大整个域名的采集量。

Trace Rules 使用同一套 Cloudflare Rules 语言，能够按路径、HTTP方法、请求头、IP地址、地理位置或其组合匹配流量。这些百分比是原文的配置示例，并非适用于所有网站的默认建议。

接收和传递追踪上下文

用户经常提出的需求是真正的分布式追踪：请求先进入 Cloudflare，穿过平台，再进入应用栈其他部分，始终能被识别为同一条 trace。

Cloudflare Traces 可以从入站请求接受符合 W3C标准的 traceparent 请求头，让 Cloudflare span 加入请求到达平台之前就已开始的 trace。是否接受这份上下文，由入站传播策略决定。

Cloudflare 也能向源站转发新的 traceparent 请求头。其他已埋点的服务可以提取这份上下文，把 trace 继续传递到API、数据库，以及运行在 Cloudflare 或其他环境中的服务。要在一个视图中看到完整链路，可以把 Cloudflare 与应用产生的 span 都发送到同一个兼容 OpenTelemetry 的后端。

把追踪导出到现有观测平台

Cloudflare span 可以通过 OTLP 导出到兼容的观测平台，与应用栈其余部分的遥测一起显示。先配置账户级目标，再选择哪些域名向该目标发送追踪。Cloudflare 用 OpenTelemetry span 表示请求活动，并通过 OTLP 传输，保留数据在不同观测工具之间的可移植性。

让编码代理参与调查

编码代理排查生产问题时，可以读代码和运行测试，却未必能看到生产请求实际发生了什么。通过 Cloudflare Observability MCP server，代理可以使用 SQL API 查询 traces 及其他可观测性数据，把实际运行中的遥测纳入调查。

代理可以寻找相关请求，比较成功与失败的 trace，识别两者的 span 从哪里开始出现差异。如果它也能检查代码仓库，就可以把发现映射到相关代码，缩小修改范围，并准备供人审核的修复。这是原文介绍的产品能力；本次整理没有连接用户账户、查询生产数据或修改应用。

价格：公告内容与生效时间

原文宣布 Cloudflare Traces 纳入统一的 Cloudflare Observability 计费模式。费用依据是摄入的可观测性数据量及保留时间，而非 span 或事件数量。公告明确写明，新价格从2026年12月1日开始适用于 Cloudflare Tracing 和 Workers Tracing。下表保留2026年10月2日公告，币种为美元；采用前应检查官方实时价格。

公开测试之后的计划

原文列出五个后续方向，应与当前已经提供的能力区分：

• 扩大自动埋点：HTTP请求路径增加DDoS规则、Access等span，Workers执行路径增加Workflows、Queues、Pipelines等覆盖。
• 带身份验证的上下文传播：让可信调用方继续已有trace，而不必接受所有入站请求提交的上下文。
• 按需追踪：不改变基础采样率，也能临时捕获指定请求。
• 完善Workers内的OpenTelemetry API，例如向现有span添加属性或取得上下文。
• 延长保留时间：让trace最长保留365天，支持持续更久的调查。

开始使用与配置提醒

按 Cloudflare Traces 文档追踪第一个请求，再用 Trace Rules 调整采样。原文说明，公开测试阶段可以通过控制台、API或Terraform使用，并支持导出到OTLP目标。

整理者的静态审核补充：追踪上下文解决链路关联，并不代替身份验证。外部传入的 traceparent 或调试请求头不应自动获得信任。提升采样率时，要结合调用方的信任边界。span属性、URL、IP和请求头也可能涉及敏感信息，启用前应检查采集范围、查看权限、目标端鉴权及保留时间。本文没有实际启用任何追踪配置，没有验证完整链路或账单，也不会把“受支持的操作”扩写为“平台所有产品”。

版权与来源：© 2026 Cloudflare, Inc.；源页未另列开放转载许可证，保留四位原作者署名及原文链接。中文译写、整理和配图依据另行授权制作；原文版权归原作者及相应权利人所有。