日志、指标与追踪从不同角度描述同一次系统活动

服务出错时，单看一条日志可能不知道影响多大，单看错误率又不知道请求在哪一跳失败。可观测性不是把数据尽可能多地收集起来，而是让工程人员能够根据系统外部输出，回答内部正在发生什么。日志、指标和分布式追踪表达的是同一系统活动的不同投影，只有共享身份和语义时才容易关联。

OpenTelemetry 把这些输出称为信号，并将 traces、metrics、logs 和 baggage 放在统一上下文中讨论。统一并不意味着所有信号采用同一种存储，也不意味着引入采集框架后就自动获得诊断能力。

日志保留离散事件的上下文

日志适合记录某个时刻发生的事件，例如请求被拒绝、任务完成、依赖返回异常或配置发生变更。结构化字段比拼接文本更容易搜索和聚合，应包含时间、严重级别、服务、环境、事件名称和必要业务标识。

日志内容需要控制。把完整请求体、令牌或个人信息写入日志会扩大敏感数据暴露面；在高流量路径逐条记录又可能增加成本并制造噪声。事件设计应围绕可执行问题，明确保留期限、脱敏规则和访问权限。

错误日志不是越多越好。同一个失败在每层重复打印，会让一次故障看起来像数十次。通常由最了解处理结果的边界记录一次完整事件，中间层通过错误类型和上下文向上传递。若异常被恢复，也应区分“已处理”与“最终失败”。

指标把大量事件聚合为计数、测量值、分布或状态，适合回答错误率是否上升、延迟分位数怎样变化、队列是否接近容量。聚合使指标存储和查询更高效，也意味着单个请求的细节通常已经丢失。

标签让指标可以按服务、区域、版本或结果拆分，但标签值集合必须受控。把用户 ID、URL 全路径或错误文本作为标签会产生高基数，拖垮采集和查询系统。高基数细节更适合放入日志或追踪属性，并通过少量稳定维度与指标关联。

计数器、直方图和仪表盘要与语义匹配。累计请求数需要通过速率解释；延迟平均值会掩盖长尾，应保留合适边界的分布；瞬时队列长度需要理解采样频率。指标名称相同但单位、边界或重置方式不同，会产生难以察觉的错误比较。

分布式追踪把一次端到端活动表示为 trace，并由多个 span 描述各服务或操作区间。父子关系展示调用结构，开始时间和持续时间展示关键路径，状态与属性帮助定位慢点和错误。

上下文必须跨进程传播。HTTP、消息队列和后台任务的边界处理不一致时，链路会断开；异步消费也不一定适合简单父子关系，需要用链接表达多个来源。追踪 ID 只能说明记录属于同一活动，不能证明某个 span 一定导致另一个 span 的错误。

全量追踪成本高，系统常采用头部或尾部采样。头部采样在请求开始时决定，简单但可能遗漏后来失败；尾部采样看到完整结果后再保留，信息更好却需要缓冲和更复杂的管道。采样策略应使查询者知道数据是否可用于估算比例，不能把偏向错误的样本当作总体分布。

日志中写入 trace ID，指标附带受控的 exemplars，追踪记录服务版本和部署环境，能让使用者从告警跳到代表性请求，再查到相关事件。服务名、集群、区域、版本等资源属性必须采用稳定词典，否则同一实例会在不同后端中出现多个名字。

Baggage 可以随上下文传播业务相关键值，但它不是任意数据通道。传播内容会经过多个服务并可能离开信任边界，必须限制大小、来源和敏感性。把客户身份或大段调试信息放入 baggage，会增加延迟并制造隐私风险。

时间同步也影响关联。主机时钟偏差会让跨度看似倒序，日志时间与接收时间混淆会误判事件顺序。采集端应记录时间来源和偏差，调查因果时仍要结合调用关系与消息标识，而不只按时间戳排序。

可观测数据要支持明确问题，例如“用户请求是否成功”“延迟预算消耗在哪里”“发布后哪个版本错误增多”。围绕服务目标设计少量关键指标，再为故障路径增加追踪和日志，通常比先收集所有字段更可维护。

告警应关注需要行动的症状。CPU 高可能是正常高效利用，用户错误率或延迟超出目标才直接反映影响。资源指标仍用于诊断，但不应让值班人员为每个内部波动响应。

仪表盘和查询需要与运行手册连接。告警到达后，应知道先看哪些切片、如何定位代表性 trace、怎样判断是依赖故障还是自身过载。没有使用路径的数据会持续产生成本，却很少在事件中提供价值。

相关性不是因果性。某个数据库 span 很慢，可能是数据库问题，也可能是上游突发并发、连接池耗尽或追踪本身的采样偏差。诊断需要结合容量、变更记录、依赖关系和实验验证。

遥测管道自身也会失败。队列积压、采集器丢弃、时钟错误和后端限流会形成观测盲区。应监测采集成功率、丢弃量、导出延迟和配置版本，并在数据缺失时明确显示，而不是把空白解释为系统健康。

可靠的可观测性最终体现在可回答性：出现用户影响时，能否从症状缩小到版本、请求路径和故障域；发布变化后，能否比较前后；证据不足时，能否看到缺口。信号是诊断材料，不是诊断结论。