Querying existing Jaeger and Zipkin traces from Grafana
Jaeger and Zipkin are both core Grafana trace data sources, so connecting Grafana to trace backends you already run is a configuration task: you add a data source for each backend, point it at the query endpoint, and test it from Grafana. The work is the same whether the traces come from Jaeger or Zipkin, but the decisions around it are not. Your team needs to decide which backend holds which services' traces, which Grafana identity may read them, and how the trace view will link out to logs and metrics that already live in your Grafana instance.
The integration does not change how traces are collected, stored or retained. Grafana reads from the backend and renders what it finds. OpenTelemetry is a framework for generating, exporting and collecting telemetry, and it is not a storage backend, so if your applications already emit OpenTelemetry, the Collector pipeline that delivers traces to Jaeger or Zipkin stays where it is. Grafana can also propagate Jaeger and W3C Trace Context information to compatible data sources, which matters when a trace view should carry context into a linked query. Confirm which propagation formats your services send and which headers your backends accept before you rely on trace-to-log or trace-to-metric links.
Before you configure anything, confirm three points with the owners of each backend: the query API version and endpoint that Grafana will reach over the network, the authentication method the backend expects if it sits behind a gateway, and whether retention is long enough for the investigations your teams run. Retention is set by the trace backend, not by Grafana, so a dashboard cannot show traces the backend has already deleted. The data source configuration should use a read-only identity where the backend supports one, and the owners should review that identity's scope before it goes live.
What a Jaeger or Zipkin integration needs before setup
Connecting Grafana to traces that already live in Jaeger or Zipkin touches version compatibility, network reachability, transport security and access scope. Each item below is a decision or check to settle with the team that runs the trace backend before anyone edits a data source.
Grafana version and edition
Record the exact Grafana release and edition you run, since trace data source behavior and settings can change between releases. Confirm which Jaeger or Zipkin versions your release supports in the Grafana data sources docs before you pick a backend version to connect to. Also confirm whether the team runs open source or Enterprise, because that affects which authentication options apply to who can open trace views.
Reachable query endpoint
Identify the query API URL of the existing Jaeger or Zipkin backend and confirm it answers from the Grafana server, not only from a developer laptop. Jaeger and Zipkin are often deployed behind internal service names or ingress paths that differ from the UI address. Write down the exact base URL, port and path so the data source configuration matches what the backend actually serves.
Network paths and firewall rules
Map the connection from every Grafana server, including each node in a high availability pair, to the trace backend port. Open only that path from the Grafana tier to the query endpoint and nothing broader. If Grafana runs in a separate network zone, the rule must be reviewed by the team that owns the backend's network segment.
TLS and backend authentication
Decide whether traffic between Grafana and the trace backend uses TLS, and which certificate authority Grafana must trust for that internal name. Confirm how the backend authenticates callers, such as a reverse proxy with basic credentials, a bearer token or mutual TLS, and store any secret in Grafana's supported secret handling rather than in plain configuration. Check the data source settings for each option in the docs for your release.
Query-scoped account
Ask whether the trace backend or the gateway in front of it supports a read-only or query-only credential. A dedicated account limited to search and retrieval endpoints means a leaked Grafana secret cannot change backend configuration or delete trace data. If the backend has no native role model, plan the restriction at the proxy layer and document who owns it.
Trace content and access review
Traces can carry service names, operation names, tags and sometimes sensitive values such as customer identifiers or query text. Review what the existing instrumentation records and who should see which services before Grafana exposes them to a wider group of viewers. Agree on this with the data owners, since the Grafana access model will only restrict what is already in the trace store.
Configuring the Jaeger or Zipkin data source step by step
This sequence takes a self-hosted Grafana from no trace source to a working Jaeger or Zipkin connection, with links to the team's existing logs and metrics and trace context carried across signals. Each step ends with a check that confirms the previous work before the next one starts.
Confirm the trace backend and its query endpoint
Before touching Grafana, the platform owner confirms which trace backend holds the data (Jaeger or Zipkin), the base URL of its query API as reachable from the Grafana servers, and whether that endpoint sits behind a proxy or gateway that requires credentials. Ask the backend team to confirm the network path from every Grafana node, including any HA nodes. Done when a plain HTTP request from a Grafana host to the query endpoint returns a response, and the team has written down the URL and the auth method it will use.
Add the Jaeger or Zipkin data source
An administrator adds the data source either in the Grafana UI under Connections, Data sources, or as a YAML file loaded at startup through the provisioning directory, which suits teams that manage Grafana as code. Set the type to Jaeger or Zipkin, enter the backend URL, and choose the authentication method the backend requires. Done when the data source's Save and test action reports a successful connection. If it fails, check the URL, DNS resolution and TLS trust on the Grafana host first.
Set authentication and TLS for the backend
Configure how Grafana proves its identity to the trace backend. For backends behind a gateway, this often means a basic auth or bearer credential stored as a secret in Grafana rather than typed into a shared dashboard. Set the custom CA certificate if the backend uses an internal certificate authority. Use a read-only service account where the backend supports one. Done when the test succeeds using the production authentication path, not a temporary admin credential, and the secret does not appear in the data source's plain-text fields in the UI.
Link traces to the existing log data source
Open the trace data source settings and enable the trace-to-logs option, then select the team's existing log data source, such as Loki, and define the tags or fields that match log labels (for example, service name and pod). Adjust the time window offsets so the log query brackets the span. Done when opening a span in Explore shows a logs link that returns log lines for that service and time range. If it returns nothing, compare the label names on a sample log line with the mapping.
Link traces to the existing metric data source
Enable trace-to-metrics and select the Prometheus-compatible data source the team already uses. Map the service tag to the label the metrics carry, so a span can open a query for request rate, errors or latency for its service. Confirm that the metric names in the query match what the team's exporters or instrumentation publish. Done when a span opens a metrics panel that plots data for the same service and time window, which confirms the label mapping is correct.
Configure trace context propagation
Set the propagation format so Grafana includes the trace identifiers its own queries use when calling downstream data sources. Grafana can propagate Jaeger and W3C Trace Context information to compatible data sources, so choose the format that matches what the instrumented services emit. Confirm with the application team which header format their SDKs send. Done when a query issued from a panel carries a trace header that the backend records, which you can verify by searching for the Grafana-originated request in the backend.
Run a trace search and open one trace
Use Explore with the new data source and search for a service you know produces traces, limiting the time range to a window where you know activity occurred. Open one trace from the results and check that the span tree, timing and service names match what the application team expects. Then follow its log and metric links. Done when a known request appears as a full trace in Explore and both links return data for the same service, which confirms the whole chain works before dashboards are built on it.
Keeping Jaeger or Zipkin versus moving traces to Tempo
If your Jaeger or Zipkin estate works today and no storage change is planned, the main job is to add Grafana as a read path. Grafana ships Jaeger and Zipkin as core trace data sources, so you connect them to the existing query endpoints without changing how services emit spans. Your applications, SDKs and collectors can stay as they are. The work is mostly network access from Grafana to the query services, service accounts or proxies where the backend requires them, and dashboards that reflect how your teams already search traces.
- Data sources: Add the Jaeger and Zipkin core data sources and point each at the query endpoint your teams use today.
- Links: Confirm which trace-to-log and trace-to-metric links your current label and tag conventions support before promising them to teams.
- Query languages: Keep the native search model each backend already offers, so existing habits and saved searches still apply.
- Propagation: Grafana can propagate Jaeger and W3C Trace Context information to compatible data sources, so check that your services pass these headers.
- Re-instrumentation: None is required for this path.
Before committing, confirm the backend version, retention settings and query endpoint behavior with your Jaeger or Zipkin administrators, since these set how much of the Grafana experience works out of the box.
Some teams want every trace in one backend that Grafana queries, often because they already run Tempo for logs or metrics and want traces alongside them. In this case, moving trace storage to Tempo is a deliberate consolidation. Tempo is one of the three core trace data sources, and it has its own query language and linking features. The change touches the collection path, so spans must reach Tempo rather than the old backend, and dashboards and alert logic must be rebuilt against the new data source.
- Data sources: Keep Jaeger or Zipkin connected during the transition so teams can query old traces while new ones land in Tempo.
- Query languages: Plan to move saved queries from the native Jaeger or Zipkin search to TraceQL, which requires new training.
- Links: Rebuild trace-to-log and trace-to-metric links against the label names Tempo receives, since they depend on consistent labels.
- Routing: Use an OpenTelemetry Collector or Grafana Alloy to send spans to Tempo, or to both backends during a parallel run.
- Re-instrumentation: Often limited to exporter configuration if services already emit OpenTelemetry or compatible spans.
Ask the implementation partner and your platform team to confirm whether any services export directly to the old backend, because each one needs its exporter changed.
Teams hitting limits in their current trace backend should first define the problem precisely: query latency, ingest volume, how long traces must be kept, or the cost of the storage underneath. Moving to Tempo is one response, but the sources do not establish performance or cost outcomes for any specific workload, so the decision needs your own measurements. A move changes the storage engine, retention policy and query path together, which makes it a migration project rather than a configuration change.
- Measure first: Record ingest rate, retention period, query patterns and storage growth for the current backend.
- Parallel run: Send spans to both backends for a period so queries can be compared before cutover.
- Retention: Define retention separately for each backend, since old traces may need to remain readable for audit or incident review.
- Collector routing: Use collector pipelines to split or duplicate traffic, with the routing rules kept under version control.
- Data sources: Grafana can read both backends during the transition, so historical traces stay available.
Ask any vendor or partner to show benchmarks on workloads resembling yours, and confirm what the move would do to query behavior and storage costs in your environment before approving it.
How trace-to-logs and trace-to-metrics links depend on shared labels
Trace-to-logs and trace-to-metrics links only work when the identifiers in your logs and metrics match what the trace backend stores. Grafana builds these links by taking a value from a span, such as the service name, a tag or the trace ID, and substituting it into a query against the log or metric source. If the log stream labels the service differently than Jaeger or Zipkin does, or the trace ID is written under another field name, the link opens an empty result without any error. The first decision is therefore a naming decision: pick one service name and one trace ID field and apply it in the instrumentation, the collector and the log pipeline before any dashboard is built.
Context propagation is what puts the trace ID into logs in the first place. Grafana can propagate Jaeger and W3C Trace Context information to compatible data sources, so the same identifiers can travel from a request into downstream calls and into log lines. Confirm which header format your services emit and which format each service in the path accepts, because a mixed estate can produce traces that split at a service boundary. Log pipelines also need the trace ID extracted into a field the log data source can filter on, and that extraction is usually configured in the log source or the collector, not in Grafana. Check whether your applications write the trace ID into each log line at all before assuming a link exists.
Verify the field names against real traces before rolling out dashboards. Pick several traces that cross at least two services, open them in the trace data source, and record the exact service name, span attribute and trace ID values. Then run the same trace ID through the log and metric sources by hand and confirm that each returns the expected lines and series. Record the mapping in a short document that dashboard authors can follow, and repeat the check after any change to instrumentation or the collector. This is also a useful place to bring in the team that owns the Jaeger or Zipkin backend, because a field renamed upstream will break links silently.
Mapping trace fields, service names and identities between systems
This table lists the attributes a team should check when Grafana reads traces from Jaeger or Zipkin and links them to logs and metrics, plus the identity and credential settings that decide who can query each backend. Use it as a checklist against your own instrumentation and access model, since field names and mappings depend on how your services emit data. The main takeaway is that link quality depends on consistent IDs and service names across systems, and access depends on which Grafana identities and backend credentials you scope.
| Attribute | What to check | Where it breaks |
|---|---|---|
| Trace ID | Confirm the trace ID format each backend returns (Jaeger and Zipkin use different encodings) and that the same value appears in log records | Logs carry a trace ID in a different case, padding or header format than the trace store |
| Span ID and parent span ID | Confirm span relationships survive export and that the span fields Grafana reads are populated for every service | Spans from one language SDK omit parent IDs, which flattens the trace view |
| Service name | Agree one canonical service name per workload and confirm it matches the label used in metrics and log streams | Renamed deployments or per-pod names split one service into several entries in dashboards |
| Operation name | Confirm the operation names used for spans match the names used in any trace-based metrics or alert queries | Operation names embed IDs or query strings, creating high cardinality and unmatched filters |
| Tags and attributes | List the tags you need for filtering and links, such as environment, cluster, region and tenant, and confirm each one is emitted | Tags set in some services only, or stored under different keys in Jaeger and Zipkin |
| Linked log and metric sources | Map each trace field to the matching log label or metric label in the data source configured for the link | Link fields point at a label that does not exist in the target source, so the link returns no results |
| Grafana user and team access | Decide which Grafana teams can open each trace data source and whether folder or dashboard permissions expose trace views | Teams inherit broad access through shared dashboards, so restricted backends stay visible |
| Backend credentials | Confirm each trace data source uses a dedicated, read-only credential scoped to the services that team owns, and that secrets are stored outside plain configuration | One shared credential grants all teams access, and audit logs cannot attribute queries to a person |
Securing trace data sources and their credentials
Trace backends often hold request paths, user identifiers and business context, so the data source connection deserves the same care as the data itself. The cards below cover where backend credentials live, who can change the connection, how traffic to the backend is protected, how far queries can reach, and how trace payloads are handled once they are on screen.
Keep backend credentials out of provisioning files
Provisioning files can define Jaeger, Tempo or Zipkin data sources at startup, but a plain-text password or token inside a YAML file is readable by anyone with repository or server access. Store backend credentials in Grafana's secure settings or an external secrets mechanism your platform already uses, and reference them from the data source definition. Check that no credential appears in Git history, container images or the Grafana data source list in plain text.
Restrict who can edit data sources
Anyone who can edit a trace data source can change its URL, so a user could redirect Grafana to an unintended endpoint or alter authentication settings. Limit data source edit rights to a small platform group and keep viewers and editors of dashboards separate from that group. Confirm the role model in your edition, because fine-grained access controls differ between open source and Enterprise.
Encrypt traffic to the trace backend
Traces travel from Grafana to Jaeger, Tempo or Zipkin over the network, and unencrypted links expose span content to anyone on the path. Configure TLS on the backend endpoint and set Grafana to verify the backend certificate, using your internal certificate authority where needed. Test the connection with an invalid certificate to confirm that Grafana refuses it rather than silently accepting it.
Limit query scope and time ranges
Broad trace queries can return large volumes of spans and expose services a given team should not see. Decide which services, tenants or time windows each group may query, and apply those limits in the backend where it supports them. Ask the backend owner which query limits, result caps and tenant headers it enforces, since these settings vary by backend and version.
Treat span payloads as sensitive data
Span attributes and events can carry user identifiers, email addresses, account numbers or query text, especially when teams add custom attributes during instrumentation. Review which attributes services emit, and filter or redact fields in the OpenTelemetry Collector before export when they are not needed for diagnosis. Apply the same retention and access rules to traces that you apply to logs.
Harden the exporter path to the backend
The Collector that sends traces to the backend needs its own credentials, TLS settings and receiver authentication, and misconfigured exporters are a common source of exposed endpoints. Use Collector authenticator extensions where the backend supports them, and avoid leaving receivers open on all interfaces. Review the Grafana security hardening settings alongside these exporter controls so that both ends of the trace path are covered.
Why Jaeger or Zipkin traces do not appear or link in Grafana
This table lists the failures teams most often hit when Jaeger or Zipkin traces fail to show up or link in Grafana, with the likely cause and the check to run first. Work down the rows in order, since an unreachable endpoint or a trust error hides every later symptom. The main takeaway is that most trace problems sit in the data source settings, the trace ID format, or the service export path rather than in Grafana itself.
| Symptom | Likely cause | Check or fix |
|---|---|---|
| Data source test fails with a connection error | The Grafana server cannot reach the Jaeger Query or Zipkin URL, often because the URL points at a name that only resolves on a laptop or uses the wrong port | Run a request to the backend URL from the Grafana host or container itself, then correct the URL and port in the data source settings |
| TLS or certificate trust errors | The backend uses a certificate issued by an internal CA that is not in the trust store of the Grafana host or container | Confirm the CA chain is installed where Grafana runs, check the certificate names match the URL, and restart Grafana after trust changes |
| Authentication rejected | The backend sits behind a proxy or gateway that requires credentials or a token, and the data source sends none, or sends a credential the gateway does not accept | Check the data source authentication method and headers against the gateway configuration, and test with a single known-good credential |
| Search returns no traces for a known service | Services export to a different backend, such as a collector pipeline that sends traces to Tempo or another store, so the Jaeger or Zipkin backend holds nothing | Confirm the exporter target in the service or Collector configuration, and check the backend's own UI for the same service name |
| Traces appear but service names are missing or differ | Instrumentation reports service names under different labels or spellings than the query expects | Compare the service name in the backend UI with the value used in the Grafana query and align the instrumentation or query |
| Trace to logs link opens an empty log view | The trace ID in the log lines does not match the trace ID format stored in the trace backend, for example 128-bit versus 64-bit or differently cased hex | Log one known trace ID from a service, search the trace backend with it, and align the log field name and format in the link settings |
| Trace to logs link opens with no results for the right trace | The log data source is set to a different instance or the log field used for the trace ID is not the one configured in the link | Check which data source the link targets and which field name the link extracts, then test with a single trace |
| Linked logs or metrics show the wrong time window | The link time range offset is too narrow for spans that start before the root span or end after it, or the linked data source stores data on a different time basis | Widen the time window offset in the link settings and compare timestamps across the trace, log and metric sources |
| Link opens the right data source but wrong or no panel data | Trace context is not propagated to the target data source, so the link carries no usable labels or tags | Review the propagation settings in the data source configuration and confirm the target stores the tags the link uses |
Questions teams ask before connecting Jaeger or Zipkin to Grafana
How much effort does connecting Jaeger or Zipkin to Grafana take?
For a single Grafana instance that already runs in production, adding Jaeger or Zipkin is usually a configuration task rather than a build project. Effort rises with the number of trace backends, the number of teams sharing the instance, and whether trace links to logs and metrics must work on day one. Each backend needs a reachable query endpoint, a data source definition, and a decision about who can see which traces. Grafana provisions data sources from files at startup, so the definitions can be written once and reviewed like any other configuration. The main unknowns are network paths from Grafana to the trace store and how much trace data the backend holds, so confirm both before estimating the work.
Can our own team connect Jaeger or Zipkin to Grafana without outside help?
Yes, if the team already operates Grafana and has access to the Jaeger or Zipkin query endpoint. The core Jaeger, Tempo and Zipkin data sources are built into Grafana, so no plugin purchase is needed for the basic connection. Outside help tends to add value in three places: wiring trace-to-log and trace-to-metric links consistently across several data sources, setting up provisioning so the configuration is repeatable, and testing that the links hold under real query load. A fixed-scope engagement lets you buy only those pieces, with deliverables and timelines agreed in writing before work starts.
What does the work need from our platform and observability staff?
Three groups usually need to be involved. Platform engineers own the network path, the Grafana host or container, and the secrets used for any authenticated trace endpoint. Observability engineers own the trace backend itself, including retention, query limits and the service names that appear in traces. Security staff should review who can query traces, since trace data often contains service names, internal hostnames and sometimes request metadata. Early agreement on these owners prevents the most common delays, which are unclear answers about which team can open a firewall rule or rotate a credential.
How long does validation take, and what sets that time?
Validation covers whether a trace found in Jaeger or Zipkin opens from Grafana, whether links to logs and metrics resolve to the right time range and labels, and whether queries stay within acceptable load on the trace store. The duration depends on how many data sources and teams are involved, how consistent service names and trace IDs are across signals, and whether authentication or proxies sit in the path. Because no validation duration is supplied for this integration, ask any partner for a written test plan with entry and exit criteria, and confirm the schedule against your change calendar.
Does Grafana propagate trace context to Jaeger or Zipkin?
Grafana can propagate Jaeger and W3C Trace Context information to compatible data sources, which lets a link from a log line or panel carry the trace ID into the trace view. Whether this works end to end depends on your instrumentation sending the same trace identifiers into logs and metrics. Engineers should check the header format used by the services, the field names in the log data source, and the derived field configuration in Grafana. Confirm the exact propagation behavior for your Grafana version in the Grafana monitoring documentation before relying on it for incident response.
When does moving trace storage to Tempo change the effort?
Moving to Tempo changes the effort when your team is already planning to replace Jaeger or Zipkin storage, when you want one object-storage backed trace store alongside Loki and Prometheus, or when the existing backend cannot meet retention or query needs. Keeping Jaeger or Zipkin means the connection work is smaller, but the backend remains a separate system to operate. Moving adds ingestion changes, a data migration or parallel-run decision, and new retention and access controls. Grafana treats Jaeger, Tempo and Zipkin as core trace data sources, so the Grafana side is comparable. The larger cost is the trace pipeline and the period when both stores run.
What recurring costs follow the connection?
The one-time cost is the configuration, testing and documentation. The recurring costs are the people who keep Grafana upgraded, the trace backend running, and data source definitions current when service names or endpoints change. Grafana publishes a release cadence with major releases once a year, minor releases every other month and patch releases at least monthly, and each minor release is supported for 9 months. Budget staff time for applying those upgrades and retesting trace links after each one. Ask any quote to separate setup, validation, and ongoing support so the recurring part is visible.
How DeployOpen scopes and delivers this Grafana integration
DeployOpen plans and implements self-hosted Grafana inside your own infrastructure, and treats the connection to existing Jaeger or Zipkin trace backends as a defined piece of work. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory which Jaeger or Zipkin instances hold traces, their versions, and who needs access to each.
- The written scope names the data source configuration, trace-to-log and trace-to-metric links, and the environments covered.
- We record which decisions stay with your team, such as keeping Jaeger or Zipkin storage or moving trace storage to Tempo.
How we build
- We configure the Jaeger and Zipkin data sources in your self-hosted Grafana, using provisioning files so the setup is repeatable.
- We set up trace-to-logs and trace-to-metrics links to the log and metric data sources you already run, and test them with real trace IDs.
- We test query permissions, data source connectivity and propagation of Jaeger and W3C Trace Context fields across the chosen data sources.
How we hand over
- You receive the provisioning files, data source settings and a record of each link between traces, logs and metrics.
- The documentation covers the data source accounts, read-only access model, and the steps to add a new trace backend later.
- We walk your platform and on-call engineers through querying traces, checking links and troubleshooting failed data source connections.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering Grafana and data source plugin version changes.
- Retainer work can include reviewing trace data source settings after Grafana upgrades and after changes to your Jaeger or Zipkin deployments.
- If you later plan to move trace storage to Tempo, we can scope that migration as a separate written engagement.
