1. 为什么我们需要可观测系统？

在分布式架构成为主流的今天，一个简单的HTTP请求可能涉及数十个微服务调用。当用户报告"页面加载慢"时，传统监控手段就像在黑暗房间里找钥匙——你只知道钥匙丢了，但不知道具体掉在哪个角落。这就是可观测性（Observability）要解决的核心问题：通过追踪（Tracing）、指标（Metrics）和日志（Logging）三大支柱，还原系统内部的真实状态。

我曾在生产环境处理过一个典型案例：订单支付成功率突然下降5%。传统监控仅显示"支付服务响应时间变长"，而通过分布式追踪，我们最终定位到是风控服务调用的第三方征信接口超时，进而触发了熔断机制。这种跨服务、跨系统的问题排查，正是OpenTelemetry+Jaeger的用武之地。

2. OpenTelemetry架构解析

2.1 核心组件与数据流

OpenTelemetry（简称OTel）作为CNCF毕业项目，其架构设计体现了云原生理念：

[Client App] --(Span数据)--> [OTel Collector] --(处理后的数据)--> [Jaeger] ↑ | |--(自动/手动埋点)---[OTel SDK]-----↓

关键组件包括：

• SDK：提供多种语言实现（Java/Go/Python等），支持自动埋点（如HTTP请求、DB查询）和手动埋点
• Collector：作为数据处理管道，支持接收、处理、导出观测数据
• Exporters：将数据推送到Jaeger、Prometheus等后端

2.2 自动埋点的实现原理

以Java应用为例，通过javaagent方式实现无侵入式埋点：

java -javaagent:opentelemetry-javaagent.jar -jar myapp.jar

agent会通过字节码增强技术自动拦截以下操作：

• Servlet容器请求（Tomcat/Jetty）
• JDBC数据库调用
• gRPC/HTTP客户端调用
• 主流框架（Spring、Quarkus等）的集成

3. Jaeger部署与配置实战

3.1 快速启动开发环境

使用Docker Compose部署Jaeger全组件：

version: '3' services: jaeger: image: jaegertracing/all-in-one:1.48 ports: - "16686:16686" # UI端口 - "14268:14268" # 接收OTLP协议 environment: - COLLECTOR_OTLP_ENABLED=true

关键端口说明：

• 16686：Jaeger UI访问端口
• 14250：接收jaeger.proto格式数据
• 4317：gRPC协议OTLP接收端口（推荐生产使用）

3.2 生产级部署建议

对于高负载环境应采用分离部署：

1. Jaeger Collector：独立部署并水平扩展
2. Storage Backend：使用Elasticsearch或Cassandra
3. Query Service：与UI分离部署

存储选型对比：

4. 代码级集成实践

4.1 Spring Boot应用集成示例

添加Maven依赖：

<dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-api</artifactId> <version>1.32.0</version> </dependency> <dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-sdk</artifactId> <version>1.32.0</version> </dependency>

配置OTLP导出器：

OpenTelemetry openTelemetry = OpenTelemetrySdk.builder() .setTracerProvider( SdkTracerProvider.builder() .addSpanProcessor( BatchSpanProcessor.builder( OtlpGrpcSpanExporter.builder() .setEndpoint("http://jaeger-collector:4317") .build() ).build()) .build()) .buildAndRegisterGlobal();

4.2 手动埋点最佳实践

创建自定义Span：

Span span = tracer.spanBuilder("calculateShippingFee") .setAttribute("user.id", userId) .setAttribute("order.weight", weight) .startSpan(); try (Scope scope = span.makeCurrent()) { // 业务逻辑代码 shippingService.calculate(weight); } catch (Exception e) { span.recordException(e); throw e; } finally { span.end(); }

关键注意事项：

1. 每个Span必须调用end()，否则会导致内存泄漏
2. 异常处理应使用recordException而非setStatus
3. 属性(Attribute)的值应使用基本类型而非复杂对象

5. 生产环境问题排查指南

5.1 高频问题与解决方案

问题1：Jaeger UI中Span丢失

• 可能原因：批处理导出器(BatchSpanProcessor)未正确关闭
• 解决方案：应用关闭时执行：

((OpenTelemetrySdk) openTelemetry).getSdkTracerProvider().shutdown();

问题2：高并发下内存溢出

• 优化方案：调整批处理参数

BatchSpanProcessor.builder(exporter) .setMaxQueueSize(2048) // 队列容量 .setMaxExportBatchSize(512) // 单次导出量 .setExporterTimeout(30, TimeUnit.SECONDS) // 导出超时 .build()

5.2 性能优化实战

通过Jaeger Trace分析发现：某订单查询接口95%时间消耗在DB查询。进一步分析Span属性发现：

• 相同的SQL被重复执行
• 缺少合理的缓存策略

优化后效果：

6. 高级特性深度应用

6.1 跨进程上下文传播

在微服务场景下，需要将Trace上下文通过HTTP头传递：

// 客户端注入 TextMapSetter<HttpURLConnection> setter = (carrier, key, value) -> carrier.setRequestProperty(key, value); injector.inject(span.getSpanContext(), connection, setter); // 服务端提取 TextMapGetter<HttpServletRequest> getter = new TextMapGetter<>() { public String get(HttpServletRequest carrier, String key) { return carrier.getHeader(key); } }; SpanContext context = extractor.extract(getter, request);

6.2 采样策略配置

生产环境推荐动态采样：

Sampler sampler = Sampler.parentBased( DynamicSampler.create( RateLimitingSampler.create(1000) // 每秒最大采样数 ) );

采样策略对比：

7. 真实业务场景下的观测实践

电商订单创建链路追踪示例：

[用户请求] → [API网关] → [订单服务] → [库存服务] → [支付服务] ↓ ↑ [风控服务] → [征信查询]

通过Jaeger UI可以清晰看到：

1. 征信查询耗时占整个链路60%
2. 风控服务存在同步调用导致的阻塞问题
3. 支付服务重试机制触发频繁

优化措施：

1. 将征信查询改为异步处理
2. 为风控服务添加熔断机制
3. 调整支付服务重试策略

效果验证：

• 订单创建成功率从92%提升至99.6%
• P99延迟从1.2s降至320ms