Cloud Trace

1. What it is

A distributed tracing system that "tracks request latency and helps you troubleshoot performance bottlenecks across services and generative AI applications."

Object	What it is
trace	the latency data for one request, across services
span	one unit of latency and timing inside a trace

It is part of Google Cloud Observability, alongside Logging and Monitoring.

2. The fact that matters most, and it is about portability

OpenTelemetry is the recommended instrumentation, over Google-specific APIs.

That single line is the most valuable thing in this document for anyone doing migration work:

instrument with OpenTelemetry and the instrumentation is not a migration cost. The same spans can be

exported to Cloud Trace, to AWS X-Ray, to Azure Monitor, or to a self-hosted collector, by changing an exporter;

instrument with a vendor SDK and the instrumentation is application code that has to be rewritten on any

move, in every service.

So: for a workload that will or might move, OpenTelemetry is not a preference — it is the difference between an exporter change and a rewrite. The vendor recommends it anyway, which makes this the easiest portability decision in the hub.

3. Two ingestion APIs

The Telemetry API (recommended) and the Cloud Trace API. Write against the recommended one for anything new.

4. Sampling

"Trace sampling" is a named topic, and the overview states no specific sampling behaviour, so none is quoted here. Read the sampling page before relying on a trace being present — a trace that is absent because it was not sampled looks exactly like a trace that is absent because instrumentation is broken, and that ambiguity costs hours.

5. For a migration estimate

Two lines, and the first one is usually a saving:

if the source estate is already OpenTelemetry-instrumented, tracing is an exporter configuration change.

Near zero.

if it uses X-Ray's or Application Insights' own SDKs, it is per-service application work. Count the

services.

And one cross-cloud note: all three clouds now point at OpenTelemetry. So the right answer to a tracing migration question is often "instrument with OpenTelemetry on the source first, then move" — which turns a migration task into a portability improvement that pays for itself even if the move is cancelled.

See guides/parity/observability.md.