该规范用于指导系统的可观测性建设，核心观点是：如果无法从外部对系统行为提出任意问题，系统只是被监控，而非可观测。
三大支柱：日志记录特定时刻发生的事件，适合诊断上下文、审计与状态变更；指标是对时间的数值聚合，适合实时健康信号、告警、趋势与容量规划；追踪记录单次请求跨组件的因果链（由 span 组成的树），适合端到端延迟拆解、依赖映射与失败路径分析。选择信号时按问题类型区分：是否健康用指标，为何失败用追踪加日志，某节点某时刻发生什么用日志，瓶颈在哪用追踪。
结构化日志：统一输出结构化记录与固定字段（timestamp、level、message、service、version、trace_id、span_id 等），生产默认 INFO 及以上，DEBUG/TRACE 需显式开启；日志级别应可运行时配置。禁止记录密码、令牌、密钥及完整 PII；异常在顶层处理记录一次，避免每层捕获-记录-重抛。
指标：区分 counter、gauge、histogram、summary 的用途；用 counter 累积事件并以 rate() 推导速率，gauge 记录状态快照，histogram 用于延迟与大小分布。面向服务测量四大黄金信号（延迟、流量、错误、饱和度），微服务用 RED，资源用 USE。命名带命名空间、基础单位与单位后缀，标签保持有界低基数，高基数维度应改用日志。延迟至少跟踪 p50、p90、p99，并对 p99 告警。
追踪：介绍 trace、span、根 span、子 span、span 上下文、属性、事件、链接与 span 类型（client、server、producer、consumer、internal）。跨进程必须传播上下文（默认 W3C Trace Context），入站提取、出站注入，不得在延续已有追踪时生成新 trace ID。采样可头采、尾采或错误全采，规则是错误追踪不丢弃，采样决策在入口做出并传播。
关联：以 trace_id、span_id、request_id 及 service.name/version 连接三类信号，日志中嵌入 trace_id 与 span_id，指标可附加 exemplar 指向具体追踪，从而形成从指标告警到追踪再到日志根因的排查链路。具体实现平台与工具未在资料中提供。