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

bash 复制代码

$ kubectl apply -f istio-1.22.8/samples/addons/jaeger.yaml

1.2 配置gw & vs
gw yaml

yaml 复制代码

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  annotations: {}
  name: trace-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - prometheus.xg.com
    - grafana.xg.com
    - jaeger.xg.com
    port:
      name: http
      number: 80
      protocol: HTTP

vs yaml

yaml 复制代码

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  annotations: {}
  name: jaeger
  namespace: istio-system
spec:
  gateways:
  - istio-system/trace-gateway
  hosts:
  - jaeger.xg.com
  http:
  - route:
    - destination:
        host: tracing
        port:
          number: 80

gw + vs 就绪后，通过本地域名 http://jaeger.xg.com:31480/ 访问确保jaeger就绪

配置 Istio 开启链路追踪
2.1 在集群istio 的configmap istio中新增 extensionProviders -> jaeger

yaml 复制代码

...
    extensionProviders:
    - name: jaeger
      opentelemetry:
        port: 4317
        service: jaeger-collector.istio-system.svc.cluster.local
...

2.2 在 kube-system 命名空间新增一个默认的Telemetry

yaml 复制代码

# tracing.yaml
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: default
  namespace: istio-system
spec:
  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/

快速产生测试数据

按需快速产生一些数据

bash 复制代码

1） 在外部快速访问 bookinfo
for i in $(seq 1 100); do curl -s -o /dev/null "http://bookinfo.xg.com:31480/productpage"; done

2） 在外部快速访问 http://test-nginx.xg.com:31480/$i
for i in $(seq 1 100); do curl --connect-timeout 2 -s -o /dev/null "http://test-nginx.xg.com:31480/$i"; done

3）在nginx 里面访问该服务：
for i in $(seq 1 100); do curl -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。

采样率不要长期保持 100%，线上根据流量规模灵活调整为 5%~50%.

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

介绍

部署验证

环境说明

部署 Jaeger

验证

注意事项

参考文档