Zipkin tracing

Setup your sandbox environment with Docker and Docker Compose, and clone the Envoy repository with Git.

Used to make requests.

The Zipkin tracing sandbox demonstrates Envoy’s request tracing capabilities using as the tracing provider. This sandbox is very similar to the front proxy architecture described above, with one difference: service1 makes an API call to service2 before returning a response. The three containers will be deployed inside a virtual network called envoymesh.

Before routing a request to the appropriate service Envoy or the application, Envoy will take care of generating the appropriate spans for tracing (parent/child/shared context spans). At a high-level, each span records the latency of upstream API calls as well as information needed to correlate the span with other related spans (e.g., the trace ID).

One of the most important benefits of tracing from Envoy is that it will take care of propagating the traces to the Zipkin service cluster. However, in order to fully take advantage of tracing, the application has to propagate trace headers that Envoy generates, while making calls to other services. In the sandbox we have provided, the simple flask app (see trace function in service.py) acting as service1 propagates the trace headers while making an outbound call to service2.

Change directory to examples/zipkin-tracing in the Envoy repository.

To build this sandbox example, and start the example apps run the following commands:

You can now send a request to service1 via the front-envoy as follows:

$ curl -v localhost:8000/trace/1
*   Trying 192.168.99.100...
> Host: 192.168.99.100:8000
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< x-envoy-upstream-service-time: 1
< server: envoy
< date: Fri, 26 Aug 2018 19:39:19 GMT
<
Hello from behind Envoy (service 1)! hostname: f26027f1ce28 resolvedhostname: 172.19.0.6