Mar Witek、Dan Lapid、Nevi Shah 和 Daniel Walsh

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

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

你可以在 Cloudflare 仪表板中为任何域启用追踪，或让你的智能体为你设置：

为你提供我们用来调试 Cloudflare 的可观测性

当我们自己的团队进行调查时，我们使用自己的内部追踪，单次追踪通常包含数千个 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。这让你能够通过遵循开放标准将追踪扩展到第三方服务并再返回。在此基础上，你可以使用基线采样率和 Trace Rules 控制哪些请求被追踪。

设置基线采样率

你可以在任何域上启用追踪并设置基线采样率，以平衡可见性、数据量和成本。你可以在正常运行期间追踪 1% 的请求，从而持续了解请求行为，而无需为每个请求收集追踪数据。

配置 Trace Rules

Trace Rules 让你在保持较低基线采样率的同时，为特定调查捕获完整追踪。如果某个客户报告了问题，你可以对其主机名、源 IP 或标识请求头的流量进行 100% 追踪，而其他所有流量保持在 1%。或者在调查期间，你可以对携带临时调试头的请求进行 100% 追踪，而所有其他流量保持在基线水平。这让你能够复现问题，而无需在整个域上增加追踪。

Trace Rules 使用相同的 Cloudflare Rules language，因此你可以针对路径、方法、标头、IP 地址、地理位置或这些属性的组合进行定位。

接受并传播追踪上下文

我们听到的最常见需求之一是实现真正的分布式追踪：一条单一的追踪，跟随请求进入 Cloudflare、穿过我们的平台，并继续流经你技术栈的其余部分。

Cloudflare Traces 可以接受来自传入请求的 W3C traceparent 标头，使 Cloudflare span 能够加入在请求到达我们平台之前就已开始的追踪。传入传播策略控制 Cloudflare 是否接受该上下文。

Cloudflare 还可以向你的源站转发新的 traceparent 标头。任何其他已插桩的服务都可以提取该上下文，并通过运行在 Cloudflare 或其他地方的 API（应用程序编程接口）、数据库和服务继续追踪。要将所有内容视为一条连接的追踪，你可以将 Cloudflare 和应用程序的 span 发送到同一个兼容 OpenTelemetry 的后端。

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

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

让你的智能体调查 Cloudflare Traces

当你让编码智能体调试生产问题时，它可能会检查你的代码并运行测试，但它可能无法看到请求在生产环境中发生了什么。借助 Cloudflare Observability MCP server，你的智能体可以利用我们的 SQL API 查询你的追踪（以及你所有的可观测性数据！），使其能够访问你的调查生产遥测数据。

让你的智能体找到正确的请求，将失败的追踪与成功的追踪进行比较，并识别它们的 span 在哪里出现分歧。由于智能体还可以检查你的代码仓库，它可以将这些发现与相关代码联系起来，缩小需要更改的范围，并帮助提出修复方案供你审查。

定价

Cloudflare Traces 将成为统一 Cloudflare Observability 定价模型的一部分。定价不再按 span/事件数量收费，而是基于你摄取多少可观测性数据以及保留多长时间。新定价将从 2026 年 12 月 1 日起在 Cloudflare Tracing（以及 Workers Tracing！）中生效。

| 方案 | 包含用量 | 保留期 | 额外用量 |
| --- | --- | --- | --- |
| 免费 | 每天 0.5 GB 摄取量 | 7 天 | 不可用 |
| 付费和企业 | 每个计费周期 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 已开放测试，可通过仪表板、API 或 Terraform 使用，并支持导出到 OTLP 目标。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：Cloudflare Blog

原创地址：https://blog.cloudflare.com/cloudflare-tracing/