由 dawei 在现代分布式系统中，一次请求可能跨越多个服务节点，从用户端到后端数据库，中间经过网关、微服务、消息队列等环节。当系统出现延迟或错误时，传统日志排查如同大海捞针。分布式追踪技术应运而生，它通过为每个请求生成唯一的追踪标识（Trace ID），将整个调用链路串联起来，实现全链路可视。
ASP.NET Core 本身提供了基础的请求上下文支持，但要实现完整的分布式追踪，需引入标准化协议如 OpenTelemetry。通过在项目中集成 OpenTelemetry SDK，可自动捕获 HTTP 请求、数据库调用、外部服务调用等关键节点的耗时与状态信息。配置简单，只需添加 NuGet 包并注册服务即可开启追踪功能。
关键在于上下文传播。当一个请求从服务 A 调用服务 B 时，必须将当前 Trace ID 和 Span ID 通过 HTTP 头部传递。OpenTelemetry 提供了标准头名称（如 traceparent），框架会自动注入和解析这些信息，确保跨服务调用链的完整性。开发者无需手动处理，只需确保客户端和服务端都启用相同格式的追踪头。
数据采集后，需要一个集中式存储与展示平台。Prometheus + Grafana 是常见组合，也可接入 Jaeger、Zipkin 等开源追踪系统。它们提供图形化界面，可直观查看调用链拓扑、响应时间分布、错误率统计，帮助快速定位性能瓶颈或异常服务。
实战中，建议为关键业务路径添加自定义 Span，例如数据库查询、文件读写、第三方 API 调用，以补充默认追踪的不足。通过设置标签（Tags）记录参数、结果状态，可实现更细粒度分析。同时，合理控制采样率，避免高频请求导致数据过载。
AI生成的分析图，仅供参考
•别忽视性能影响。追踪虽强大，但过度埋点会增加网络开销与内存占用。建议在生产环境启用低采样率，并结合实际业务场景动态调整。真正的进阶，是让追踪成为诊断利器，而非系统负担。