企业 OpenTelemetry 监控

OpenTelemetry 让受支持的 Copilot 客户端向团队的可观测后端发送 agent 遥测，帮助分析模型调用、工具执行和跨步骤耗时。它与 GitHub 网站审计日志是不同通道。

三类信号

信号	用途与示例
Traces	将会话步骤串起来，例如模型调用 → readFile → 再次模型调用
Metrics	观察累计或分布数值，例如输入和输出 token
Events	记录某个时刻的动作，例如用户接受或拒绝 agent edit

默认不包含提示、回答或工具参数。可选择启用内容采集，但它可能包含代码、文件内容和用户输入；要按实际诊断需求决定，而不是认为全部遥测天然只含匿名计数。

部署顺序

1. 准备支持 OTLP 的后端；若后端不能直接接收，可部署 OpenTelemetry Collector 接收、处理和转发。
2. 配置各客户端启用 OTel，并提供 endpoint、headers 与认证 token。
3. 在后端按会话、模型请求和工具事件检查数据，再分析趋势。

不能仅部署 collector 就假定用户客户端已经发送数据，也不能仅设置 endpoint 就保证后端已接收成功。

托管配置

企业可用 managed settings 的 telemetry 配置强制受支持客户端设置。具体键、内容采集与锁定见托管观测设置。客户端支持范围仍需按 managed-settings 参考核对，不把同一个 JSON 自动扩展到所有入口。

客户端详细字段与配置分别见CLI OpenTelemetry和SDK OpenTelemetry。

与其他报告配合

用量看板适合组织级采用趋势，审计日志适合许可证、政策与网站动作；OTel 适合客户端执行链路与调用统计。不同系统的事件边界可能不同，不能把导出的 token、根 span 与子 span 同名计量重复相加，再当作账单金额。

本来源未规定外部后端统一保留期限；应按团队所选后端和数据治理配置处理，不能套用 GitHub 审计日志180天或活动CSV90天的期限。

通用参考的 JetBrains telemetry 矩阵与正文范围存在差异，详见托管客户端矩阵，部署前按实际客户端核对。