日志内容很多，排查时却无法确认是不是同一笔业务，往往是关联字段不一致。日志设计应从排查问题出发，约定服务、环境、版本和请求标识，而不只是统一输出格式。
让字段表达稳定含义
区分请求关联标识、业务标识和消息标识。一个业务可能经过多次请求和重试，不能只靠某个 HTTP 请求 ID 串起全部生命周期。字段名称与用途应在团队中保持一致。
记录结果与必要上下文
关键状态变化、拒绝原因和外部调用结果，通常比大量“开始执行”“执行完成”更有用。日志应帮助回答发生了什么以及接下来怎么查，避免在每层重复记录同一个异常堆栈。
控制敏感数据与规模
不要默认记录完整请求体、凭证或客户资料。必要业务标识应受访问权限和保留规则控制。对高频路径先估算日志量，避免为了排查方便制造不可持续的存储成本。
验收从客服信息找到业务
只提供时间范围和受控业务标识，让另一位成员定位服务、版本和关键状态。若仍需要原开发者解释字段，说明日志约定还不够清楚。
常见问题：Trace ID 能替代订单号等业务标识吗？
不能完全替代。一次订单可能跨越多个请求与异步过程，技术关联与业务关联需要配合使用。
技术参考：微软：.NET 与 OpenTelemetry。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。