# VM Trace Stores: Wire Tempo, Jaeger or Zipkin to a Space > Add a Grafana Tempo, Jaeger or Zipkin endpoint in Settings, attach it to a VM space, and the platform probes for write and read before saving. Source: https://zop.dev/resources/blogs/vm-trace-store-connect-tempo-jaeger-or-zipkin-to-a-space Published: 2026-10-20 · Author: riya-mittal · Tags: cloudops, observability --- A tracing backend that is not connected to the platform is a tracing backend the platform cannot use. Logs tell you what happened inside one service. Metrics tell you how often and how fast. Neither connects a single request across the services it touches. ZopDay VM services now support request tracing with Grafana Tempo, Jaeger or Zipkin. The connection runs through two steps: add the endpoint in Settings, then Integrations, then Observability, and attach it to the space where the VM services run. A space-scoped integration is one where the tracing backend is bound to a space, not to individual services. Every service in that space can opt in without a separate setup. ## Adding the Endpoint Probes for Both Write and Read Access In Settings, then Integrations, then Observability, admins add a Grafana Tempo, Jaeger or Zipkin endpoint. The platform probes the endpoint for both write access and read access before saving. | Check | What it verifies | |---|---| | Write probe | The platform can send spans to this endpoint | | Read probe | The platform can query traces back from this endpoint | A backend that accepts writes but fails reads is saved with a warning. Spans would arrive, but the Requests tab could not display them. The probe catches this before the team enables tracing on a service and wonders why traces are missing. The [role-based access model](https://zop.dev/resources/blogs/cloud-governance-rbac-viewer-editor-admin-custom-roles) controls who can add or change integrations. An operator sets up the backend once. Developers view the traces but cannot modify the connection. Every configuration change appears as a row in the [platform audit log](https://zop.dev/resources/blogs/mcp-audit-logs-ai-assistant-reads). ## Attaching the Integration to a Space Unlocks Per-Service Tracing After saving the endpoint, the admin attaches it to a space in that space's Settings, then Observability. Once attached, every service in that space sees a Requests tab under Observability. Without this step, the Requests tab does not appear. A single tracing backend can serve multiple spaces if the same endpoint is attached to each one. Each space's services send spans to the same collector, and the Requests tab queries the same backend. This avoids duplicate infrastructure for teams running [VM services with resource limits](https://zop.dev/resources/blogs/container-limits-for-zopday-vm-services-refused-before-saving) across several spaces. diagram The attachment is a space-level setting, not an org-level default. A space that does not need tracing is never connected. Teams that track [billing activity per day](https://zop.dev/resources/blogs/finops-zopcloud-billing-activity-one-row-per-day) can control which spaces incur trace-storage costs. ## Detaching a Trace Store Does Not Stop Running Services Detaching a trace store from a space does not remove the environment variables from running services. A service continues sending spans to the old endpoint until it is redeployed. The collector logs fill with connection errors in the meantime. Plan a redeploy for every affected service after detaching, or the errors accumulate silently. The platform does not trigger an automatic redeploy on detach because the team may want to attach a replacement backend first. For teams adding observability to VM workloads that already run [compliance audit checks](https://zop.dev/resources/blogs/free-cloud-audit-compliance-findings-shown-the-rest-locked), the trace store connection adds the runtime visibility that static scans cannot provide.