# Managed OpenTelemetry Tracing Zuplo's managed OpenTelemetry tracing pipes every request span from your gateway into Zuplo-hosted storage and surfaces them in the portal. No code change is required — once the feature is enabled on your account, the runtime auto-emits spans for every request handled by your environments. ## Enabling Managed Tracing Managed tracing is a paid add-on and is off by default for every account. To turn it on, contact [support@zuplo.com](mailto:support@zuplo.com) or your account manager. Internally, this flips the `tracingEnabled` account entitlement; once that is set, every environment under the account begins emitting spans on its next deployment. The feature applies at the account level. All projects and environments under the account share the same setting. ## What Gets Emitted When managed tracing is enabled, the Zuplo runtime emits a span for every request that passes through the gateway. Each trace inherits a set of resource attributes that identify the source of the span: - `service.name` — the deployment name (the same value shown in the portal for the environment) - `zuplo.account_id` — the account that owns the deployment - `zuplo.project_id` — the project that owns the deployment - `zuplo.environment_type` — `edge`, `working-copy`, or `local` (matches the `environmentType` field documented in [Logging](./logging.mdx)) - `zuplo.request_id` — the value of the `zp-rid` header for the request The runtime auto-instruments the same surface area as the BYO [OpenTelemetry plugin](./opentelemetry.mdx): - The full request lifecycle (entry through response) - Outbound `fetch` calls made from policies and handlers - Cache reads and writes via the [caching APIs](../programmable-api/cache.mdx) - Inbound and outbound policy execution - Handler execution Spans follow standard OpenTelemetry lifecycle semantics: a span starts when its unit of work begins, captures its attributes and events as it runs, and ends when the work completes. Parent–child relationships preserve the request tree so a trace shows the full call graph for a request. :::note The clock-tick limitation documented for the BYO plugin also applies to managed tracing: span durations only advance during I/O operations because of Zuplo's serverless, multi-tenant architecture. See [Limitations](./opentelemetry.mdx#limitations) for details. ::: ## Where to View Traces Traces are available in the portal **Observability** tab on each project, under the **Traces** sub-tab. The Observability tab is the new home for traces. ## Retention Spans are retained for **90 days** from the time they are ingested. After 90 days, spans are deleted and are no longer visible in the portal. ## Coexistence with `@zuplo/otel` Managed tracing does not replace the BYO [`@zuplo/otel`](./opentelemetry.mdx) plugin. Both pipelines can run at the same time on the same project. Spans flow through a shared `TracerProvider` that fans out to every configured exporter, so: - Enabling managed tracing on an account that already uses `OpenTelemetryPlugin` keeps both pipelines active. Your existing third-party backend (Honeycomb, Datadog, Dynatrace, Jaeger, and so on) continues to receive spans alongside Zuplo's managed storage. - A failure in one exporter is isolated from the other. If Zuplo's managed ingest is degraded, your BYO exporter continues to receive spans. If your BYO endpoint returns errors, managed ingest continues to receive spans. This means migrating to managed tracing is non-disruptive: enable it, validate spans in the portal, and decide whether to remove the BYO plugin on your own schedule. ## Not Yet Supported The initial release of managed observability covers **spans only**. The following signals are not yet supported on the managed pipeline: - OpenTelemetry **metrics** - OpenTelemetry **logs** If you need managed metrics or logs today, use the BYO [`@zuplo/otel`](./opentelemetry.mdx) plugin to export them to your preferred backend. Support for managed metrics and logs is planned for future releases.