Observability Signals
可观测性信号
可观测性信号是系统为了说明自身行为而发出的证据。常见信号包括跟踪、指标、日志，以及在服务间传递少量上下文信息的 `Baggage`（上下文数据）。
另一个例子
结账的 p95 延迟超过 800ms。指标指向欧盟地区，样本链接会打开跟踪 `7af…`，跨度找到 `inventory.reserve`，关联日志显示超时类型，但不包含卡号。部署字段把错误缩小到 `2026.07.30` 版本，而且采样仍会保留错误。
主要部分
- 01插桩遥测
- 02关联跟踪／指标／日志
- 03收集、采样、存储和查询
什么时候用
按用户能感受到的服务目标设计信号。要传递跟踪上下文、关联 ID、限制标签值的数量，并删除敏感数据。
什么时候不要用
收集所有数据不等于可观测性。不要记录秘密或无限制的用户 ID，也不要建立没有调查方式或告警处理计划的仪表板。
代码里的名称
OpenTelemetry traces + metrics + logs + resource/attribute conventions + context propagation 上线前要检查
检查环境与预先准备的测试数据。定义看得到的预期结果、失败与边界案例。也要定义隔离方式、固定输入、排错信息与清理流程。设置执行时间预算、负责人及不稳定测试的处理规则。
预期结果：用 可观测性信号 (Observability Signals) 收集可重复验证这项行为或质量风险的证据。 用户场景：结账的 p95 延迟超过 800ms。指标指向欧盟地区，样本链接会打开跟踪 `7af…`，跨度找到 `inventory.reserve`，关联日志显示超时类型，但不包含卡号。部署字段把错误缩小到 `2026.07.30` 版本，而且采样仍会保留错误。 验证方式：可观测性信号 (Observability Signals)。 适用理由：按用户能感受到的服务目标设计信号。要传递跟踪上下文、关联 ID、限制标签值的数量，并删除敏感数据。 不应使用的情况：收集所有数据不等于可观测性。不要记录秘密或无限制的用户 ID，也不要建立没有调查方式或告警处理计划的仪表板。 测试要求：说明要测的系统与环境。定义预先准备的测试数据（Fixture）、其他输入，以及看得到的预期结果。加入预期失败、边界案例、容差、隔离方式及清理流程。 测试维护：让失败原因容易查找，并控制随机或会变化的输入。指定负责人。测试速度与维护成本要符合发布前检查的需要。 验收标准：已知缺陷存在时测试会失败，修复后通过。测试能在目标环境重复执行，提供可采取行动的证据，且不泄露或改动无关数据。 证据与限制（证据边界）：它只代表该来源的官方说法。其他平台或团队可能有不同用法。 待确认：发布前必过的检查、环境、测试数据、容差、执行时间预算、负责人，以及不稳定测试的处理规则。
检查这份需求
请 AI 编程助手检查当前如何使用 可观测性信号 (Observability Signals)。 定义：可观测性信号是系统为了说明自身行为而发出的证据。常见信号包括跟踪、指标、日志，以及在服务间传递少量上下文信息的 `Baggage`（上下文数据）。 生产环境检查：检查环境与预先准备的测试数据。定义看得到的预期结果、失败与边界案例。也要定义隔离方式、固定输入、排错信息与清理流程。设置执行时间预算、负责人及不稳定测试的处理规则。 修改程序前，先列出看到的证据、缺口、严重程度，以及最小且安全的修正。