-
Notifications
You must be signed in to change notification settings - Fork 43
Mission: Distributed Tracing Istio
lthon: THIS PAGE IS (MOST LIKELY) A BAD DUPLICATE AND SHOULD BE REMOVED, THE CORRECT ONE IS HERE: https://github.com/fabric8-launcher/launcher-documentation/wiki/ISTIO-Distributed-Tracing-Mission
| ID | Short Name |
|---|---|
|
|
| Group | Owner |
|---|---|
Tracing |
Georgios Andrianakis |
This mission showcases the interaction of Distributed Tracing capabilities of Istio and properly instrumented microservices.
In a microservice topology, where a single incoming HTTP call to the cluster could end up calling a host of other services, getting insights on the interactions of the individual services and performing debugging becomes complicated. Distributed tracing provides developers and operators the ability to gain insights on these interactions. Istio provides some Distributed Tracing features out of the box but also places a small requirement (the propagation of special HTTP headers) on applications deployed in the Service Mesh in order to fully realise the benefits of Distributed Tracing.
The applications deployed to the Service Mesh need to be properly instrumented. At the very least, instrumentation consists of propagating the proper HTTP headers when making requests between microservices. There are two options here: Manual instrumentation where the developer of each service needs to take care to propagate the HTTP headers to all downstream calls Use a library to auto-magically perform the instrumentation These libraries in addition to propagating headers, also create new spans for each application component they instrument
The second option besides making the code of each service much cleaner, also yields the additional benefit of providing extra insight into the inner workings of the application. When the library reports it’s spans to the same collector as the Envoy proxy does, a complete picture of the paths an incoming HTTP request follows can be deduced. This blog post on distributed tracing provides a wealth of details.
We simply reuse the standard greeting_service → name_service provided by other boosters. The only difference is that we add the necessary plumbing for propagation of the Tracing HTTP Headers.