Claude Code 2.1.235 遥测事件目录¶

版本证据：Static（已发布 bundle 的 AST 清单）+ Derived（确定性聚合）+ Heuristic（字段名启发式）+ Boundary（静态包无法证明的运行时/服务端状态）。

60 秒看懂：一条事件如何走到不同出口¶

读者问题： Claude Code 里一次工具调用、API 请求、压缩或错误到底会留下什么事件？事件从哪个客户端通道产生、携带哪些静态可见字段、是否具备 Datadog 转发资格，又有哪些信息仅凭发布包无法证明？

这份目录把 1,441 个静态一方事件和 43 个动态事件名调用点分开：前者可以按名字聚合，后者只能保留表达式与位置，不能伪装成已经解析的产品事件。

一句话模型： 业务组件在本地调用通道专属 logger 形成事件候选，客户端再按门控、采样、队列、批处理和 exporter 配置决定是否尝试发送；静态事件名或 Datadog allowlist 命中都不等于运行时已经上报，更不证明服务端接受或保留。

贯穿场景：用户发起一次请求，Agent 调用工具，权限层作出决定，工具返回结果，随后上下文触发 compact。这个场景可以同时遇到两组互不等价的记录面：

1. 一方业务代码可能调用 H / Fv 记录 tengu_tool_use_success、tengu_api_success、tengu_compact 等候选事件。它们先进入一方队列，再受共享非必要流量门、远程采样和 batch exporter 控制。
2. 管理员显式启用 OTEL 后，代码中的 Nd 调用点可形成 tool、tool_decision、tool_result、compaction 等 structured event，并交给管理员配置的 exporter。
3. 若一方事件名位于 Datadog 的 181 项 allowlist，它只获得进入该转发分支的资格；first-party provider、feature gate、killswitch、初始化、限流与发送成功仍是额外条件。
4. 同一动作没有“一条万能遥测记录”。不同通道拥有不同 gate、字段处理、队列和目的地，不能拿一个通道的开关或删除字段推断另一个通道。

通道所有权表¶

family 层的 tengu_other 只表示事件名没有命中 release-local family 规则。它不是产品 owner、模块边界或服务端分类；后文 caller projection 只给 140 个逐项复核的 exact callsite 归属，剩余 891 个事件保持 Unresolved。像 tengu_background 这类 singleton label 仍只匹配同名事件，不会自动吞并所有同前缀名字。

字段怎么读¶

隐私、采样、批处理、失败和服务端边界¶

• 隐私： 一方 envelope、Datadog 归一化和 OTEL content gate 是不同层。Datadog 的 26 个删除字段只约束 Datadog 分支；OTEL prompt/tool/response 正文还受独立开关和长度上限控制；字段名启发式不能替代值级审计。
• 采样： 一方事件可按事件名读取 sample_rate。缺少/非法/等于 1 时不额外采样，<= 0 丢弃，0 < rate < 1 才随机判定。目录中的调用点不会因为运行时未采中而消失。
• 队列与批处理： 一方 sink 安装前 FIFO 上限 1,000，logger 初始化前队列上限 1,024；默认 provider queue 8,192、batch 200、flush 10 秒、请求 timeout 10 秒。Datadog 默认 batch 100、flush 15 秒、timeout 5 秒。
• 失败： 一方 exporter 的连续失败周期默认最多 8 attempts，二次 backoff 在 500 ms 到 30 s 之间；剩余 batch 可写入本地 telemetry storage，部分成功时只重写未发送部分。HTTP 401 还存在去认证头的单次 fallback。OTEL 默认 flush timeout 5 s、shutdown timeout 2 s；超时只说明客户端停止等待，不能证明 collector 最终收到了积压。调用点清单本身不记录某次发送结果。
• 服务端边界： bundle 能证明客户端分支、字段和 transport 形状，不能证明服务端接收、去重、聚合、告警、保留期限、账号风控或人工访问。任何此类结论都需要 wire capture、服务端配置或服务端证据。

从事件产生到各出口的有序生命周期¶

下面按一次真实业务动作可能经过的顺序拆开状态。H / Fv 的一方通道与 Nd 的 OTEL 通道可以由同一业务动作分别调用，但没有证据表明一个 logger 自动复制成另一个 logger。

可读源码证据锚点¶

以下链接指向同一 2.1.235 readable view，不使用本机绝对路径：

1. 全局 sink/FIFO 与排空路径。
2. 错误上报的 provider/auth/policy/compliance gates。
3. 一方 batch endpoint 与 exporter 构造。
4. 失败 batch 文件/stream 持久化与恢复。
5. 一方 provider、pre-init queue、flush/rebuild。
6. sampling config 与 batch config 读取。
7. Datadog endpoint、client 和默认 batch 参数。
8. Datadog feature gate、allowlist、字段归一化与限流。
9. OTEL structured events 与内容字段处理。
10. OTEL/Perfetto span 构造与关联。
11. OTEL metrics/logs/traces exporter bootstrap。
12. 观测环境变量、content gates、flush/shutdown 配置入口。

Token、成本、延迟、隐私和副作用¶

按排障场景阅读：事件名、字段和状态变化¶

下面不是再造一套事件 taxonomy，而是把最常用的调用点放回真实状态机。箭头表示同一业务场景中可能出现的先后关系，不保证每次都经过所有节点；例如预授权工具不会显示 permission dialog，API 首次成功也不会产生 retry。

为什么 family tengu_other 不能再承担语义归属¶

tengu_other 不能当作语义兜底或低价值垃圾桶；它只表示当前 family 前缀规则没有命中。独立 caller projection 已逐项复核 compact、transcript 写入/压实、tool hook、remote review、fast mode、daemon recall、GitHub setup、官方 Marketplace、remote stage file 与 File History rewind 等 exact caller；tengu_query_error 等未映射事件继续标成 Unresolved。排障先看 exact caller 证据，再用 family 做名字导航；family 和行区间都不能决定产品所有权。

精确覆盖摘要¶

字段名启发式总览¶

1,441 个事件的静态 expanded field 集合共有 2,292 个唯一字段名。下面只是字段名命中，不读取运行时值，也不表示字段一定会发送。一个字段可以命中多个组。

Datadog 的删除字段和 tag 字段在后文独立列出。redacted 是该分支的静态处理集合，tag 是归一化/索引集合；两者都不能被外推成所有遥测通道的统一隐私策略。

tengu_other caller/owner 场景投影¶

family projection 有 911 个名字、1,297 个静态调用点落入 tengu_other。生成器先把它们与同哈希 readable view 逐个对齐，再只接受 140 条逐 caller 人工 allowlist：这些调用点完整覆盖 20 个事件，其余 891 个事件、1,157 个调用点保持 Unresolved。family 继续承担名字导航；caller projection 不会用邻近行替未审阅 caller 猜 owner。

分类合同¶

1. 输入不是事件名清单。 每条 allowlist 同时固定 event name、readable line、词法 function、consumer parent/relation/role、inventory comparison key 和 16 位证据指纹；缺一项都不能命中。
2. owner 由 exact caller allowlist 决定。 readable range 只帮助人阅读附近代码，分类器完全不读取 range；扩大导航区间不会吸收同区间的其他 caller，事件前缀也不会自动成为 owner。
3. 同名事件按全部调用点聚合。 全部 caller 都有 exact mapping 且落在同一 owner 才是 Single-owner；跨 host/owner 的同名事件标成 Cross-owner；只有一部分 caller 命中时标成 Partially resolved；所有调用点都没有 exact mapping 才是 Unresolved。
4. 双重身份校验防止静默换义。 inventory comparison key 参与初筛；event/function/consumer/payload/canonical position/readable line/rule 生成的 16 位 SHA-256 前缀再做复核。整个 140 条 allowlist 连同 rule 的状态变化与 Boundary 另有完整 SHA-256，删除或篡改都会让生成失败。
5. 这是客户端 Derived 投影。 它说明 2.1.235 中 logger caller 的状态 owner，不证明分支实际执行、采样命中、网络送达、服务端保留，也不声称这些 owner 是 Anthropic 原始源码模块名。

覆盖结果¶

Caller owner buckets¶

Unresolved bucket 是未完成人工归属的显式欠账，不是一个产品 owner。事件 membership 可以在 Cross-owner 情况下进入多个已解析 owner bucket，所以 owner 表的 member-event 列不能相加后当作 911；上面的 status 表才是互斥覆盖。callsites 按真实调用点计数。

代表性因果链¶

不靠名字猜的代表： tengu_copper_lantern 的名字和空 payload 都不提供产品语义；其唯一 caller 位于 daemon supervisor 的 service-recall 条件，紧邻 worker drain、service uninstall 和 tengu_daemon_exit{cause=service_recall}。因此 exact identity event + L632061 + named:Ehy + ExpressionStatement/expression/other + comparison key + fingerprint 才绑定到 remote-runtime / daemon supervisor；L632000-L632084 仅供阅读上下文。

不能强行单归属的代表： tengu_fast_mode_toggled 有四个 caller，分别位于身份/模型访问、remote review、usage picker 和消息 UI。目录把它保留为 Cross-owner，说明同名事件可以是共享观测词，而不是共享状态 owner。

Cross-owner events¶

这些同名事件的 caller 确实跨 owner；把它们按名字强制归入一个功能，会丢掉 host 或状态所有权差异。

真正未收口的调用点¶

当前明确欠账是 891 个 Unresolved events / 1,157 个 callsites。Unresolved 不是低价值事件，而是当前没有逐 caller 复核结果承担语义归属。即便调用点恰好落在某个已解释机制附近，也不会自动继承邻近 owner。

高频仍不等于可批量认领。 本批只有在逐 caller 复核后才收口 tengu_review_remote_precondition_recovery：前 12 个 caller 位于 remote-review gate/recovery 链，最后 1 个 caller 则以独立 exact identity 绑定 /ultrareview 的 branch/no-merge-base continuation；它不是从前一段导航区间继承 owner。相反，tengu_feedback_survey_event 的 13 个 caller 仍分布在多种 survey/feedback surface，tengu_left_arrow_blocked 的 10 个 caller 仍跨输入编辑、inflight guard 与不同 TUI 路径，tengu_git_operation 的 10 个 caller 仍同时观察 shell command 与 MCP tool name；这三组继续保持 Unresolved。

下列四个反例仍必须保持 Unresolved：前三个证明宽行区间不能赋 owner；tengu_streaming_fallback_to_non_streaming 则与已映射 parser event 共享 named:vAm，但 event/line/consumer/comparison identity 不同，证明同名函数也不能赋 owner。即使把 allowlist 导航区间扩大到全文件，它们仍不会命中：