2019-05-15

来源:《Go 夜读》微信群

Q: jaeger好像是由入口服务决策这条trace是否需要采样上报的?所有下游的服务都会根据入口服务的采样标记决定是否将数据上报给agent,这样的话有个问题: 如果我的后端服务架构中,入口服务的请求量特别大,但是最下游的两三个服务请求量相对下(相差100倍以上),那如何妥善地设置采样比例?

比例小的话,下游服务的上报量可能会很少,统计分析的时候准确度不够; 比例大的话,入口服务的上报量又会太大

A: 不太明白:入口和最下游服务不是一起访问?

Q: 不是的,你可以把我们后台看作类似于漏斗形架构,数据每经过一个服务就会做判断,可能需要继续访问下游服务,也可能不需要、直接返回,所以越往下游的服务接受的请求量越小; 每个请求到底会经过哪些服务,是不固定的 依赖于每一层服务的判断结果;

A: 没想到办法[悠闲]

Q: 暂时想到的办法是,每台机的agent单独采样,根据单机请求量来调整上报数据, 这样可以确保每台机器的上报数据量均衡,但是es里最终存储的不是完整trace,完整trace需要单独回访数据

A: agent单独采样:是指使用远程采集策略?

Q: 不是远程策略,远程策略,归根到底也是入口服务做采样决策的,这里需要的是agent来决策采样,不过这样就意味着客户端到agent的数据是全量的,udp传输开销应该会很大,又需要改造为共享内存传输之类的。

A1: 那采样就进程内概率随机采,每台机的agent汇总,agent再做一些可动态调整的limiter呢

A: 不太清楚你的具体实现,但全量上报再由agent决策,好像也解决不了下游服务只有很小访问的问题吧?

Q: 下游服务访问量小,所以下游服务的机器agent就可以根据情况调整采样比例增加数据上报量

A: 意思是不需要看到和入口服务在同一条链路上? Q: 是的,前面说的,这样的做法就是es存储的span不一定能拼成完整的trace;

Q: 需求上来讲,更需要的是全局视图, 统计整体链路的请求响应情况 需要某个具体case的时候再去回放,带有debug标志的trace的所有span都会上报,可以形成完整链路

A: 单独对你的下游服务设定不同的采集策略不会好点?

Q: 问题不是在于,jaeger是从入口服务进行采样决策的吗

Q: Jaeger libraries implement consistent upfront (or head-based) sampling.

or example, assume we have a simple call graph where service A calls service B, and B calls service C: A -> B -> C. When service A receives a request that contains no tracing information, Jaeger tracer will start a new trace, assign it a random trace ID, and make a sampling decision based on the currently installed sampling strategy. The sampling decision will be propagated with the requests to B and to C, so those services will not be making the sampling decision again but instead will respect the decision made by the top service A.

A: 如果你们能接受不在一条链路上,可以进行不同设定,例如入口使用随机采集策略,几率是(1/1000),那下游服务就(1/100)

Q: “so those services will not be making the sampling decision again but instead will respect the decision made by the top service A” jaeger下游服务不做采样决策了

A: 如果你想看到在同一条链路上,下游就不需要做决策,但是现在你们可以接受不在一条链路上,那就下游自己做决策

Q: 那下游自己决策,应该需要改动client吧?

A: 不需要啊,你只要不去找爸爸就行了, 不提取上游的传递的数据

Q: 嗯,这也是一种


未梳理,只是讨论纪要。