Cloudflare 文档写得很清楚：Workers 的 tracing 在 beta 期可以白嫖，从 2026 年 10 月 1 日起按事件计费，和 Workers Logs 共享额度思路——Paid 大约每月含 1000 万 events，超出按每百万事件计费（以官方定价页为准）。自动 tracing 能吐 OTel 兼容 span，也能导出到第三方。
边缘上「终于能看清请求链路」是好事。可计费一临近，后端的老问题就回来了：可观测性若没有采样与属性策略，账单比故障先到。
边缘 tracing 和你在 K8s 里那套不一样
Workers 跑在 V8 isolate 里，不是完整 Node 进程。几件具体差异：
- 标准 Node OTel SDK 很多装不上或行为不对，要用 Workers 兼容的导出路径（OTLP over HTTP 等）
- CPU 时间有限，span 导出常靠
waitUntil在响应后刷出，避免拖长 TTFB - 一次请求可能串 KV、D1、R2、Queue、子 Worker；span 很碎，事件数涨得比你想的快
- 冷启动、地区、绑定配置都会进属性；属性基数一炸，下游系统比 Cloudflare 账单先哭
所以「打开自动 tracing 就完事」只适合 demo。生产要先问：哪些路由全量，哪些采样，哪些属性允许上高基数。
10 月前我会做的四件事
1. 盘点事件量，而不是盘点「开没开」
拉一周：
- 请求 QPS × 平均每请求 span 数
- 有没有在循环里打 span（例如对数组每项
startSpan） - 日志是否和 trace 重复记录同一段 payload
粗算：日请求 × 每请求 spans × 30 对照包含额度。若已经在额度 50% 以上，先砍 span，再谈大盘分析。
2. 采样策略写进配置，不写进心情
// 示意：错误全要，健康检查不要，其余按比例
function sampleDecision(req: Request, status: number): number {
const path = new URL(req.url).pathname
if (path === '/health' || path === '/ready') return 0
if (status >= 500) return 1
if (path.startsWith('/admin')) return 1
return 0.05 // 5%
}
关键支付、鉴权回调、队列消费失败路径：全量或高采样。静态资源、健康检查：直接 0。不要全局 100% 「先看着」。
3. 属性白名单
允许：route（模板路径，不是完整 URL）、method、status、cf.ray（若需要）、queue_name、binding。
默认丢掉：完整 query string、Authorization、邮箱、用户输入原文、大 body 哈希以外的内容。
高基数的 user_id 若必须关联，考虑后处理联表，或只在错误样本里保留。你把每个用户 id 打进 span 属性，轻则钱爆，重则隐私事件。
4. 导出目标先定 SLA
Dashboard 内查看和 OTLP 导出不是同一账单心智。导出到 Grafana / Honeycomb / 自建 collector 时：
- 用 HTTP/protobuf 或平台推荐协议，注意 Workers 里 gRPC 往往不友好
- collector 侧再做一次尾部采样（错误与慢请求保留）
- 本地与 staging 开全量，production 严格采样——环境变量分开，别共用一份 wrangler 秘籍
图：边缘请求穿过多层绑定，span 数量会沿扇出成倍增加
和「自动埋点」相处的方式
自动 tracing 很香：handler、fetch 出站、部分绑定调用不用手写。风险是它不知道你的业务哪段贵。
我的折中：
- 自动埋点开着，负责骨架
- 业务 span 只包真正慢或真关键的段落（计费决策、外部支付、批量写）
- 禁止在热循环里手打 span
- 定期用「按 span name 聚合的 top N」开会，砍掉只带来噪声的名字
BullMQ 一类队列现在也有 OTel 插件。队列 job 的 trace id 要和触发它的 HTTP trace 连得上，否则你只是在两个系统里各看各的半截故事。propagation 用标准 traceparent，别自创 header 还不上文档。
钱之外的可靠性
计费会逼你少打点，但少打点不能等于瞎。底线：
- 5xx 与自定义业务错误码：样本必须足够定位
- 依赖超时：出站 fetch 的 span 要有
- 部署版本 / 配置版本：作为低基数属性挂上，方便对比回归
若额度紧张，优先保错误与延迟尾部，牺牲成功快速路径的全量画像。出了事故再临时提高采样，比常年全量烧钱清醒。
每请求 span 预算怎么定
我给中小型 API Worker 的经验值（可按业务改）：
- 入站 handler：1
- 鉴权 / 限流：0～1（可合并进 handler 属性）
- 每个外部依赖：1（KV/D1/R2/fetch 各算）
- 业务关键段：最多 2
- 合计常见目标：成功路径 ≤ 8 spans，错误路径可以到 12
超了就查 fan-out：是不是一次请求里顺序打了 20 个 KV、每个都单独成 span。能 batch 就 batch；不能 batch 就接受采样，而不是假装「多一点信号总没坏处」。
计费临近时，再加一条发布检查：staging 压一轮，导出 span name 直方图，和上周 diff。新增 name 必须有 owner 说明，否则回滚自动埋点配置。可观测性也是代码，也该有 diff review。
和日志的分工也写死：trace 回答「慢在哪一段、调了谁」；日志回答「业务上下文和错误正文」。同一段 JSON body 不要既进 span 属性又进 log 全文，那是双倍付费。
小结
Workers tracing 从「免费试用的望远镜」变成「按 span 计价的水电」，是可观测性成熟的正常一步。10 月前把采样、属性白名单、每请求 span 预算做完，比纠结选哪家 APM 更要紧。
边缘计算把进程变轻了，没把分布式系统变简单。链路还在，只是 span 更碎、账单更敏感。你要管的是：哪些信号值得花钱看见。
