本文基于一个真实的.NET 9项目集成可观测性栈的经历分享从为什么做到怎么落地的完整过程。一、为什么需要集成可观测性1.1 触发点一个慢接口项目中有一个业务接口涉及多表关联、缓存查询、外部服务调用业务联链条很长。上线后用户反馈慢但具体慢在哪一步是数据库查询是外部调用还是序列化靠日志很难定位本地复现也困难。我的诉求很简单想上好监控做到心里有数。接口整体耗时多少哪些步骤最耗时系统运行时的QPS、错误率、内存、CPU是什么水平出问题时能快速定位而不是靠猜。这就是我们集成可观测性的起点——不是为了高大上而是为了解决一个具体的问题。二、可观测性架构设计此次集成用到的核心组件有4个OpenTelemetry,Prometheus,jaeger,grafana在这之前日志的部分我们已经集成到了ELK所以整个可观测性的架构设计图如下组件作用说明OpenTelemetry Collector数据中枢接收应用推来的 OTLP 数据分发给后端Prometheus指标存储存 QPS、延迟、内存等时序数据Jaeger链路追踪存每次请求的完整调用链Grafana可视化把Prometheus和Jaeger的数据做成图表ElasticSearch日志存储通过Logstash将系统产生的各类日志传输存储注意本篇后续不过多涉及ELK相关内容这里点出来是因为和可观测性组件产生了交集。此外本文演示的相关中间件的部署环境都是基于Windows大家部署时可以根据实际情况选择部署环境。*2.1 部署架构我这里的数据可观测组件部署情况是只在1台中心服务器上部署了JaegerPrometheus和Grafana而所有应用节点服务器都通过Otel将数据推送到中心服务器也就是webapi的trace/metric全部汇聚到中心服务器只提供一个面板地址同一排查。这套架构在我这里的场景验证是有效的适合中小型项目。2.2 OpenTelemetry Collector数据中枢Collector是整个栈的核心枢纽应用只跟它通信它负责把数据分发给Prometheus和Jaeger。核心配置receivers:otlp:protocols:grpc:endpoint:0.0.0.0:4317# 应用通过这个端口推数据过来processors:batch:timeout:5s# 攒批超时减少网络开销memory_limiter:limit_mib:512# 防止数据堆积导致OOMexporters:prometheus:endpoint:0.0.0.0:8889# 暴露给Prometheus抓取otlp/jaeger:endpoint:127.0.0.1:14250# traces推给Jaegertls:insecure:true# 内网不需要TLSservice:pipelines:metrics:receivers:[otlp]exporters:[prometheus]traces:receivers:[otlp]exporters:[otlp/jaeger]关键点receivers定义数据怎么进来OTLP gRPCexporters定义数据往哪去Prometheus收指标Jaeger收tracesprocessors做批量和内存保护注意不要加namespace前缀否则Grafana查询metric名会不匹配2.3 Prometheus指标存储Prometheus 定时去 OTel Collector 拉数据pull 模式。核心配置global:scrape_interval:15s# 每 15 秒抓一次scrape_configs:-job_name:otel-collectorstatic_configs:-targets:[localhost:8889]# Collector的Prometheus exporter端口启动参数prometheus.exe--config.fileprometheus.yml--storage.tsdb.retention.time30dretention.time30d数据保留 30 天自动清理2.4 Jaeger链路追踪Jaeger负责存储和查询traces可以看到每次请求的完整调用链。核心配置Jaeger v2格式receivers:otlp:protocols:grpc:endpoint:0.0.0.0:14250# 接收 Collector 推送的 tracesexporters:jaeger_storage_exporter:# 写入存储必须否则UI为空trace_storage:jaeger_storageextensions:jaeger_query:# Web UIstorage:traces:jaeger_storagejaeger_storage:# 内存存储后端backends:jaeger_storage:memory:max_traces:100000service:pipelines:traces:receivers:[otlp]exporters:[jaeger_storage_exporter]# 必须包含踩坑提醒traces pipeline必须包含jaeger_storage_exporter否则Jaeger UI里Service下拉为空这是最常见的坑。2.5 Grafana可视化Grafana负责把数据做成图表配置两个数据源即可datasources:-name:Prometheustype:prometheusurl:http://localhost:9090isDefault:true-name:Jaegertype:jaegerurl:http://localhost:16686部署顺序很重要1. Jaeger ← 必须先启动Collector 要连它的 14250 2. OTel Collector ← 接收应用数据 3. Prometheus ← 抓取指标 4. Grafana ← 可视化上述服务部署后控制台输出效果分别如下jaeger服务启动后控制台输出启动Otel Collector后传输数据效果如下启动Prometheus后控制台输出效果如下grafana启动后控制台输出三、项目代码3.1 和OpenTelemetry通信.NET项目里只需要做一件事通过OTel SDK把数据推给OTel Collector。后面的Prometheus、Jaeger、Grafana都是接收和展示不需要应用关心。NuGet 包PackageReferenceIncludeOpenTelemetry.Extensions.HostingVersion1.15.3/PackageReferenceIncludeOpenTelemetry.Instrumentation.AspNetCoreVersion1.15.2/PackageReferenceIncludeOpenTelemetry.Instrumentation.RuntimeVersion1.15.1/PackageReferenceIncludeOpenTelemetry.Exporter.OpenTelemetryProtocolVersion1.15.3/服务注册约 30 行代码privatestaticvoidConfigureOpenTelemetry(thisWebApplicationBuilderbuilder){stringotlpEndpointbuilder.Configuration[OTEL_EXPORTER_OTLP_ENDPOINT]??http://localhost:4317;builder.Services.AddOpenTelemetry().WithTracing(tracing{tracing.AddAspNetCoreInstrumentation()// 自动采集HTTP请求traces.AddSource(Declaration.*)// 通配自定义Span.ConfigureResource(rr.AddService(Magic.Declaration.WebAPI)).AddOtlpExporter(options{options.EndpointnewUri(otlpEndpoint);options.ExportProcessorTypeExportProcessorType.Batch;});}).WithMetrics(metrics{metrics.AddAspNetCoreInstrumentation()// 自动采集HTTP请求指标.AddRuntimeInstrumentation()// .NET运行时指标GC、CPU、内存.ConfigureResource(rr.AddService(Magic.Declaration.WebAPI)).AddOtlpExporter(options{options.EndpointnewUri(otlpEndpoint);});});}采集信息类别类别指标说明HTTP 请求QPS、延迟分布、状态码Instrumentation.AspNetCore自动采集.NET 运行时GC、CPU、内存、线程池Instrumentation.Runtime自动采集3.2 开发环境为了保持开发环境的高效且能看到采集到的基本数据我们可以在开发环境配置将采集的数据输出到控制台。if(builder.Environment.IsDevelopment()){tracing.AddConsoleExporter();// traces 输出到控制台}启动应用后控制台会直接输出每次请求的 trace 信息Activity.TraceId: 8d35e... Activity.SpanId: a7f2e... Activity.DisplayName: GET /api/order/detail Activity.Kind: Server Activity.Duration: 00:00:00.1234 Resource associated with Activity: service.name: MyApp.WebAPI效果如下开发阶段用控制台就够了不用装任何额外组件。3.3 可拔插设计这套可观测性栈是锦上添花型接入不是项目运行的必要条件不装 OTel Collector应用正常跑只是不采集数据不装 Prometheus/JaegerCollector 可以只做控制台输出环境变量不配代码里有默认值http://localhost:4317对业务代码零侵入所有配置都收敛在服务注册阶段业务代码不需要任何改动。四、怎么验证和分析采集到的数据4.1 验证数据流部署完成后先验证数据是否流通# 1. 检查 Collector 是否在接收数据curlhttp://localhost:8888/metrics|findstraccepted_spans# 2. 检查 Prometheus 是否有指标curlhttp://localhost:9090/api/v1/query?queryhttp_server_request_duration_seconds_count# 3. 检查 Jaeger 是否有 tracescurlhttp://localhost:16686/api/services4.2 Jaeger链路追踪分析Jaeger UI地址http://localhost:16686定位链条打开Jaeger面板后点击某条Trace展开看完整的调用链[HTTP GET /api/order/detail] 120ms ├── [MyApp.CreateOrder] 95ms ← 你的自定义 Span │ ├── [FreeSql Query] 80ms ← 数据库查询 │ └── [Redis Get] 5ms ← 缓存读取 └── [HTTP Response] 10msTips链路追踪数据除了在Jaeger面板查看也可以集成到Grafana统一管理本篇受篇幅限制不在赘述下面分别给出Jaeger和Grafana的面板效果。jaeger面板grafana面板常见场景场景操作接口慢但不知道慢在哪搜该接口的Trace → 看哪个Span耗时最长间歇性超时搜Duration 1s的Trace → 对比正常和异常的差异500 错误搜Status ERROR的Trace → 看Logs中的异常信息4.3 Grafana配置DashboardGrafana UI地址http://localhost:3000第一步添加数据源如果用 provisioning 文件部署则自动配置Configuration → Data Sources → Add data source → 选 Prometheus 和 Jaeger第二步创建 Dashboard推荐先建一个包含以下面板的Dashboard面板数据源PromQL实时QPSPrometheussum(rate(http_server_request_duration_seconds_count[1m]))P95延迟Prometheushistogram_quantile(0.95, sum(rate(http_server_request_duration_seconds_bucket[5m])) by (le))错误率Prometheussum(rate(http_server_request_duration_seconds_count{http_response_status_code~5..}[5m])) / sum(rate(http_server_request_duration_seconds_count[5m]))内存占用Prometheusdotnet_gc_last_collection_heap_size_bytesCPU使用率Prometheusrate(dotnet_process_cpu_time_seconds_total[1m])第三步按路由分组想看每个接口的独立指标用by (http_route)分组sum(rate(http_server_request_duration_seconds_count[5m])) by (http_route, http_request_method)Dashboard 设计原则顶部放概览数字QPS、延迟、错误率、CPU中间放趋势图按时间变化底部放明细表按接口分组Grafana效果注意以上统计的方法均可在Grafana社区官网查询到也可以在这里https://grafana.com/grafana/dashboards/查询一些模板直接套用。还可以直接把你的需求告诉你的智能体助手。五、总结集成可观测性的本质是让系统运行状态可见而不是靠猜。四个组件各司其职OpenTelemetry Collector 做数据中枢Prometheus 存指标Jaeger 存链路Grafana 做展示.NET 项目要做的很少接入 OTel SDK配置 OTLP 导出地址自动采集 HTTP 请求和运行时指标需要时加自定义 Span 定位业务逻辑开发阶段控制台就能看生产环境按需部署可拔插、零侵入不装组件不影响业务运行配置都在服务注册阶段业务代码无感环境变量控制接入程度可观测性不是一次性任务而是持续的过程——先跑起来遇到问题再逐步深入。