---
cuppy_hub: gcp
cuppy_path: reference/observability/cloud-trace.md
cuppy_section: docs
cuppy_doc: JZDZ-SFTM
cuppy_doc_uuid: fbb3e0b6-4839-41db-8e85-2298ea8eed98
cuppy_permalink: https://cuppy.io/gcp/d/JZDZ-SFTM
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/observability/cloud-trace
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 0fb8cfd514c9c2beadaa4feb43730fe625ba250787cc55d1d602bcd1119cb5c6
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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:

1. **if the source estate is already OpenTelemetry-instrumented**, tracing is an exporter configuration change.
   Near zero.
2. **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`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->