Istio笔记04-基于Jaeger的分布式链路追踪-拓冰建站

介绍

在微服务网格场景下，服务调用拓扑复杂，故障定位、时延分析难度大幅提升。Istio 原生支持分布式追踪标准，可将调用跨度数据上报至链路追踪系统。本文基于Jaeger完整落地 Istio 网格内服务调用链路采集、可视化，覆盖部署、网格配置、流量验证、生产选型等核心环节。

部署验证

环境说明

K8S 版本：1.32
Istio 版本：1.22.8
追踪组件：all-in-one:1.76.0
追踪协议：OpenTelemetry
可以参考 Istio笔记01–快速体验Istio 快速部署k8s+istio基础环境。

部署 Jaeger

安装了istio后，直接用jaeger.yaml的all-in-one快速验证
1.1 部署jaeger

$ kubectl apply-fistio-1.22.8/samples/addons/jaeger.yaml

1.2 配置gw & vs
gw yaml

apiVersion: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:HTTP

vs yaml

apiVersion:networking.istio.io/v1kind:VirtualServicemetadata:annotations:{}name:jaegernamespace:istio-systemspec:gateways:-istio-system/trace-gatewayhosts:-jaeger.xg.comhttp:-route:-destination:host:tracingport:number:80

gw + 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:"jaeger"randomSamplingPercentage:100.0# 按需设置采集比率customTags:cluster:literal:value:"k8s-bj-xx-1-yy"# 可以按需更改为需要的集群request_method:header:name:":method"request_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/null"http://bookinfo.xg.com:31480/productpage";done2） 在外部快速访问 http://test-nginx.xg.com:31480/$iforiin$(seq1100);docurl--connect-timeout2-s-o/dev/null"http://test-nginx.xg.com:31480/$i";done3）在nginx 里面访问该服务：foriin$(seq1100);docurl-s-o/dev/null"http://productpage.default:9080/productpage";done

前端展示
上述3种测试都可以正常看到其请求链路和对应的耗时、接口信息，能查看服务-服务的链路信息
3.1 从外部访问bookinfo
3.2 从外部访问nginx
3.3 从内部 nginx pod 直接访问 productpage.default

注意事项

如何单独根据traceid查询？
直接在上面输入框内输入traceid即可检索
如何根据x-request-id查询？
用户获取请求id(从日志或者istio sidecar里面查询), 然后在Search那里选中目标服务，在Tags那里输入 guid:x-request-id=4f05f59b-83d9-9c1f-9e45-604a5019853a 即可查看指定x-request-id的请求链路信息

生产环境怎么部署？
可以使用官方的helm chart部署，后端按需选择为 Elasticsearch 或者 Cassandra。
选型结论：
3.1 选择 Elasticsearch
业务需要依据自定义标签（X-Request-ID、错误码、接口名）检索链路；排查方式多样化。代价：做好分片规划、ILM 冷热索引、控制写入压力。
3.2 选择 Cassandra
只有一个查询方式：已知 TraceID 查链路；不需要任何标签检索；集群 Span 量级极大，优先保障写入稳定。

对比项	Cassandra	Elasticsearch
写入性能	极高。顺序时序写入，高吞吐、低写入抖动，适合大规模微服务海量 Span。	写入低于 Cassandra；存在段合并压力，流量极高需精细调优（分片、刷新间隔）。
检索能力	短板。仅主键 TraceID 高效查询；Tag / 自定义字段过滤无索引，全表扫描，基本不可用。	强项。支持 Span Tag、http.x_request_id 等标签过滤、模糊检索、聚合统计，满足业务按 X-Request-ID、接口名检索需求。
存储成本	压缩优秀；冷数据 TTL 清理友好。	同等数据量磁盘占用更高；开启多字段索引会进一步放大存储。
扩缩容	横向扩容简单；重平衡数据流可控，但运维门槛高（修复未压实分区、GC 调优）。	分片扩容、重建索引成本高；大规模集群运维复杂度更高。
故障恢复	节点宕机数据依赖副本，修复周期较长。	分片副本机制；容易出现分片不可用、unassigned 分片问题。
典型适用场景	只通过TraceID 查询链路；追求超高写入吞吐量；几乎不用标签检索。	需要按 Tag、RequestID、接口、状态码检索链路；经常模糊排查问题（你的业务场景首选）。
TTL 清理	原生支持按时间分区，过期数据删除轻量化。	依靠索引生命周期 ILM，定期删除整个索引，粒度为索引级别，无法单条删除 Span。