Distributed Tracing with Emoji.voto
This is a fork of the Emoji.voto project with distributed tracing instrumentation built in. This is intended to serve as a reference architecture for how to add distributed tracing to an application.
For more information about Emoji.voto and for instructions on how to build and run the project, see the upstream README.
To see the changes that were necessary to instrument Emoji.voto, see the diff.
kubectl apply -f tracing.yml kubectl apply -f emojivoto.yml kubectl apply -f ingress.yml kubectl -n tracing port-forward deploy/jaeger 16686 & open http://localhost:16686
We use the OpenCensus Service collector to collect traces and Jaeger to store and display them. Each Emoji.voto service is instrumented with the OpenCensus Go client to emit trace data to the collector. Nginx acts as an ingress and makes all sampling decisions about when to initiate a trace (in this example we use a 50% sample rate.) HTTP communication uses the Zipkin trace propagation headers and gRPC communication uses the gRPC trace metadata.
Nginx is deployed as an ingress controller. For each request it receives, it
has a 50% change of sampling that trace. For any traces that it samples, it
sends span data to the OpenCensus collector using the Zipkin reporting protocol
and sets the
X-b3-* headers on the request to mark that downstream services
should sample it as well in order to produce a full trace.
All Emoji.voto services use the OpenCensus Go client to propagate trace context from the incoming requests to the outgoing requests. They also honor the sampling decision made by the ingress. If a trace should be sampled, they report span data to the OpenCensus collector using the OpenCensus agent protocol.
The collector is an aggregation and translation layer which receives span data from Nginx and the Emoji.voto services and forwards that data to Jaeger.
Jaeger receives traces from the OpenCensus collector, stores them, and displays them in a web UI.