我做了一个简单的3层服务,类似于Istio网站上的bookinfo应用程序。除了使用zipkin或jaeger进行跟踪之外,一切似乎都很正常。
为了澄清,我有3个服务S1,S2,S3,它们都非常相似,都在向下游传递请求并做一些工作。我可以在跟踪中看到S1和S2,但看不到S3。我已经进一步缩小了范围,当我使用Istio版本0.5.0时,我也可以在跟踪中看到S3,但只有在一段时间后,使用Istio版本0.5.1,我才能在跟踪中看到S1和S2,即使服务工作正常并且调用一直向下传播到S3。
我能看到的唯一区别是istio-proxy中使用istio版本0.5.0的S3输出,而不是0.5.1版本的istio-proxy
"GET /readiness HTTP/1.1“”200 -0 39 1 1 "-“"kube-probe/1.9+”"0969a5a3-f6c0-9f8e-a449-d8617c3a5f9f“"10.X.X.18:8080”"127.0.0.1:8080“
如果需要,我可以添加精确的yaml文件。此外,我不确定跟踪是否应该像istio文档中显示的那样来自istio-proxy,但在我的例子中,我没有看到istio-proxy,而只看到istio-ingress。
发布于 2019-12-30 09:11:10
可能缺少跟踪上下文传播。
https://istio.io/docs/tasks/observability/distributed-tracing/overview/#trace-context-propagation
Although Istio proxies are able to automatically send spans, they need some hints to tie together the entire trace. Applications need to propagate the appropriate HTTP headers so that when the proxies send span information, the spans can be correlated correctly into a single trace.
To do this, an application needs to collect and propagate the following headers from the incoming request to any outgoing requests:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Additionally, tracing integrations based on OpenCensus (e.g. Stackdriver) propagate the following headers:
x-cloud-trace-context
traceparent
grpc-trace-binhttps://stackoverflow.com/questions/48794097
复制相似问题