用途：让生产系统可被回答两个问题——任意请求为何慢或失败（凭 trace ID 无需新增埋点即可定位），以及凌晨三点出了什么故障（基于症状的告警，仅在用户受损时呼叫，并关联 runbook 与仪表盘）。
主要能力：涵盖结构化日志、指标、分布式追踪、SLO 与告警、运维就绪，既讲如何正确构建，也讲如何对抗式审计。核心观点是遥测本身是一个有用户（值班工程师）和成本（存储、基数、注意力）的产品。
BUILD 模式：写代码前先确定信号需求，明确每个端点/任务影响哪个 SLI、哪个宽事件描述工作单元、哪些 span 界定外部调用；库中使用 OpenTelemetry API 而非厂商 SDK，仅在应用入口配置 SDK/导出器，遵循 OTel 语义约定；每个请求/任务完成时发一条规范宽事件，携带 trace_id、结果、耗时与业务上下文；通过 W3C traceparent 在 HTTP、队列消息头、消费者与定时任务中传播上下文；在日志器而非调用点做脱敏，对未知对象转储失败关闭；指标标签值集必须有界，禁止 ID、URL、用户输入；随功能交付运维面（健康端点、仪表盘、燃尽率告警、runbook）；用模拟验证（杀依赖、发慢请求、触发错误）确认追踪、宽事件、指标、告警均可见且交叉链接。
AUDIT 模式：评估现有代码库与部署，先读 rules/06 完整手册，抽样真实代码路径而非信任 README。按 CRITICAL/HIGH/MEDIUM/LOW 分级，每条发现含位置、证据、影响、修复与工作量，最后给出两问结论（YES/PARTIAL/NO）及最短达标路径。
规则索引：rules/01 结构化日志、02 指标、03 追踪、04 SLO 与告警、05 运维就绪、06 审计手册。
十条不可妥协：每条日志带 trace/关联 ID；ERROR 意味着必须有人行动；遥测中无密钥与 PII；每个工作单元一条宽事件；指标标签有界；绝不平均百分位；库用 OTel API、边缘才用 SDK；存活检查只看进程、就绪检查看依赖；每次呼叫可行动、基于症状、关联 runbook；遥测有预算，刻意采样并每月审查成本。
限制：资料未提供具体安装命令、收费方式、支持平台或实测效果。