一、为什么需要集成可观测性？

至于触发点，一个“慢”接口

项目中有一个业务接口。涉及多表关联、缓存查询、外部服务调用，业务链路很长。怎么说呢，上线后使用者反馈“慢”，但具体慢在哪一步？是数据库查询，是外部调用？还是序列化，靠日志很难定位，本地复现也困难。

我的诉求很简单：想上好监控，做到心里有数。

• 接口整体耗时多少？哪些步骤最耗时，
• 水平？
• 出问题时能快速定位，而不是靠猜。

这就是我们集成可观测性的起点——不是为了“高大上”，而是为了解决一个具体的问题。

二、可观测性架构设计

此次集成，用到的主要组件有四个：OpenTelemetry、Promeus、Jaeger、Grafana；日志部分已经通过 ELK完成。说到整体架构如下，

组件	作用	说明
OpenTelemetry Collector	数据中枢，接收应用推送的 OTLP 数据并分发给后端
Promeus	指标存储，保存 QPS、延迟、内存等时序数据
Jaeger	链路追踪。存每次请求的完整调用链
Grafana	可视化，把 Promeus 与 Jaeger 的数据做成图表
ElasticSearch	日志存储，通过 Logstash 将程序产生的各类日志传输并持久化

* 部署架构

在我的实践中，只在一台中心服务器上部署 Jaeger、Promeus 与 Grafana；所有应用节点有效，

OpenTelemetry Collector：数据中枢

Collector 是整个栈的主要枢纽。应用只与它通信，它负责把数据分发给 Promeus 与 Jaeger。

主要配置：

receivers:
otlp这方面，protocols:
说到grpc，endpoint: "0.0.0.0:4317"
processors:
从batch来看，timeout: 5s # 攒批超时减少网络开销
memory_limiter:
limit_mib: 512 # 防止数据堆积导致 OOM
exporters:
promeus:
endpoint: "0.0.0.0:9464" # 暴露给 Promeus 抓取
otlp/jaeger:
endpoint: "http://jaeger:14250"
tls的观点是。insecure: true # 内网不需要 TLS
service:
pipelines:
metrics:
receivers:
exporters:
至于traces，receivers:
exporters:

关键点：

• `receivers` 定义数据如何进来。
• `exporters` 定义数据往哪去。 老实说，
• `processors` 做批量和内存保护。
• 不要随意添加 `namespace` 前缀，否则 Grafana 查询 metric 名会不匹配。

Promeus：指标存储

PROMETHEUS 使用 pull 模式定时去 OTel Collector 拉取指标。

global:
scrape_interval: 15s
scrape_configs:
- job_name: "otel-collector"
static_configs:
- targets: # Collector 的 Promeus exporter 地址

启动参数示例：

promeus.exe --config.file=promeus.yml --storage.tsdb.retention.time=30d
# retention.time=30d 表示保留30天的数据，会自动清理旧数据。按理说，

至于Jaeger。链路追踪

Jaeger 用于存储和查询 traces，可以看到每次请求的完整调用链。

receivers:
从otlp来看，protocols:
至于grpc，endpoint: "0.0.0.0:4317"
exporters:
jaeger_storage_exporter:
extensions:
jaeger_query:
service:
pipelines:
从traces来看。receivers:
exporters:
extensions:
storage:
trace_storage_type: memory # 简化演示，可换为 Elasticsearch 等持久化方案

S​踩坑提醒：S​t​races pipeline 必须包含 `jaeger_storage_exporter`，否则 Jaeger UI 中 Service 列表为空，这是最常见的问题。说起来，

Kibana 已经负责日志展示。这里只需要把 Promeus 与 Jaeger 加入 Grafana 即可。

D​ata‑source 配置示例：

datasources:
- name: Promeus
至于type，promeus
url : http://localhost:${PROMETHEUS_PORT}
isDefault : true
- name : Jaeger
type : jaeger
url : http://localhost:${JAEGER_QUERY_PORT}

D​eployment order ：

. Jaeger ← 必须先启动
. OpenTelemetry Collector ← 接收应用数据
. Promeus ← 抓取指标
. Grafana ← 可视化展示

三、项目代码

和 OpenTelemetry 通信

.NET 项目里只需要做一件事：#通过 OTel SDK 把数据推给 OTel Collector#”。后端组件全部由 Collector 转发，无需业务代码感知。

N uGet 包：

服务注册 ：

 private static void ConfigureOpenTelemetry
{
string otlpEndpoint = builder.Configuration
从"http来看，//localhost:{OTLP_PORT}";// Tracing -------------------------------------------------
builder.Services.AddOpenTelemetry
.WithTracing(tracing =>
{
tracing.AddAspNetCoreInstrumentation // 自动采集 HTTP 请求 trace
.AddSource // 自定义 Span 前缀，可按需添加
.ConfigureResource)
.AddOtlpExporter(opts =>
{
opts.Endpoint = new Uri;opts.ExportProcessorType = ExportProcessorType.Batch;})，})
// Metrics -------------------------------------------------
.WithMetrics(metrics =>
{
metrics.AddAspNetCoreInstrumentation // 自动采集 HTTP 请求指标
.AddRuntimeInstrumentation // .NET Runtime 指标
.ConfigureResource)
.AddOtlpExporter);})，}

采集信息类别 ：

<\/ad>

类别	指标	说明
HTTP 请求	QPS 、 延迟分布 、 状态码	Instrumentation.AspNetCore 自动采集 HttpServerRequest* 系列 metric HttpServerRequestDuration* histogram HttpServerResponseStatusCode* counter / td>
.NET Runtime	dotnetgc*。dotnetprocesscputimesecondstotal,dotnetthreadpool_* ... / td>	\ n Instrumentation.Runtime 自动采集 \ n <\/tbody> <\/table> 开发环境<\/h33>

。

---