devgo.cn做分布式追踪的开发者大概率都遇到过这个尴尬：客户端到应用之间的那段代理层，在 trace 里永远是一团黑。请求进了网关之后到底被哪条安全规则拦了、URL 被哪个 Transform 规则改写过、路由匹配到了哪个 Worker，这些信息只能靠翻日志和猜配置。Cloudflare 最近把 Traces 功能放到了公开测试版，解决的正是这个问题——它把从 Workers 到整个请求路径上的所有环节，包括安全规则、转换、缓存决策、路由、Worker 执行、源站处理，全部自动变成 OpenTelemetry span，拼成一条完整的请求级时间线，而且你一行埋点代码都不用写。
这件事为什么重要？因为代理层往往是分布式系统里最容易被忽略的盲区。以前你的 trace 里只有客户端和应用两端，中间发生了什么全靠事后推断。现在每个环节都变成了带耗时、结果和属性的 span，问题定位从"猜"变成了"看"。Cloudflare 官方举的例子都是开发者日常会开工单的真实场景：哪条安全规则拦了请求，规则评估花了多久？Transform Rule 是不是在应用收到请求之前就改写了 URL，这件事发生在路由的哪个阶段？哪个 Page Rule、Snippet 或 Worker 处理了这个请求，匹配的是哪条路由模式？时间到底花在了哪里——官方示例里有个缓存未命中的请求，539ms 的总耗时里有 527ms 都花在等源站响应上。
嵌套的缓存、上游和源站 span，展示请求时间花在哪里（来源：Cloudflare 博客）
真正让它超越"Cloudflare 自家视图"的是上下文传播（context propagation，即把一次请求的追踪标识在服务间传递下去的机制）。Traces 能接收 incoming 请求里携带的 W3C traceparent 头（W3C 标准的追踪上下文传递格式），这样 Cloudflare 的 span 就能加入一个从上游就开始了的 trace；同时它也能把新的 traceparent 转发给源站，让已经接入埋点的服务继续往下传。这里有个关键设计：incoming 传播策略（incoming propagation policy，控制是否接受调用方传来的追踪上下文）决定了 Cloudflare 到底要不要接受调用方的上下文。这个开关很重要，因为如果无条件接受任何客户端传来的 trace ID，恶意流量就能往你的 trace 里灌噪音数据，把真正的问题淹没。
采样（sampling，即只对部分请求记录 trace 以控制成本）跑在 Cloudflare 一贯使用的规则引擎上。团队可以设一个基线采样率，比如正常情况下的 1%，然后写 Trace Rules 对匹配特定条件的流量覆盖这个基线。官方示例：对某个客户域名、源 IP 或特定标识头的所有请求都做全量追踪，其他流量保持基线；或者排查问题时，把所有携带临时 debug 头的请求都抓下来。规则可以针对路径、方法、头、地址、地理位置或这些条件的组合。
展示上下文传播如何让 Cloudflare span 加入上游 trace 并继续传给源站（来源：Cloudflare 博客）
Span 通过 OTLP（OpenTelemetry Protocol，OpenTelemetry 的传输协议，用于把追踪数据发给后端）导出到任何兼容的后端。团队配置一个账号级别的导出目的地，然后选择哪些域名把 trace 发过去。Cloudflare 把这解读为对 OpenTelemetry 的承诺，以及保证数据在可观测性工具之间可移植。
展示 OTLP 导出到任意兼容后端的架构（来源：Cloudflare 博客）
还有个 Agent 的视角值得注意。通过 Cloudflare Observability MCP server（Model Context Protocol server，让 AI 编程代理能访问外部工具和数据的标准接口），编码代理可以用 SQL API 查询 trace，把失败的 trace 和成功的对比，找出 span 在哪里开始分叉，再把发现关联到仓库里的代码。这延续了 InfoQ 在 8 月报道过的 Cloudflare agent tracing 工作的模式——遥测数据变成代理读的东西，而不是人盯的仪表盘。
已经在用 Workers Tracing 的团队要注意这次计费变更，这是两个月内的第二次。8 月的报道说从 2026 年 10 月 1 日起每个 span 都会变成计费事件。Cloudflare 现在把这个模型改成了从 2026 年 12 月 1 日起按数据摄入量和保留时长收费。免费计划每天包含 0.5GB 摄入量，保留 7 天，没有额外费用。付费和企业计划每个计费周期包含 50GB 摄入量和 10GB-月存储，超出部分按每 GB 摄入 $0.25、每 GB-月存储 $0.10 收费。最长一年的保留期标注为"即将推出"。
展示新的按量计费模型（来源：Cloudflare 博客）
按量而不是按 span 计费，这个变化的影响更大。采样决策现在直接映射到账单上，这也解释了为什么 Trace Rules 设计成现在这个样子：基线保持低，对正在排查的流量提高采样率。
覆盖范围目前是有意做成部分的，Cloudflare 列出了还缺什么。计划中的更广泛自动埋点覆盖整个 HTTP 请求路径，包括 DDoS 规则和 Access，以及 Workers 执行路径，包括 Workflows、Queues 和 Pipelines。还计划支持认证上下文传播（authenticated context propagation，让受信任的调用方可以继续 trace，而不用 Cloudflare 接受所有人的上下文）、对特定请求做临时追踪而不改变基线采样率，以及在 Workers 里支持 OpenTelemetry API 给已有 span 加属性。
展示未来计划覆盖的路径（来源：Cloudflare 博客）
这个思路能直接用到什么场景？如果你在 Cloudflare 后面跑服务，现在就能从 dashboard、API 或 Terraform 开启 Traces 公测，任何域名都行，导出到 OTLP 目的地。对不在 Cloudflare 生态里的人，更值得借鉴的是那个"代理层自动埋点"的思路——任何网关、API 网关或边缘层，如果能自动产出标准格式的 span，整个链路追踪的盲区就少了一大块。要注意的坑是：incoming 传播策略一定要按需开启，别让任何人往你的 trace 里灌数据；采样规则要跟预算挂钩，基线设低一点，排查时再针对性提高。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/news/2026/10/cloudflare-traces-open-beta/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global