介绍在微服务网格场景下服务调用拓扑复杂故障定位、时延分析难度大幅提升。Istio 原生支持分布式追踪标准可将调用跨度数据上报至链路追踪系统。本文基于Jaeger完整落地 Istio 网格内服务调用链路采集、可视化覆盖部署、网格配置、流量验证、生产选型等核心环节。部署验证环境说明K8S 版本1.32Istio 版本1.22.8追踪组件all-in-one:1.76.0追踪协议OpenTelemetry可以参考 Istio笔记01–快速体验Istio 快速部署k8sistio基础环境。部署 Jaeger安装了istio后直接用jaeger.yaml的all-in-one快速验证1.1 部署jaeger$ kubectl apply-fistio-1.22.8/samples/addons/jaeger.yaml1.2 配置gw vsgw yamlapiVersion:networking.istio.io/v1kind:Gatewaymetadata:annotations:{}name:trace-gatewaynamespace:istio-systemspec:selector:istio:ingressgatewayservers:-hosts:-prometheus.xg.com-grafana.xg.com-jaeger.xg.comport:name:httpnumber:80protocol:HTTPvs yamlapiVersion:networking.istio.io/v1kind:VirtualServicemetadata:annotations:{}name:jaegernamespace:istio-systemspec:gateways:-istio-system/trace-gatewayhosts:-jaeger.xg.comhttp:-route:-destination:host:tracingport:number:80gw vs 就绪后通过本地域名 http://jaeger.xg.com:31480/ 访问确保jaeger就绪配置 Istio 开启链路追踪2.1 在集群istio 的configmap istio中新增 extensionProviders - jaeger...extensionProviders:-name:jaegeropentelemetry:port:4317service:jaeger-collector.istio-system.svc.cluster.local...2.2 在 kube-system 命名空间新增一个默认的Telemetry# tracing.yamlapiVersion:telemetry.istio.io/v1alpha1kind:Telemetrymetadata:name:defaultnamespace:istio-systemspec:tracing:-providers:-name:jaegerrandomSamplingPercentage:100.0# 按需设置采集比率customTags:cluster:literal:value:k8s-bj-xx-1-yy# 可以按需更改为需要的集群request_method:header:name::methodrequest_path:header:name::path验证相关测试服务域名按需准备如下测试域名当前没有接入LB,直接指向gw svc对应的31480端口http://test-nginx.xg.com:31480/http://bookinfo.xg.com:31480/http://jaeger.xg.com:31480/快速产生测试数据按需快速产生一些数据1 在外部快速访问 bookinfoforiin$(seq1100);docurl-s-o/dev/nullhttp://bookinfo.xg.com:31480/productpage;done2 在外部快速访问 http://test-nginx.xg.com:31480/$iforiin$(seq1100);docurl--connect-timeout2-s-o/dev/nullhttp://test-nginx.xg.com:31480/$i;done3在nginx 里面访问该服务foriin$(seq1100);docurl-s-o/dev/nullhttp://productpage.default:9080/productpage;done前端展示上述3种测试都可以正常看到其请求链路和对应的耗时、接口信息能查看服务-服务的链路信息3.1 从 外部访问bookinfo3.2 从外部访问nginx3.3 从内部 nginx pod 直接访问 productpage.default注意事项如何单独根据traceid查询直接在上面输入框内输入traceid即可检索如何根据x-request-id查询用户获取请求id(从日志或者istio sidecar里面查询), 然后在Search那里选中目标服务在Tags那里输入 guid:x-request-id4f05f59b-83d9-9c1f-9e45-604a5019853a 即可查看指定x-request-id的请求链路信息生产环境怎么部署可以使用官方的helm chart部署后端按需选择为 Elasticsearch 或者 Cassandra。选型结论3.1 选择 Elasticsearch业务需要依据自定义标签X-Request-ID、错误码、接口名检索链路排查方式多样化。 代价做好分片规划、ILM 冷热索引、控制写入压力。3.2 选择 Cassandra只有一个查询方式已知 TraceID 查链路不需要任何标签检索集群 Span 量级极大优先保障写入稳定。对比项CassandraElasticsearch写入性能极高。顺序时序写入高吞吐、低写入抖动适合大规模微服务海量 Span。写入低于 Cassandra存在段合并压力流量极高需精细调优分片、刷新间隔。检索能力短板。仅主键 TraceID 高效查询Tag / 自定义字段过滤无索引全表扫描基本不可用。强项。支持 Span Tag、http.x_request_id 等标签过滤、模糊检索、聚合统计满足业务按 X-Request-ID、接口名检索需求。存储成本压缩优秀冷数据 TTL 清理友好。同等数据量磁盘占用更高开启多字段索引会进一步放大存储。扩缩容横向扩容简单重平衡数据流可控但运维门槛高修复未压实分区、GC 调优。分片扩容、重建索引成本高大规模集群运维复杂度更高。故障恢复节点宕机数据依赖副本修复周期较长。分片副本机制容易出现分片不可用、unassigned 分片问题。典型适用场景只通过TraceID 查询链路追求超高写入吞吐量几乎不用标签检索。需要按 Tag、RequestID、接口、状态码检索链路经常模糊排查问题你的业务场景首选。TTL 清理原生支持按时间分区过期数据删除轻量化。依靠索引生命周期 ILM定期删除整个索引粒度为索引级别无法单条删除 Span。采样率不要长期保持 100%线上根据流量规模灵活调整为 5%~50%.参考文档www.jaegertracing.iowww.jaegertracing.io/demoistio doc - 分布式追踪的常见问题Jaeger存储后端选择Elasticsearch与Cassandra对比分析