Tempo data source on Grafana Labs

Configure the Tempo data source

Fri, 03 Apr 2026 19:43:06 +0000

Configure a Tempo data source

The Tempo data source sets how Grafana connects to your Tempo database and lets you configure features and integrations with other telemetry signals.

You can configure the data source using either the data source interface in Grafana or using a configuration file. This page explains how to set up and enable the data source capabilities using Grafana.

If you’re using your own installation of Grafana, you can provision the Tempo data source using a YAML configuration file.

Depending upon your tracing environment, you may have more than one Tempo instance. Grafana supports multiple Tempo data sources.

Before you begin

To configure a Tempo data source, you need administrator rights to your Grafana instance and a Tempo instance configured to send tracing data to Grafana.

If you’re provisioning a Tempo data source, then you also need administrative rights on the server hosting your Grafana instance. Refer to Provision the data source for next steps.

Add or modify a data source

You can use these procedures to configure a new Tempo data source or to edit an existing one.

Note
You can’t modify a provisioned data source using the Tempo data source settings in Grafana Cloud.

If you want to modify any capabilities of a provisioned data source, you can clone the provisioned data source and then edit the new data source in the Grafana UI. Refer to Clone a provisioned data source for Grafana Cloud for more information.

Add a new data source

Follow these steps to set up a new Tempo data source:

Select Connections in the main menu.
Enter Tempo in the search bar.
Select Tempo.
Select Add new data source in the top-right corner of the page.
On the Settings tab, complete the Name, Connection, and Authentication sections.

Use the Name field to specify the name used for the data source in panels, queries, and Explore. Toggle the Default switch for the data source to be pre-selected for new panels.
Under Connection, enter the URL of the Tempo instance, for example, https://example.com:4100.
Complete the Authentication section.

Optional: Configure other sections to add capabilities to your tracing data. Refer to the additional procedures for instructions.
Select Save & test.

Update an existing data source

To modify an existing Tempo data source:

Select Connections in the main menu.
Select Data sources to view a list of configured data sources.
Select the Tempo data source you wish to modify.
Configure or update additional sections to add capabilities to your tracing data. Refer to the additional procedures for instructions.
After completing your updates, select Save & test.

Authentication

Use this section to select an authentication method to access the data source.

Note
Use Transport Layer Security (TLS) for an additional layer of security when working with Tempo. For additional information on setting up TLS encryption with Tempo, refer to Configure TLS communication and Tempo configuration.

To set up authentication:

Select an authentication method from the drop-down list:
- Basic authentication: Authenticates your data source using a username and password
- Forward OAuth identity: Forwards the OAuth access token and the OIDC ID token, if available, of the user querying to the data source
- No authentication: No authentication is required to access the data source
For Basic authentication only: Enter the User and Password.
Optional: Complete the TLS settings for additional security methods.

TLS Client Authentication

Toggle on to use client authentication. When enabled, it adds the Server name, Client cert, and Client key fields. The client provides a certificate that is validated by the server to establish the client’s trusted identity. The client key encrypts the data between client and server. These details are encrypted and stored in the Grafana database.

Add self-signed certificate

Activate this option to use a self-signed TLS certificate. You can add your own Certificate Authority (CA) certificate on top of one generated by the certificate authorities for additional security measure.

Skip TLS certification validation

When activated, it bypasses TLS certificate verification. Not recommended, unless absolutely necessary for testing.
Optional: Add HTTP Headers. You can pass along additional context and metadata data about the request and response. Select Add header to add Header and Value fields.
Select Save & test to preserve your changes.

Streaming

Streaming enables TraceQL query results to be displayed as they become available. Without streaming, no results are displayed until all results have returned.

To use streaming, you need to:

Run Tempo version 2.2 or later, or Grafana Enterprise Traces (GET) version 2.2 or later, or use Grafana Cloud Traces.
Tempo must have stream_over_http_enabled: true for streaming to work.

For more information, refer to Tempo gRPC API.
For self-managed Tempo or GET instances: If your Tempo or GET instance is behind a load balancer or proxy that doesn’t supporting gRPC or HTTP2, streaming may not work and should be deactivated.

Activate streaming

Streaming is available in Grafana and Grafana Cloud. You can activate streaming by turning the Streaming toggle to on in the Tempo data source.

When streaming is active, it’s shows as Enabled in Explore. To check the status, select Explore in the menu, select your Tempo data source, and expand the Options section.

Trace to logs

The Trace to logs setting configures trace to logs that’s available when you integrate Grafana with Tempo. Trace to logs can also be used with other tracing data sources, such as Jaeger and Zipkin.

You can configure a custom query where you can use a template language to interpolate variables from the trace or span.

Configure a custom query

Select the target data source from the drop-down list.

You can also click Open advanced data source picker to see more options, including adding a data source.
Set start and end time shift. As the logs timestamps may not exactly match the timestamps of the spans in the trace it may be necessary to widen or shift the time range to find the desired logs.
Optional: Select tags to map. These tags can be used in the custom query with ${__tags} variable. This variable interpolates the mapped tags as list in an appropriate syntax for the data source. Only the tags that were present in the span are included; tags that aren’t present are omitted You can also configure a new name for the tag. This is useful in cases where the tag has dots in the name and the target data source doesn’t allow dots in labels. For example, you can remap http.status to http_status. If you don’t map any tags here, you can still use any tag in the query, for example, method="${__span.tags.method}". You can learn more about custom query variables here.
Skip Filter by trace ID and Filter by span ID settings as these cannot be used with a custom query.
Switch on Use custom query.
Specify a custom query to be used to query the logs. You can use various variables to make that query relevant for current span. The link will only be shown only if all the variables are interpolated with non-empty values to prevent creating an invalid query.

Configure trace to logs

The following table describes the ways in which you can configure your trace to logs settings:

Setting name	Description
Data source	Defines the target data source. You can select Loki or any compatible log store.
Span start time shift	Shifts the start time for the logs query, based on the span’s start time. You can use time units, such as `5s`, `1m`, `3h`. To extend the time to the past, use a negative value. Default: `0`.
Span end time shift	Shifts the end time for the logs query, based on the span’s end time. You can use time units. Default: `0`.
Tags	Defines the tags to use in the logs query. Default: `cluster`, `hostname`, `namespace`, `pod`, `service.name`, `service.namespace`. You can change the tag name for example to remove dots from the name if they are not allowed in the target data source. For example, map `http.status` to `http_status`.
Filter by trace ID	Toggles whether to append the trace ID to the logs query.
Filter by span ID	Toggles whether to append the span ID to the logs query.
Use custom query	Toggles use of custom query with interpolation.
Query	Input to write custom query. Use variable interpolation to customize it with variables from span.

Trace to metrics

The Trace to metrics setting configures the trace to metrics feature available when integrating Grafana with Tempo.

There are two ways to configure the trace to metrics feature:

Use a basic configuration with a default query, or
Configure one or more custom queries where you can use a template language to interpolate variables from the trace or span.

Refer to the Trace to metrics configuration options section to learn about the available options.

Set up a simple configuration

To use a simple configuration, follow these steps:

Select a metrics data source from the Data source drop-down.
Optional: Change Span start time shift and Span end time shift. You can change one or both of these settings. The default start time shift is -2 minutes and 2 minutes for end time shift.
Optional: Choose any tags to use in the query. If left blank, the default values of cluster, hostname, namespace, pod, service.name and service.namespace are used.

The tags you configure must be present in the spans attributes or resources for a trace to metrics span link to appear. You can optionally configure a new name for the tag. This is useful for example if the tag has dots in the name and the target data source doesn’t allow using dots in labels. In that case you can for example remap service.name to service_name.
Don’t select Add query.
Select Save and Test.

Set up custom queries

To use custom queries, you need to configure the tags you’d like to include in the linked queries. For each tag, the key is the span attribute name. In cases where the attribute name would result in an invalid metrics query or doesn’t exactly match the desired label name, you can enter the label name as the second value. For example, you could map the attribute k8s.pod to the label pod.

You can interpolate the configured tags using the $__tags keyword. For example, when you configure the query requests_total{$__tags} with the tags k8s.pod=pod and cluster, it results in requests_total{pod="nginx-554b9", cluster="us-east-1"}. The label values are dynamically inserted based on the span attributes’ values.

You can link to any metric you’d like, but metrics for span durations, counts, and errors filtered by service or span are a great starting point.

To use custom queries with the configuration, follow these steps:

Select a metrics data source from the Data source drop-down.
Optional: Choose any tags to use in the query. If left blank, the default values of cluster, hostname, namespace, pod, service.name and service.namespace are used.

These tags can be used in the custom query with ${__tags} variable. This variable interpolates the mapped tags as list in an appropriate syntax for the data source and will only include the tags that were present in the span omitting those that weren’t present. You can optionally configure a new name for the tag. This is useful in cases where the tag has dots in the name and the target data source doesn’t allow using dots in labels. For example, you can remap service.name to service_name in such a case. If you don’t map any tags here, you can still use any tag in the query like this method="${__span.tags.method}". You can learn more about custom query variables here.
Click Add query to add a custom query.
Specify a custom query to be used to query metrics data.

Each linked query consists of:
- Link Label: (Optional) Descriptive label for the linked query.
- Query: The query ran when navigating from a trace to the metrics data source. Interpolate tags using the $__tags keyword. For example, when you configure the query requests_total{$__tags}with the tags k8s.pod=pod and cluster, the result looks like requests_total{pod="nginx-554b9", cluster="us-east-1"}.
Select Save and Test.

Trace to metrics configuration options

Setting name	Description
Data source	Defines the target data source.
Span start time shift	Shifts the start time for the metrics query, based on the span’s start time. You can use time units, such as `5s`, `1m`, `3h`. To extend the time to the past, use a negative value. Default: `0`.
Span end time shift	Shifts the end time for the metrics query, based on the span’s end time. You can use time units. Default: `0`.
Tags	Defines the tags used in linked queries. The key sets the span attribute name, and the optional value sets the corresponding metric label name. For example, you can map `k8s.pod` to `pod`. To interpolate these tags into queries, use the `$__tags` keyword.
Link Label	(Optional) Descriptive label for the linked query.
Query	Input to write a custom query. Use variable interpolation to customize it with variables from span.

Trace to profiles

Using Trace to profiles, you can use Grafana’s ability to correlate different signals by adding the functionality to link between traces and profiles.

Trace to profiles lets you link your Grafana Pyroscope data source to tracing data. When configured, this connection lets you run queries from a trace span into the profile data using Explore. Each span links to your queries. Clicking a link runs the query in a split panel. If tags are configured, Grafana dynamically inserts the span attribute values into the query. The query runs over the time range of the (span start time - 60) to (span end time + 60 seconds).

Embedded flame graphs are also inserted into each span details section that has a linked profile. This lets you see resource consumption in a flame graph visualization for each span without having to navigate away from the current view.

There are two ways to configure the trace to profiles feature:

Use a basic configuration with default query, or
Configure a custom query where you can use a template language to interpolate variables from the trace or span.

Before you begin

Traces to profile requires a Tempo data source with Traces to profiles configured and a Grafana Pyroscope data source.

As with traces, your application needs to be instrumented to emit profiling data. For more information, refer to Linking tracing and profiling with span profiles.

Use a basic configuration

To use a basic configuration, follow these steps:

In the left menu, select Connections > Data sources.
Select your configured Tempo data source from the Data source list.
Scroll down to the Traces to profiles section.
Select a Pyroscope data source in the Data source drop-down.
Optional: Add one or more tags to use in the query. If left blank, the default values of service.name and service.namespace are used.

The tags you configure must be present in the spans attributes or resources for a trace-to-profiles span link to appear.

You can optionally configure a new name for the tag. This is useful if the tag has dots in the name and the target data source doesn’t allow dots in labels. In that case, you can remap service.name to service_name.
Select one or more profile types to use in the query. Select the drop-down and choose options from the menu.

The profile type or app must be selected for the query to be valid. Grafana doesn’t show any data if the profile type or app isn’t selected when a query runs.
Select Save and Test.

If you have configured a Pyroscope data source and no profile data is available or the Profiles for this span button and the embedded flame graph isn’t visible, verify that the pyroscope.profile.id key-value pair exists in your span tags.

Configure a custom query

To use a custom query with the configuration, follow these steps:

In the left menu, select Connections > Data sources.
Select a configured Tempo data source from the Data source list.
Scroll down to the Traces to profiles section.
Select a Pyroscope data source in the Data source drop-down.
Optional: Choose any tags to use in the query. If left blank, the default values of service.name and service.namespace are used.

These tags can be used in the custom query with ${__tags} variable. This variable interpolates the mapped tags as list in an appropriate syntax for the data source. Only tags present in the span are included. Tags that aren’t present are omitted.

You can also configure a name for the tag. Tag names are useful where the tag has dots in the name and the target data source doesn’t allow using dots in labels. For example, you can remap service.name to service_name. If you don’t map any tags here, you can still use any tag in the query, for example: method="${__span.tags.method}". Learn more about custom query variables.
Select one or more profile types to use in the query. Select the drop-down and choose options from the menu.
Switch on Use custom query to enter a custom query.
Specify a custom query to be used to query profile data. You can use various variables to make that query relevant for current span. The link shows only if all the variables are interpolated with non-empty values to prevent creating an invalid query. You can interpolate the configured tags using the $__tags keyword.
Select Save and Test.

Configuration options

The following table describes options for configuring your Trace to profiles settings:

Setting name	Description
Data source	Defines the target data source. You can select a Pyroscope [profiling] data source.
Tags	Defines the tags to use in the profile query. Default: `cluster`, `hostname`, `namespace`, `pod`, `service.name`, `service.namespace`. You can change the tag name for example to remove dots from the name if they’re not allowed in the target data source. For example, map `http.status` to `http_status`.
Profile type	Defines the profile type that used in the query.
Use custom query	Toggles use of custom query with interpolation.
Query	Input to write custom query. Use variable interpolation to customize it with variables from span.

Custom query variables

To use a variable in your trace to logs, metrics, or profiles, you need to wrap it in ${}. For example, ${__span.name}.

Variable name	Description
__tags	This variable uses the tag mapping from the UI to create a label matcher string in the specific data source syntax. The variable only uses tags that are present in the span. The link is still created even if only one of those tags is present in the span. You can use this if all tags are not required for the query to be useful.
__span.spanId	The ID of the span.
__span.traceId	The ID of the trace.
__span.duration	The duration of the span.
__span.name	Name of the span.
__span.tags	Namespace for the tags in the span. To access a specific tag named `version`, you would use `${__span.tags.version}`. In case the tag contains dot, you have to access it as `${__span.tags["http.status"]}`.
__trace.traceId	The ID of the trace.
__trace.duration	The duration of the trace.
__trace.name	The name of the trace.

Additional settings

Use the down arrow to expand the Additional settings section to view these options.

Advanced HTTP settings

The Grafana Proxy deletes forwarded cookies. Use the Allowed cookies field to specify cookies by name that should be forwarded to the data source.

The Timeout field sets the HTTP request timeout in seconds.

Service graph

The Service graph setting configures the Service Graph data.

Configure the Data source setting to define in which Prometheus instance the Service Graph data is stored.

To use the Service Graph, refer to the Service Graph documentation.

Node graph

The Node graph setting enables the node graph visualization, which isn’t activated by default.

Once activated, Grafana displays the node graph above the trace view.

Tempo search

The Search setting configures Tempo search.

You can configure the Hide search setting to hide the search query option in Explore if search is not configured in the Tempo instance.

TraceID query

The TraceID query setting modifies how TraceID queries are run. The time range can be used when there are performance issues or timeouts since it narrows down the search to the defined range. This setting is disabled by default.

You can configure this setting as follows:

Name	Description
Enable time range	Use a time range in the TraceID query. Default: `disabled`.
Time shift start	Time shift for start of search. Default: `30m`.
Time shift end	Time shift for end of search. Default: `30m`.

Tags time range

The Tags time range feature controls how tag and tag-value queries are executed by specifying the time window applied to these requests. You can select one of the following options to constrain your queries:

Name	Description
Last 30 minutes	Last 30 minutes of selected range.
Last 3 hours	Last 3 hours of selected range.
Last 24 hours	Last 24 hours of selected range.
Last 3 days	Last 3 days of selected range.
Last 7 days	Last 7 days of selected range.

Tag limit

The Tag limit setting modifies the max number of tags and tag values to retrieve from Tempo. Default: 5000

Span bar

The Span bar setting helps you display additional information in the span bar row.

You can choose one of three options:

Name	Description
None	Adds nothing to the span bar row.
Duration	(Default) Displays the span duration on the span bar row.
Tag	Displays the span tag on the span bar row. You must also specify which tag key to use to get the tag value, such as `component`.

Private data source connect

Note
This feature is only available in Grafana Cloud.

Use private data source connect (PDC) to connect to and query data within a secure network without opening that network to inbound traffic from Grafana Cloud.

Refer to Private data source connect for more information on how PDC works and Configure Grafana private data source connect (PDC) for steps on setting up a PDC connection.

Use the drop-down list to select a configured private data source. If you make changes, select Test & save to preserve your changes.

Use Manage private data source connect to configure and manage any private data sources you have configured.

Provision the data source

You can define and configure the Tempo data source in YAML files as part of the Grafana provisioning system. Provisioning is primarily used Grafana instances that don’t use Grafana Cloud.

You can use version control, like git, to track and manage file changes. Changes can be updated or rolled back as needed.

For more information about provisioning and available configuration options, refer to Provisioning Grafana.

Note
You can’t modify a provisioned data source using the Tempo data source settings in Grafana. Grafana displays a message for provisioned data sources.

Example file

This example provision YAML file sets up the equivalents of the options available in the Tempo data source user interface.

apiVersion: 1

datasources:
  - name: Tempo
    type: tempo
    uid: EbPG8fYoz
    url: http://localhost:3200
    access: proxy
    basicAuth: false
    jsonData:
      tracesToLogsV2:
        # Field with an internal link pointing to a logs data source in Grafana.
        # datasourceUid value must match the uid value of the logs data source.
        datasourceUid: 'loki'
        spanStartTimeShift: '-1h'
        spanEndTimeShift: '1h'
        tags: ['job', 'instance', 'pod', 'namespace']
        filterByTraceID: false
        filterBySpanID: false
        customQuery: true
        query: 'method="$${__span.tags.method}"'
      tracesToMetrics:
        datasourceUid: 'prom'
        spanStartTimeShift: '-1h'
        spanEndTimeShift: '1h'
        tags: [{ key: 'service.name', value: 'service' }, { key: 'job' }]
        queries:
          - name: 'Sample query'
            query: 'sum(rate(traces_spanmetrics_latency_bucket{$$__tags}[5m]))'
      tracesToProfiles:
        datasourceUid: 'grafana-pyroscope-datasource'
        tags: ['job', 'instance', 'pod', 'namespace']
        profileTypeId: 'process_cpu:cpu:nanoseconds:cpu:nanoseconds'
        customQuery: true
        query: 'method="$${__span.tags.method}"'
      serviceMap:
        datasourceUid: 'prometheus'
      nodeGraph:
        enabled: true
      search:
        hide: false
      traceQuery:
        timeShiftEnabled: true
        spanStartTimeShift: '-1h'
        spanEndTimeShift: '1h'
      spanBar:
        type: 'Tag'
        tag: 'http.path'
      streamingEnabled:
        search: true

Clone a provisioned data source for Grafana Cloud

If you have a data source that is provisioned by a configuration file in Grafana Cloud, you can clone that provisioned data source and then edit the new data source in the Grafana UI.

For example, let’s say you want to edit the Trace to logs settings in your Tempo data source that is provisioned on Grafana Cloud. You’d like to enable traceID and spanID but you can’t because the data source is provisioned. By cloning the data source, you’d be able to edit these capabilities.

To clone a provisioned data source, follow these steps:

Create a viewer Cloud Access Policy token in the Grafana Cloud Portal, making sure it has read permissions at least for the data types you are trying to clone.
Create a new data source of the same type you want to clone.
Copy all of the settings from the existing provisioned data source into the new data source while replacing the password with the API key you created.

The easiest way to do this is to open separate browser windows with the provisioned data source in one and the newly created data source in another.

Of course, after copying the HTTP and Auth section details, pasting the Cloud Access Policy token into the Password field, and changing any of the other options that you want, you can save and test the data source.

Best practices for tracing

Fri, 03 Apr 2026 19:43:06 +0000

Best practices for tracing

This page provides some general best practices for tracing.

Span and resource attributes

Traces are built from spans, which denote units of work such as a call to, or from, an upstream service. Spans are constructed primarily of span and resource attributes. Spans also have a hierarchy, where parent spans can have children or siblings.

In the screenshot below, the left side of the screen (1) shows the list of results for the query. The right side (2) lists each span that makes up the selected trace.

A span attribute is a key/value pair that provides context for its span. For example, if the span deals with calling another service via HTTP, an attribute could include the HTTP URL (maybe as the span attribute key http.url) and the HTTP status code returned (as the span attribute http.status_code). Span attributes can consist of varying, non-null types.

Unlike a span attribute, a resource attribute is a key/value pair that describes the context of how the span was collected. Generally, these attributes describe the process that created the span. This could be a set of resource attributes concerning a Kubernetes cluster, in which case you may see resource attributes, for example: k8s.namespace, k8s.container_name, and k8s.cluster. These can also include information on the libraries that were used to instrument the spans for a trace, or any other infrastructure information.

For more information, read the Attribute and Resource sections in the OpenTelemetry specification.

Naming conventions for span and resource attributes

The OpenTelemetry project defines a number of semantic conventions for attributes, which can help you to determine which attributes are most important to include in your spans. These conventions provide a common vocabulary for describing different types of entities, which can help to ensure that your data is consistent and meaningful.

When naming attributes, use consistent, nested namespaces to ensures that attribute keys are obvious to anyone observing the spans of a trace and that common attributes can be shared by spans. Using our example from above, the http prefix of the attribute is the namespace, and url and status_code are keys within that namespace. Attributes can also be nested, for example http.url.protocol might be HTTP or HTTPS, whereas http.url.path might be /api/v1/query.

For more details around semantic naming conventions, refer to the Recommendations for OpenTelemetry Authors and OpenTelemetry Semantic Conventions documentation.

Some third-party libraries provide auto-instrumentation that generate span and span attributes when included in a source base.

For more information about instrumenting your app for tracing, refer to the Instrument for distributed tracing documentation.

How many attributes should spans have?

The decision of how many attributes to include in your spans is up to you. There is no hard and fast rule. Keep the number of attributes to a minimum, as each attribute adds overhead to the tracing system. In Grafana Cloud, this results in higher tracing costs.

Only include attributes that are relevant to the operation that the span represents. For example, if you are tracing an HTTP request, you might include attributes such as the request method, the URL, and the response status code.

If you are unsure whether or not to include an attribute, it is always better to err on the side of caution and leave it out. You can always add additional attributes later if you need them.

In general, consider the following guidelines:

Don’t include metrics or logs as attributes in your spans.
Don’t use redundant attributes.
When determining which attributes to add, consider an application’s service flow, and execution in the context of only the current span.

The OpenTelemetry project doesn’t specify a maximum number of attributes that a span can have. However, the default limits for the number of attributes per span is 128 entries, so you will have to adjust that. There are also default limits on attribute value and name character lengths.

Determining where to add spans

When instrumenting, determine the smallest piece of work that you need to observe in a trace to be of value to ensure that you don’t over (or under) instrument.

Creating a new span for any work that has a relatively significant duration allows the observation of a trace to immediately show where significant amounts of time are spent during the processing of a request into your application or system.

For example, adding a span for a call to another services (either instrumented or not) may take an unknown amount of time to complete, and therefore being able to separate this work shows when services are taking longer than expected.

Adding a span for a piece of work that might call many other functions in a loop is a good signal of how long that loop is taking (you might add a span attribute that counts how many time the loop runs to determine if the duration is acceptable). However, adding a span for each method or function call in that loop might not, as it might produce hundreds or thousands of worthless spans.

Span length

While there are some (high) default limits to the length that a span (and by definition, the traces they belong to) can be, these can be adjusted by these configurations. Traces that include a large number of spans and/or long-running spans can have an impact on the time taken to query them once stored. Cloud Traces users should contact Grafana Support to modify overrides.

For long-running spans and traces, the best way to see this impact on requests is to send a few test cases and see what the performance looks like and to evaluate the trace size.

From there, you can modify the configuration for Tempo or determine ways to re-architect how the trace is produced.

You can consider breaking up the spans in several ways:

Decompose the query
- For example, if a complex SQL query involves multiple operations (for example, uses joins, subqueries, or unions), consider creating separate spans for each significant operation.
Improve granulation of long-running spans
- For long-running operations, you could create a new span for every predetermined interval of execution time.
  Note
  This requires time-based tracking in your application’s code and is more complex to implement.
Use span linking
- Should data flow hit bottlenecks where further operations on that data might be batched at a later time, the use of span links can help keep traces constrained to an acceptable time range, while sharing context with other traces that work on the same data. This can also improve the readability of traces.

Use traces in Grafana

Fri, 03 Apr 2026 19:43:06 +0000

Use traces in Grafana

Using traces, you can search for traces, generate metrics from spans, and link your tracing data with logs, metrics, and profiles.

This page provides a summary of how you can use tracing data in Grafana.

For general documentation on querying data sources in Grafana, refer to Query and transform data.

Query your data

Using tracing data in Grafana and Grafana Cloud Traces, you can search for traces, generate metrics from spans, and link your tracing data with logs, metrics, and profiles.

Note
Trace results for matching spans are returned on a first-match basis. These results may not be the latest traces stored by Tempo.

Use Traces Drilldown to investigate tracing data

Grafana Traces Drilldown helps you visualize insights from your Tempo traces data. Using the app, you can:

Use Rate, Errors, and Duration (RED) metrics derived from traces to investigate issues
Uncover related issues and monitor changes over time
Browse automatic visualizations of your data based on its characteristics
Do all of this without writing TraceQL queries

Expand your observability journey and learn about the Drilldown apps suite.

Search for traces

Search for traces using common dimensions such as time range, duration, span tags, service names, etc. Use the Explore trace view to quickly diagnose errors and high latency events in your system.

Search is non-deterministic

Most search functions are deterministic. When given the same criteria, a deterministic algorithm returns consistent results. For example, let’s say that you query a search engine for the definition of “traces.” The results list the same top matches for each query for “traces” in that search engine.

However, Tempo search is non-deterministic. If you perform the same search twice, you’ll get different lists, assuming the possible number of results for your search is greater than the number of results you have your search set to return.

When performing a search, Tempo does a massively parallel search over the given time range, and takes the first N results. Even identical searches differ due to things like machine load and network latency. This approach values speed over predictability and is quite simple; enforcing that the search results are consistent would introduce additional complexity (and increase the time the user spends waiting for results). TraceQL follows the same behavior.

By adding most_recent=true to your TraceQL queries, the search results become deterministic. For more information, refer to Retrieve most recent results.

Use trace search results as panels in dashboards

You can embed tracing panels and visualizations in dashboards. You can also save queries as panels. For more information, refer to the Traces Visualization documentation.

For example dashboards, visit play.grafana.org.

Use TraceQL to query data and generate metrics

Inspired by PromQL and LogQL, TraceQL is a query language designed for selecting traces.

Using Grafana Explore, you can search traces. The default traces search reviews the whole trace. TraceQL provides a method for formulating precise queries so you can zoom in to the data you need. Query results return faster because the queries limit what is searched.

You can construct queries using the TraceQL query editor or use the Search query type.

For details about constructing queries, refer to the TraceQL documentation.

TraceQL metrics queries

Note
TraceQL metrics is an experimental feature. Engineering and on-call support is not available. Documentation is either limited or not provided outside of code comments. No SLA is provided. Enable the feature toggle in Grafana to use this feature. Do not enable this feature in production environments.

TraceQL language provides metrics queries as an experimental feature. Metric queries extend trace queries by applying an aggregate function to trace query results. For example: { span:name = "foo" } | rate() by (span:status) This powerful feature creates metrics from traces, much in the same way that LogQL metric queries create metrics from logs.

Grafana Traces Drilldown is powered by metrics queries.

For more information about available queries, refer to TraceQL metrics queries.

Generate metrics from spans

RED metrics can drive service graphs and other ready-to-go visualizations of your span data. RED metrics represent:

Rate, the number of requests per second
Errors, the number of those requests that are failing
Duration, the amount of time those requests take

For more information about RED method, refer to The RED Method: how to instrument your services.

To enable metrics-generator in Grafana Cloud, refer to Enable metrics-generator.

To enable metrics-generator for Tempo, refer to Configure metrics-generator.

These metrics exist in your Hosted Metrics instance and can also be easily used to generate powerful custom dashboards.

Metrics automatically generate exemplars as well which allows easy metrics to trace linking.

Service graph view

Service graph view displays a table of request rate, error rate, and duration metrics (RED) calculated from your incoming spans. It also includes a node graph view built from your spans.

To use the service graph view, you need to enable service graphs and span metrics. After it’s enabled, this pre-configured view is immediately available in Explore > Service Graphs.

Refer to the service graph view documentation for further information.

Integrate other telemetry signals

Link traces and logs

If you’re already doing request/response logging with trace IDs, they can be easily extracted from logs to jump directly to your traces.

In the other direction, you can configure Grafana and Grafana Cloud to create a link from an individual span to your Loki logs. If you see a long-running span or a span with errors, you can immediately jump to the logs of the process causing the error.

Note
Cloud Traces only supports custom tags added by Grafana Support. Cloud Traces supports these default tags: cluster, hostname, namespace, and pod. Contact Support to add a custom tag.

Link traces and metrics

Grafana can correlate different signals by adding the functionality to link between traces and metrics. Trace to metrics lets you navigate from a trace span to a selected data source. Using trace to metrics, you can quickly see trends or aggregated data related to each span.

For example, you can use span attributes to metric labels by using the $__tags keyword to convert span attributes to metrics labels.

To set up Trace to metrics for your data source, refer to Trace to metric configuration.

Link traces and profiles

Using Trace to profiles, you can correlate different signals by adding the functionality to link between traces and profiles.

Trace to profiles lets you link your Grafana Pyroscope data source to tracing data in Grafana or Grafana Cloud. When configured, this connection lets you run queries from a trace span into the profile data.

For more information, refer to the Traces to profiles documentation and the Grafana Pyroscope data source documentation.

For Cloud Traces, Refer to the Traces to profiles documentation for configuration instructions.

Query tracing data

Fri, 03 Apr 2026 19:43:06 +0000

Query tracing data

The Tempo data source’s query editor helps you query and display traces from Tempo in Explore. The queries use TraceQL, the query language designed specifically for tracing.

For general documentation on querying data sources in Grafana, refer to Query and transform data.

Tip
Don’t know TraceQL? Try Grafana Traces Drilldown, an intuitive, queryless app that lets you explore your tracing data using RED metrics.

Before you begin

You can compose TraceQL queries in Grafana and Grafana Cloud using Explore and a Tempo data source.

TraceQL knowledge helpful, but not required

You don’t have to know TraceQL to create a query. You can use the Search query builder’s user interface to select options to search your data. These selections generate a TraceQL query. Any query generated using Search query builder can be transferred to the TraceQL query editor, where you can edit the query directly.

To learn more about how to query by TraceQL, refer to the TraceQL documentation.

Choose a query editing mode

The query editor has three Query types that you can use to explore your tracing data. You can use these modes by themselves or in combination to create building blocks to generate custom queries. Adding another query adds a new query block. Refer to Use query types together for more information.

The three query types are:

Search query builder - Provides a user interface for building a TraceQL query.
TraceQL query editor - Lets you write your own TraceQL query with assistance from autocomplete.
Service Graph view - Displays a visual relationship between services. Refer to the Service graph documentation for more information.

Search query builder

The Search query builder provides drop-down lists and text fields to help you write a query. The query builder is ideal for people who aren’t familiar with or want to learn TraceQL.

Refer to the Search using the TraceQL query builder documentation to learn more about creating queries using convenient drop-down menus.

TraceQL query editor

The TraceQL query editor lets you search by trace ID and write TraceQL queries using autocomplete.

Refer to the TraceQL query editor documentation to learn more about constructing queries using a code-editor-like experience.

You can also search for a trace ID by entering it into the query field.

Service graph view

The Service Graph view uses metrics to display span request rates, error rates, and durations, as well as service graphs. After the requirements are set up, this preconfigured view is immediately available.

Using the service graph view, you can:

Discover spans which are consistently erroring and the rates at which they occur.
Get an overview of the overall rate of span calls throughout your services.
Determine how long the slowest queries in your service take to complete.
Examine all traces that contain spans of particular interest based on rate, error, and duration values (RED signals).

For more information about the service graph, refer to Service graph.

Use TraceQL panels in dashboards

To add TraceQL panels to your dashboard, refer to the Traces panel documentation.

To learn more about Grafana dashboards, refer to the Use dashboards documentation.

Set options for query builder and editor

The following options are available for the Search and TraceQL query types. You can modify these settings in the Options section.

After changing any option, re-run the query to apply the updates.

Limit: Determines the maximum number of traces to return. Default value is 20.
Span Limit: Sets the maximum number of spans to return for each spanset. Default value is 3.
Table Format: Determines whether the query results table is displayed focused on Traces or Spans. Traces is the default selection. When Traces is selected, the results table starts with the trace ID. When Spans is selected, the table starts with the trace service.
Step: Defines the step for metrics queries. Use duration notation, for example, 30ms or 1m.
Streaming: Indicates if streaming is active. Streaming lets you view partial query results before the entire query completes. Activating streaming adds the Table - Streaming Progress section to the query results.

Use query types together

You can use + Add query to create customized queries that use one or more of the query types together. Each time you add a new query, it adds a new section, or query block, that contains Search, TraceQL, or Service Graph user interface.

The added query and results table appear in the navigation under Queries and Tables respectively. You can use the navigation to view query, results table, and service graph blocks.

Navigating through the query blocks

To add a query block:

Select + Add query.
Choose a query type: Search, TraceQL, or Service Graph.

To remove a query block, select the Remove query trash can icon.

To rename a block, select the Rename edit icon next to the query block name. The name changes in the queries and table list.

Additional query block options

Each query block has a set of icons in the right top corner.

These icons include:

Show data source help: Displays the Tempo Cheat Sheet with links to documentation.
Create recorded query: Lets you save the current query block as a recorded query. This option is available in Grafana Cloud and Grafana Enterprise. For more information, refer to Recorded queries.
Duplicate query: Copies the current block and adds a new identical block.
Remove query: Deletes the query block.

Use query history and query inspector

Explore provides a history of all queries you’ve used within a data source and an inspector that lets you view stats, inspect queries, view JSON, and general information for your data source queries.

For more information, refer to the Query inspector in Explore and Query management in Explore documentation.

Cross-tenant TraceQL queries

If you’ve configured a multi-stack Tempo data source, you can perform TraceQL queries across those stacks and tenants.

Queries performed using the cross-tenant configured data source, in either Explore or inside of dashboards, are performed across all the tenants that you specified in the X-Scope-OrgID header.

TraceQL queries that compare multiple spansets may not correctly return all traces in a cross-tenant query. For instance,

{ span.attr1 = "bar" } && { span.attr2 = "foo" }

TraceQL evaluates a contiguously stored trace. If these two conditions are satisfied in separate tenants, then Tempo doesn’t return the trace.

Refer to Set up a multi-stack Tempo data source in Grafana for information about configuring the Tempo data source.

For information about Tempo configuration requirements, refer to the Cross-tenant query and Enable multitenancy documentation.

Service Graph and Service Graph view

Fri, 03 Apr 2026 19:43:06 +0000

Service Graph and Service Graph view

The Service Graph is a visual representation of the relationships between services. Each node on the graph represents a service such as an API or database.

You use the Service Graph to detect performance issues; track increases in error, fault, or throttle rates in services; and investigate root causes by viewing corresponding traces.

Display the Service Graph

Configure Grafana Alloy or Tempo or GET to generate Service Graph data.
Link a Prometheus data source in the Tempo data source’s Service Graph settings.
Navigate to Explore.
Select the Tempo data source.
Select the Service Graph query type.
Run the query.
(Optional) Filter by service name.

For details, refer to Node Graph panel.

Each circle in the graph represents a service. To open a context menu with additional links for quick navigation to other relevant information, click a service.

Numbers inside the circles indicate the average time per request and requests per second.

Each circle’s color represents the percentage of requests in each state:

Color	State
Green	Success
Red	Fault
Yellow	Errors
Purple	Throttled responses

Open the Service Graph view

Service graph view displays a table of request rate, error rate, and duration metrics (RED) calculated from your incoming spans. It also includes a node graph view built from your spans.

For details, refer to the Service Graph view documentation.

To open the Service Graph view:

Link a Prometheus data source in the Tempo data source settings.
Navigate to Explore.
Select the Tempo data source.
Select the Service Graph query type.
Run the query.
(Optional) Filter your results.

Note
Grafana uses the traces_spanmetrics_calls_total metric to display the name, rate, and error rate columns, and traces_spanmetrics_latency_bucket to display the duration column. These metrics must exist in your Prometheus data source.

To open a query in Prometheus with the span name of that row automatically set in the query, click a row in the rate, error rate, or duration columns.

To open a query in Tempo with the span name of that row automatically set in the query, click a row in the links column.

Span filters

Fri, 03 Apr 2026 19:43:06 +0000

Span filters

When working with traces, especially those comprising a vast number of spans, pinpointing specific spans of interest can be a daunting task. This is where span filtering comes in. Located above the trace view, span filters allow you to refine the spans displayed based on specific criteria. Whether you’re looking to identify spans from a certain service, those exceeding a particular duration, or spans tagged with specific attributes, span filtering streamlines the process.

Using span filters, you can filter your spans in the trace timeline viewer. The more filters you add, the more specific are the filtered spans.

You can add one or more of the following filters:

Service name
Span name
Duration
Tags (which include tags, process tags, and log fields)

Use span filters

You can access span filters from within the trace view. You can add one or more filters. The more filters you add, the more specific data that you are filtering.

Expand a trace to view individual spans.
Select a span to view the span details.
Select Span Filters to display the available filters.

Query results in the span view update as you select filters.

Show matches only

For a more focused view, the Show matches only toggle ensures only the spans meeting your criteria are displayed. This is particularly useful when sifting through thousands of spans, allowing you to zero in on those that truly matter. For instance, if you’re keen on understanding why a specific request is lagging, or if you’re on the hunt for spans without a certain tag, span filtering is your go-to tool. It even lets you search for spans based on specific tag keys, like cluster.

Remove a filter

To remove a filter, select the X next to the line item.