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

欢送拜访我的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的利用）配置采样，并且入手验证成果，罕用的客户端采样策略有以下三种：

固定：要么全副采样，要门全副不采样
比例：依照指定比例采样
限速：固定工夫周期内采样固定数量，例如每秒一个

接下来，一一配置和体验这三种采样的成果

对于实战用的工程

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

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

为了不便批改代码后重新部署启动，我写了个名为full.sh的shell脚本文件，运行即可将批改后的代码制作成最新的镜像并用docker-compose运行起来：

#!/bin/bashecho "进行docker-compose"cd jaeger-service-provider && docker-compose down && cd ..echo "编译构建"mvn clean package -U -DskipTestsecho “创立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 -fecho "启动docker-compose"cd jaeger-service-provider && docker-compose up -d && cd ..

如果您用的是IDEA，在下图红框地位增加一个自定义命令，选中上述shell文件，就能够在IDEA中用run命令来编译构建部署了：

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

固定采样

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

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

再看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全副上报：

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

比例采样

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

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

向jaeger-service-consumer的/hello接口发送完一百次申请后，能够从docker容器日志中查看采样状况，这里应用grep和wc命令的组合来统计日志中呈现sampled=true和sampled=false的行数，残缺的命令如下：

docker logs jaeger-service-consumer| grep 'sampled=true'|wc -l

100个申请，采样率百分之十，然而用上述命令失去的后果并不是准确值10，而是8，再统计未采样的日志行数(把true改成false)，失去的后果是92，总数对得上，然而采样数并非准确的百分之十，如下图：

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

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

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

限速采样

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

配置如下图红框所示：

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

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

用命令docker logs jaeger-service-consumer| grep 'sampled=true'|wc -l查看采样总数，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  }}

至此，采样配置实战曾经实现，心愿能给您提供一些参考，辅助您针对实际状况定制更加适合的采样策略

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

Java系列
Spring系列
Docker系列
kubernetes系列
数据库+中间件系列
DevOps系列

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

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