之前我分享过Jaeger的入门使用，介绍了Jaeger的基本概念、架构、部署和使用方法，很多朋友反馈很有帮助。

但是，用了一段时间之后，大家发现Jaeger还有很多高级功能和技巧，平时很少用到，但是用好了能大幅提升排查问题的效率和系统的可观测性。比如，怎么高效地查询Trace？怎么合理设置采样策略？怎么优化Jaeger的性能？怎么和日志、监控等其他工具集成？怎么自定义扩展Jaeger？

这些问题，在入门文章里都没有详细讲。今天，我就来分享一下Jaeger的一些进阶技巧，这些技巧可能很多人都不知道，但是用好了能让Jaeger发挥更大的价值。

本文假设你已经了解Jaeger的基本概念和使用方法，如果还不了解，可以先看看我之前的入门文章。

一、高级查询技巧

Jaeger的UI提供了基本的查询功能，比如按服务、操作、时间范围、标签查询。但是，很多人不知道，Jaeger还有一些高级查询技巧，能让你更高效地找到想要的Trace。

技巧1：用标签组合精确查询

Jaeger的查询，支持按标签（Tag）查询，而且支持多个标签组合查询。很多人只用了服务名和操作名查询，不知道可以用标签来精确筛选。

比如，你想查询所有HTTP状态码为500的请求，可以这样查询：

  • 服务：order-service
  • 标签：http.status_code=500

再比如，你想查询某个用户的所有请求，可以这样查询：

  • 标签：user.id=12345

还可以组合多个标签，比如：

  • 服务：order-service
  • 标签：http.status_code=500 AND error=true

用标签组合查询，能快速定位到你关心的请求，特别是在Trace数量很多的时候，比只按服务和操作名查询高效很多。

要使用标签查询，你需要在代码里给Span设置合适的标签。比如，HTTP请求的状态码、请求方法、URL、用户ID、订单ID等，都可以设置为标签，方便后续查询。

技巧2：用操作名模糊匹配

Jaeger的操作名查询，支持模糊匹配。很多人不知道，以为只能精确匹配操作名。

比如，你的服务有很多操作，比如GET /api/users、POST /api/users、GET /api/users/{id}等，你想查询所有用户相关的操作，可以在操作名里输入/api/users，Jaeger会模糊匹配所有包含这个字符串的操作。

模糊匹配，在操作名很多的时候特别有用，能快速筛选出一类操作。

技巧3：用Trace ID直接跳转

如果你已经知道了Trace ID（比如从日志或者告警里拿到的），可以直接在Jaeger UI的右上角输入Trace ID，直接跳转到这个Trace的详情页，不需要再去查询。

这个技巧，在排查问题的时候特别有用。比如，用户反馈某个请求出错了，你从日志里拿到了Trace ID，直接输入Trace ID，就能看到完整的调用链，快速定位问题。

技巧4：用比较功能对比两个Trace

Jaeger UI有一个比较（Compare）功能，可以对比两个Trace的差异。很多人不知道这个功能。

比如，你有一个正常的请求和一个异常的请求，你可以把这两个Trace都加入比较，Jaeger会展示它们的差异，比如耗时差异、调用链差异、标签差异等。通过对比，能快速发现异常请求和正常请求的区别，找到问题的原因。

使用方法：在查询结果里，勾选你想比较的Trace，然后点击"Compare"按钮，就能进入比较页面。

技巧5：用Trace详情页的各种视图

Jaeger的Trace详情页，提供了多种视图，很多人只用了默认的时间轴视图，不知道还有其他视图。

  • 时间轴视图（Timeline）：默认视图，展示每个Span的时间轴，能看到调用顺序和耗时。
  • 图视图（Graph）：展示服务之间的调用关系图，能直观地看到调用链路和依赖关系。
  • 统计视图（Stats）：展示这个Trace的统计信息，比如总耗时、Span数量、每个服务的耗时占比等。

不同的视图，有不同的用途。排查问题的时候，可以切换不同的视图，从不同角度分析Trace。

二、采样策略优化

采样（Sampling）是分布式追踪中一个很重要的概念。因为如果全量采集Trace，数据量会非常大，存储和查询的压力都很大。所以，需要采样，只采集一部分Trace。

Jaeger支持多种采样策略，合理设置采样策略，能在保证排查问题能力的前提下，大幅减少数据量，降低成本。

策略1：常量采样（Const Sampler）

常量采样，就是固定采样率，比如采样率为1，就是全量采集；采样率为0，就是不采集；采样率为0.1，就是采集10%的Trace。

这是最简单的采样策略，适合流量不大的服务，或者对追踪要求高的核心服务。

策略2：概率采样（Probabilistic Sampler）

概率采样，和常量采样类似，也是按概率采样，但是实现方式不同。概率采样用的是随机数，每个Trace有一定的概率被采集。

概率采样适合流量较大的服务，可以根据流量大小，设置合适的采样率，比如1%、5%、10%等。

策略3：限速采样（Rate Limiting Sampler）

限速采样，就是限制每秒最多采集多少个Trace。比如，设置为每秒最多采集10个Trace，那么不管流量多大，每秒最多采集10个。

限速采样适合流量波动大的服务，能保证采集速率稳定，不会因为流量突增而导致数据量暴增。

策略4：自适应采样（Adaptive Sampler）

Jaeger的Agent支持自适应采样，能根据后端存储的容量，自动调整采样率。如果后端存储压力大，就降低采样率；如果压力小，就提高采样率。

自适应采样适合流量不稳定、后端存储容量有限的场景，能自动平衡采集量和存储压力。

采样策略的最佳实践

  1. 不同服务设置不同的采样率：核心服务、流量小的服务，可以设置高采样率，甚至全量采集；非核心服务、流量大的服务，可以设置低采样率。
  2. 错误的Trace全量采集：对于出错的Trace（比如HTTP状态码5xx、业务错误），应该全量采集，因为出错的Trace最有排查价值。Jaeger支持在代码里设置采样优先级，确保错误的Trace被采集。
  3. 重要的操作全量采集：对于一些重要的操作（比如下单、支付），可以全量采集，因为这些操作的Trace最有价值。
  4. 根据存储容量调整采样率：定期检查Jaeger后端存储的使用情况，根据容量调整采样率，避免存储被写满。
  5. 采样率可以动态调整：Jaeger的采样率可以通过配置动态调整，不需要重启服务。在排查问题的时候，可以临时提高某个服务的采样率，采集更多的Trace，排查完之后再调回去。

三、性能优化技巧

Jaeger的性能，包括客户端的性能（对应用的影响）和后端的性能（存储和查询）。合理优化，能让Jaeger对应用的影响更小，后端的性能更好。

客户端性能优化

  1. 异步发送Span：Jaeger的客户端，默认是异步发送Span的，不会阻塞应用的主线程。但是，要确保客户端的配置正确，使用异步发送模式，避免同步发送导致应用性能下降。
  2. 合理设置缓冲区大小：Jaeger客户端有一个缓冲区，用来暂存待发送的Span。缓冲区太小，可能会导致Span丢失；缓冲区太大，会占用过多内存。根据服务的流量，合理设置缓冲区大小。
  3. 批量发送：Jaeger客户端支持批量发送Span，把多个Span合并成一次请求发送，减少网络请求次数，提升性能。确保开启了批量发送功能。
  4. 减少不必要的标签和日志：Span的标签和日志越多，数据量越大，发送和存储的成本越高。只记录有价值的标签和日志，不要什么都记录。
  5. 合理设置采样率：如前所述，合理设置采样率，减少采集量，降低对应用的影响。

后端性能优化

  1. 选择合适的存储后端：Jaeger支持多种存储后端，比如Cassandra、Elasticsearch、Kafka等。不同的存储后端，性能特点不同。根据你的数据量和查询需求，选择合适的存储后端。数据量大的话，推荐用Cassandra或者Elasticsearch集群。
  2. 合理设置存储的保留时间：Trace数据不需要永久保留，设置合理的保留时间（比如7天、30天），定期清理过期数据，避免存储无限增长。
  3. 优化存储的配置：根据存储后端的不同，做相应的优化。比如Cassandra的 compaction策略、Elasticsearch的索引模板和分片策略等。
  4. Collector水平扩展：Jaeger的Collector是无状态的，可以水平扩展。根据数据量的大小，部署多个Collector实例，做负载均衡，提升处理能力。
  5. Query水平扩展：Query服务也是无状态的，可以水平扩展。根据查询量的大小，部署多个Query实例，提升查询性能。
  6. 用Kafka做缓冲：如果数据量很大，Collector处理不过来，可以在Collector前面加一层Kafka做缓冲，Agent先把数据写到Kafka，Collector再从Kafka消费，避免数据丢失。
  7. 索引优化：对于Elasticsearch存储，合理设置索引模板，只索引需要查询的字段，减少索引大小，提升查询速度。

四、与其他工具集成

Jaeger不是孤立的，它可以和很多其他工具集成，形成完整的可观测性体系。

集成1：与日志系统集成

分布式追踪和日志，是互补的。Trace能告诉你请求经过了哪些服务，耗时多少；日志能告诉你详细的错误信息和调试信息。两者结合，排查问题的效率更高。

Jaeger可以和日志系统（比如ELK、Loki）集成：

  1. 在日志里打印Trace ID：在应用的日志里，打印当前的Trace ID和Span ID。这样，在日志系统里搜索Trace ID，就能找到这个Trace相关的所有日志。
  2. 在Jaeger UI里跳转到日志：Jaeger UI支持配置外部链接，可以在Span的详情页里，添加一个跳转到日志系统的链接，点击就能看到这个Span相关的日志。
  3. 用Trace ID关联日志和Trace：通过Trace ID，把日志和Trace关联起来，在排查问题的时候，可以从Trace跳转到日志，也可以从日志跳转到Trace，双向关联。

集成2：与监控系统集成

监控（Metrics）和追踪（Tracing），也是互补的。监控能告诉你系统的整体状态，比如错误率、响应时间、吞吐量；追踪能告诉你具体某个请求的详细情况。两者结合，能从宏观到微观，全面了解系统状态。

Jaeger可以和监控系统（比如Prometheus、Grafana）集成：

  1. 从监控告警跳转到Jaeger：在监控告警里，包含Trace ID或者查询链接，收到告警的时候，点击就能跳转到Jaeger，查看相关的Trace，快速定位问题。
  2. 在Grafana里展示Jaeger数据：Grafana支持Jaeger数据源，可以在Grafana的仪表盘里，展示Jaeger的追踪数据，比如服务的响应时间分布、错误率、调用量等，和监控数据放在一起，更直观。
  3. 用监控数据辅助分析Trace：在分析Trace的时候，可以结合监控数据，看看当时系统的整体状态，比如CPU使用率、内存使用率、错误率等，帮助定位问题的原因。

集成3：与服务网格集成

如果你用了服务网格（比如Istio、Linkerd），那么Jaeger可以和服务网格深度集成。

服务网格可以自动采集追踪数据，不需要在应用代码里埋点。服务网格的Sidecar会自动拦截服务之间的调用，生成Span，发送到Jaeger。这样，你不需要修改应用代码，就能获得完整的分布式追踪数据，特别适合那些无法修改代码的遗留系统。

而且，服务网格还能提供更多的上下文信息，比如请求的路由、重试、熔断等，让Trace的信息更丰富。

集成4：与CI/CD集成

Jaeger还可以和CI/CD集成，在发布的时候，自动对比发布前后的性能变化。

比如，在CI/CD流水线里，每次发布之后，自动运行一些性能测试，采集Trace数据，对比发布前后的响应时间、错误率等指标，如果性能下降超过阈值，就告警或者回滚。

这样，能在发布的时候，及时发现性能问题，避免把性能问题带到生产环境。

五、自定义扩展技巧

Jaeger是开源的，支持自定义扩展，可以根据自己的需求，定制和扩展Jaeger的功能。

扩展1：自定义采样器

Jaeger的客户端，支持自定义采样器。如果内置的采样器不满足你的需求，你可以实现自己的采样逻辑。

比如，你可以实现一个基于业务规则的采样器：对于VIP用户的请求，全量采集；对于普通用户的请求，按比例采样。或者，对于某些重要的操作，全量采集；其他操作，按比例采样。

自定义采样器，需要实现Jaeger客户端的Sampler接口，然后在初始化Tracer的时候，指定使用你的自定义采样器。

扩展2：自定义Reporter

Jaeger的客户端，支持自定义Reporter。Reporter负责把Span发送到后端。默认的Reporter是发送到Jaeger Agent，但是你可以实现自己的Reporter，把Span发送到其他地方，比如直接发送到Collector，或者发送到Kafka，或者保存到本地文件。

比如，在测试环境，你可以实现一个Reporter，把Span打印到控制台，方便调试。或者，你可以实现一个Reporter，把Span同时发送到多个Jaeger后端，做数据冗余。

扩展3：自定义存储插件

Jaeger的后端，支持自定义存储插件。如果内置的存储后端（Cassandra、Elasticsearch等）不满足你的需求，你可以实现自己的存储插件，把Trace数据存储到你想要的地方，比如MySQL、PostgreSQL、HBase等。

Jaeger的存储插件，是基于gRPC的，你需要实现存储插件的gRPC接口，然后配置Jaeger使用你的插件。

不过，自定义存储插件的开发成本比较高，一般不推荐，除非你有特殊的需求。大部分场景，用内置的Cassandra或者Elasticsearch就够了。

扩展4：自定义UI插件

Jaeger的UI，也支持自定义扩展。你可以添加自定义的面板、链接、视图等，根据自己的需求，定制Jaeger UI。

比如，你可以添加一个跳转到内部日志系统的链接，或者添加一个展示业务数据的面板，或者自定义Trace详情页的展示方式。

Jaeger UI是基于React开发的，你可以通过配置或者插件的方式，扩展UI的功能。

扩展5：基于OpenTracing的自定义埋点

Jaeger支持OpenTracing标准，你可以基于OpenTracing的API，做自定义埋点，记录你关心的信息。

比如：

  • 在关键的业务操作上，创建Span，记录操作的耗时和结果
  • 在Span上设置自定义标签，记录业务相关的信息，比如用户ID、订单ID、商品ID等
  • 在Span上记录自定义日志，记录关键的事件和错误信息
  • 实现上下文传播，把Trace ID传播到异步任务、消息队列、第三方调用等

自定义埋点，能让Trace的信息更丰富，更贴合你的业务，排查问题的时候更高效。但是，也要注意不要过度埋点，只记录有价值的信息，避免数据量过大。

六、最佳实践总结

最后，总结一下Jaeger使用的一些最佳实践。

最佳实践1：合理命名服务和操作

服务名和操作名，是Jaeger查询和展示的基础。要合理命名，确保名字清晰、有意义、统一。

  • 服务名：用小写字母和连字符，比如order-service、user-service
  • 操作名：要能描述这个操作的含义，比如GET /api/orders、createOrder、sendEmail
  • 不要用太泛的名字，比如handle、process、doIt，这样的名字没有意义，查询的时候也不好筛选

最佳实践2：设置有价值的标签

标签是Jaeger查询和分析的重要依据。要设置有价值的标签，不要什么都设置，也不要什么都不设置。

推荐设置的标签：

  • HTTP请求：http.method、http.url、http.statuscode、http.useragent
  • 数据库操作：db.type、db.statement、db.instance
  • 消息队列：messagebus.destination、messagebus.operation
  • 业务相关：user.id、order.id、product.id、tenant.id等
  • 错误信息：error=true、error.object=异常类型、error.message=错误信息

不要设置的标签：

  • 变化太频繁的值，比如请求ID、时间戳等（这些会导致标签基数太大，影响查询性能）
  • 敏感信息，比如密码、token、身份证号等（安全风险）
  • 没有价值的信息，比如日志级别、线程名等（除非你确实需要按这些查询）

最佳实践3：记录错误信息

出错的Trace，是最有排查价值的。一定要在Span里记录错误信息，方便后续查询和分析。

记录错误信息的方法：

  • 设置error=true标签，标记这个Span出错了
  • 记录异常类型，比如error.object=NullPointerException
  • 记录错误信息，比如error.message=用户不存在
  • 记录异常堆栈（可选，堆栈信息比较大，如果需要可以记录）

记录了错误信息之后，你就可以在Jaeger里，按error=true查询所有出错的Trace，快速定位问题。

最佳实践4：合理设置Span的层级

Span的层级，反映了调用的关系。要合理设置Span的层级，确保调用链清晰。

  • 每个外部请求，创建一个根Span
  • 每次服务间调用，创建一个子Span
  • 每次数据库操作、缓存操作、消息队列操作，创建一个子Span
  • 关键的业务逻辑，也可以创建子Span，记录耗时
  • Span的嵌套不要太深，一般不超过10层，太深了会影响可读性和性能

合理的Span层级，能让调用链清晰，排查问题的时候，一眼就能看到请求经过了哪些环节，哪个环节最慢，哪个环节出错了。

最佳实践5：确保上下文传播正确

上下文传播，是分布式追踪的关键。如果上下文传播不正确，Trace就会断裂，无法串联完整的调用链。

要确保上下文传播正确：

  • 服务间调用（HTTP、gRPC等），要正确注入和提取Trace上下文
  • 消息队列（Kafka、RabbitMQ等），要把Trace上下文放到消息的属性里，消费的时候提取
  • 异步任务（线程池、协程等），要把Trace上下文传递到异步线程
  • 第三方调用，要把Trace上下文传递给第三方（如果第三方支持的话）
  • 跨语言调用，要确保两边都用OpenTracing标准，上下文格式一致

上下文传播，是最容易出问题的地方，一定要仔细测试，确保每个环节的上下文都能正确传播。

最佳实践6：定期检查和优化

Jaeger的使用，不是一劳永逸的，需要定期检查和优化。

定期检查的内容：

  • 检查采样率是否合理，数据量是否在存储容量范围内
  • 检查存储的使用情况，是否需要扩容或者调整保留时间
  • 检查Trace的完整性，是否有断裂的情况，上下文传播是否正确
  • 检查标签的设置，是否有高基数的标签，是否有敏感信息
  • 检查Jaeger的性能，查询是否慢，Collector和Query是否有瓶颈
  • 检查团队的使用情况，是否大家都会用Jaeger排查问题

定期检查和优化，能确保Jaeger始终处于良好的状态，发挥最大的价值。

结语

Jaeger是一个功能强大的分布式追踪工具，但是很多人只用了它的基本功能，没有发挥出它的全部价值。

本文分享了Jaeger的一些进阶技巧，包括高级查询、采样策略优化、性能优化、与其他工具集成、自定义扩展、最佳实践等。这些技巧，可能很多人都不知道，但是用好了能大幅提升排查问题的效率和系统的可观测性。

当然，Jaeger的功能远不止这些，还有很多高级特性和技巧，需要你在使用过程中不断探索和总结。希望本文能起到抛砖引玉的作用，帮助你更深入地用好Jaeger。

分布式追踪，是微服务架构下不可或缺的工具。Jaeger，作为目前最流行的分布式追踪工具之一，值得你深入学习和掌握。

最后，用一句话总结："工具的价值，不在于它有多少功能，而在于你用好了多少功能。Jaeger的功能很强大，深入学习，用好它的高级特性，才能让它发挥最大的价值。"

愿每一个微服务实践者，都能深入掌握分布式追踪，让系统更稳定，让排查更高效。