在微服务架构中，请求往往会跨越多个服务，排查问题和性能瓶颈变得复杂。.NET 生态中有一些成熟的工具可以帮助实现分布式追踪，让开发者看清请求的完整调用链路。
1. OpenTelemetry（推荐）
OpenTelemetry 是目前最主流的开源观测性框架，支持 .NET 并已成为行业标准。它能自动收集追踪（Traces）、指标（Metrics）和日志（Logs），并支持多种后端导出。
主要特点： 官方维护的 .NET SDK（OpenTelemetry和
OpenTelemetry.Extensions.Hosting包） 支持 ASP.NET Core、gRPC、Entity Framework 等常见组件的自动检测 可将追踪数据导出到 Jaeger、Zipkin、Application Insights、Prometheus 等系统 通过 W3C Trace Context 标准传递 TraceId，确保跨服务上下文一致
使用示例（在 Program.cs 中配置）：
builder.Services.AddOpenTelemetry()
.WithTracing(tracing => tracing
.AddAspNetCoreInstrumentation()
.AddGrpcClientInstrumentation()
.AddEntityFrameworkCoreInstrumentation()
.AddOtlpExporter()); // 发送到 Collector 或后端
2. Azure Application Insights
如果你的应用部署在 Azure 或使用微软云生态，Application Insights 是一个集成度很高的选择。它基于 OpenTelemetry 构建，提供开箱即用的分布式追踪能力。
优势包括： 无需额外编码即可监控 ASP.NET Core 请求、依赖调用、异常等 自动生成服务映射图，直观展示服务间调用关系 与 Azure Monitor 深度集成，支持告警和仪表盘 支持自定义 TelemetryProcessor 进行数据过滤或增强只需添加 NuGet 包并配置连接字符串：
builder.Services.AddApplicationInsightsTelemetry();
3. Jaeger + OpenTelemetry
Jaeger 是 CNCF 成熟的分布式追踪系统，常用于 Kubernetes 环境。.NET 应用可通过 OpenTelemetry 将数据发送给 Jaeger。
典型配置方式： 使用 OpenTelemetry SDK 收集数据 通过 OTLP 或 Zipkin 协议导出到 Jaeger Agent 或 Collector 在 Jaeger UI 中查看完整的调用链、延迟分布和错误详情适合需要统一多语言追踪平台的团队。
4. Elastic APM (.NET Agent)
如果你使用 ELK（Elasticsearch + Logstash + Kibana）技术栈，Elastic APM 提供了官方的 .NET 代理，支持自动追踪。
功能亮点： 自动捕获 HTTP 请求、数据库调用、外部依赖 与 Kibana 集成，提供服务性能概览和分布式追踪视图 支持自定义事务和跨度（Span）安装
Elastic.Apm.NetCoreAll包并启用中间件即可。 基本上就这些主流方案。OpenTelemetry 是未来方向，灵活且不绑定厂商；如果用 Azure，Application Insights 更省心；已有 ELK 或 Jaeger 基础设施的团队可对应选择。关键是统一 TraceId 传递和上下文传播，确保跨服务链路不断。
