Distributed tracing in a multi-cloud environment can be challenging. We want to fulfill the same objective that we would with a single cloud environment, that is, to visualize the single end-to-end trace associated with a request as it passes through services within and across each cloud, but may face complications when dealing with different context propagation formats and storage of the tracing data in different formats per cloud.

The first challenge is to ensure that a trace continues across different cloud environments. This is a problem because, at the time of writing this book, there is not a widely adopted or standardized trace context format. Usually, each tracing system uses different headers and formats to propagate the tracing context. For instance, Zipkin uses B3 propagation, Jaeger uses a ber-trace-id header, Amazon X-Ray uses X-Amzn-Trace-Id, and Google uses X-Cloud-Trace-Context. Therefore, if a request has to be traced across heterogenous tracing systems, each time it leaves or enters a different environment, the trace context has to be converted. This can usually be done by configuring a tracer with a custom injector or extractor implementation. However, this is currently beyond the scope of the MicroProfile OpenTracing project. In the future, the trace context format might be standardized under the W3C Trace Context project (https://www.w3.org/TR/trace-context/). 

The second challenge, even in a homogenous tracing environment, is to visualize tracing data from multi-cloud environments. This can be problematic because tracing data in each cloud might be stored in different databases or in different formats. This can be overcome by replicating the data to a single unified storage or sending missing tracing data between systems on-demand with the appropriate data format adjustments.

Next, we will discuss the challenges of using Eclipse MicroProfile in a service mesh, such as Istio.