乐趣区

关于云计算:Jaeger的客户端采样配置Java版

jiezi

欢送拜访我的 GitHub

https://github.com/zq2599/blog_demos

内容：所有原创文章分类汇总及配套源码，波及 Java、Docker、Kubernetes、DevOPS 等；

对于采样（Sampling）

  • 采样很好了解：应用 Jaeger 时，未必须要将所有申请都上报到 Jaeger，有时候只有抽取其中一部分察看即可，这就是依照肯定策略进行采样；
  • Jaeger SDK 是反对多种采样配置的，在分布式系统中，他们遵循的准则是前置断定（consistent upfront 或者 head-based），简略来说，如果 consumer 服务调用 provider 服务，那么某一次申请只有 consumer 决定不采样，那么 provider 在解决这个申请的时候也不会采样，也就是说对于一次残缺的 trace，只有最后面的服务不上报到 jaeger，那么整个 trace 前面波及的服务都不会上报到 jaeger
  • Jaeger 采样配置分为客户端和服务端两种配置，默认用的是服务端配置
  • 本文咱们来理解如何在客户端（也就是接入 Jaeger 的利用）配置采样，并且入手验证成果，罕用的客户端采样策略有以下三种：
  1. 固定：要么全副采样，要门全副不采样
  2. 比例：依照指定比例采样
  3. 限速：固定工夫周期内采样固定数量，例如每秒一个
  • 接下来，一一配置和体验这三种采样的成果

对于实战用的工程

  • 采样配置实战不波及编码，只须要改一些配置，所以没必要声势浩大的新建工程写代码，用《Jaeger 开发入门 (java 版)》一文中的两个 maven 子工程即可：服务提供方 <font color=”blue”>jaeger-service-provider</font> 和服务调用方 <font color=”blue”>jaeger-service-consumer</font>，都做成 docker 镜像，用 docker-compose 启动，网络架构如下图：

  • 请确保我的项目的日志模板中已增加了 <font color=”blue”>traceId</font>、<font color=”blue”>spanId</font>、<font color=”blue”>sampled</font> 等变量，如下图红框所示，有了这些配置，咱们在日志中就能看到对应的 trace 是否被采样（这一步 <font color=”red”> 十分重要 </font>）：

  • 为了不便批改代码后重新部署启动，我写了个名为 <font color=”blue”>full.sh</font> 的 shell 脚本文件，运行即可将批改后的代码制作成最新的镜像并用 docker-compose 运行起来：
#!/bin/bash
echo "进行 docker-compose"
cd jaeger-service-provider && docker-compose down && cd ..

echo "编译构建"
mvn clean package -U -DskipTests

echo“创立 provider 镜像”cd jaeger-service-provider && docker build -t bolingcavalry/jaeger-service-provider:0.0.1 . && cd ..

echo“创立 consumer 镜像”cd jaeger-service-consumer && docker build -t bolingcavalry/jaeger-service-consumer:0.0.1 . && cd ..

echo "清理有效资源"
docker system prune --volumes -f

echo "启动 docker-compose"
cd jaeger-service-provider && docker-compose up -d && cd ..
  • 如果您用的是 IDEA，在下图红框地位增加一个自定义命令，选中上述 shell 文件，就能够在 IDEA 中用 run 命令来编译构建部署了：

  • 当初筹备工作曾经实现，开始实战吧，从最简略的固定采样开始；

固定采样

  • 固定采样的逻辑很简略：要么全副上报，要么一个也不报
  • 固定采样的配置形式如下图红框所示：

  • 要留神的是：依据前置断定（consistent upfront 或者 head-based）准则，只有将上述配置写入 <font color=”blue”>jaeger-service-consumer</font> 我的项目的配置文件即可，至于 <font color=”blue”>jaeger-service-provider</font> 维持原状不做任何改变
  • 执行后面写的 full.sh 脚本，编译构建部署
  • 浏览器拜访 <font color=”blue”>http://localhost:18080/hello</font>，产生一些 web 申请，多拜访几次
  • 看 jaeger-service-consumer 容器的日志，如下图，红框中的 <font color=”red”>sampled=false</font> 示意未采样，三此申请的日志都是如此：

  • 再看 jaeger-service-provider 容器的日志，如下图红框，也全副都没有采样，这证实 Jaeger 的前置断定准则（consistent upfront 或者 head-based）是精确的，jaeger-service-consumer 是一次 trace 的源头，被它敞开了采样的 trace，在后续的服务中也会主动敞开采样：

  • 去 Jaeger 的 web 页面看看，空洞无物，连服务列表中都没有 jaeger-service-consumer 和 jaeger-service-provider：

  • 试过了全副不采样，再来试试全副采样的配置，如下图红框：

  • 重新部署，再产生几次申请，去看 jaeger-service-consumer 容器的日志，如下图红框，全副都被采样了：

  • 去看 jaeger-service-provider 容器的日志，也是如此，所有 trace 都被采样：

  • 关上 Jaeger 的 web 页面，可见 jaeger-service-consumer 的三次申请对应的 trace 全副上报：

  • 至此，最简略的固定采样已实现，来看看更实用的比例采样

比例采样

  • 顾名思义，就是依照肯定的百分比采样，配置如下图所示：

  • 执行后面写的 <font color=”blue”>full.sh</font> 脚本，编译构建部署
  • 测试比例采样的办法就是发多个申请，查看采样的 trace 是否是总数的十分之一，我这里用 jmeter 来执行屡次申请，您能够抉择本人善于的工具，或者写代码写脚本，甚至手动拜访屡次
  • 应用 jmeter 能够管制申请次数，用的是 <font color=”blue”>Loop Controller</font>，如下图红框所示：

  • 向 jaeger-service-consumer 的 /hello 接口发送完一百次申请后，能够从 docker 容器日志中查看采样状况，这里应用 <font color=”blue”>grep</font> 和 <font color=”blue”>wc</font> 命令的组合来统计日志中呈现 <font color=”red”>sampled=true</font> 和 <font color=”red”>sampled=false</font> 的行数，残缺的命令如下：
docker logs jaeger-service-consumer| grep 'sampled=true'|wc -l
  • 100 个申请，采样率百分之十，然而用上述命令失去的后果并不是准确值 10，而是 8，再统计未采样的日志行数 (把 true 改成 false)，失去的后果是 92，总数对得上，然而采样数并非准确的百分之十，如下图：

  • 而后将申请总数减少到一千条，失去的采样比例靠近百分之十，如下：

  • 关上 Jaeger 的 web 页面，可见果然只有 106 个 trace：

  • 比例采样实现了，接下来是限速采样

限速采样

  • 对于限速，仿佛不够具体不便于了解，然而看看官网文档上的关键字 <font color=”blue”>leaky bucket</font>，如下图红框，聪慧的您肯定想到了其中的要害，漏桶限流算法（留神，是漏桶，不是令牌桶，漏桶算法的峰值和桶大小无关）：

  • 配置如下图红框所示：

  • 执行后面写的 <font color=”blue”>full.sh</font> 脚本，编译构建部署
  • 咱们的配置是每秒钟一次采样，所以验证的时候要管制好发送申请的时长，我这里还是用 jmeter 来发申请的，如下图红框所示，jmeter 有种 <font color=”blue”>Runtime Controller</font> 类型的控制器，能够管制继续申请的时长，我这里设置为 10 秒：

  • 用 jmeter 继续发送 10 秒的申请，从 jmeter 的汇总报告中可见一共发了 70 个申请：

  • 用命令 <font color=”blue”>docker logs jaeger-service-consumer| grep ‘sampled=true’|wc -l</font> 查看采样总数，10 秒的预期是 10 个，后果如下，并不准确，只是靠近而已:

  • 清掉所有数据，将时长改成 100 秒试试，一共收回次 852 申请：

  • 采样总数为 96，靠近预期：

  • 关上 Jaeger 的 web 页面也是 96 次 trace：

服务端配置一瞥

  • 还记得《分布式调用链跟踪工具 Jaeger？两分钟极速体验》、《Jaeger 开发入门 (java 版)》等文章中的操作吗？那时咱们并没有增加任何与采样无关的配置，然而每次申请都能在 Jaeger 的 web 页面上查到对应的 trace，也就是说所有申请全副被采样了，这是为啥？
  • 如果配置文件中没有采样相干的内容，那么默认应用的就是近程配置，具体的信息就在 jaeger 的 all-in-one 容器中，执行上面这个命令，就能看到近程采样配置：
docker exec jaeger cat /etc/jaeger/sampling_strategies.json
  • 上述命令能够看到 sampling_strategies.json 的内容如下，原来服务端的配置是比例采样，不过比例是百分之百，这就能解释为何所有申请都能在 Jaeger 的 web 页面查到 trace 信息了：
{
  "default_strategy": {
    "type": "probabilistic",
    "param": 1
  }
}
  • 至此，采样配置实战曾经实现，心愿能给您提供一些参考，辅助您针对实际状况定制更加适合的采样策略

你不孤独，欣宸原创一路相伴

  1. Java 系列
  2. Spring 系列
  3. Docker 系列
  4. kubernetes 系列
  5. 数据库 + 中间件系列
  6. DevOps 系列

欢送关注公众号：程序员欣宸

微信搜寻「程序员欣宸」，我是欣宸，期待与您一起畅游 Java 世界 …
https://github.com/zq2599/blog_demos

退出移动版