用户说“订单一直转圈”，团队却只能在几台服务器上分别搜索异常。日志并不少，但无法确认请求经过了哪些服务、卡在哪一步、与最近发布是否相关。此时需要改善的是证据之间的联系，而不仅是再安装一个日志平台。
一、从一次真实业务请求开始
选一个最常被投诉或最重要的流程，写出从入口到数据库、外部接口、消息处理的路径。列出当前能够获取的请求时间、服务版本、错误信息和业务结果，也标记哪些环节完全没有证据。
排查时要能区分“请求失败”和“请求成功但业务状态不符合预期”。前者可能有异常堆栈，后者往往需要业务状态变化记录。观测字段应服务于具体问题，而不是无限增加日志内容。
二、给不同证据安排清楚的职责
| 证据 | 主要帮助回答的问题 |
|---|---|
| 指标 | 问题何时开始，影响范围多大，错误率或耗时是否变化？ |
| 链路 | 一条请求经过哪些操作，耗时分布在哪里？ |
| 日志 | 当时的错误、分支判断和必要上下文是什么？ |
| 发布与配置记录 | 问题出现前后发生了哪些系统变更？ |
OpenTelemetry 使用 Trace 和 Span 表达请求及其操作之间的关系，能为跨组件分析提供统一基础。它仍需要正确的埋点、上下文传递和数据后端，不能自动覆盖所有业务问题。参见OpenTelemetry 链路概念。
三、先打通关联，再扩大覆盖
检查入口、应用日志、HTTP 调用与消息消费能否关联。对有消息队列的流程，还要确认发送和消费之间如何传递上下文，不能把异步业务误认为一条始终同步等待的调用。
- 同一请求的 Trace ID 能否在应用日志中检索？
- 记录里是否带有服务名称、版本和环境？
- 数据库或外部接口的耗时能否与当前请求关联？
- 重试、超时和业务拒绝能否区分，而不是全部记录为同一种异常？
四、控制采集范围与敏感信息
不建议为了方便排查就记录完整请求体、令牌和客户个人信息。先列出真正需要的字段，约定脱敏、访问权限与保留周期。业务标识可以按场景放入受控日志或链路属性，不应不加限制地成为指标标签，否则可能产生大量时间序列。
链路采样会影响可见范围。没有找到某条链路，不足以证明请求没有发生；排查时应结合采样配置、入口记录和数据采集状态。采集与查询平台本身也需要有人维护。
五、用一次排查演练检查成果
在测试环境设置一个已知异常，让未参与埋点的团队成员从告警开始定位。观察能否找到受影响接口、关联发布版本、进入对应链路，再定位具体日志和依赖。记录断点并补齐操作说明。
验收重点可以是关键流程可追踪、错误可分类、排查路径可复现，而不是仪表盘数量。如果你的 .NET 系统仍然靠逐台查日志定位问题，可以通过架构与运行诊断先确定观测缺口，再规划日志、链路和告警的实施范围。