【架构实战】链路追踪与可观测性实践从日志孤岛到全链路可见分布式系统出问题的时候最让人崩溃的不是服务挂了而是不知道哪里挂了。一个请求经过网关→认证→业务→数据库→缓存→消息队列涉及七八个服务任何一个环节出问题都可能导致最终响应慢或报错。但日志散落在各个服务里查一个问题要在多个终端之间来回跳转效率极低。链路追踪Distributed Tracing解决的就是这个问题——给每个请求打上唯一ID全程记录调用链路让请求去了哪里、卡在哪里一目了然。这篇从原理到实践把可观测性体系讲清楚。一、可观测性的三大支柱可观测性Observability不等于监控它包括三个维度1. Metrics指标聚合后的数值如QPS、延迟P99、CPU使用率。回答系统健康吗。2. Logs日志离散的事件记录如ERROR日志、用户操作日志。回答发生了什么。3. Traces链路追踪请求在系统中的完整流转路径。回答为什么慢/失败了。三者的关系Metrics发现问题告警Traces定位问题根因Logs验证细节上下文。缺任何一环都不完整。二、链路追踪核心概念2.1 Trace与SpanTrace一次完整的请求调用链从入口到出口所有服务和组件的调用串联起来SpanTrace中的一个节点代表一个操作如查询用户信息、“调用支付接口”。每个Span记录操作名、开始时间、结束时间、标签Tags、关联的子Span。一个典型的Trace长这样Trace ID: abc123 └── Span: [HTTP] GET /api/orders 0ms - 850ms ├── Span: [MySQL] SELECT orders 50ms - 200ms ├── Span: [Redis] GET cache 10ms - 15ms └── Span: [HTTP] POST /pay 220ms - 600ms └── Span: [gRPC] PaymentSvc 240ms - 580ms2.2 TraceContext的传播链路追踪的关键是TraceContext在服务间的传递。入口服务生成TraceID和SpanID后续每次服务调用通过HTTP Header通常是traceparent、x-b3-traceid或gRPC Metadata把Context往下游传。下游服务提取Header继续记录自己的Span形成完整的调用链。主流标准有两个W3C TraceContext新标准traceparent: 00-traceid-spanid-flagsB3 PropagationZipkin风格X-B3-TraceId、X-B3-SpanId三、选型Jaeger vs Zipkin vs SkyWalking vs OpenTelemetry方案特点适用场景Zipkin轻量最早的追踪系统社区成熟简单场景快速上手JaegerCNCF项目K8s友好支持多种存储云原生推荐SkyWalking国产 APMUI强大集成Metrics/Logs大型企业国产化要求OpenTelemetryCNCF标准统一数据采集支持多后端推荐未来趋势强烈推荐用OpenTelemetryOTel它是CNCF的观测标准融合了OpenTracing和OpenCensus统一了Traces/Metrics/Logs的采集。一个SDK采集三种数据全部覆盖后端可以接Jaeger、Zipkin、Prometheus、Grafana等任意组合。四、Spring Boot OpenTelemetry实战4.1 引入依赖dependencygroupIdio.opentelemetry/groupIdartifactIdopentelemetry-api/artifactId/dependencydependencygroupIdio.opentelemetry.instrumentation/groupIdartifactIdopentelemetry-spring-boot-starter/artifactId/dependency4.2 配置application.ymlotel:exporter:otlp:endpoint:http://otel-collector:4317# OTel Collector地址service:name:order-service4.3 手动埋点关键操作// 方式1自动埋点Spring Boot Web自动拦截// 引入starter后所有HTTP请求自动追踪// 方式2手动埋点自定义业务逻辑importio.opentelemetry.api.trace.Tracer;ServicepublicclassOrderService{privatefinalTracertracer;publicOrderService(Tracertracer){this.tracertracer;}publicOrderResultcreateOrder(OrderDTOdto){// 开始一个SpanSpanspantracer.spanBuilder(createOrder).setAttribute(user.id,dto.getUserId()).setAttribute(order.amount,dto.getAmount()).startSpan();try(Scopescopespan.makeCurrent()){// 业务逻辑validateOrder(dto);deductStock(dto);OrderordersaveOrder(dto);span.setAttribute(order.id,order.getId());span.setAttribute(order.status,success);returnorder;}catch(Exceptione){span.recordException(e);span.setAttribute(order.status,failed);throwe;}finally{span.end();}}}4.4 异步任务的追踪异步任务如线程池、消息队列是链路追踪的难点——子任务会创建新的Span但需要正确关联到父Trace// 使用Context.current()保持链路关联SpanparentSpanSpan.current();CompletableFuture.supplyAsync(()-{// 在子线程中继续父Span的链路try(ScopescopeparentSpan.makeCurrent()){returnsendNotification(orderId);}},asyncExecutor);消息队列的追踪也一样消费者需要从MQ Header里提取TraceContextRabbitListener(queuesorder.notify)publicvoidhandleOrderNotify(Messagemsg){// 从消息Header中提取TraceContextContextextractedGlobalOpenTelemetry.getPropagators().getTextMapPropagator().extract(Context.current(),msg,GETTER);try(Scopescopeextracted.makeCurrent()){// 处理消息自动关联到原始TraceprocessNotification(msg);}}五、K8s中部署Jaeger OpenTelemetry Collector追踪数据量大不能直接让应用发往Jaeger需要经过Collector做聚合、采样、转发。5.1 OTel Collector的Deployment配置apiVersion:apps/v1kind:Deploymentmetadata:name:otel-collectornamespace:observabilityspec:replicas:1template:spec:containers:-name:otelcolimage:otel/opentelemetry-collector-contrib:latestargs:---config/etc/otelcol-contrib/config.yamlports:-containerPort:4317# OTLP gRPC-containerPort:4318# OTLP HTTP-containerPort:8888# Prometheus metricsvolumeMounts:-name:otel-configmountPath:/etc/otelcol-contribvolumes:-name:otel-configconfigMap:name:otel-collector-config---apiVersion:v1kind:ConfigMapmetadata:name:otel-collector-confignamespace:observabilitydata:config.yaml:|receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318processors:batch:timeout:1ssend_batch_size:1024memory_limiter:check_interval:1slimit_mib:512exporters:jaeger:endpoint:jaeger-collector:14250tls:insecure:trueservice:pipelines:traces:receivers:[otlp]processors:[memory_limiter,batch]exporters:[jaeger]5.2 部署JaegerapiVersion:apps/v1kind:Deploymentmetadata:name:jaegernamespace:observabilityspec:replicas:1selector:matchLabels:app:jaegertemplate:spec:containers:-name:jaegerimage:jaegertracing/all-in-one:latestenv:-name:COLLECTOR_OTLP_ENABLEDvalue:trueports:-containerPort:16686# Jaeger UI-containerPort:14250# gRPC (Collector)-containerPort:14268# Thrift (legacy)---apiVersion:v1kind:Servicemetadata:name:jaegernamespace:observabilityspec:type:NodePortports:-port:16686targetPort:16686nodePort:31686selector:app:jaeger部署后访问http://node:31686打开Jaeger UI输入服务名或TraceID即可查询。六、采样策略别让追踪数据把你淹没生产环境请求量极大100%采样会把存储打爆也推高计算成本。采样策略是关键。6.1 常见采样策略1. 固定采样Probabilisticprocessors:tail_sampling:decision_wait:10spolicies:-name:probabilistic-policytype:probabilisticprobabilistic:sampling_percentage:10# 采样10%2. 尾部采样Tail-Based Sampling这是最实用的策略——先收集所有Trace请求结束后根据结果决定是否保留。只保留慢请求1s、错误请求、有特定标签的请求极大减少存储量processors:tail_sampling:decision_wait:10spolicies:# 保留所有错误请求-name:errors-policytype:status_codestatus_code:{status_codes:[ERROR]}# 保留超过1秒的慢请求-name:slow-traces-policytype:latencylatency:threshold_ms:1000# 保留特定接口的请求-name:payment-policytype:string_attributestring_attribute:key:http.routevalues:[/api/pay/*]# 兜底10%采样-name:probabilistic-policytype:probabilisticprobabilistic:sampling_percentage:106.2 服务级别的采样配置不同服务请求量差异很大可以按服务配置采样率# 低流量服务100%采样高流量服务1%采样receivers:otlp:protocols:grpc:endpoint:0.0.0.0:4317配合Prometheus自动发现让高频服务自动降低采样率。七、可视化让数据说话链路追踪的最终价值在可视化。Jaeger提供Trace视图查看单个请求的完整调用链每个Span的耗时、状态一目了然服务依赖图Service Graph自动从Trace数据中生成服务依赖关系图延迟分析看P50/P95/P99的Span耗时分布找出性能瓶颈。# 查询最近10分钟内超过2秒的慢Tracejaeger-cli traces--limit20\--serviceorder-service\--lookback10m\--min-duration2s配合Grafana可以做成仪表盘把MetricsQPS、延迟 Traces慢Trace详情放在同一张报表里// Grafana面板配置Jaeger数据源{datasource:Jaeger,query:{service:order-service,operation:POST /api/orders,limit:20}}八、与Metrics、Logs的联动可观测性的真正威力在于三者联动。OpenTelemetry Grafana Loki存Logs Prometheus存Metrics Jaeger存Traces是目前最主流的可观测性技术栈。告警触发 → 自动跳转TracePrometheus告警order-service P99 2s时自动带上PromQL查出的时间窗口在Grafana里点一下就能跳到对应时间段的Trace列表查看哪些请求慢、慢在哪一步。这就是可观测性的闭环。九、小结链路追踪是分布式系统不可缺的工具。核心要点统一标准用OpenTelemetry作为采集层一次接入后端随意切换正确埋点HTTP/数据库/消息队列默认自动埋自定义业务逻辑手动埋别遗漏异步任务采样策略尾部采样优先保留有价值的Trace慢的、错的不要100%采样三大支柱联动Metrics发现异常 → Traces定位根因 → Logs验证细节缺一不可统一存储Jaeger/SkyWalking存TracePrometheus存MetricsLoki存LogsGrafana做统一可视化。可观测性不是可选项是分布式系统的必备能力。越早建线上问题排查效率越高熬夜越少头发越多。下篇预告从本地缓存到多级缓存架构—— Caffeine Redis 本地热点缓存的实战设计。