Hi,
I’m confused about the envoy-based vs. mixer based tracing at https://istio.io/faq/distributed-tracing. I have a local k8s cluster deployed w/ istio and bookinfo. Jaeger as tracing backend to listen at zipkin.istio-system:9411. It appears this can be verified by checking the istio-proxy container startup args in productpage, i.e. --zipkinAddress zipkin.istio-system:9411. This seems to be the envoy-based approach.
If that’s the case, then how can we enable mixer based one? I am seeing istio-telemetry is configured w/ --trace_zipkin_url=http://zipkin.istio-system:9411/api/v1/spans. And, I know mixer supports tracespan template according to the document. How does that come into play? Why trace_zipkin_url is needed when it’s envoy-based tracing?
I’m still new to istio and hope someone could help me figure out… Thanks a lot!
I know envoy can be configured to send to .
Mixer has the ability to generate its own set of traces for monitoring the behavior of Mixer itself. This is independent of being used to generate trace data on behalf of other services within the mesh. Mixer takes the trace_zipkin_url argument for where to send the traces it generates for its own (internal) execution.
The tracespan template is used for customizing trace generation for services within a mesh. It is used just like other Mixer templates (say, metric or logentry). You would create instance, handler, and rule config depending on your use case. Some docs on this configuration model are available here: https://istio.io/docs/reference/config/policy-and-telemetry/mixer-overview/#configuration-model.
I would only recommend using Mixer for tracing if you need to customize the generated spans in some way. Otherwise, pointing Istio at any Zipkin API-compatible tracing solution (like Jaeger) is much simpler.
Sorry for my late response… Thanks @douglas-reid… Regarding:
I’m curious if this is also partially because of the performance impact? To have envoy sidecar send to tracing backend is pretty much efficient, and to have all envoys in mesh routed to centralized Mixer then to tracing backend will make Mixer becomes bottleneck. But maybe I’m wrong, as I was seeing from the trace logs, it look envoy always sends raw data to Mixer both for check and report…
@morningspace perf is also a concern, though the impact of just adding an additional dispatch to a tracing adapter may not be overly problematic if you are already using Mixer for Report().
Get it… that makes sense… thanks for your reply 