用途：在功能开发阶段同步编写可观测性代码，使生产行为可被外部查询和诊断，而非上线后再补。适用于新增服务、端点、后台任务或外部集成，排查耗时过长的故障，配置与审查告警规则，以及评审涉及 I/O、重试、队列或跨服务调用的 PR。不适用于诊断正在发生的故障、性能剖析优化，或发布日监控清单与回滚触发条件。
主要能力与做法：先写下 2 至 4 个值班工程师会问的问题，再让每个信号对应其中一个问题，否则不开始埋点。按问题选择信号：结构化日志回答“这次具体发生了什么”，指标回答“总体频率与速度”，追踪回答“时间消耗在哪些服务之间”；通常指标说明出了问题、追踪说明位置、日志说明原因。
必要用法要点：日志用 JSON 结构化字段与稳定事件名，不用字符串拼接；级别区分 error、warn、info、debug；系统边界生成或接受 request-id 并在每条日志、span 和外部调用中传播。指标对每个端点和外部依赖实施 RED（速率、错误、时长直方图），对队列、连接池、主机用 USE；标签只能来自固定小集合（路由模板、状态类、提供方名），禁止使用用户 ID、原始 URL、错误文本等无界值；延迟用直方图读 p50/p95/p99，不取平均。追踪用 OpenTelemetry 自动埋点，仅在有意义的内部分工作单元加手动 span，并跨异步边界传播上下文，默认低采样、错误尽量全留。告警基于用户可感知的症状而非原因，每条必须可行动、链接运行手册、阈值有依据，只保留 page 与 ticket 两级。最后要通过触发错误、发送测试流量、跨服务跟踪单个请求、试触发每条新告警来验证遥测本身正确。
限制：仅在上游来源与本地项目上下文明确匹配时使用；应用改动前需验证命令、生成代码、依赖、凭证和外部服务行为；示例不能替代环境特定测试、安全审查或对破坏性、高成本操作的用户批准。日志中严禁出现密钥、令牌、密码或完整 PII。