我提供了与Istio网站上的bookinfo应用类似的简单3层服务。除了使用zipkin或jaeger进行跟踪之外，其他所有内容似乎都可以正常工作。
为澄清起见，我有3个服务S1，S2，S3，所有服务都非常相似且微不足道，并向下游传递请求并进行一些工作。我可以在跟踪中看到S1和S2，但看不到S3。我进一步缩小了范围，当我使用Istio版本0.5.0时，也可以在跟踪中看到S3，但是过了一段时间，但是，对于Istio版本0.5.1，我只能看到S1和S2在跟踪中，即使服务正常运行并且呼叫一直传播到S3。
我可以看到的唯一区别是不确定使用istio版本0.5.0在S3中的istio-proxy中的输出，但在0.5.1中不是，我不确定，即使这不是问题，也是如此
“ GET / readiness HTTP / 1.1” 200-0 39 1 1“-”“ kube-probe / 1.9 +”“ 0969a5a3-f6c0-9f8e-a449-d8617c3a5f9f”“ 10.XX18：8080”“ 127.0.0.1 ：8080“
我可以根据需要添加确切的Yaml文件。另外，我不确定该跟踪是否应该来自istio-proxy，如istio文档中所示，但就我而言，我看不到istio-proxy，而仅是istio-ingress。
跟踪上下文传播可能会丢失。
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-bin